Bug 121146 - "unknown filter was not added: PHP" error after upgrade from RH9
"unknown filter was not added: PHP" error after upgrade from RH9
Product: Fedora
Classification: Fedora
Component: httpd (Show other bugs)
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Joe Orton
Depends On:
  Show dependency treegraph
Reported: 2004-04-17 22:07 EDT by Bruce Drake
Modified: 2007-11-30 17:10 EST (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2005-01-13 05:25:49 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
My current /etc/httpd/conf/httpd.conf (36.26 KB, text/plain)
2004-04-18 16:16 EDT, Bruce Drake
no flags Details
My current /etc/httpd/conf.d/php.conf (738 bytes, text/plain)
2004-04-18 16:17 EDT, Bruce Drake
no flags Details
My current /etc/httpd/conf.d/php.conf (1.11 KB, text/plain)
2004-04-18 16:52 EDT, Bruce Drake
no flags Details
Functional /etc/httpd/conf.d/php.conf (1.14 KB, text/plain)
2004-04-18 17:02 EDT, Bruce Drake
no flags Details

  None (edit)
Description Bruce Drake 2004-04-17 22:07:01 EDT
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4.1)

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:

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
Comment 1 Joe Orton 2004-04-18 03:58:40 EDT
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.
Comment 2 Bruce Drake 2004-04-18 16:16:18 EDT
Created attachment 99517 [details]
My current /etc/httpd/conf/httpd.conf
Comment 3 Bruce Drake 2004-04-18 16:17:33 EDT
Created attachment 99518 [details]
My current /etc/httpd/conf.d/php.conf
Comment 4 Joe Orton 2004-04-18 16:26:52 EDT
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.
Comment 5 Bruce Drake 2004-04-18 16:28:18 EDT
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.
Comment 6 Bruce Drake 2004-04-18 16:52:45 EDT
Created attachment 99519 [details]
My current /etc/httpd/conf.d/php.conf

Updated to add AddTypes as suggested.
Comment 7 Joe Orton 2004-04-18 16:57:28 EDT
You need to remove the <Files *.php> sections entirely from php.conf.
Comment 8 Bruce Drake 2004-04-18 17:02:10 EDT
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!
Comment 9 Joe Orton 2004-04-18 17:34:37 EDT
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.
Comment 10 Bruce Drake 2004-04-20 17:20:46 EDT
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

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.
Comment 11 Joe Orton 2005-01-13 05:25:49 EST
This is just a case where some manual config file tweaks are needed
after an upgrade, it's not really possible to solve cleanly,

Note You need to log in before you can comment on or make changes to this bug.