Extension talk:Page Forms/Archive August to October 2016

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:<unique ID>" 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 [1] 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 {{#time:d.m.Y|{{{fieldname|}}}}} 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:

{{{field|My field|input type=tree|structure={{Hierarchy}}}}}

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

if (!defined( 'SF_NS_FORM'))
{
  define('SF_NS_FORM' , 106);
  define('SF_NS_FORM_TALK' , 107);
}

(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:

<form action="/Special:FormEdit/Test_form/Test_page" method="get" target="_self">
<button type="submit" value="test test test">test test test</button>
</form>

(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 "<span class="myClass">{{#forminput:...}}<span>" - 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: {{{field|FieldName|input type=checkboxes|values=Alpha, alpha, Beta, beta}}}. 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:

{{TEMPLATENAME

|subject=value one

}}

{{TEMPLATENAME

|subject=value one

}}

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:

{{TEMPLATENAME

|subject=value two

}}

{{TEMPLATENAME

|subject=value two

}}

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 Special:FormStart 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#regexp ? 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 ('#free_text').wikiEditor, just as they exist for ('#wpTextbox1').wikiEditor.

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:

{{{for template|SOE_Prerequisites|multiple|display=spreadsheet}}}
<div>
{| class="formtable"

|'''Version''' 
|{{{field|Version|input type=text}}}'''
|'''Subcomponent''' 
|{{{field|Subcomponent|input type=text}}}'''
|-
|'''Note'''
|{{{field|Note|input type=text}}}'''
|'''Third party component prerequisites'''
|{{{field|ThirdParty|input type=text}}}'''
|-
|'''Acquired by customer''' 
|{{{field|Customer|input type=dropdown|values=Yes,No}}}'''
|'''Provided by Company'''
|{{{field|Company|input type=dropdown|values=Yes,No,Resell}}}'''
|-
|'''Conditions/Limitations'''
|{{{field|Conditions|input type=text}}}'''
|}
</div>
{{{end template}}}

/*Table Declaration */
{{#cargo_declare:_table=SOE_Prerequisites|Version=Text|Subcomponent=Text|Note=Text|ThirdParty=Text|Customer=Text|Company=Text|Conditions=Text}}

/*Template*/
{{#cargo_store:_table=SOE_Prerequisites
|Version={{{Version|}}}
|Subcomponent={{{Subcomponent|}}}
|Note={{{Note|}}}
|ThirdParty={{{ThirdParty|}}}
|Customer={{{Customer|}}}
|Company={{{Company|}}}
|Conditions={{{Conditions|}}}
}}

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. -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 --[[kgh]] (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. --[[kgh]] (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={{PAGENAME}}". 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 {{Generate form|awesome}} 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:

{{{ info | page name = Foo 1/<unique number;start=1> }}}
{{{ for template | My template }}}
Name: {{{ field | Name | property = Name }}}

{{{ end template }}}

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 target=foo 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 {{{info|...}}} 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 "&lt;" and "&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 page name=Foo (something entirely without angled brackets) the same issue still occurs. It's more like the link is not able to find the `{{{info|...}}} 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:

{{Generate form|awesome}}
{{{ info | page name = Foo 1/<unique number;start=1> }}}

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 {{{param|}}} | {{{param}}} }}). 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 --[[kgh]] (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. --[[kgh]] (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 --[[kgh]] (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 {{{free text|}}} or similar? I would need to place the free text as in input for another template in my template: {{TwoColumns|1={{{free text|}}}}}.
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/{{{City|}}}", 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 [[Wikipedia:New York City|New York City]] or [[Wikipedia:{{{City|}}}|{{{City|}}}]]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 {{ and }} 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 {{ , }}, [[Category:XYZ]] 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.

Edit with form

In Special:SpecialPages under Semantic Forms, the link Edit with form goes directly to Special:FormEdit, it is not asking the user which form name and target page that should be edited so users are not redirected to Special:FormEdit?form=<form name>&target=<target page>", or "Special:FormEdit/<form name>/<target page>.

Even with forms created, users are not asked which form they want to edit with Special:FormEdit which says this twice:

No target page specified.

This is the page for editing with a form. You must specify both a form name and a target page in the URL; it should look like "Special:FormEdit?form=<form name>&target=<target page>", or "Special:FormEdit/<form name>/<target page>".

No target page specified.

This is the page for editing with a form. You must specify both a form name and a target page in the URL; it should look like "Special:FormEdit?form=<form name>&target=<target page>", or "Special:FormEdit/<form name>/<target page>".

It's not good that the error message shows up twice, but in any case, I don't think there's any guarantee that Special:SpecialPages functions as a sort of dashboard, i.e. that every link in that page will lead to some meaningful interface. Let me know if you disagree. But the lack of a true dashboard for MediaWiki is why I created the Admin Links extension. Yaron Koren (talk) 23:45, 10 October 2016 (UTC)

"random" page name shows http error 500

Hello, I've tried to use "random" in the one-step process for creating page names, but this gives me a 500 HTTP error. It won't save the page. When I create with something like {{{info|page name=ANL<unique number;random;6;>}}} I only get the result of ANL, ANL1, ANL2, when I use the version without comma {{{info|page name=ANL<unique number;random;6>}}}, I get code 500. It is working with something like {{{info|page name=ANL<unique number;5;start=00001>}}}, where I found the "start" to be stronger than the number given. Any ideas why the failure of "random" is happening? --Zabien (talk) 17:09, 11 October 2016 (UTC)

That's strange that the version without the semicolon at the end doesn't work... would this help in seeing the actual error message? Yaron Koren (talk) 19:11, 11 October 2016 (UTC)

Focus on input

Hi!

I have installed in my wiki and everything works fine, but I would like to know if there is any way to disable the focus in the input field when I enter in a page where I have a {{#forminput}}. I have the input in the main page and when I enter in it, the view moves to the field and it is ready to write in the field. Is there anyway to disable this focus?

I don't know if I explained fine that, therefore I share with you my project to test it yourself. Thanks in advance.

Regards, Ivanhercaz (talk) 15:15, 12 October 2016 (UTC) Please, {{Ping }} me to receive a notification.

The #forminput function has a "no autofocus" parameter - you should try that, if you haven't already. Yaron Koren (talk) 02:35, 13 October 2016 (UTC)

Hiding the image name on image-upload

Dear Yaron,
Many thanks for your fantastic and continuous work on Semantic Forms! We love it! One question: Is there a way to hide the (pre-defined) image name in the form for image upload? So that the user only sees the link for uploading files (and after the upload the image-preview). This would be very useful as it makes the upload even more user-friendly. The text-box can be a bit confusing for not so experienced users. Many thanks again and best wishes, --Kasimir Katowitsch (talk) 12:01, 24 October 2016 (UTC)

You could probably use CSS to hide it, but there's no official way to do it. That's an interesting idea, though. Yaron Koren (talk) 16:50, 24 October 2016 (UTC)

Just use the "class" parameter to the field tag like e.g. {{{field|Logo|uploadable|class=hidecreateboxInput}}} and then add the following CSS to your "MediaWiki:Common.css" page:

#sfForm .hidecreateboxInput {
    display: none;
}

However, total disaster strikes after clicking the upload link, but that's another story. Cheers --[[kgh]] (talk) 23:25, 7 November 2016 (UTC)

Problem with input type Tree

Hi,

First of all, thanks for the great extension.

I experience the following problem (MW 1.27): when using the input type tree (with the structure= parameter) in a multiple instance template call, after a first selection has been saved, the tree interaction does not work as well: the tree branches can not be expanded or collapsed anymore. If the instance is removed, and another added, the tree interacts fine (the + and - icons work as expected).

This shows in the console: 19:54:4.121 - Dynatree._create(): version='$Version: 1.2.4$', debugLevel= 1 .load.php:2:717 Use of "wgWikiEditorEnabledModules" is deprecated. Use mw.config instead.

I'd be happy to provide with more information.

Thanks for any help.

Sorry for the long delay. There are various JavaScript elements that don't work correctly in newly-created instances of multiple-instance templates - this is apparently one of them. I hope to fix this. Yaron Koren (talk) 02:18, 15 November 2016 (UTC)

Customized form chooser

I would like to link all my red links to forms. Ideally I would use a customized version of the form chooser. Instead of a full list of all forms with the default message I would like to show my users:

• the single form to be used for 9 out of 10 pages highlighted,
• a list of the other available forms, leaving out the query forms,
• an explanation, for example when to create a page without a form.

Is something like this currently possible? If not, is it possible to enable customization of the existing feature, for example by adding a variable to set a custom form in LocalSettings? − Ecthelion3 (talk) − Kerkliedwiki (MW 1.26.3 / SMW 2.4.1) 10:02, 28 October 2016 (UTC)

No, it's not currently possible. Out of curiosity, how would you imagine such a thing would be defined? Via its own form? Via some settings (like "most important forms = ...")? Via custom PHP? Yaron Koren (talk) 12:48, 28 October 2016 (UTC)

My idea was to have this defined via a custom form. If needed you can set the name of this custom form in LocalSettings using an additional variable. The name of the new page can passed as an parameter. Unfortunately I don't know any PHP at this moment, so I don't know if this can be implemented. I do think it would make the form chooser much more usefull. − Ecthelion3 (talk) − Kerkliedwiki (MW 1.26.3 / SMW 2.4.1) 12:23, 8 November 2016 (UTC)

This could be implemented, but it might be overkill, if all that's needed is a way to separate out the more important forms from the less important ones, plus some custom text. Yaron Koren (talk) 13:48, 8 November 2016 (UTC)