Extension talk:Page Forms

Remote autocomplete and mapping property don't work together
Hi all,

I've been using Semantic MediaWiki extensively on our Intranet and I've hit a snag.

I've frequently been using URLs of the form "Object:" to store semantic pages, and then using the Semantic Titles extension for useful display titles. For autocomplete values on Semantic Forms, I use the mapping property parameter to specify the title property so that the friendly title is displayed to users. This works well for small autocomplete lists; however, I have discovered that when remote autocomplete is in action (when there are a large number of possible values for autocomplete), the mapping property parameter is ignored.

I'm using SF 3.4.

Is there a fix for this already?


 * Unfortunately, no. What you can do, though, is increase the size of $sfgMaxLocalAutocompleteValues (by default, it's 100), to make remote autocompletion occur less. Yaron Koren (talk) 13:01, 5 August 2016 (UTC)


 * Thanks a bunch for the suggested workaround. Unfortunately the category I'm trying to autocomplete has over 16,000 pages so I'm not sure how practical that will be but I'll give it a go. User:Kriegfrj2
 * Oh... that doesn't sound practical at all. Yaron Koren (talk) 02:19, 7 August 2016 (UTC)

#time parser function SMW 2.4.1
The #time parser function described in seem to be broken with Semantic MediaWiki 2.4.1

How can I manually set the display format for dates? C Wagner (talk) 13:57, 5 August 2016 (UTC)


 * What do you mean by "broken"? It's not part of SMW - it's part of the ParserFunctions extension - and as far as I know, it still works fine. Yaron Koren (talk) 14:41, 5 August 2016 (UTC)


 * I have in a SMW template but it keeps formatting Y/m/d since upgrade to SWM 2.4.1 C Wagner (talk) 15:01, 5 August 2016 (UTC)


 * I don't see any way that the SMW version would have an impact on this. Did you also upgrade MW? Maybe you need to also upgrade ParserFunctions? Yaron Koren (talk) 17:53, 5 August 2016 (UTC)


 * Thanks a lot for the tip. Solved. You're doing a great job! Even solving problems not directly connected to your extension. C Wagner (talk) 07:19, 6 August 2016 (UTC)

Using a template to hold a form parameter value
I would like to use the same tree structure on several forms, and have it be relatively easy to add elements to that tree structure -- i.e. I don't want to have to edit each form to keep them all in sync. This could be done by setting up categories for all the tree nodes, but I'd prefer to avoid creating all those categories. I've tried using the following:

where Template:Hierarchy is looks something like:


 * Root
 * Child 1
 * Child 2

... but when the form is rendered, this gives a blank box with a stray }} afterwards.

Should it be possible to use templates to provide form parameter values? If so, how should I do it? If not, can you suggest another way to approach this? (The HierarchyBuilder extension looks good, but unfortunately we're using Cargo, rather than SMW.)

Many thanks! Paul T (talk) 14:51, 9 August 2016 (UTC)


 * I first thought this was a more complex problem, but actually it's just due to the 2nd issue described here. If you put a space before the three closing brackets, it should work. Yaron Koren (talk) 17:35, 9 August 2016 (UTC)


 * Thank you. Adding a space fixes it. Apologies for overlooking that. Paul T (talk) 10:50, 10 August 2016 (UTC)

undefined SF_Namespaces with German language code
in our german mw $wgLanguageCode = "de"; (switch to "en" -> no warnings)

i got warnings of not defined SF_NS_FORM and SF_NS_TALK in SF_Namespaces.php.(since mw125)

so i have to wrote in begin of extensions/SemanticForms/languages/SF_Namespaces.php

(like it was done in Maps/Maps.i18n.namespaces.php for the layer-namespace)

Is this a known problem? - Flexmaen (talk) 21:59, 10 August 2016 (UTC)


 * That's strange - I haven't heard of that one before, I don't think. What version of Semantic Forms and MediaWiki are you running? And are you running Semantic MediaWiki as well, and if so, what version? Also, are you calling SF after SMW in LocalSettings.php (assuming you're using SMW)? Yaron Koren (talk) 02:30, 11 August 2016 (UTC)


 * MW 1.27, SMW 2.4.1, Semantic Forms 3.6. Installed via composer which first calls for SMW and then for SF. - Flexmaen (talk) 11:09, 11 August 2016 (UTC)


 * Ah - the use of Composer is probably the issue. SF fails in different ways when it's installed with Composer; I believe that with the very latest version of SF, Composer is now disabled. I would uninstall SF with Composer and then download/install it in the "normal" way. Yaron Koren (talk) 13:23, 11 August 2016 (UTC)


 * This problem also exists when SF is installed the "normal" way. This was not our first installation - we installed SF many times now, but this time had this problem with the specific versions. So maybe someone could check if this is not a general problem rather than a mistake in the installation procedure. - Flexmaen (talk) 10:53, 13 August 2016 (UTC)


 * Alright. My new guess is that this behavior is due to changes in SMW 2.4.1, which was just recently released, which is why no one else has pointed out this error yet. Anyway, I just checked in what I think is a fix, based on your fix - it does seem to be a more reliable solution. Thanks! Yaron Koren (talk) 19:03, 14 August 2016 (UTC)

