Hi,
I'm getting strange "page not found" errors in the watchdog logs of several sites. In common to all those sites is that I'm using a panels page on the front page; on English sites it's URL path is /frontpage
, on German sites it's /hauptseite
. However, the URL alias does exist and is working when entered directly into the browser (e.g. http://www.mysite.org/frontpage
.
The error messages from watchdog log look like this:
Type page not found
Date Tuesday, June 29, 2010 - 10:06
User Anonymous
Location (...) /sites/default/files/css/css_c8422c178f9cc122e3ed52d4febeb504.css
Referrer
Message frontpage
Severity warning
When clicking on the given location (../css_c8422c178f9cc122e3ed52d4febeb504.css), a search is performed for "frontpage" with the result: "The page you requested does not exist." This search is triggered by the Search 404 module which is supposed to work like this:
Instead of showing a standard "404 Page not found", this module performs a search on the keywords in the URL, e.g. if a user goes to http://example.com/does/not/exist, this module will do a search for "does not exist".
So this might indicate that Drupal can't find the panels page aliased to /frontpage
.
The panels page is configured like this (excerpted the relevant settings):
- Path: /frontpage ("This is your site home page.")
- Access: This page is publicly accessible.
- Administrative title: Frontpage
- Machine name: frontpage
- Title type: (no title) - this might be the reason why a search by Search404 fails, also
I have clean paths enabled, and I'm running pathauto. This happens on a pure English website, so this is not an issue related to i18n. However, this gets a lot weirder on true multilanguage sites, but I'll try to reduce the complexity by locating the simplest cases.
Another case is a site which runs by default in German. Here this error message is triggered - for example - by sending a message through the contact form; after successfully sending the message, Drupal redirects to the home page - in my case a panels page, again - and prints a notice lilke "the message has been sent". Strangely, sending such a message as logged-in user gives no error, but an anonymous users receives this notice:
Die von Ihnen angeforderte Seite wurde nicht gefunden. Eine Suche nach hauptseite hat diese Seite gefunden.
Die Nachricht wurde gesendet.
This means: "The requested page was not found. A search resulted in this page. The message was sent". Again a panels page is involved that definitely exists but somehow can't be found by the system. This message is printed on the page http://www.mysite.org/?nocache=1
.
Example watchdog record:
Typ page not found
Datum Dienstag, 29. Juni 2010 - 18:53
Benutzer Gast
Ort (...) /sites/default/files/js/js_44d839655ead03a8d129b28d159058f8.jsmin.js
Referrer (...) /kontakt
Nachricht hauptseite
Schweregrad Warnung
The configuration of this page:
- Path: /hauptseite ("Dies ist die Startseite der Website.")
- Access: Die Seite ist öffentlich erreichbar.
- Administrative title: Hauptseite
- Machine name: hauptseite
- Title type: "Manually set" - left blank
In both cases, the $base_url
is not set in settings.php
.
I am not sure what exactly causes these strange "page not found" errors. My candidates:
Possibly involved:
- Panels - most probable candidate since in al cases I have investigated the watchdog log points to "existing-unexisting" panel pages
- Boost - used in all cases investigated so far
- Pathauto - used in all cases investigated so far
- Search404 - used in all cases investigated so far
- Caching (core) - the watchdog record seems to always point to an aggregated css file
- Clean URLs (core)
- Something else - ?
I'm kindly asking for advice how to track this issue further. I'll try to figure out instructions how to reproduce this and report back.
If you think another issue queue might be better suited please feel free to modify it.
Thanks & greetings,
-asb
Comments
Comment #1
asb CreditAttribution: asb commentedI can reproduce the described behaviour on the German site when accessing the contact form as anonymous user.
Additional potential candidates:
Boost: Deactivating and clicking "Clear Boost's Database & File Cache" at
/admin/settings/performance/boost
has the following results:However, the contact message is being sent (and logged in watchdog).
Changing issue queue to 'Boost' which seems to be the most probable candidate.
Comment #2
mikeytown2 CreditAttribution: mikeytown2 commentedcan I get a quick summary of what to look for?
Comment #3
asb CreditAttribution: asb commentedHm... all I know so far is that the aggregated CSS file (eg ./sites/default/files/css/css_c8422c178f9cc122e3ed52d4febeb504.css) seems to cause "page not found" errors even if the page exists. I really have no idea how a CSS file could cause this, and I don't understand why the watchdog "Location" record (.../css_c8422c178f9cc122e3ed52d4febeb504.css) is hyperlinked to a panel page respectively the website's front page.
Ah yes, and I can say for sure that I'm experiencing similar issues on different websites, all runing Boost. As far as I can reproduce this "page not found" behaviour it vanishes as soon as I disable Boost (plus clicking "Clear Boost's Database & File Cache").
Example generated boost rules:
If it helps I can try to document the Boost settings from
./admin/settings/performance/boost
or anything else that might be necessary. This applies to boost 6.x-1.x-dev from 2010-Jun-12.Thanks & greetings,
-asb
Comment #4
asb CreditAttribution: asb commentedUpdated to the latest dev release, but the watchdog log is still flooded with messages like this:
So, is there any news on this issue, or could I do something to help tracking this down?
Thanks & greetings, -asb
Comment #5
merlinofchaos CreditAttribution: merlinofchaos commentedIt's possible that the Panels cached CSS is getting cleared but Boost's output is not, causing the CSS to go AWOL which then cascades into the error you see?
Comment #6
asb CreditAttribution: asb commentedThat sounds quite reasonable. But how do I verify this?
At least I can get rid of this problem by disabling the Boost cache, so it's definitely related to boost somehow. However, disabling Boost creates a whole bunch of other problems (i.e. severe server load ;), so it's no usable solution.
Comment #7
jdwfly CreditAttribution: jdwfly commentedI'm running into a similar problem. Error log shows that my panel page is a 404, but in reality it can't find a certain javascript file that just got flushed on cron.
Comment #8
tlangston CreditAttribution: tlangston commentedSame here - am experiencing only when not logged on and on all my panel pages. Not using Boost - so that doesn't apply here. Am using Pathauto. Tried updating to 3.7 and had errors flying - backed off to 3.5.
Comment #9
merlinofchaos CreditAttribution: merlinofchaos commentedIf you're not using Boost, why did you take over an issue from the Boost queue that's about people having issues with Boost?
That is incredibly disrespectful to the people having the issue with boost.
Comment #10
qproI think a have similar problem
My site's url is www.example.com/est/%node
In arguments options I assign the argument to a Node ID
Then i can previsualize the panel but the panel page is not found.
Any solution , thanks
Comment #11
Alexander Ufimtsev CreditAttribution: Alexander Ufimtsev commentedI've come across this issue with Panels & Boost recently (but for Drupal v5), and hence, my post here :-)
In my case it appears that Drupal caches have been corrupted (not Boost cache). To solve the problem, just empty Drupal cache (If you are using Administration Menu, use 'Empty cache' option), or truncate all the 'cache%' tables in your DB.
Up to now I was not able to identify the root of the problem though :-(
Comment #12
mikeytown2 CreditAttribution: mikeytown2 commentedthe 5.x version of boost is very tame in comparison to the 6.x version; good to know. I shouldn't be caching on non 200 responses so I do need to look into this more.
Comment #13
asb CreditAttribution: asb commentedI'm still getting these errors with the latest dev release of 'boost', and I don't have the faintest idea what is causing this. Anyone?
Comment #14
mikeytown2 CreditAttribution: mikeytown2 commentedCould this be an issue with an incomplete menu router update? I've gotten 404's for pages that exist if the menu router update bombs due to multiple threads writing to the same table in the database.
http://drupal.org/node/512962#comment-3340052
I have not experienced this bug in any way so I am guessing here; and we use lots of panels.
Comment #15
EvanDonovan CreditAttribution: EvanDonovan commentedI think merlin's suggestion in #5 is still the most likely. When I used Boost, I used to run into issues with Drupal clearing CSS cache while my Boost was set to still cache. Possibly if people would attach a txt file detailing their Boost settings it would be easier to debug.