Cannot modify header information...
jlee - May 18, 2007 - 05:06
| Project: | Path Access |
| Version: | 5.x-1.x-dev |
| Component: | Code |
| Category: | bug report |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | needs work |
Jump to:
Description
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

#1
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
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
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
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
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
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
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
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
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
Did anybody try this on their local install to see if it resolved the issue?
#11
Subscribing.
#12
I'm having the same problem with the second call to drupal_bootstrap (although in a custom module based on statistics)
#13
Same problem here.
#14
is there a patch for this problem yet ? path access is a very useful modu
#15
I've been running my drupal with the change as suggested in #9 since that time succesfully now. Don't see any side effects.