Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.I'm currently using Domain Access on a site with a few top level domains and a bunch of subdomains for the main domain. Shortly after I upgraded to the new security release 6.x-2.6 yesterday, I started seeing the error message below instead of the content of my pages:
Fatal error: Call to undefined function filter_xss_bad_protocol() in /home/site/public_html/includes/common.inc on line 1053
for every page on my site including user and admin pages.
My site is only usable again after I delete the 6.x-2.6 files and replace them with the 6.x-2.5 version I was using before.
The error is displayed even after I disable all the other Domain related modules.
Is there anything I can do to resolve this issue other than going back to 6.x-2.5?
Thanks
| Comment | File | Size | Author |
|---|---|---|---|
| #15 | 921984-uri.patch | 2.03 KB | agentrickard |
Comments
Comment #1
agentrickardThat function is in a required module (filter.module). Why would it not be present? Are you using aggressive page caching? Any page caching?
This is not something I have been able to replicate.
I don't suppose you can find out what in the call stack is invoking this function?
Comment #2
agentrickardComment #3
sitordance CreditAttribution: sitordance commentedThanks for the reply. I checked and the filter module was active (according to the module page and status set to 1 in the database) and there were no issues when I was running 6.x-2.5.
I was not using aggressive page caching but I do use boost and memcache.
I disabled boost and memcache, upgraded to 6.x-2.6 again and restarted my server.
It's been running for a few hours now without any caching and I haven't seen the issue whereas I was seeing it on every page load before. I'll re-enable boost then memcache and test to see if I can reproduce it. If I can, I'll post the info you requested above.
Thanks again.
Comment #4
agentrickardSo it has something to do with how either Boost or Memcache is interacting with DA, I suspect. Personally, I don't understand why filter_xss_bad_protocol() isn't in common.inc, since url() requires it.
When debugging, the trick is to find out what process is calling url() before filter module is loaded.
We did move a loader function from hook_init() to hook_boot() in 6.x.2.6, to fix a conflict reported in [##820062]. This could be the problem. You might try downloading and reversing this patch: http://drupal.org/node/820062#comment-3108614
Comment #5
agentrickardShorten title.
Comment #6
agentrickardDid you see this node in the Boost README?
Comment #7
agentrickardAlso note that memcache requires you to edit $conf in settings.php. This should be done _before_ the domain access settings setup code.
Comment #8
Steve Hanson CreditAttribution: Steve Hanson commentedI too have been having this same issue with upgrading to 2.6 or 2.7. I backed out the patch as indicated in #4 above, and now 2.6 seems to be working just fine for me. I have no idea WHY this fails, but making this change seems to fix it.
I am not using memcache or boost on this particular site.
I probably SHOULD say that the only oddity here I can think of that might be different from your test environment is that I am running PHP under fcgid on the site, with APC as a cache, and apache is running in worker MPM, not prefork. I dont' see why any of that ought to matter, but for completeness ---
Comment #9
agentrickardThere's an easier way to back out the patch here: #927808: PHP Fatal error: module_implements() .
It looks like we have two competing requirements, and moving the url rewrite function to hook_boot() breaks some implementations. Not doing so, however, breaks other implementations.
APC might matter, but the more likely culprit is some other module calling url() before the end of hook_boot(), which seems odd.
Comment #10
agentrickardI'd still like someone to trace the call stack and tell me what function is invoking the filter_xss_bad_protocol(). I know it comes from url() and likely domain_get_path(), but something is calling that function too early. Maybe a contributed domain extension module?
Other than that, patch discussion is at #927808: PHP Fatal error: module_implements()
Comment #11
Steve Hanson CreditAttribution: Steve Hanson commentedhi Ken.
I'll try to do that - but at the moment I'm packing up to go on vacation for 10 days or so, so it's likely not to happen till I get back.
Comment #12
sitordance CreditAttribution: sitordance commentedDomain Access was setup before Boost or Memcache as DA is a central feature for the site.
The Boost features listed above match my current settings with the exception of these 2:
[x] Overwrite the cached file if it already exits
[x] Expire content in DB, do not flush file.
At the time I was experiencing the issue, it's possible that one or both of those were enabled as I was experimenting with the settings. I'll enable them again to see if they make a difference with the error.
The Memcache settings were made to settings.php.
I forgot to mention it before but APC is also installed on the server.
Since, disabling Boost and Memcache, upgrading to 6.x-2.6 again and restarting my server on Sept 24, I've not seen the error message.
Comment #13
agentrickardAPC shouldn't matter. I suspect Boost here. I think the current memcache release has some issues as well. Still looking for actual details of the call stack that leads to this error.
Comment #14
agentrickardI just tested Boost, and that module is _awesome_. Worked like a charm with DA, so that isn't the issue here, AFAIK.
My understanding is that Memcache module is a little buggy right now.
Comment #15
agentrickardThe following will ensure this does not happen, but also forces use of HTTP or HTTPS (which is the way the module is now.