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.


 * What I worry about is an explosion of implementation types - beyond what would be useful to someone learning to use/customize MediaWiki. If we have a "type" for form, what about other UI widgets? There are an awful lot of them: see Category:Extensions by visual element.  My other concern is whether or not "form" is an implementation technique.  The purpose of the implementation 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.  Do you think of "form" as an implementation type? If so, what about the other widgets? Do we need a "form" type?  A "widget" implementation type? If so, 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. Looking forward to your response,  Egfrank 16:32, 19 September 2007 (UTC), revised 04:09, 20 September 2007 (UTC).
 * PS - Just took a closer look at your code... based on what you've actually done to implement this, I'd consider changing your implementation type to "special+search" and use categories for the namespace (also more of a "why use this" rather than "how to do this" category). Egfrank 04:35, 20 September 2007 (UTC)
 * PS - Just took a closer look at your code... based on what you've actually done to implement this, I'd consider changing your implementation type to "special+search" and use categories for the namespace (also more of a "why use this" rather than "how to do this" category). Egfrank 04:35, 20 September 2007 (UTC)

Non-patch implementation
I like your idea but I believe there is a way you can implement this without a patch to core code. (a lot of people won't use extension-by-patch because it can be an upgrade nightmare). Here's how:


 * subclass
 * add a function to the hook. In that function change the array entry for the special page to use your class (key=special page name, value=array containing class name and constructor parameters).

Also, for customizing preferences to turn your multi-select list box on and off,you might want to take a look at the hook and Manual:User toggles.

If you'd like some help implementing it, let me know User:egfrank. Egfrank 04:27, 20 September 2007 (UTC)


 * Unfortunately, I'm not much of a programmer. Tim Laqua actually made it work correctly so he might be a better person to approach with this idea (since he also made an extension that allows changing the "[edit]" section text to an image).

Multi-select recentchanges
Could a similar extension be made for recentchanges? I'm surprised it doesn't seem to exist yet... It would be just helpful for a ton of things. --Anonymous