I have just hit the same bug on my Linux system, running Apache 2.0.39.  The number of includes that work vary depending on what the included file contains.  I've had a file with 6 identical includes in, and nothing else.  With a simple 'echo "hello world";' file included, only the first one gets parsed.  With a more complex php file, each alternate instance gets parsed.
Any file that doesn't get parsed, just appears as the raw php code in the browser.
Hope this helps.  --Dave

Latests comments indicate that such bug is cross-platform.

Seems to be a similar problem here
(apache-2.0.40 & php-4.3dev latest from cvs)

Is anybody working on fixing that?

I assumed this to be a problem with Apache (mod_incude?), but according to http://nagoya.apache.org/bugzilla/show_bug.cgi?id=10041 the Apache people cast the blame on PHP.

So let me add that I too am experiencing this problem on Solaris 8 using PHP 4.2.1 with Apache 2.0.39.

updated version

This is a known bug in the apache2filter module for PHP.
It currently does not interact properly with other Apache
filters, and won't do so until we make some major changes.

Any idea of a rough time-scale for that Aaron (or anyone)?

This is a really annoying bug--is it going to be fixed soon?

If it's a known bug, status -> analyzed.  I have also been able to reproduce this problem

I have discovered this problem continues up to Apache 2.0.43 and PHP 4.3.0 (latest release 12/14/02) on my WinXP system. It seems as though several months have passed without resolution of this seemingly critical error. I too find this error to be extremely annoying and would appreciate hearing when the issue will be resolved.

Apache 2's filters are basically broken.  This is not going to be fixed anytime soon.  Nobody is working on it and I doubt anybody will until someone sits down and rewrites the Apache2 filter API from scratch.  Perhaps in Apache 2.2.

Yey! 

Why do you keep pushing things from side to an another ? Would it be just plain nice of both sides would work this thing out ? If you php guys know that the problem is somewhere in specific code, then why dont go to the a2 bugzilla and point out the real issue about this bug and/or otherway around ?

The Apache folks are well aware that the current filter code is a mess and needs a rewrite.  

I've reproduced this bug using Apache 2.0.43 and PHP 4.3.0 on RedHat Linux 7.3

I suggest that people start voting to get this bug fixed in Apache!
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=10041
and
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=15356

Now, back to Apache 1.3.27.... :(

reproduced with
apache 2.0.39 php 4.2.2 and php 4.3.0
apache 2.0.43 php 4.2.2 and php 4.3.0

linux kernel 2.4.19
gcc version 2.96 20000731 (Red Hat Linux 7.1 2.96-81)

if php is built as module, the rest of includes output php's code without interpretation

I have run accross this as well on IIS5 and Win2k so it isn't limited to just Apache. 

Going back to PHP 4.2.3 resolves the issue but 4.3.0 will only acknowledge the first include and then page halts loading when the second is encountered.

This bug has been fixed in CVS.

In case this was a PHP problem, snapshots of the sources are packaged
every three hours; this change will be in the next snapshot. You can
grab the snapshot at http://snaps.php.net/.
 
In case this was a documentation problem, the fix will show up soon at
http://www.php.net/manual/.

In case this was a PHP.net website problem, the change will show
up on the PHP.net site and on the mirror sites in short time.
 
Thank you for the report, and for helping us make PHP better.

When you say "This bug has been fixed in CVS" do you mean 4.3.x-dev or 5.0.x-dev?

Both.

RE: apache2 & php developers not working together.

I agree.
infact 2 apache2 developers spent a couple of hours and created a new php/apache2 sapi interface, and It would be great if you could give it a try and send some feedback

if you could try the --with-apxs2handler instead of --with-apxs2 this might help. this uses the standard handler mechanism, and not the filter API. 

look forward to hearding how it goes.
Ian

Is this apxs2 an apache configuration option or a php option?  I am using apache 2.0.45, with php 4.3.1, and am still encountering the error.  I have tried
  --with-apxs2handler=/usr/local/bin/apxs
and
  --with-apxs2filter=/usr/local/bin/apxs
in both PHP and Apache, with no successes.  In fact, now (though my configuration is good), any PHP page is not executed or parsed, but returned as type x-httpd-php, which is "somewhat" operational (i.e. it has the right type, but the libphp4 module is not being called as specified in my httpd.conf file).

Wait for PHP 4.3.2. There using --with-apxs2 will enable
the new handler version of the apache2 module.

I use several includes on every PHP page.  I have not had any problems until today when my webhost upgraded to PHP 4.3.2.  Now none of my includes are being parsed.  Yes, my webhost uses Apache, and we are discussing it in our forum at <a href="http://www.rivalpro.net/forums/iv1/index.php?act=ST&f=16&t=524&s=7e56594f281f099bcc05bbfb451bee12">http://www.rivalpro.net/forums/iv1/index.php?act=ST&f=16&t=524&s=7e56594f281f099bcc05bbfb451bee12</a>.  I hope there is a solution other than changing back to shtml pages.

Was this ever resolved - I am getting this error on a default RPM install of RedHat 9.0

I am also having this problem on a default install of Redhat 9 - Apache v. 2.0.40, PHP 4.2.2.  Apache was not installed from an RPM (to my surprise), but PHP was.  

The posts here are confusing; one says go to PHP 4.3.2, the next says that installing 4.3.2 broke scripts.

Any CLEAR solutions?  After a year and a half, it seems like this should be resolved once and for all.

I too would really like to know if there is a fix for this problem. We are having the exact same problem running a clean install of Apache 2.0,40 Linus 9.0 with PHP 4.2.2 on our new server. 

We did try it using FreeBSD and everything worked fine. All of the php includes pased fine. Reinstalled Redhat and ran into the same problem again.

After reading this thread I too am unsure where or how I can fix this problem. We really need to find a solution because it is holingup the implementation of our new server.

Use the apache2handler sapi and it should work fine.  The filter handler doesn't work very well.

What the heck does that mean?

Is the bug fixed, or not?  Is the problem that the binary included in the RPMs is faulty, and we need to rebuild PHP and/or Apache from scratch, or is this "apache2handler sapi" voodoo you speak of some kind of undocumented configuration option?

I'm sorry, but you're assuming a lot of knowledge here.  A google for "apache2handler sapi" doesn't turn up anything immediately useful.