Hi everybody!
I'm writing an extension that needs to replace/disable the build-in suggestion feature of the search box. In earlier versions this could be archived by setting $wgEnableMWSuggest (http://www.mediawiki.org/wiki/Manual:$wgEnableMWSuggest) to false. But with 1.20 this option is no longer available.
In includes/OutputPage.php:2484 it seems that $wgUseAjax is the only condition (despite of user settings) that is evaluated to decide whether to add the module "mediawiki.searchSuggest" or not. But I don't want to disable the ajax features completely.
ResourceLoader doesn't offer me any hooks or interfaces that would allow my extension to remove the module programmatically.
Any hints on this? Thanks in advance!
Best regards,
Robert Vogel Social Web Technologien Softwareentwicklung Hallo Welt! - Medienwerkstatt GmbH ______________________________
Residenzstraße 2 93047 Regensburg
Tel. +49 (0) 941 - 66 0 80-198 Fax +49 (0) 941 - 66 0 80-189
www.hallowelt.bizhttp://www.hallowelt.biz/ vogel@hallowelt.bizmailto:vogel@hallowelt.biz
Sitz: Regensburg Amtsgericht: Regensburg Handelsregister: HRB 10467 E.USt.Nr.: DE 253050833 Geschäftsführer: Anja Ebersbach, Markus Glaser, Dr. Richard Heigl, Radovan Kubani
On 01/15/2013 03:18 AM, Robert Vogel wrote:
Hi everybody!
I'm writing an extension that needs to replace/disable the build-in suggestion feature of the search box. In earlier versions this could be archived by setting $wgEnableMWSuggest (http://www.mediawiki.org/wiki/Manual:$wgEnableMWSuggest) to false. But with 1.20 this option is no longer available.
In includes/OutputPage.php:2484 it seems that $wgUseAjax is the only condition (despite of user settings) that is evaluated to decide whether to add the module "mediawiki.searchSuggest" or not. But I don't want to disable the ajax features completely.
There's a preference, disablesuggest, that controls it.
I don't know if there's an easy way for extensions to alter user preferences (probably not). But in the installation instructions, you can tell them to set it to true (true is disabled), and hide it from the preferences view.
See https://www.mediawiki.org/wiki/Manual:FAQ#How_do_I_change_default_user_prefe...
Matt Flaschen
On Jan 15, 2013, at 9:18 AM, Robert Vogel vogel@hallowelt.biz wrote:
Hi everybody!
I'm writing an extension that needs to replace/disable the build-in suggestion feature of the search box.
In case there may be a better approach to solve your problem, what is it you're looking to add to this feature?
Most of this module is pretty trivial and only wraps around other features that have elaborate hooks and toggles (such as PrefixIndex and the API).
-- Krinkle
Hi Matt, hi Krinkle!
Thanks for your replies.
@Matt: Thank you for the hint. I'm now using the hooks "UserGetDefaultOptions", "UserLoadOptions" and "GetPreferences" to set the "disablesuggest" useroption to true and to remove the checkbox in the user preferences. This works for me.
@Krinkle: I've written a custom API module that returns categorized results. I wanted to have a categorized output like in this demo: http://jqueryui.com/autocomplete/#categories My first approach was to override some of the logic in "mediawiki.searchSuggest" on the client side. But this didn't work as I expected. Then I saw that "jquery.ui.autocomplete" was part of MW framework and so I tried to use this according to the demo I mentioned before. But "mediawiki.searchSuggest" always "occupied" the input element so I couldn't apply "jquery.ui.autocomplete" to it. But now with the hint from Matt it works pretty good :)
Are there any future plans to make the removal of already added modules available in ResourceLoader?
- Robert
-----Ursprüngliche Nachricht----- Von: wikitech-l-bounces@lists.wikimedia.org [mailto:wikitech-l-bounces@lists.wikimedia.org] Im Auftrag von Krinkle Gesendet: Mittwoch, 16. Januar 2013 18:02 An: Wikimedia developers Betreff: Re: [Wikitech-l] Disable module "mediawiki.searchSuggest" in MW 1.20+
On Jan 15, 2013, at 9:18 AM, Robert Vogel vogel@hallowelt.biz wrote:
Hi everybody!
I'm writing an extension that needs to replace/disable the build-in suggestion feature of the search box.
In case there may be a better approach to solve your problem, what is it you're looking to add to this feature?
Most of this module is pretty trivial and only wraps around other features that have elaborate hooks and toggles (such as PrefixIndex and the API).
-- Krinkle
_______________________________________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
On Jan 17, 2013, at 10:05 AM, Robert Vogel vogel@hallowelt.biz wrote:
@Krinkle: I've written a custom API module that returns categorized results. I wanted to have a categorized output like in this demo: http://jqueryui.com/autocomplete/#categories My first approach was to override some of the logic in "mediawiki.searchSuggest" on the client side. But this didn't work as I expected. Then I saw that "jquery.ui.autocomplete" was part of MW framework and so I tried to use this according to the demo I mentioned before. But "mediawiki.searchSuggest" always "occupied" the input element so I couldn't apply "jquery.ui.autocomplete" to it. But now with the hint from Matt it works pretty good :)
mediawiki.searchSuggest does NOT use jquery.ui.autocomplete.
On Jan 17, 2013, at 10:05 AM, Robert Vogel vogel@hallowelt.biz wrote:
Are there any future plans to make the removal of already added modules available in ResourceLoader?
When taking the question literally I'd say, no, not ever and for good reason.
Features and modules should not be confused. Removing a module would do nothing but make things crash and fail. If the module is referenced somewhere it is expected to exist and provide a certain API. Removing the module would lead to a missing dependency exception.
Now, one could create a different module in its place with the same name, but that would violate the naming conventions and is generally a bad idea as it defeats the modular design we have. Module names are unique identifiers for a piece of code, not an idea or concept. Loading a module brings the expectation that that exact module is going to be loaded and not some duck punched impersonator in its place that may be implement a similar feature.
Instead you'd register your own module with its own name and make sure it is loaded instead of some other module. The method used can differ based on the feature at hand, but handling this at the module level is not the way to go.
Let's take editors for example. There is a legacy editor, the WikiEditor extension and the VisualEditor extension and many others. They all have their own coding structure, API modules and ResourceLoader modules.
The EditPage provides a hook to change which modules are queued. That's where you hook in, not in the module itself.
I think in the case of SearchSuggest it should probably be loaded by the Skin, not by OutputPage. The only use case I can think of where server-side hooks are not enough (PrefixIndex, API modules etc.), is if the visual presentation (as opposed to the suggested items themselves) needs to be different.
-- Krinkle
Hi Krinkle!
Thanks for the clarification!
mediawiki.searchSuggest does NOT use jquery.ui.autocomplete.
Yes, I know. I never said anything like this. Maybe this was a misunderstanding. I said I wanted to replace "mediawiki.searchSuggest" with my own implementation _based on_ "jquery.ui.autocomplete". As "jquery.ui.autocomplete" is delivered together with MW and can easily be made available on the client side thanks to ResourceLoader and its dependency management it was a good choice for me.
Instead you'd register your own module with its own name and make sure it is loaded instead of some other module. The method used can differ based on the feature at hand, but handling this at the module level is not the way to go.
Yes I understand this. And I think this was my problem. I did not find a proper way to "make sure it is loaded instead of some other module", because 'mediawiki.searchSuggest' module is added by OutputPage and there seems to be no way (but changing the current users settings as Matt suggested) to avoid that.
I think in the case of SearchSuggest it should probably be loaded by the Skin [...]
This would probably be a good idea as it may allow a more specific server side hook. :)
So, again, thanks for your explanations. Those where very helpful and I think I now have a better understanding of the concepts of modules.
-- Robert
Am 21.01.2013 09:48, schrieb Robert Vogel:
Hi Krinkle!
Thanks for the clarification!
mediawiki.searchSuggest does NOT use jquery.ui.autocomplete.
Yes, I know. I never said anything like this. Maybe this was a misunderstanding. I said I wanted to replace "mediawiki.searchSuggest" with my own implementation _based on_ "jquery.ui.autocomplete". As "jquery.ui.autocomplete" is delivered together with MW and can easily be made available on the client side thanks to ResourceLoader and its dependency management it was a good choice for me.
Instead you'd register your own module with its own name and make sure it is loaded instead of some other module. The method used can differ based on the feature at hand, but handling this at the module level is not the way to go.
Yes I understand this. And I think this was my problem. I did not find a proper way to "make sure it is loaded instead of some other module", because 'mediawiki.searchSuggest' module is added by OutputPage and there seems to be no way (but changing the current users settings as Matt suggested) to avoid that.
I ran into big problems when using jquery.ui.autocomplete. Xes, I _do_ know how to use it and have years of bad experience with it.
_It is difficult to customise and creates more overhead than it claims to save_ -- especially when you need to modify the suggestion output according to your needs -- , and my advice for MediaWiki is, _not_ to go this way.
My advice: stick on using the current version.
Major problems into which you may run are [1-3].
- customising suggestion output (when you want to use HTML, when you want to highlight something in the suggestions): very difficult, lot of overhead - when leaving the tab and returning. the suggestion list disappears. Retriggering onfocus is almost impossible without negative side-effects.
Tom [1] https://forum.jquery.com/topic/jquery-ui-autocomplete-bug-autocomplete-sugge... [2] https://forum.jquery.com/topic/autocomplete-ie7-backspace-issue#147370000025... [3] bugs.jqueryui.com/ticket/8832
wikitech-l@lists.wikimedia.org