Classes for links and buttons
Hi Yaron, I was wondering if you could add a small new feature to the next release of SF. Those default grey buttons are not exactly eye-candies so it would be wonderful if the #forminput, #formlink and #autoedit parsers let you add a text and button class. I'm sure that others would appreciate this. Cavila 08:24, 15 August 2016 (UTC)


 * Are you talking about setting the appearance of those buttons across the wiki, or just in individual pages? If it's the former, most of those inputs already have classes you can use. Yaron Koren (talk) 15:49, 15 August 2016 (UTC)

Thanks, I was thinking of the latter. As for the former, I did not find any classes associated with #formlink. When either button or post button is specified as link type, the result just looks like this in html:  test test test (SF 3.6). The #autoedit parser looks fine. Cavila 12:01, 16 August 2016 (UTC)


 * Yes, I should add a class for #formlink - although it wouldn't help you, if I understand it correctly, since you want custom display per input. You could always put a div or span tag around the relevant input, I would think - like " &lt;span class="myClass"&gt;&lt;span&gt; " - then set the CSS using that class. Yaron Koren (talk) 15:57, 16 August 2016 (UTC)


 * That'll do for now, thanks. I first need to test this but I guess that a CSS class 'wrapper' is currently the best option, provided that that you use > (child) selectors and a div rather than span. Cavila 18:27, 18 August 2016 (UTC)


 * Okay, great. But wouldn't both div and span work? Yaron Koren (talk) 12:47, 22 August 2016 (UTC)

sort order of values input type checkboxes
How are values in a form using the input type checkboxes sorted? Is there a way to force a specific sorting method? C Wagner (talk) 14:14, 17 August 2016 (UTC)


 * Alphabetically, if I remember correctly. There's no way to change the sorting in the form definition - though you could probably accomplish it with some sort of JavaScript hack in MediaWiki:Common.js. Yaron Koren (talk) 14:47, 17 August 2016 (UTC)


 * I would be glad if the values would be sorted alphabetically. Is there a way to force alphabetical sort order? C Wagner (talk) 13:25, 19 August 2016 (UTC)


 * It displays alphabetically for me... where is your checkboxes input getting its values from? Yaron Koren (talk) 12:49, 22 August 2016 (UTC)


 * It sorts "Alpha, Beta, alpha, beta". But in my opinion it should sort "Alpha, alpha, Beta, beta". The values are manually entered text. C Wagner (talk) 15:20, 22 August 2016 (UTC)


 * That does sound like a bug - although I can't reproduce it; I just tried it out, and the sorting happened for me in a case-insensitive way. By "manually entered", do you mean that the values are coming from an SMW property? If so, what type is the property, and what version of SMW and SF are you using? Yaron Koren (talk) 19:57, 22 August 2016 (UTC)


 * I'm using SF 3.6; SMW 2.4.1; MW 1.27.0  I entered the values directly in the form:  . The corresponding SMW property is of type text. C Wagner (talk) 14:09, 19 September 2016 (UTC)


 * That's strange - for me, the "checkboxes" input doesn't sort at all when the values are entered manually; they're simply displayed in the order they appear in the form definition. You could try upgrading to the latest version of SF, 3.7... Yaron Koren (talk) 15:58, 19 September 2016 (UTC)

