The gut of the issue started here:
http://drupal.org/node/88707#comment-179268
http://drupal.org/node/88707#comment-179275

To recap: First, I don't know that its still some type of caching issue as was claimed in the other report but I do know this:
1. Aliased pages
1.a. no menu entry
1.a.i. will not work as error pages. resorts to /node/ instead
1.b. menu entry (even if deleted lated)
1.b.i. will work as error page

2. Unaliased pages
1.a. either way, with or without menu entry it works fine

Hope thats clear!

So the short term workaround is just to create a menu entry for the page and then delete it again.

Comments

RobRoy’s picture

RobRoy commented
Status: Active » Closed (duplicate)

Duplicate of http://drupal.org/node/108695.

jimmygoon’s picture

jimmygoon commented
Status: Closed (duplicate) » Active

No. That bug report was fixed. That was only for unaliased URL's. I can still confirm that it IS a problem with aliased URL's. That bug report is closed. One of the two needs to stay opened. This one has more specific information about the aliases so I'm going to reopen.

forngren’s picture

forngren commented
Version: 5.0 » 6.x-dev

The same/similar issue in HEAD.

gpk’s picture

gpk commented

I have what appears to be a related problem (and may I suspect have the same root cause) in that my 404 page (which has an imaginatively-named alias '404') seems to be cached, so that updates to the page are not visible when a 404 error is generated. See http://drupal.org/node/158005. Am using Drupal 5.1.

Workaround: since the 404 page seems to be stored in the menu cache, doing anything that clears same fixes the problem, i.e. resubmit the admin/build/modules page or the admin/settings/error-reporting page. Or clear the cache table by hand.

chx’s picture

chx commented
Status: Active » Closed (won't fix)

I just checked and this is not an issue in HEAD which is not surprising at all given the menu system redux.

gpk’s picture

gpk commented

Thanks for the update, chx