Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations strongm on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

Cannot load application

Status
Not open for further replies.

waydown

Programmer
Apr 27, 2009
49
GB
Hi,
I'm trying to load an application on unix server but when it does system check I keep on getting following error message and application will not load.
Code:
Your PHP Version is 5.6.22, but always_populate_raw_post_data = 0. $HTTP_RAW_POST_DATA is deprecated from PHP 5.6 onwards and will be removed in PHP 7.0. This will stop the installer from running. Please open your php.ini file and set always_populate_raw_post_data to -1. If you need more help please call your hosting provider.
As suggested by my hosting provider I've created php.ini file and put
Code:
always_populate_raw_post_data = -1
into file and placed in public_html folder. But it is not solving problem. Any suggestion as to what I should do to solve problem? I'm completely new to all this. All help will be greatly appreciated.
 
You don't create a new php.ini file, you edit the existing one. There always is a php.ini already in place, that's read and applied as default configuration for every ne php process.

Putting a new file somewhere doesn't help at all, as php is only reading in the php.ini right aside to itself.

run this and see where your php.ini is to be found, besides lots of other information about your php installation and settings:

PHP:
<?php phpinfo(); ?>

To limit the infoprmation somewhat (still including the php.ini path):

PHP:
<?php phpinfo(INFO_GENERAL); ?>

Bye, Olaf.
 
OlafDoschke said:
There always is a php.ini already in place

True, but some hosting providers offer the ability to use alternate ini files at the user level that may augment or override options set in the system's main ini file.

Verify the host's direction. Are you sure they didn't mean you to place it above the public_html folder?
 
>Verify the host's direction
Yes, good hint, if there is an override/additional ini evaluated, it surely must go in a place specified by the hoster.

You may simply test, whether that additional ini is used and its configuration becomes active, when again doing phpinfo, or use ini_get to get any specific ini setting.

Bye, Olaf.
 
Hi,
Many thanks for your replies. I've done as you suggested. I get following info:
Code:
Configuration File (php.ini) Path 	/opt/alt/php56/etc
Loaded Configuration File 	/home/some9753/public_html/php.ini
Scan this dir for additional .ini files 	/opt/alt/php56/link/conf
Additional .ini files parsed 	/opt/alt/php56/link/conf/alt_php.ini
I can't see the directories /opt/alt/php56/etc from cpanel so I wouldn't know what to do.
Apart from above, in the php info file under "Core" always_populate_raw_post_data is set to -1 for Local Value as well as Master Value. So I don't know how the installer is coming up with always_populate_raw_post_data = 0??? Please help.
 
I don't know what you mean with "Core", but as Loaded Configuration File seems to be in your own public_html root, do you have always_populate_raw_post_data = -1 in there? Also, did you look there is no line where this is set =0 later?

And do I get it correctly, /opt/alt/php56/etc is the main inin under the hoster control only? then the additional ini also only is under his control in /opt/alt/php56/link/conf/alt_php.ini. If that's the case your own ini already is third level. Any of the hosters ini have to be done to import your own ini, this isn't done automatically, but /home/some9753/public_html/php.ini sounds like your own home folder and public_html is the web root. You may test so by just outputting a script location of a php script you provide:

PHP:
<?php echo __FILE__; ?>
This weay you know what your location is in the Linux file sysstem of the server.

If you have it as -1 and you do any php script just using ini_get, is that -1 at that moment? Because thats also what any install.php you put there will see, simply use ini_get as said:

PHP:
<?php echo 'always_populate_raw_post_data= ' . ini_get('always_populate_raw_post_data'); ?>

Is that giving you -1?

Bye, Olaf.
 
Hi, When I run <?php phpinfo(); ?> php info file appears and there is a section labelled "Core" where I see
Configuration File (php.ini) Path /opt/alt/php56/etc
Loaded Configuration File ........

In Loaded Configuration File always_populate_raw_post_data = -1. I've put the file firstly in public_html and secondly in the topmost file I have access to /home2/some9753, neither have made any difference. I CANNOT see any point where always_populate_raw_post_data = 0

/opt/alt/php56/etc and /opt/alt/php56/link/conf/alt_php.ini are under control of host, I've no access to them. As you said my php.ini is third level.

When I run script <?php echo __FILE__; ?> I get: /home/some9753/public_html/index.php

When I run <?php echo 'always_populate_raw_post_data= ' . ini_get('always_populate_raw_post_data'); ?> I get:
always_populate_raw_post_data= -1
 
__FILE__ being in /home/some9753/public_html/ and Loaded Configuration File being /home/some9753/public_html/php.ini makes it very good news, you have your own ini, also ini_get('always_populate_raw_post_data') returning -1 is nice. I'm a bit out of ideas. When you run your/my php script and it sees -1 as the setting, it's really a puzzle how a setup/install script of some application sees 0.

