Extension talk:Multi-select Namespace Search

Your "select multiple NS idea"
(Moved from User talk:Eep)

Hey - I would hope there's a good way to do that w/o hacking stock code, but since you were walking that path and seemed to be pretty interested in it - try this (I didn't test too dilligently - just tested a few times on a MW 1.10.1 installation, it seemed to work as expected):

powerSearchBox function replacement powerSearch function replacement

Thanks for your interest but where would the powerSearch function be placed? Excuse my programming ignorance... -Eep² 00:53, 30 July 2007 (UTC)


 * ;-) powerSearch is also in SpecialSearch.php (above powerSearchBox) - lemme know if it does what it's supposed to do. --Tim Laqua 00:55, 30 July 2007 (UTC)


 * Parse error: syntax error, unexpected ';', expecting T_FUNCTION in ../includes/SpecialSearch.php on line 402 but that line is the end of the file... -Eep² 01:02, 30 July 2007 (UTC)


 * ;-) You pasted over the closing } for the class def.  Add a } to the end of the file on the last line.--Tim Laqua 01:09, 30 July 2007 (UTC)


 * Well, I copied it exactly where it should have gone. Anyway, without adding that } it seems to have fixed itself but now I get this error: Parse error: syntax error, unexpected '[' in ../includes/SpecialSearch.php on line 253 which is $arr[] = $selectedOption;... -Eep² 01:11, 30 July 2007 (UTC)


 * Try the new powerSearch Func (I updated my earlier post) --Tim Laqua 01:19, 30 July 2007 (UTC)


 * OK, that one works, though it doesn't include the "List redirects" checkbox, which isn't that big a deal, I guess, since it's not a namespace, per se anyway. Also, in the URL, it has ns%5B%5D=0 instead of ns=0. Is that supposed to be ns[]=0 and is that because of the array? Not that big a deal but it's always nice to keep the URL as clutter-encoded-free, I say. Anyway, thanks! Now to see if this works for SpecialPreferences.php and wherever else namespace checkboxes appear in (is there a way to just call this multi-select namespace function without having to duplicate it in multiple PHP files? Maybe with <?include 'namespaceSelect.php';?></tt> or something? -Eep² 01:49, 30 July 2007 (UTC)


 * I think the funcs below shoudl take care of that ugly URL and as for the simplicity part - I'll research - those two functions have to be replaced and I'll see if I can come up w/ an elegant way of doing it w/o hacking the files themselves. (no ETA on that, may be a bit.  Maybe someone else has an idea - "how to replace/overwrite/override stock functions within classes) --Tim Laqua 01:52, 30 July 2007 (UTC)


 * OK, thanks. I'll update the extension page and give you most of the credit. ;) -Eep² 02:01, 30 July 2007 (UTC)

Alternative Funcs for Prettier Search URLs (ns=1&ns=14&...)
powerSearchBox func

powerSearch func

I noticed the URLs output by the multiple select box title looked kinda ugly - so this one uses "ns" for the name instead of "ns[]" - then preg_match_all to suck the values out of the query string. --Tim Laqua 01:43, 30 July 2007 (UTC)


 * Argh...hate when there is an edit conflict--MediaWiki needs a way to stop that! Anyway, thanks; will try one of these. -Eep² 01:49, 30 July 2007 (UTC)

Implementation Type revert,addition of user interface
The "inteface" implementation type (which corresponds to Category:user interface extensions) is meant to be a catch all for user interface types that aren't more precise - the category had over 200+ members a week ago (too much to be useful) and we've been trying to come up with a way to make it more useful by moving extensions into subcategories: e.g. search, page action, skin, etc. (See Template:Extension). It's a work in progress - is there some subcategory in "interface" that you feel is missing? Egfrank 10:57, 18 September 2007 (UTC).


 * The problem is, category:page action extensions doesn't necessarily imply a user interface relationship. I've changed the UI type to "form". —Eek 12:15, 18 September 2007 (UTC)

Interesting point... it certainly was intended to, BUT as noted in API:Changing_wiki_content this is actually a problem. There should be an API to perform page actions without a user interface.

However, the purpose of this field is to capture "how I did it" so other people can find examples of how to implement certain kinds of things. There isn't really a "how to do a form" in MediaWiki - rather a collection of techniques ranging from modifying skins and interface messages to embedding html form code in a controlled fashion - see Manual:Forms for a fuller discussion. So I wonder, is this really an example of "how to implement a form?" - if so, I guess form is an implementation type and we need to rethink the discussion at Template_talk:Extension which recommended deprecating those values that seemed to be more about purpose and less about technique.

Put another way, wouldn't adding it to manually Category:Search widget extensions capture its UI-ness without requiring us to come up with an implementation type for every possible user interface element? Egfrank 16:32, 19 September 2007 (UTC)