[pmwiki-devel] Search forms and FmtPageList()

[Petko Yotov]

On Thursday 24 September 2009 17:32:33 Hans wrote:
> I am working on integrating the TextExtract recipe with
> action=search and the standard PmWiki pagelist functions.
> 
> I found two problematic things in FmtPageList(), and wonder
> how to solve them:
> 
> 1. At the beginnig of FmtPageList() are some code lines which
> check if input from a search query starts with 'someword/'
> and assign group=someword and remove 'someword/' as query argument.
> This is fine for the standard PmWiki search box which has only the
> one text input field. But other search forms can be built, with
> (:input:) markup, or hardcoded in scripts, which can have a separate
> filed for group and/or pagename input. TextExtract is using such
> a form. So now I am missing for a mechanism which can disable the
> standard behaviour of treating 'word/' as group=word.
> It is a lot of trouble trying to undo later what FmtPageList() does
> to such input. A global config variable would be handy to turn off
>  'word/' => group=word

Hello. Could you possibly use in recipe.php something like :

  if ($action=="search")
    $_REQUEST['q'] = 'whatever transformation I need';

?

First things I think of :
* quote initial Group/ to "Group/"
* prepend it, Group/ to myrecipe=Group/
* store it in a local variable and remove it from $_REQUEST['q']
* etc.

Question: what happens if a user actually searches for stuff in a Group/ ? 
(Because it is written in the documentation etc.)

> 2. FmtPageList() applies
>    htmlspecialchars(stripmagic(@$_REQUEST['q']), ENT_NOQUOTES);
> to the search query. All other input is missing out on stripmagic()
> treatment. This does not work well if a server has magic quotes
> enabled. Would it be feasable to apply stripmagic to all $_REQUEST
> input?  And htmlspecialchars()?

Yes, it would be feasible, and you can apply it from your recipe.

  $my_input = stripmagic(@$_REQUEST['user_input']);

> What is the preferred way for recipes to deal with this, or for users
> bulding some custom search forms with custom input fields?

I am not aware of any such way yet :-) I suspect we might have a "preferred" 
way when there are at least 2 ways -- or more... :-)

Thanks,
Petko