I'd like to propose two new functions to this extension. The first is a button color/class option. E.g. green button could be managed by "buttoncolor=green" or by 'buttonclass=mw-ui-progressive". The second is the level of the new section heading. E.g. 3rd heading could be managed by "headinglevel=3" What do you think? Could they be added?
Button color/class and new section heading
@Dvorapa: Re: button colors - One goal of the ongoing design work, is to make a User Interface that is consistent, as in, once people are familiar with a button's action/outcome, they can expect consistent results. Hence, the button to submit a form (as in this extension, and others) should always be a single color (blue in our case). There's some related information at this (slightly outdated) page: Wikimedia Foundation Design/Color usage#Functional Colors.
Re: heading levels - I almost filed a feature-request for this in phabricator, but then I couldn't find any examples (I checked a few dozen pages linked from en:WP:Requests). Here's what I had drafted; please add your use-case, and any pre-existing examples you can find, and post it in phab.
- Title: Allow inputbox to create an H3 heading
- Description: Suggested feature: The addition of a new parameter, which would let an inputbox specify what Heading level to use, when creating the `section=new`. This would allow editors to use it more flexibly, on pages where the desired practice is to create feedback in a series of H3 sections. Example pages where this practice is wanted (or already done but manually) include ...
Note: I'm not sure if this is technically feasible though. The current system just hooks into the standard "New topic" tab on all talkpages. Adding new code to allow changing the H-level might be more complex than is desired.
This would be super helpful - it is difficult to design a page around the light grey color of the 'create' button.
why not jquery icons?
I wondering there is no option for this as old templates support this on Wikimedia like Template:Clickable_button, I see this because someone used some unicode signs which are not really supported by many systems: 🔍
I believe this would be covered by phab:T106948 ("Convert InputBox to use OOJs UI where possible"), but I'll ask some folks...
I believe that task would cover the issue of extensions/tools which desire to have consistent/pre-determined icons within buttons, see examples in OOjs_UI/Widgets/Buttons_and_Switches. So, after that work was done, additional work could be done on the InputBox extension to include a magnifying-glass icon on the
type=fulltext/search/search2 form input buttons by default. However, changing the image manually for each usage of the InputBox, would run counter to the desire for standardization (for a more intuitive/learn-able interface). HTH.
Editing page header searchbox
Hi, I have a header search box but I can't find a way to edit it and use InputBox, more precisely i wanted to do something like this:
<inputbox>type=search namespaces=Main**,Help </inputbox>
So users could selected categories to search. How can I change this?
That should work, assuming you mean "namespace" and not "categories". (See functional example at W:en:Help:Contents)
If you mean "categories", I don't believe it is possible to use the checkboxes for those. However, defaults could be entered in, per Help:CirrusSearch#Filters (intitle:, incategory: and linksto:). e.g.
<inputbox> type=search default=incategory:"Freeware games" incategory:"Art games" </inputbox>
Use of "summary"
Can anyone provide an example to show how the "summary" parameter works? The example provided does not seem to have an edit summary.
It doesn't seem to work with type "comment", only with "create" and "move". I'll update the docs.
Namespaces for create form
Is it possible to use InputBox with VisualEditor ?
I guess you are asking about the create article "problem"?
I'm a newbie, so probably what I'm suggesing might be very bad, but worked for me
so I search in the source files and found that if you change the file /extensions/Inputbox/Inputbox.classes.php and change action to veaction (see below) the magic happens. This doesn't work When you are using the parameter prefix, it won't create an article with prefix in the name.
$htmlOut .= Xml::openElement( 'input', array( 'type' => 'hidden', 'name' => 'veaction', 'value' => 'edit', )
An easier way (now) to do this is add the parameter 'useve' for InputBox. I'm not sure when this was added, but I'm running MediaWiki 1.26.2.
Thanks for that ;-)
Do you know if using a preload is possible with VisualEditor?
@Mattho69 Did you manage to get preload working with VisualEditor?
I'm not sure what you mean by preload. I'm pretty new to administering an instance of MediaWiki. Still figuring a lot out. Sorry I can't be of more help.
Remove Flow so that the talkpage becomes usable
Can someone remove Flow? I would like to use this talkpage, and Flow is a buggy mess.
You apparently just managed to use this talk page using Flow.
Getting the "Subject" string into preloadparams
I'd like to make the preloadparams value equal to the "Subject" or 'title' field, when creating a new page.
I'm not sure if there is any easy way to do that, so I'm trying with some code management without success since I'm quite a beginner with php.
In that way I could set the only parameter I want to change ($1) to the title of the new page. If there's other way to do that, it would solve my problem as well.
preloadparams Doesn't work (version 1.24.1)
I'm using InputBox for the first time. All seems to be working well apart from one feature: preloadparams.
<inputbox> type=create preload=Template:Preload_Page preloadparams=abcde </inputbox>
In the preload page I'm calling, I'm expecting it to replace the string $1 with the text abcde, but it just outputs $1.
Ideally, I want to pass in a category string (like [[category:categoryname]]) but I thought I'd just start off simple to get it working.
Any ideas where I'm going wrong?
You're not going wrong, but apparently support for
preloadparams was added for the 1.25 version of InputBox and it's not present in 1.24
Doing a grep of the code of 1.24 doesn't match anything for preloadparams, but for 1.25 it does. I've fixed the compatibility column.
Ah, I see! Thanks Ciencia!
The code to support preloadparams was added before the extension was forced into 1.24. I've got it running on 1.23 at the moment.
I had to pull the extension with git and force it back to the commit where support was added:
git clone https://git.wikimedia.org/git/mediawiki/extensions/InputBox.git cd InputBox git reset --hard 474dd170d24e3710144a5ae0a4ddfea1b520773e
No idea about the stability. Its version shows up in Special:Version as "0.3.0 (474dd17) 01:47, 13 November 2014".
Well, I'm having the exact same problem, but I have no shell access. Would be there any easier solution? (A whole mediawiki upgrade is possible but it would be great to solve without doing that).
Actually I've solved this changing the code that comes with it. It's working just fine right now!
it would be great if this extension had options for word completion. Some of the code could perhaps be borrowed from Extension:Semantic Forms, which for example lets you autocomplete on a given namespace.