Extension talk:Multi-select Namespace Search

From MediaWiki.org
Jump to navigation Jump to search

Your "select multiple NS idea"[edit]

(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

        function powerSearchBox( $term ) {
                $namespaces = '';
                foreach( SearchEngine::searchableNamespaces() as $ns => $name ) {
                        $checked = in_array( $ns, $this->namespaces )
                                ? ' SELECTED' # from ' checked="checked"'
                                : '';
                        $name = str_replace( '_', ' ', $name );
                        if( '' == $name ) {
                                $name = wfMsg( 'blanknamespace' );
                        }
                        $namespaces .= " <option value=\"$ns\" {$checked} >{$name}</option>\n";
                }
 
                $checked = $this->searchRedirects
                        ? ' CHECKED' # from ' checked="checked"'
                        : '';
                $redirect = "</select><input type='checkbox' value='1' name=\"redirs\"{$checked} />\n";
 
                $searchField = '<input type="text" name="search" value="' .
                        htmlspecialchars( $term ) ."\" size=\"16\" />\n";
 
                $searchButton = '<input type="submit" name="searchx" value="' .
                  htmlspecialchars( wfMsg('powersearch') ) . "\" />\n";
 
                $ret = wfMsg( 'powersearchtext',
                        $namespaces, $redirect, $searchField,
                        '', '', '', '', '', # Dummy placeholders
                        $searchButton );
 
                $title = SpecialPage::getTitleFor( 'Search' );
                $action = $title->escapeLocalURL();
                return "<br /><br />\n<form id=\"powersearch\" method=\"get\" " .
                  "action=\"$action\">\n<select name=\"ns[]\" multiple>{$ret}\n</form>\n"; # from "action=\"$action\">\n{$ret}\n</form>\n"
        }

powerSearch function replacement

	function powerSearch( &$request ) {
		return $request->getIntArray('ns');
	}

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';?> 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&...)[edit]

powerSearchBox func

        function powerSearchBox( $term ) {
                $namespaces = '';
                foreach( SearchEngine::searchableNamespaces() as $ns => $name ) {
                        $checked = in_array( $ns, $this->namespaces )
                                ? ' SELECTED' # from ' checked="checked"'
                                : '';
                        $name = str_replace( '_', ' ', $name );
                        if( '' == $name ) {
                                $name = wfMsg( 'blanknamespace' );
                        }
                        $namespaces .= " <option value=\"$ns\" {$checked} >{$name}</option>\n";
                }
 
                $checked = $this->searchRedirects
                        ? ' SELECTED' # from ' checked="checked"'
                        : '';
                $redirect = preg_replace('/SELECTED/i','CHECKED',"</select><input type='checkbox' value='1' name=\"redirs\"{$checked} />\n");
 
                $searchField = '<input type="text" name="search" value="' .
                        htmlspecialchars( $term ) ."\" size=\"16\" />\n";
 
                $searchButton = '<input type="submit" name="searchx" value="' .
                  htmlspecialchars( wfMsg('powersearch') ) . "\" />\n";
 
                $ret = wfMsg( 'powersearchtext',
                        $namespaces, $redirect, $searchField,
                        '', '', '', '', '', # Dummy placeholders
                        $searchButton );
 
                $title = SpecialPage::getTitleFor( 'Search' );
                $action = $title->escapeLocalURL();
                return "<br /><br />\n<form id=\"powersearch\" method=\"get\" " .
                  "action=\"$action\">\n<select name=\"ns\" multiple>{$ret}\n</form>\n"; # from "action=\"$action\">\n{$ret}\n</form>\n"
        }

powerSearch func

	function powerSearch( &$request ) {
                preg_match_all("/ns=(\d+)&/i",$_SERVER['QUERY_STRING'],$nsArray, PREG_PATTERN_ORDER);
		return $nsArray[1];
	}

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[edit]

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#Type). 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#Type taxonomy 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)

Non-patch implementation[edit]

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:

Also, for customizing preferences to turn your multi-select list box on and off,you might want to take a look at the UserTogglesTemplate:Enlink/list1 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[edit]

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