Warning: ini_get_all() has been disabled for security reasons

With my limited knowledge, I think that people should not leave the info.php file present on their site for security reasons, but I may be out of date on this?

When you’re done with the info.php file, rename it or delete if you like. I do actually check against my IP address and if it doesn’t match denies access. There are several plugins that will output the information like WordPress phpinfo() which seems to work well.

Note, my Shared Hosting at Surpass Hosting did not have this. My 4.6 version is working fine.

My site is hosted by https://www.fast2host.com/ (cPanel)

The good news overall is there are 7 people here with this problem, and we’ve processed over half a million updates so far: https://www.ads-software.com/download/counter/

Granted, that’s not good news for you folks here, but good news for anyone following a long at least. I’d like to encourage anyone here though to help out with testing next time: https://make.www.ads-software.com/core/handbook/testing/beta/

In particular, this would have been caught during even the first public beta released June 29 https://www.ads-software.com/news/2016/06/wordpress-4-6-beta-1/ if at least one person with this server configuration had participated in the testing. The volunteers who devote their time to developing WordPress just can’t possibly test every potential server configuration, that’s why we make the beta releases public starting at least a month out from the final release.

As for the issue at hand, personally I do recommend reaching out to your hosting provider. The security “benefit” of blocking ini_get_all is dubious at best, if not simply nonsense. All that does is fetch PHP’s current configuration options so WordPress knows what it’s dealing with. Why a host wouldn’t want a PHP process to know what it has to work with is kind of odd, nothing malicious can be done with that information (unless that information reveals that a *real* security vulnerability on the server was never patched). It’s kind of like encasing your entire home in concrete because your door won’t lock anymore. Sure, that will keep the bad people out, but the better solution would be to fix the lock.

Anyway, I’m not denying that you’re in a bad situation right now, and that having to either revert a backup or mess around with your own PHP configuration isn’t the best of times. I’m just pointing out that really the server should have never been configured that way in the first place. For what it’s worth, we have some recommended hosting providers at https://www.ads-software.com/hosting/ if they still refuse.

Beyond that, some great advice has already been posted here suggesting ways you might be able to fix this yourself without even bothering your hosting provider.

Just been Googling (to preempt possible hosting company objections to enabling the function)… Looks like it was possibly disabled due to a vulnerability in php 5.3. I’m guessing this vulnerability is now patched in current php version, but php.ini has not been updated accordingly.

https://support.servergrove.com/phpinfo-function-disabled-shared-hosting/

https://www.sektioneins.com/en/blog/14-07-04-phpinfo-infoleak.html

https://www.eukhost.com/blog/webhosting/dangerous-php-functions-must-be-disabled/

A possible workaround from the coding side…
https://www.verot.net/php_class_upload_forum.htm?lang=en-GB&php_class_upload_forum_id=3839&php_class_upload_forum_thread_id=3839&php_class_upload_forum_action=add

@james

Beyond that, some great advice has already been posted here suggesting ways you might be able to fix this yourself without even bothering your hosting provider.

Please restate the ways to fix this without bothering hosting provider – I for one don’t have access to php.ini and others have written that editing wp_debug does not resolve it.

“if at least one person with this server configuration had participated in the testing”

Pissy much? Nobody is required to be your personal bug tester.

Please restate the ways to fix this without bothering hosting provider – I for one don’t have access to php.ini and others have written that editing wp_debug does not resolve it.

Modifying php.ini is specifically what I was referring to. Most hosts allow this, or an equivalent called phprc .

If you can’t modify either of those, then you will need to bother your hosting provider.

Pissy much? Nobody is required to be your personal bug tester.

Not being pissy, just stating a fact. WordPress is offered for free and entirely developed and supported by volunteers, so the more people we can get to help with beta testing, the better off everyone will be; developers and users alike.

@james: Thanks. I’ll see what my hosting provider responds with tomorrow.

You’re welcome!

Hi James Huff

Thanks for the info. I have full access to root via my WHM and I could not get the setting to change myself.

I had EUKhost support fix it for me.

I was not complaining, I was just stating that if we all went off and did temporary fixes it did not resolve the issue in the long term. I have in the past done “self Fixes” via php or htacces which worked for me but at the end of the day It just made things worse for future updates.

When you receive this error if you have the SELECT in PHP hosting package you have received if, that will be enough to upgrade to PHP version 5.5, you can set your PHP Edition.

php error will be corrected when you upgrade to version 5.5.

Have Fun!

I was not complaining, I was just stating that if we all went off and did temporary fixes it did not resolve the issue in the long term.

What I meant was, no longer blocking ini_get_all isn’t really a temporary fix, it should have never been blocked in the first place. In a sense, unblocking it *is* the permanent fix.

There was a time under PHP 5.3 where a vulnerability was discovered, but that vulnerability was fixed properly many years ago. Any host that would rather just outright block ini_get_all (an actually useful, and purely informative, call) either doesn’t know that it has been safe for many years or has never bothered to fix the actual problem.

php error will be corrected when you upgrade to version 5.5.

Thanks for the tip!

And while you’re there, if you see PHP 5.6 offered, go for it! PHP 5.6 is the current recommended version: https://www.ads-software.com/about/requirements/

@james Huff
You’re right! PHP 5.6 it’s preferred and recommended by WordPress.

Hi guys.

At least we are now eight persons. I have the same problem, I seriously regret for doing the update.

I’m looking for a solution too.

I’m trying to understand the error, but after three hours and a headache, no results.

Thank you for all your efforts!

If you’re unfamiliar with working in php.ini or phprc (the files which control your PHP configuration), I recommend seeing if you have the ability to easily upgrade your version of PHP in your hosting account’s control panel to a higher version (preferably 5.6.x, though 7.0.x should be fine too).

If that is not an option for you, then I recommend contacting your hosting provider with something like:

Please enable ini_get_all() in my PHP configuration. This useful and purely informative call has not been a security risk for years (assuming the real security fix was properly applied to my server when it was released years ago). This perfectly safe call is used by WordPress 4.6 and, due to it being blocked in my PHP configuration, my site is now broken.

We have already discussed this issue with WordPress at https://www.ads-software.com/support/topic/warning-ini_get_all-has-been-disabled-for-security-reasons

I had the same problem with one of the sites we manage.

I upgraded their PHP version to 5.6 and the error has now been fixed.

Thanks to everyone who posted here.