@PhilETaylor shouldn't this be conditional, if php_ini_parse not exist then use FOF?

FOF does that check!

I know Travis is unhappy, will look at that in a moment, but this fix fixes the brokenness

Still, this will be faster (one less file, less memory for the good hosts):

		$isMoronHostFile = !function_exists('parse_ini_file');

		if ($isMoronHostFile)
		{
         		$strings = FOFUtilsIniParser::parse_ini_file($filename, true);
		}
		else
		{
			$strings = @parse_ini_file($filename);
		}

Should we really create another dependencey to FOF where we try to remove it at other places?

Unless you want to write your own pure PHP implementation of parse_ini_file quickly to resolve the issue...

FOFUtilsIniParser is nothing but a wrapper to parse_ini_file_php

There is no point in pulling parse_ini_file_php out into another file, and duplicating code in the core...

Using FOF certainly isn't right.

Well it works. If someone cares to lay out exactly what "fix" they would prefer to merge, it can be coded...

I was not involved with the breaking change, I was just fed up with 60+ comments of people saying "it doesnt work" in #15587 so I looked, and within seconds found a solution...

How you want that solution cemented into the core, well it appears anyway but the ways I chose..

@PhilETaylor

remove QQ replacement (apparently its not needed)

why do you think so?

parse_ini_file can do that: http://php.net/manual/en/function.parse-ini-file.php

Constants may also be parsed in the ini file so if you define a constant as an ini value before running parse_ini_file(), it will be integrated into the results.

But i can not find something like that for parse_ini_string: http://php.net/manual/en/function.parse-ini-string.php

I have not tested this yet but maybe you have..

why do you think so?

Cause "he said so" :-) #15620 (comment)

I can put it back?

As i have said i have not checked it yet and i have not saw that comment above. Needs to be tested.

Honestly, just revert #13407.

I think pretty much that is where I have got to :)

@Bakual i think the rest (array + renaming a var) can stay from that PR? Just that str_replace needs to be checked i guess.

@mbabker if we are removing the requirement for Joomla to have parse_ini_file enabled, then we can remove this check too ? https://github.com/joomla/joomla-cms/pull/15619/files

You absolutely can not remove the qq processing!!

Do not revert #13407

The only thing you need to do is basically if parse_ini_file is usable then use it otherwise use our old way which supports broken INI files

1. We need to stop allowing broken crap to work in our core APIs
2. The simplest option is to use the simplest function if available, since apparently hosts are 3 steps past moronic we can have a sensible fallback (i.e. the old code which has been proven to work with broken files)
3. The fact that this project is still so reluctant to accept valid third party solutions is really getting out of hand. We don't have the developers to write everything ourselves because we keep chasing everyone with half an ounce of skill away.

I have tested this item ✅ successfully on dc00875

For testers:
add
disable_functions = parse_ini_file
on your php.ini file
Stop and restart server.

Stop and restart server.

Or your php-fpm process, depending on how you are running PHP :)

Constants for parse_ini_string() are supported in php version 5.3.2.
I have checked it at https://3v4l.org/#preview

Constants are not supported in hhvm 3.19.1 and lower at all for both (parse_ini_file, parse_ini_string)

I tested with code:

echo phpversion() . "\n";
define('__QQ__', " WORKS ");
print_r(parse_ini_string('A="IT"__QQ__"GREATE!"'));
print_r(parse_ini_file(__DIR__ . '/test.ini'));

For hhvm I got:

5.6.99-hhvm
Array
(
    [A] => IT__QQ__GREATE!
)
Array
(
    [A] => IT__QQ__GREATE!
)

Does Joomla officially support HHVM ? (https://downloads.joomla.org/technical-requirements)

If you will add unittest for __QQ__ then you will have to:)

Afaik currently unit tests run on HHVM. But the CMS itself not necessary. To my knowledge we don't support it yet officially.

Can some test this so that we can get this in 3.7.1?

Can some test this so that we can get this in 3.7.1?

Please everyone test.

I have tested this item ✅ successfully on 30e69b3

I have tested this item ✅ successfully on 30e69b3

Patch ok for me

RTC after two successful tests.

Boy, did I also have a rough time with this update from 3.6.5 to 3.7.0. After the upgrade all the text in the admin panel as well as some text on the public pages were a mess. I also have a host/server that doesn't allow me to alter php.ini files. :(

I had to revert back my changes (glad I made a backup of the files/database). I hope you guys find a common ground for 3.7.1. I read all arguments and though it would be nice that some hosts would not do this, but as long this can be fixed using a bit of code, perhaps this is best for everyone.

This patch got merged and we hope that 3.7.1 will drop towards the end of next week with the fix for you in :)

Hi all, this issue is still existing with a fresh 3.7.2 installation. Shall I open a new issue?

Yes please

Fresh installation or a 3.7.3 upgrade still shows us that moronic hosting issue interferes Joomla and prevents Joomla from rocking. All Joomla loverz, let's unite and let Joomla rock!

You are all invited to the reopening of #17198