Media Temple VE - Ubuntu server - Support for C5 Request URLs failure on install

Permalink
I am at a loss as to what to try next. I have a concrete install running just fine on my work's dev server but when I tried to put one on a Media Temple VE server that I installed Ubuntu on I am getting the "concrete5 cannot parse the PATH_INFO or ORIG_PATH_INFO information provided by your server" error.

I tried the cgi.fix_path = 1 edit in my php.ini but no change.

Here is my phpinfo -http://andersontranslationservice.com/test.php... and attached is the server's conf from /etc/apache2/apache2.conf

Does anyone have a couple minutes to look at my setup? I have to move a client from my work dev env to a Media Temple VE in two days and I was assuming it would be a no brainer but now I am looking at reinstalling a different OS on the VE or something else...

1 Attachment

 
Ward replied on at Permalink Reply
Anybody?
Ward replied on at Permalink Reply
Solution: Downgrade from Ubuntu 11 natty narwhal to the previous LTS long term support release which is Ubuntu 8 hardy heron and then it just worked.
ThomasJ replied on at Permalink Reply
ThomasJ
This is the description of my problem also. I am running the Very Generic LAMP model on my laptop with Ubuntu 11.04, the latest Lt version that was released. the responder that advises us to move backward to a 4 year old version of Ubuntu with an obsolete kernel has given insight to even more avenues of researching this problem if in fact he knows that the latest stable version of concrete5 does install in Ubuntu 8.xx without this error. I have a feeling that it might be more prone that the old version of the php engine that runs in that Ubuntu version might be closer to the problem.

While I have been using php for many years now, I still regard myself as a novice at it. I have not encountered this error before and have no knowledge as to what prompted this error, I have been researching it for the past couple of days.

There are 2 Server Super-globals mentioned in the error message, PATH_INFO and ORIG_PATH_INFO. These Constants are generated by the server. However, Apache2's default is if the page to be served is passed to a handler such as php then that Handler will create the Super-Globals. So, it seems that php itself will generate the Server Super-Globals from the path that is passed to the php script. The actual URL that is specified in the header ends at the actual php script and the trailing file path that comes after the php script becomes the information passed to that Handler. The specification for $_SERVER[PATH_INFO] should contain a path passed to it minus any query string that is attached to it. $_SERVER[ORIG_PATH_INFO] should be the original path passed before any php processing. I am using a test script to see what php is doing with these 2 Constants. (script shown below) In my install, PATH_INFO comes back as the proper path passed to it. ORIG_PATH_INFO comes back NULL. I am still not sure of what I should expect in ORIG_PATH_INFO. If they are just looking for the Path info being set, it shouldn't be returning an error. I hope that they aren't using $HTTP_SERVER_VARS to get PATH_INFO. That has been deprecated and doesn't work in php5.

Anyway, that is my verbose explanation as to what is going on with me on research of the same problem that a lot of people seem to be having. I hope that this description of my efforts can be of help to you and Maybe if you find the cause, you could post the fix back here.

This problem has been expressed by many, many individuals for many years. And, reading these threads, it looks like there are many different probable causes. I think that there is enough history with this same error message that a posting with a detailed description of the many possible origins of this error.

test.php:
<?php
echo "PATH_INFO = [".$_SERVER['PATH_INFO']."]<br>\n";
echo "ORIG_PATH_INFO = [".$_SERVER['ORIG_PATH_INFO']."]<br>\n";

$path_parts = pathinfo('./test/test.php');

echo $path_parts['dirname'], "<br>\n";
echo $path_parts['basename'], "<br>\n";
echo $path_parts['extension'], "<br>\n";
echo $path_parts['filename'], "<br>\n";
?>
Ward replied on at Permalink Reply
I have since noticed that Ubuntu 10.04 Lucid Lynx is available on Media Temple's VE plan and that release is a LTS as well. I switched the OS to 10.04 and found concrete worked there as well. So, as of now, I have done two installs of 11.04 with C5 support url failure, two installs of 8.04 with Concrete working correctly and one install with 10.04 with Concrete working correctly. All of these installs were on Media Temple.
ThomasJ replied on at Permalink Reply
ThomasJ
Ward;

That is helpful. There must be a change in the php engine between these two Ubuntu versions. From what I can conclude is that the php engine itself is the origin of these Constants. I will be focusing on this.

Reguards;
ThomasJ
Ward replied on at Permalink Reply
I am unsure if it is the php engine. There is a post in these forums where a poster points out the location of the function that is parsing the path_info. At the time I found that post I had two installs on different servers going - a broken install on 11.04 and a working install on 8.04. I put debugging lines in the function that was parsing path_info on both of these and found the same results being returned.

However, on the broken install I couldn't access a working page beyond the TLD so for each of these machines I was testing just example.com/
ThomasJ replied on at Permalink Reply
ThomasJ
More thread reading, I found where concrete5 uses putenv() to set the environment variables. If putenv() is disabled, it receives an error and this could be the source of the problem. I checked my server with the following script and it writes to the environment just fine.

<?php
print "env PATH_INFO = [".getenv(PATH_INFO)."] ORIG_PATH_INFO = [".getenv(ORIG_PATH_INFO)."]<br>\n";
print "(doing: putenv test, andtest)<br>\n";
putenv("PATH_INFO=test");
putenv("ORIG_PATH_INFO=andtest");
print "After change:<br>";
print "env PATH_INFO = [".getenv("PATH_INFO")."] ORIG_PATH_INFO = [".getenv("ORIG_PATH_INFO")."]<br>\n";
phpinfo(INFO_ENVIRONMENT);
?>

Result:
env PATH_INFO = [] ORIG_PATH_INFO = []
(doing: putenv test, andtest)
After change:
env PATH_INFO = [test] ORIG_PATH_INFO = [andtest]

I am beginning to think that the error flag on the install page is just an aberration that can be ignored. tomorrow, I am going ahead with the install in spite of the red dot flag.
ThomasJ replied on at Permalink Reply
ThomasJ
I have just completed a series of tests on php.ini. It took me a while because when I re-installed the php5 engine using Zend's release, It set it's php.ini file in it's own subdirectory but it left the /etc/php5/apache2/php.ini file in place. I spent a lot of time modifying the wrong file. Anyway, I confirmed which php.ini file that php was using by moving it out of the selected directory and php stopped working. That said, I turned off all error reporting and I still have a red error dot on the install page.

Now that I have confirmed that it is not a php reported error, I have to look elsewhere for the answer to this problem. Anyone have any Ideas? I really would like to try concrete5 but if I can't even get past the opening install page, I am forced to look elsewhere for my CMS solution.

regards,
ThomasJ
ThomasJ replied on at Permalink Reply
ThomasJ
While in IR chat, it was pointed out to me that I was trying to install c5 version 5.4.2 and he recommended that I install ver. 5.5. He was right. The newest version doesn't have this problem and it installed really slick.

I wish I could be posting a fix to installing the current stable release, But I guess that the fix for this version is to just install version 5.5.

Cheers,
thomasJ