Download & Extend
Path Access » Issues

Cannot modify header information...

Posted by jlee on May 18, 2007 at 5:06am
Project:Path Access
Version:5.x-1.x-dev
Component:Code
Category:bug report
Priority:normal
Assigned:Unassigned
Status:patch (to be ported)

Issue Summary

This may or may not be caused by this module.... however I only noticed the error after installing and activating the module...so I am passing this this along.

During navigation...users are "sporadically" presented with this error message:

warning: Cannot modify header information - headers already sent by (output started at /home/mysite/public_html/includes/bootstrap.inc:546) in /home/mysite/public_html/includes/common.inc on line 141.

Is this a bug in the module code?

Thanks

Login or register to post comments

Comments

#1

Posted by bennyfio on July 12, 2007 at 7:42pm

I am getting the same error... if Path Access is enabled and Caching mode is set to normal almost 50% of times there is that warning message being shown, disabling the plugin the issue disappears.

#2

Posted by budda on August 27, 2007 at 2:28pm
Status:active» postponed (maintainer needs more info)

This is really hard to diagnose. I've not had this problem myself on about 10 sites which the module has been deployed on.

The module function path_access_init() gets called on every page load, but does no printing to the screen to cause such an error that you have reported.

Are you able to re-create this problem from a clean Drupal 5.x install? What web server are you running on? Do you have the aggressive caching option in Drupal enabled?

#3

Posted by bpsommerville on September 17, 2007 at 7:34am

Another data point.

We have had this problem for a while. I tried upgrading to the dev version of path_access and still saw the same problem.
Disable path_access & it goes away, reenable and it comes back

#4

Posted by gjxl on September 17, 2007 at 8:31pm

I can confirm this problem. It seems the problem only manifests itself when you ask for a page with a browser that doesn't support gzip (I only get it from some bots that query my site, or if I use wget).
I can easily reproduce the error when:
- Caching is set to normal
- I request a cached page with wget

#5

Posted by budda on September 17, 2007 at 8:59pm
Version:5.x-1.1» 5.x-1.x-dev

So if you turn off caching completely the problem goes away?

Does anybody know a solution for this as i don't currently have spare time to test and create a solution.

#6

Posted by gjxl on September 17, 2007 at 9:22pm

No caching -> no bug
Aggressive caching -> no bug

I would guess the problem is with the call to 'drupal_bootstrap(DRUPAL_BOOTSTRAP_PATH)'. Since that recursively calls the bootstrap stuff (since path_access_init gets called from the LATE_PAGE_CACHE bootstrap fase).

I don't really understand why you need that call either. I guess it's just for access to the 'drupal_get_path_alias' function in the cache bootstrap phase. But page caching is only for anonymous users, and therefore restricted pages will never be in the page cache.

So I guess you could just drop the call the drupal_bootstrap, and instead explicitely check if a cached page is being served, and in that case just return from your path_access_init without doing anything.

#7

Posted by gjxl on September 17, 2007 at 10:05pm

Ok, I've digged some more into this, and my previous comment is right. It's actually an incompatibility between Statistics module and Path_access module (the error doesn't occur with statistics module disabled). It's because they both call drupal_bootstrap(DRUPAL_BOOTSTRAP_PATH), the second call (in statistics_exit) will result in a DRUPAL_BOOTSTRAP_FULL.
The way drupal_bootstrap is setup doesn't really cater for repeated (let alone recursive) calls to it.

#8

Posted by budda on September 17, 2007 at 10:16pm
Status:postponed (maintainer needs more info)» needs work

Thanks for your investigation in to this. makes sense that i never noticed it as i've not used statistics.module on any live site before.

If you could provide a replacement _init() function i would be happyto stick it in -dev for others to test before committing to a new point release.

#9

Posted by gjxl on September 17, 2007 at 10:36pm

Hum, I don't see any obvious way to determine the bootstrap phase, so my previous suggested solution might be unfeasible.

Alternatively you could just replace:

     drupal_bootstrap(DRUPAL_BOOTSTRAP_PATH)

by:

     _drupal_bootstrap(DRUPAL_BOOTSTRAP_PATH)

(Thus calling the internal functin with leading underscore).
This requires some testing though.

#10

Posted by budda on February 9, 2008 at 6:38pm

Did anybody try this on their local install to see if it resolved the issue?

#11

Posted by DanielTheViking on February 10, 2008 at 12:22pm

Subscribing.

#12

Posted by Doobyfrucan on February 21, 2008 at 12:07pm

I'm having the same problem with the second call to drupal_bootstrap (although in a custom module based on statistics)

#13

Posted by halftone on March 16, 2008 at 5:56pm

Same problem here.

#14

Posted by ratskates on March 20, 2008 at 12:00pm

is there a patch for this problem yet ? path access is a very useful modu

#15

Posted by gjxl on July 23, 2008 at 11:09pm

I've been running my drupal with the change as suggested in #9 since that time succesfully now. Don't see any side effects.

#16

Posted by budda on December 25, 2009 at 12:15am
Status:needs work» patch (to be ported)

I've committed this change to the 6.x-dev CVS based on the feedback from gjxl.

Should be ported to 5.x for completeness.