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)

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)

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)

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)