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
_______________________________________________
pmwiki-devel mailing list
pmwiki-devel@pmichaud.com
http://www.pmichaud.com/mailman/listinfo/pmwiki-devel