Have you looked sources, how it determines the always_populate_raw_post_data? Maybe it reads and parses one of the other ini files and doesn't look at the ini_get setting currently in effect? For now all looks like an error on that apps setup/installation. Or there are additional ini files/settings this app is doing, so make a full text search in that apps php files for ini_set and of course always_populate_raw_post_data.

Bye, Olaf.

 
This error message means that you should STOP using $HTTP_RAW_POST_DATA because it is deprecated.

Your PHP Version is 5.6.22, but always_populate_raw_post_data = 0. $HTTP_RAW_POST_DATA is deprecated from PHP 5.6 onwards and will be removed in PHP 7.0. This will stop the installer from running. Please open your php.ini file and set always_populate_raw_post_data to -1. If you need more help please call your hosting provider.

And if you want to stop the error appearing while you fix the problem turn OFF deprecated code error warnings in PHP.ini




Chris.

Indifference will be the downfall of mankind, but who cares?
Time flies like an arrow, however, fruit flies like a banana.

Never mind these jesus character, stars had to die for me to live.
 
Chris, the part of the error message "This will stop the installer from running." is not coming from a PHP deprecation message. The installer really sees a different setting of always_populate_raw_post_data = 0, while it is set -1, so either you use the installer wrongly somehow or it does weird things instead of using ini_get to determine this wrong value and refusing to continue. I don't even think it's worth a try other than to let you see it will still not make the installer continue.

Bye, Olaf.

 
One more thing you could try is making a .htaccess file in the installers directory and in it put
Code:
php_value always_populate_raw_post_data -1

It requires your hoster to have set AllowOverride Options or AllowOverride All. But if the install script is not using ini_get to determine the settings state I fear this also won't help.

Bye, Olaf.
 
the part of the error message "This will stop the installer from running." is not coming from a PHP deprecation message

How do you know that?

The 'application' has not been mentioned as yet, so there is no way you can have empirically verified that 'fact'. Plus, so far none of the 'guesses' have provided an effective solution, so maybe it is time some one asked the "What are you trying to install"? question, then the guesses might become 'educated' ones.

Chris.

Indifference will be the downfall of mankind, but who cares?
Time flies like an arrow, however, fruit flies like a banana.

Never mind these jesus character, stars had to die for me to live.
 
Tell me any PHP deprecation message talking about some "Installer".

Bye, Olaf.
 
WordPress has an 'installer', Joomla! has an 'installer' and patently the application the OP is using has an installer!
Plus there is Softaculous, Scriptaculous, [other 'one click installers' are available] cPanel's "Site Software" feature, Plesk has a site scripts installer. Not everybody is a 'shell' user or knows how to install over FTP and create a database and associated tables using phpMyAdmin or similar.

But of course I haven't tried every PHP application available to be absolutely confident that no such thing exists. And given that the 'application' is still unknown no one yet knows HOW this aforementioned application sets up it's environment OR what it checks for in that environment.

Patently it does test for $HTTP_RAW_POST_DATA being available, otherwise the 'error' would NOT be raised during the process, and this thread would be entirely non-existent.



Chris.

Indifference will be the downfall of mankind, but who cares?
Time flies like an arrow, however, fruit flies like a banana.

Never mind these jesus character, stars had to die for me to live.
 
Yes, all those have an installer, and their setup error messages are not coming from PHP native errors and deprecation warnings, they themselves know about deprecations and check settings before they continue to install. You install them by uploading them and starting a setup.php or install.php. And somewhere in there you'd find the test on the always_populate_raw_post_data and that must be done in a way not getting the real curtrent setting, so the installer stops prematurely and with wrong information. But as any php script running will see the same always_populate_raw_post_data as the simple script I gave using ini_get, the installer must do something else, perhaps something weird, perhaps deducting the always_populate_raw_post_data=0 setting in a way not correct, reading the server side ini /opt/alt/php56/etc, like phpinfo that info can be retrieved and that ini can be parsed. That's then not considering there could be further inis loaded and overriding the values given in the central ini. An installer should always simply use ini_get to test whether certain settings are as needed or not, but installer doesn't seem to do so.

Bye, Olaf.
 
are not coming from PHP native errors and deprecation warnings,
They might, if the code was not written to to handle such errors. You seem to be assuming that all programmers of PHP script 'installers' are almost infallible and have tested every single possible condition of that particular installation on every possible environment.