Tooltip not working
It looks like the 'title' attribute needed to enable to the 'tooltip' feature in #formlink/#autoedit is missing for the (post) button link. It's working fine with regular links. There is a workaround (wrapping a div with the title attribute about the whole thing - sounds familiar eh?), but it would nice if this were fixed. Cavila 13:59, 24 August 2016 (UTC)


 * Yes, indeed - I guess I never tested it with buttons. I just checked in a patch so that "tooltip" should now work with #formlink and #autoedit (and #formredlink). Yaron Koren (talk) 14:00, 26 August 2016 (UTC)

#autoedit overwrites every template of the target page
Hi,

I'm trying to edit a page through #autoedit. But everytime the button is clicked, the target page is completely edited. Means, that all the existing templates with their parameters are overwritten. There isn't any template left with parameters. Even the template, which is adressed in the query string hasn't been edited.

I'm using MediaWiki 1.26.3, Semantic MediaWiki 2.4.1 and Semantic Forms 3.6 I've got an older Wiki with MediaWiki 1.24.2, Semantic Mediawiki 2.1.3 and Semantic Forms 3.2. In this one the parser function works fine.

Is there any bug with the new version of Semantic Forms? Thanks a lot!


 * I just tried this out, and I too am seeing problems with #autoedit, although not quite the ones you're describing. The only issue I see is that, for forms with more than one template, templates that are not included in the query string get deleted from the page. Which is obviously not good, but it's not as bad as the query string having no effect, which is what I think you're talking about. In your #autoedit call, are you sure that the query string is correct, including capitalization? Yaron Koren (talk) 20:59, 25 August 2016 (UTC)


 * You were right, there was a missing letter in the query string. After I tried with the correct query string the value were written in the target page. At the moment it seems to best solution to write all the existing templates in the query string.


 * Is there anything I need to be aware when I adress multiple instance templates in the query string? I'm using exactly the same query string syntax, which I've been using in the older wiki without any problems: query string=TEMPLATENAME[1][subject]=value one&... After the autoedit button is clicked the value is written on the page twice:


 * I just tested the following query string syntax: query string=TEMPLATENAME[2][subject]=value two&... the result is that value two is also written on the page twice and value one is overwritten:


 * I don't know if there's a way to get #autoedit working with multiple-instance templates right now, unfortunately - clearly there are bugs in the implementation. Yaron Koren (talk) 10:53, 29 August 2016 (UTC)

Generating an article title based on semantic form input
I wonder whether there is a way (perhaps a spinoff extension?) that allows to create a new article based on semantic forms but with the article title generated from the form inputs. So This would look like  but without an input to enter the article title. The article would be created with a title generated from the form inputs. Would be great if someone could point me into the right direction. --Danwe (talk) 10:24, 25 August 2016 (UTC)


 * Hi - this may be what you're looking for. Yaron Koren (talk) 17:27, 25 August 2016 (UTC)


 * Thank, you. That's it. --Danwe (talk) 07:01, 5 September 2016 (UTC)

Custom functions in form fields
Hi all,

We are using Semantic Forms (latest stable) for defining predefined structure for new pages.

For example, a user goes to Special:Forms, chooses a form and starting to enter text to input fields of the form. All input is finished, the user clicks "Save page".

At this moment we need to do some validation of data entered to the form, e.g. check if the string of the field conatins certain text using regexp.

Is it possible to pass such functions (javascript/php) to mediawiki form? Any ideas will be appreciated.

Thanks!


 * What about Extension:Semantic_Forms/Input types ? Cavila 09:51, 28 August 2016 (UTC)


 * That is it, thank you!

Customising the WikiEditor toolbar in Semantic Forms
Others have asked about this before (see especially this thread on the mailing list), but I don't think any up-to-date solution has been proposed as yet. Recommendations that have been made to date don't work for me with Wikieditor 0.4.0 and SF 3.6, so it seems like a good time to bring it up again.

If I understand WikiEditor's documentation correctly, the first thing to do with javascript is to set the condition under which custom code (for adding, removing or modifying toolbar elements) is to be triggered. if ( $.inArray( mw.config.get( 'wgAction' ), [ 'edit', 'submit'] ) !== -1 ) stuff here };

Part of the older solution was to add 'formedit' to the array here, but on loading a form, wgAction is actually set to 'view' rather than 'formedit'. If 'view' is added to the array instead, or if the condition is removed altogether, all input fields in the form are moved to the top of the form. Similarly, I've tried 'wgCanonicalSpecialPageName' with the value 'FormEdit', but this leads to the same behaviour. (Incidentally, Yury talked about inputs being "glued together", which sounds similar, but the specific context that he was referring to seems to be a form loaded by putting "action=formedit" in the url).

