[pmwiki-users] "PmWiki can't process your request" error message.

Patrick R. Michaud pmichaud at pobox.com
Fri Jan 5 17:36:09 CST 2007


On Sat, Jan 06, 2007 at 10:01:51AM +1100, Kathryn Andersen wrote:
> On Fri, Jan 05, 2007 at 11:51:47PM +0100, Roman wrote:
> > On 1/5/07, Patrick R. Michaud <pmichaud at pobox.com> wrote:
> > > On Fri, Dec 29, 2006 at 04:09:12PM +0200, Athan wrote:
> > > > PmWiki can't process your request
> > > > ?invalid page name
> > > > We are sorry for any inconvenience.
> > >
> > > Are you simply looking for PmWiki to use a 404 status code in the
> > > response, or do you want/need it to actually return a complete
> > > page with skin and decorations (similar to what happens when
> > > requesting a non-existing but valid page name)?
> > >
> > 
> > BTW, error message is hardcoded, so it's not so easy to translate or
> > customize it. If you would return Site.PageNotFound it would solve
> > both problems.
> 
> Or make it customizable so that one could return either
> Site.PageNotFound or some other page (like Site.InvalidPage)
> because sometimes you really want to inform folks that it *is* an
> invalid page rather than a not-found page.

Part of the difficulty of returning Site.PageNotFound (or Site.InvalidPage)
is that there are many things that need to occur between the time we
discover something is an invalid page name and when the page can
be displayed -- usually we get the invalid page name before other
things, including skins, have been loaded.

This is why the current message is so terse -- at the time we discover
that there's an invalid page name, a skin hasn't been loaded yet.

Now then, we could default PmWiki to treating any invalid page
request as being exactly equivalent to a browse request for
Site.InvalidPage... i.e.:

    if (/* page name is invalid */) {
      $pagename = "$SiteGroup.InvalidPage";
      $action = 'browse';
    }

Then, any Site.php and Site.InvalidPage.php customizations would be
loaded, the headers/footers/sidebar would look as though they're
coming from the Site group, etc.  

But this also has the potential to impact other recipes in a
negative way, because many of them also depend on knowing a
valid $pagename.  The code that currently aborts on invalid pagenames
is ResolvePageName, so when a recipe or local customization does

    $pagename = ResolvePageName($pagename);

it's expecting PmWiki to abort if the pagename is invalid.
If we change this too drastically, then recipes may suddenly
find themselves operating on Site.InvalidPage where previously
it aborted.

Perhaps we can handle this with an extra parameter to ResolvePageName
that specifies what to return if $pagename is invalid, and if
no extra parameter is provided, then Abort (as it does now).
Then we have

    # aborts on invalid pagename    
    $pagename = ResolvePageName($pagename);   

    # returns Site.InvalidPage on invalid pagename
    $pagename = ResolvePageName($pagename, 'Site.InvalidPage');

Then recipes will continue to work as before.  But, this negates
the whole point of the exercise, because any site that calls
ResolvePageName() (or calls a recipe that calls ResolvePageName())
would have to be updated to provide the extra parameter, otherwise
we get the existing Abort() behavior that we were trying to avoid.  :-(

So, I guess I don't have a good answer for getting an invalid
pagename to return Site.InvalidPage, at least not without 
drastically reworking the page resolution sequence.  I can
at least get it to return a 404 status code without much difficulty,
instead of the 200 it's returning now.

I'm open for other suggestions.  I'd also be curious to know
if anyone thinks that recipes would have problems if
ResolvePageName() started to return 'Site.InvalidPage' 
for invalid pagenames instead of aborting as it does now.

Pm




More information about the pmwiki-users mailing list