If their development environment was on a PHP version BEFORE $HTTP_RAW_POST_DATA (v5.6.0) was deprecated the error message would not be raised. Whether you think that a deprecation error message should NOT cause a failure condition is utterly immaterial. Based on the evidence so far presented IT is happening in this particular application, so your assertion that it shouldn't happen is wrong. The first principle of the "scientific method" as explained by Richard Feynman.

Guess -> Theorise and predict -> Test and observe, but if the observation does not match your predictions, ... Your theory is wrong.


Chris.

Indifference will be the downfall of mankind, but who cares?
Time flies like an arrow, however, fruit flies like a banana.

Never mind these jesus character, stars had to die for me to live.
 
And yes of course I may be wrong in my hypothesis, and I am not asserting that I must be right, I need more evidence, and something I can test for myself.



Chris.

Indifference will be the downfall of mankind, but who cares?
Time flies like an arrow, however, fruit flies like a banana.

Never mind these jesus character, stars had to die for me to live.
 
>if the code was not written to to handle such errors.
But it was in this case: Why should PHP say it stops here with installing. Alone the message part "This will stop the installer from running. Please open your php.ini file and set always_populate_raw_post_data to -1." tells yet and you stil refuse to accept this must come from the installer code and not from PHP, PHP has no idea that what runs and reads a always_populate_raw_post_data is an installer, only an installer has that intenal knowledge. It's sufficient evidence for me. No normal PHP error message tells things like "This will stop the installer from running".

I think waydown already either gave up or solved the issue.
Anyway, there is no point for me in continuing the discussion just with you, so let's stop the discussion here at this point.

Bye, Olaf.
 
so let's stop the discussion here at this point.
Why? It's only just getting interesting

OlafDoschke said:
ChrisHirst said:
f the code was not written to to handle such errors.
But it was in this case:
How do you know it was?

PHP has no idea that what runs and reads a always_populate_raw_post_data is an installer, only an installer has that intenal knowledge.
Absolutely and utterly incorrect.

The PHP core provides the 'deprecated function' warning message, NOT the installer.
If I code a script that sets up the necessary environment for itself or for additional scripts and it tests if certain conditions or functions are extant, I as the developer writing this script in say 2006, have no idea what functions MAY OR WILL be deprecated or removed at some future time that will inhibit the operation of the application or reduce it's efficacy. So one would generally 'echo' the response from the interpreter to the user IF the return signal was NOT what was expected, if this installer script is written when PHP 4.3 (2002-2005) or 4.4 (2005-2008) was the current release, I, as the developer do NOT have the foreknowledge that in version 5.6 the function I am testing for will be deprecated and I certainly would not know that in TEN YEARS time it will be removed from ver 7.0 (2015-2018), only the core language interpreter of later versions will have that information.

and you stil refuse to accept this must come from the installer code

On the contrary, I am fully aware that the message is initiated by the installer, but I understand the words are not coming from the 'installer', the installer is merely the catalyst for the warning not the root cause.


Chris.

Indifference will be the downfall of mankind, but who cares?
Time flies like an arrow, however, fruit flies like a banana.

Never mind this jesus character, stars had to die for me to live.
 
Wow, how can a single person be so blind. What can I say to make you see? How near do you need to be steered to the words to understand them?

myself said:
PHP has no idea that what runs and reads a always_populate_raw_post_data is an installer, only an installer has that intenal knowledge.
Chris said:
Absolutely and utterly incorrect.[/quote

PHP simply runs what's give to it as code, it "knows" the script name, it "knows" the code, it runs it, but it has no awareness what the code it runs means and what it belongs to, whether it is an installer, the installed app, a virus, anything. It is ignorant about that.

Again, the message says "This will stop the installer from running.". PHP can't know it runs an installer, there is no convention or standard telling PHP it runs an installer and so this message is coming from the installer itself, in my simply deduction. The only unusual thing about it is, this message means the installer is talking about itself in third person, or more precise, the developer decided for such a third person message to the end user running the installer.

The message continues: "Please open your php.ini file and set always_populate_raw_post_data to -1. If you need more help please call your hosting provider."
This is for sure a decision the installer does, it doesn't crash on the false setting, lets PHP werite out its error/warning and let it dies, it puts this message to the user and decides not to continue. I dare to say this is no assumption. This is described as happening, it happens, it doesn't come from PHP itself.

The main point is that PPH may talk about deprecation of settings by default, yes, but it wouldn't take the word "installer". I now deprecation messages, and they are not that way, they also don't tell what to do and to ask help from the hoster, this is all pointing to being a warning message from the installer itself after checking its own prerequisites. And that's normal for installers, that's not what PHP itself puts out to end users. I'd like to point you to a list of all php error messages, but I don't find one. I know enough of them and have enough PHP experience over about 20 years to say I never read any including the word installer, as simple as that.

Bye, Olaf.
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top