In other words, it's perfectly possible to set the condition (using 'wgCanonicalSpecialPageName' is probably the way to go), but what follows is a bit of a mess and I really wouldn't know how to go from here.

P.S. As for this passage from the docs:
 * If you want to add any additional custom toolbars to WikiEditor, you will need to add them in the Javascript to, just as they exist for.

This, of course, is intended for free text input only, although in SF 3.6 at least the textarea section uses id="sf_free_text" rather than id="free_text". If WikiEditor is enabled for any other field, numbered ids are used instead ("input_1", "input_2", etc., if I recall correctly). The alternative, or so I would think, is to use the "wikieditor" class, which has the advantage of being consistent across textarea fields using the editor.

Cavila 09:48, 28 August 2016 (UTC)

Postprocess user input
Hi All,

We have requirement to postprocess some text entered to the form field - for example, a user enters something like text1.jpg into the text field and clicks "Save page". After that the .jpg part of the text input should be stripped off and the result text should be text1.

Any ideas on how to implement that?


 * Semantic Forms doesn't let you alter what the person entered - that's done on purpose. However you can change the display to not show the file extension part - there are various ways to do that, including the ParserFunctions extension. Would that work for you? Yaron Koren (talk) 13:37, 30 August 2016 (UTC)

Dropdowns in Spreadsheet Style Editing
Hi all,

Do dropdowns work in spreadsheet style editing? I have not been able to get them to work. Are there any restrictions on dropdowns in spreadsheets?

Thank you,

JLara


 * What did you try? Did you set a "values=" parameter? Yaron Koren (talk) 13:38, 30 August 2016 (UTC)


 * Hi Yaron, Here's what I tried for the form:

/*Table Declaration */

/*Template*/


 * I just tried this, and it works for me - I see dropdowns in the "Customer" and "Company" columns. What version of SF are you running? Yaron Koren (talk) 15:29, 1 September 2016 (UTC)


 * I'm using Semantic Forms 3.6. I can enable dropdowns in the normal view but not in the spreadsheet view. I added the table declaration above in case that makes a difference. I've tried it on MW 1.25.3 and 1.26.2 (fresh install).


 * I doubt that's the issue... although I think you should change most or all of those fields from type "Text" to "String" - a relatively new field type in Cargo. Yaron Koren (talk) 00:21, 7 September 2016 (UTC)


 * Thanks for your help so far Yaron. I'm still not able to figure out why I can't get the dropdowns in spreadsheet display. Do you have an example or sandbox wiki where I can try out spreadsheets/dropdowns? -JLara


 * You can see a demonstration (including a dropdown field) here. Yaron Koren (talk) 13:20, 13 September 2016 (UTC)


 * Thanks! The working example helped. It still didn't work on my server but it started working when I used Semantic Forms 3.7 instead of 3.6. Not sure if related but I also noticed the following console errors disappeared between 3.6 and 3.7: Use of "sfgGridParams" is deprecated. Use mw.config instead. Use of "sfgGridValues" is deprecated. Use mw.config instead.</tt> -JLara


 * Great! Yes, that warning message was fixed. I doubt it's related, but who knows. Yaron Koren (talk) 02:00, 20 September 2016 (UTC)

Showing CAPTCHAs for "formedit"
Is there a way to allow showing CAPTCHAs for the "formedit" action? At least when using ReCAPTCHA (NoCAPTCHA) via the ConfirmEdit extension it is only shown after the first failed attempt to save a page. I know there is an issue with popup forms but this one here is a "regular" form. Cheers --&#91;&#91;kgh&#93;&#93; (talk) 15:10, 1 September 2016 (UTC) // MediaWiki 1.27.1 (17e44c4) - Semantic Forms 3.6 (0dae7d5) - ConfirmEdit 1.4.0 (dbff612)
 * I guess these extensions are just incompatible. Never mind. --&#91;&#91;kgh&#93;&#93; (talk) 20:46, 7 September 2016 (UTC)

Save page as
Hi All,

We are using Semantic Forms to create forms for page creation. Once user has created a page using form, a user might need to create another page from the existing page. In other words we need an implementation of "Save page as" functionality.

