Red Hat Bugzilla – Bug 121146
"unknown filter was not added: PHP" error after upgrade from RH9
Last modified: 2007-11-30 17:10:40 EST
From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4.1) Gecko/20031114 Description of problem: After what seemed to be a good upgrade from RH9 updated to Fedora Core 1 regardless of update level, PHP scripts stopped working altogether (although PHP scripts from the command line worked as expected). Pouring over the documentation for configuration errors was fruitless, no core dump is produced. If it was due to a package compile error, i'm surprised that no one else has seen this problem. I have 3 Fedora systems and the problem exists on all 3. Version-Release number of selected component (if applicable): httpd-2.0.47-10 or httpd-2.0.48-1.2; php-4.3.4-1.1 How reproducible: Always Steps to Reproduce: 1. set up a web page to href to a php script as always 2. use any legit php script for testing, a Hello World one will do 3. use any browser to attempt to see results of php script Actual Results: You will see the browser ask you to save or send unknown mime type application/php4script, meaning that php did not operate as a filter. Expected Results: I would have expected the reasonable output of whatever php script executed. Additional info: A sample of my /var/log/httpd/error_log file: [Sat Apr 17 21:13:32 2004] [notice] Apache/2.0.47 (Fedora) configured -- resuming normal operations [Sat Apr 17 21:14:00 2004] [error] an unknown filter was not added: PHP [Sat Apr 17 21:14:00 2004] [error] an unknown filter was not added: PHP the last message was in fact duplicated in the log file, and reflects my attempts to access the PHP script. Setting error output in php.ini didn't seem to help at this point. If it matters, the PHP application I was trying to use (and was using fine before) is TWIG 2.7.7 from http://www.informationgateway.org
Check that /etc/httpd/conf.d/php.conf contains the line: AddType application/x-httpd-php .php if you've got an "AddType application/php4script .php" in httpd.conf that is the problem. Otherwise, please attach both the conf.d/php.conf and httpd.conf.
Created attachment 99517 [details] My current /etc/httpd/conf/httpd.conf
Created attachment 99518 [details] My current /etc/httpd/conf.d/php.conf
That is a modified php.conf from RHL9: it should have been overwritten by the new FC1 php.conf, and the old renamed to php.conf.rpmsave, but hasn't been for some reason. Do you have an /etc/httpd/conf.d/php.conf.rpmnew file? How did you upgrade, from CD? Regardless, you should replace those <Files *.php> with AddType application/x-httpd-php .php and similarly for .php3 etc.
At your first response, I did notice that the "AddType application/x-httpd-php .php" was indeed missing, so I added it into php.conf. Now, I get the plain text exact copy of my php script in my browser (Mozilla)! See for yourself at http://bmdrake.dyndns.org/twig I suspect that the problem is installation/upgrade related, since the error_log shows that PHP is an unknown filter.
Created attachment 99519 [details] My current /etc/httpd/conf.d/php.conf Updated to add AddTypes as suggested.
You need to remove the <Files *.php> sections entirely from php.conf.
Created attachment 99520 [details] Functional /etc/httpd/conf.d/php.conf This version corrected the problem. I suppose that the problem was really in the lack of a new php.conf.rpmnew to look at since mine was tweaked. Thank you for your rapid and effective assistance!
OK. You never answered the question: how did you upgrade, from CD? The lack of a /etc/httpd/conf.d/php.conf.rpmnew file implies something went wrong during the upgrade.
Yes, I used downloaded .iso files to make CDs, booted them and went from there, using automatic settings for the upgrade. Come to think of it, something didn't go exactly right on any of the 3 upgrades I did. None of them were identical, but the most frequent difficulty was observing that certain packages didn't seem like they upgraded at all. I only recall that on the last one I did, up2date didn't upgrade, so I did it manually. I thought it odd, but I didn't have the time at that point to deal with it via reporting. I made the assumption that I couldn't be the only one upgrading systems from RH9 and that systematic errors would show up for about everyone. I'll be more dilligent about recording observations and reporting them in the future. Checking the upgrade.log, I see where php.conf was saved as php.conf.rpmsave, but given that I ran into the problem right away, and I don't see the file there now, there must have been something amiss. I did get in there and tried to adjust the php.conf file, recognizing it as the one I had before, to no avail. I hit the Apache web site, and that's how I ended up with the one I posted here to see. Now that I know what I know, I looked just now and the upgrade went well on another system I have, but the php apps I have weren't installed there, so the issue was not seen. I hope something here helps you. Let me know if there is something I can do to help further.
This is just a case where some manual config file tweaks are needed after an upgrade, it's not really possible to solve cleanly, unfortunately.