[4.0] Move the additional language strings in a separate file & fix postinstall

[zero-24]

Pull Request for Issue #18301 (comment)

Summary of Changes

Is there a reason why all the language strings are in the .sys.ini language file and not spread across two language files as normal

Thanks @brianteeman

• Fixing the postinstall behavior as this was broken before.

Testing Instructions

• install this branch https://github.com/zero-24/joomla-cms/archive/httpheader.zip
• Check the config page of the httpheader plugin and make sure all language strings are still loaded. -
• Check the postinstall message and make sure all language strings are still loaded too. (please make sure to disable the plugin inorder to trigger the postinstall message)

Expected result

two files & postinstall works also on new installs

Actual result

one file & postinstall is broken.

[infograf768]

The xml file has no manifest part for languages. I suggest to add them.

	<languages>
		<language tag="en-GB">en-GB.plg_system_httpheader.ini</language>
		<language tag="en-GB">en-GB.plg_system_httpheader.sys.ini</language>
	</languages>

[infograf768]

There are other things that can be done for customhttpheader.xml but it could be done in another PR;

1. windows eol should be modified to Unix
2. No use to utilize specific strings for Site and Administrator as we already have the global ones, JSITE and JADMINISTRATOR.
3. String PLG_SYSTEM_HTTPHEADER_ADDITIONAL_HEADER_CLIENT="Site selection" proposing Site, Administrator or Both, makes no sense. It should have "Client" as value.

[zero-24]

Thanks fixed.

[Quy]

Should this be 700?

[infograf768]

As far as I see 700 is a common id in postinstall table, 487 in the extensions table

[zero-24]

sorry it looks like i missed your messages :(

I have now choose a different way to solve this problem by renaming the core plugin it is not going to conflict with the 3.x version on a upgrade. So no need for that complete sql stuff.

[zero-24]

The Enable default security headers button does nothing.

can you please double check that? It should just enable the plugin currently there is no redirection implemented.

[Quy]

<ul> tag should not be inside a <p> tag.

[zero-24]

<p> - tag is removed now.

[Quy]

Still disabled. I expect the postinstall message to disappear after clicking the button if the plugin is to be enabled.

[zero-24]

Still disabled. I expect the postinstall message to disappear after clicking the button if the plugin is enabled.

Sure. hmm I'm going to debug this one. Maybe i'm also going to redirect the user to the edit page so they can configure the needed values in the plugin if they hit enable. Let's see what is the problem and how to fix it.

[zero-24]

I have just fixed the button. A redirect to the plugin edit page is not possible ;)

[brianteeman]

Yes it is - i did it in the recaptcha v1 pr #19648 or i misunderstand

[zero-24]

I'm going to review that proposal. Thanks!

[zero-24]

hmm look like this is working. My test before that resulted into a "you are not allowed to use this link directly" error. Now this is fixed. So commit is in coming. Thanks @brianteeman

[Quy]

The default headers are not set. A var dump of $this->params->get('xframeoptions') results in string(1) "1" which is not the same type as ===1.

		// X-Frame-Options
		if ($this->params->get('xframeoptions', 1) === 1)
		{
			$this->app->setHeader('X-Frame-Options', 'SAMEORIGIN');
		}

[zero-24]

Thanks should be fixed by the last commit.

[Quy]

I had to save the plugin initially before it would be in effect. 1 should be a string as follows:

get('xframeoptions', '1')

[Quy]

I am testing with your branch rather than via PatchTester. This is the error I get when doing a fresh install. I know it is unrelated to your PR, but how to fix it?
0 Could not create session directory "/var/lib/php/session"

[zero-24]

Hmm i have no idea how the session things works nowdays in 4.0 can your user write to that path?

[wilsonge]

Thanks Tobias :)

[zero-24]

🎉