Any ideas how to implement that?


 * I don't think there's any way to do the exact thing you're asking about - though there's no specific reason why it should be Semantic Forms that provides it. But what you can do is have, within each page, a #forminput or #formlink call (depending on the form being used) that contains a parameter like " preload= ". Which may be close enough. Yaron Koren (talk) 01:55, 5 September 2016 (UTC)

New example for “holds template” and “embed in field”
This got asked before but it seems the example that was given in 2011 is offline now. Is there any other example somewhere? I tried to play with this but didn't really achieve anything - at least not what I imagined this would look like. --Danwe (talk) 13:41, 4 September 2016 (UTC)


 * Ah, yes. Here's a live example (though this form is not actually in use). Yaron Koren (talk) 02:01, 5 September 2016 (UTC)


 * Cool! I updated the documentation to link to that example as well. Thank you. --Danwe (talk) 07:26, 5 September 2016 (UTC)


 * Great, thank you! Yaron Koren (talk) 12:50, 5 September 2016 (UTC)

Dynamically generating a form via template
I am trying to generate a form via a template.

So on the form's page I am calling  and in my Generate form template I am building all the required markup. I am doing this by using  and my own   (for  ) and. Semantic forms seems not to accept this generated markup. When I attempt to use the form, I get "No target page specified." even though it is. Generated is a form link and the following form markup:

Name:

If I copy the same markup into another form page, then that works. Any idea how to marke this generating of forms via template work? --Danwe (talk) 07:38, 5 September 2016 (UTC)


 * Does it work if you set a target name? Is that the only issue? Yaron Koren (talk) 12:52, 5 September 2016 (UTC)


 * Great, that's like a light at the end of the tunnel. With an additional  I get the form generated at least. But I don't quite understand why it doesn't work without the target name. After all, I want the title auto generated from the   section. Any idea what is preventing this from working here? --Danwe (talk) 17:48, 5 September 2016 (UTC)


 * Ah. My guess is that the angled brackets in the "page name=" value are getting parsed too soon. Maybe try replacing them with "&amp;lt;" and "&amp;gt;", or with templates? Yaron Koren (talk) 22:11, 5 September 2016 (UTC)


 * No, that's not it I am afraid. Even if I change it to  (something entirely without angled brackets) the same issue still occurs. It's more like the link is not able to find the `  section and therefore doesn't know how to construct the page name...  --Danwe (talk) 23:02, 6 September 2016 (UTC)


 * Now, that's it^^ If I do:
 * then it works... The link generated in Generate form Special:FormEdit will then find the info section. Now, that's no solution but at least we know the cause now. I have to think about this more. --Danwe (talk) 23:09, 6 September 2016 (UTC)
 * then it works... The link generated in Generate form Special:FormEdit will then find the info section. Now, that's no solution but at least we know the cause now. I have to think about this more. --Danwe (talk) 23:09, 6 September 2016 (UTC)


 * There is a live example now (here). The first "New" link shows the bug, clicking the second "New" link works since a target is set explicitly. --Danwe (talk) 01:04, 7 September 2016 (UTC)


 * I thought about this some more - the "info" tag does get parsed differently from the other tags, since it's a directive and not a form component. Try not escaping the "{{{" around it. Yaron Koren (talk) 13:45, 7 September 2016 (UTC)


 * The info tag is also generated in the template. The template gets transcluded into the Form page and if I don't escape the "{{{" then the parser treats it as a template parameter. But despite that, it seems the "info" tag parser just takes the form page and doesn't parse it but instead just does a string operation to grab the info tag. So with the current implementation I will probably never be able to generate the info tag from within a template while everything else works quite well.
 * So my only option right now is to define two things in my Form pages: A template call plus an info tag. Unless I get some time to fix the code - but I have this project deadline looming over me ;-)--Danwe (talk) 20:31, 7 September 2016 (UTC)


 * Ah. If you need a quick fix, I guess you could always modify that line in the SF code... Yaron Koren (talk) 22:01, 7 September 2016 (UTC)

Hide empty field
Hi all,

by default, if user doesn't type something into the field, the label of that field is displayed on a page. Is there a way to omit field label if the field is not populated?


 * You have to edit the template which the form is reporting to and just hide the field if that parameter is empty (basically it comes down to ). If you use Extension:Page Schema there is also a "Display if not empty" field option in the schema. --Danwe (talk) 17:26, 5 September 2016 (UTC)

Tag for 3.7
Thank you for the new release of Semantic Forms. Cannot wait to pull it. It will be nice to get a tag for it. Thanks and cheers --&#91;&#91;kgh&#93;&#93; (talk) 20:47, 7 September 2016 (UTC)


 * Yes, sorry about that - there was a problem creating the tag, but it's done now. (Now that git.wikimedia.org is gone, tags have become necessary for downloads, which is kind of strange.) Yaron Koren (talk) 15:32, 8 September 2016 (UTC)


 * Thank you and no worries. I just wanted to check if the latest bug I reported was indeed fixed. Indeed WMF have a mind of their own when it comes to deploy stuff. They actually believe there is not reason for tagging at all - just use REL for cloning and downloading. However, we will cope. --&#91;&#91;kgh&#93;&#93; (talk) 15:40, 8 September 2016 (UTC)

SF 3.7 - Missing "two listboxes"
Hi,

our whole wiki depended on the input format "two listboxes". Unfortunately, this isn't available in SF 3.7 anymore. Can I place a feature request on this? Or is there another input type, where the user just has to click on an item in a list? Except for "listbox" which isn't as userfriendly as "two listboxes" was.

Thx RacingRalf (talk) 09:26, 12 September 2016 (UTC)


 * Answering the question myself: "two listboxes" is still available. Seems "redirected" to "tokens" RacingRalf (talk) 09:26, 12 September 2016 (UTC)


 * Good to know since I remember now that I have worked with a couple of wikis using "two listboxes" in the past. I believe this should somehow be documented. Currently the docu is still referring to the Semantic Forms Inputs extension. Cheers --&#91;&#91;kgh&#93;&#93; (talk) 12:10, 12 September 2016 (UTC)


 * "two listboxes" has always been part of Semantic Forms Inputs - it was never part of Semantic Forms. I don't think it's "redirecting" to "tokens" - rather, "tokens" is presumably the default input type for that form field or fields, when SF can't find the specified input type. You might still be able to use "two listboxes" if you re-install SFI - it's listed as obsolete, though I don't know if it's already unusable. Though I do think "tokens" is the better alternative to "two listboxes" - which is a big part of the reason why I didn't copy it over to SF. (That and the fact that I didn't know if anyone was using "two listboxes".) RacingRalf - what do you think - do you still think "two listboxes" has advantages over "tokens"? Yaron Koren (talk) 13:00, 12 September 2016 (UTC)

Use "free text" at certain position within template?
Hi Yaron, is it possible to use the "free text" at a certain position within a template - like  or similar? I would need to place the free text as in input for another template in my template:.

Up to now I used a field instead of "free text" but the problem is that I can't edit subsections in my article then. With "free text" I could edit subsections... --Stefahn (talk) 11:16, 13 September 2016 (UTC)


 * No, unfortunately there's no way to do that. If you know what the section names will be ahead of time, you could use the "section" tags to have a separate form input for each one... Yaron Koren (talk) 13:17, 13 September 2016 (UTC)


 * Luckily I found a workaround. I use 2 different templates now within my form and "free text" in the middle. At the end of the first template there is some HTML code which is closed in the beginning of the second template. Works great :) See you at SMWCon in Frankfurt :) --Stefahn (talk) 20:05, 13 September 2016 (UTC)

Link entries to Wikipedia-Articles
This is not entirely a question for Semantic Forms. But maybe someone here has already done that or knows a solution:

In a form I added the possibility to enter a city name. How can I generate a link to the Wikipedia-Article with the name of the City? C Wagner (talk) 14:19, 19 September 2016 (UTC)


 * Just put in something like " http://en.wikipedia.org/wiki/ ", I would think. Yaron Koren (talk) 02:02, 20 September 2016 (UTC)


 * Thanks, that works well for city names with just one word. But what about something like "New York City". Is there some kind of parser to replace spaces with underscores? C Wagner (talk) 06:47, 20 September 2016 (UTC)


 * To do this in a more robust way you can use the Interwiki extension. You can then do  or   which can results in: New York City. You can setup the Interwiki extension just the way you want. Regards, --Felipe (talk) 09:08, 20 September 2016 (UTC)


 * That is indeed the better solution, though if you want to do a text replacement, you can use the #replace function from the ParserFunctions extension. Yaron Koren (talk) 13:41, 20 September 2016 (UTC)

UX improvement suggestion for tokenized autocomplete
When entering text into field that's defined to hold a list of page names, the autocomplete and "tokenizing" behaviour looks great and works well. I have one minor suggestion for an improvement: where the field allows new values as well as existing values, it's not always clear to the user whether they've matched an existing value or are creating a new one. The auto-complete dropdown shows what you've typed (whether it's a match or not) first, followed by any other matches, but there's no visual distinction between them. The user would have more of a clue if (for example) the dropdown text was only emboldened if it's a match. Alternatively (and maybe more obviously) it might make sense for non-matches to be red (analogous to the idea of a red link) -- this approach could be extended to the token display, as well as the autocomplete dropdown. Paul T (talk) 10:23, 27 September 2016 (UTC)


 * This sounds like three different ideas: un-bold new values in the dropdown, change the color of new values in the dropdown, and change the color of tokens representing new values. The first two only cover the initial entry of the data, while the third one would (I assume) take effect each time someone went to the form. The first one seems doable - just a matter of removing the bolding - though I don't know how big a difference it would make. Have you heard from others that the data entry for new values can be confusing? For the second two - and especially the third one - I'm loath to make any substantial changes to the input behavior, because I don't want SF to be pioneering anything in terms of interface. I'd rather use approaches that have undergone usability testing, etc. by others, and match what users already expect to see. That's not always possible - I've had to basically invent some things - but the goal is to be consistent with other interfaces (and especially with the MediaWiki interface, though I don't think MW has any sort of "tokens" input yet). So unless someone else has implemented different-colored tokens, I don't want to get involved with it. The first idea, though, is not unreasonable. What do you think? Yaron Koren (talk) 02:09, 28 September 2016 (UTC)


 * You're right, it is three separate ideas. I haven't had reports from users that they're confused by this, but I did find myself in a situation where I realised that there was no way to tell whether I was going to create something new or not. It strikes me that the first and second ideas are interchangeable, and could be implemented by the one change: by exposing through CSS whether the autocomplete suggestion is a match or not. (That would also be a good way to make the third idea optional.) Paul T (talk) 10:59, 28 September 2016 (UTC)

Fields dependencies
Let's say we have the field A, and the field B. Now, we want to make a validation - if user types the text into field A, then the field B must be empty. And vice versa - If user types the text into field B, then A must be left empty. In other words, only one of two fields must be fulfilled before clicking "Save" or "Preview page" buttons. Is that possible in Semantic Forms?


 * I don't think so. What you can have, though, is a dropdown field that lets users select either A or B - when used with "show on select", you can set it up so that only field A or field B is displayed at any one time. Yaron Koren (talk) 14:03, 27 September 2016 (UTC)

Disabling Semantic wiki syntax in Form Fields
Hey all, is there a way to force forms to cleanse semantic wiki syntax (such as #ask: or #show:) from its fields? In our wiki we would like to avoid users from seeing the list of all users in any way possible, but today we found out you can technically find out if you know you can write asks in the Description of an Event (for example) and you know the category of the users (and the pages Category:User and all Special Pages were explicitly set to only be visible by Admins for this exact purpose).

I would prefer avoiding using a widget to disallow 🇦🇩 characters from fields but I guess I will have to do that if there are no better options.


 * I don't think so. More generally, I think it would be very difficult to fully prevent users from accessing this information - and the attempt to do so would severely hamper the running of the wiki. You've already restricted all special pages - which has removed a lot of useful functionality, like search and watchlists. In addition, you would have to disable the API, remove free text inputs from all forms, remove access to "action=edit", and even then I'm not sure the user list information would be inaccessible. I don't know what the real goal is, but it may be worth rethinking your approach. Yaron Koren (talk) 12:32, 3 October 2016 (UTC)


 * Thanks for the answer. I agree that our implementation of MediaWiki is not classic and might go against some principles of the framework itself, but we cannot change it mid-development so there's that. In the end we went with a Widget approach that disables the usage of ,, and |field_ from all our form fields. This does not solve the issue for people who actively want to retrieve information, but it should be enough to prevent semi-involuntary attempts to mess with pages users can edit.