Extension talk:Page Forms/Archive August to December 2017

"Run query" does not ask for user input

In Special:SpecialPages under Page Forms, the link Run query goes directly to Special:RunQuery, it is not asking the user what to run. This is what Special:RunQuery saying:

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

Error: No form was found on page "".

--David Hedlund (talk) 21:25, 6 August 2017 (UTC)

That's true; you shouldn't go to Special:RunQuery by itself; it should always be Special:RunQuery/FormName. Probably Special:SpecialPages shouldn't be linking to it. Yaron Koren (talk) 01:40, 7 August 2017 (UTC)

Validation about data submitted by users?

Hi everyone!

Here is my problem : I have created a form with two inputs of type "date" (a date of beginning and a date of end).

Do you know if it's possible to write an error on validation to the user if the date of end is set before the date of beginning?

More generally, is it possible to perform some checks about the data submitted by users?

Thanks a lot :)

Unfortunately, there's no way to do validation based on the value of more than one input - short of you adding in some custom code to do it. It would be great to be able to have that kind of "compound validation" - and I think ensuring that date B is greater than date A would be the most obvious use case for it. Yaron Koren (talk) 01:06, 8 August 2017 (UTC)

Ok... never mind, thanks for your response :)

Maybe another obvious use case would be to check that a submitted date is not before or not after the current date or a certain date?

That seems less useful, since users can presumably add an event at any point, even after it's happened. But who knows. Yaron Koren (talk) 01:23, 9 August 2017 (UTC)

Restricted fields are removed from template upon revision using form

I have a form and template wherein I set a few of the fields as restricted. When I revise the page using the form, those restricted fields are stripped from the page (not just the values, but the field names as well). Originally I had set these fields in the form to restricted=foo so that nobody could edit those fields, not even admins. But I verified this also happens with just the "restricted" parameter added.

Am I missing something or is this a bug?

--Darenwelsh (talk) 22:14, 7 August 2017 (UTC)

That's very odd. Could you pastebin the form definition or something? I don't see how the field name/label could be getting hidden as well. Yaron Koren (talk) 01:09, 8 August 2017 (UTC)

Please look at the example page I made on the SMW sandbox. I initiated the page with the same contents as the page in question on my wiki, with the same exact template and form. I then revised the page using the form and all the restricted fields have been stripped.

--Darenwelsh (talk) 14:09, 8 August 2017 (UTC)

Ah, I originally thought you meant that the field names disappear when viewing the form - now I understand.

I got worried when I saw what that form was doing to the page! Thankfully, at least part of the issue is that there are some problems with the form definition. There's an open comment tag (on the "OCAD Modification Timestamp" line) that's left unclosed, which comments out most of the form, leading to some strange behavior. Also, some of the fields (like "Control") are defined twice, which again leads to problems. There might still be some issues with "restricted", but could you clean up that form so that we can know for sure? Yaron Koren (talk) 01:13, 9 August 2017 (UTC)

Wow, I missed that sloppy oversight! Thanks for catching the unclosed comment tag and the duplicate fields. I think this has solved the issue. --Darenwelsh (talk) 02:56, 9 August 2017 (UTC)

Follow-up question - Is it default/expected behavior for PageForms to remove unused/empty fields from a template definition when a page is revised using the form? For example, if I revise a page, but leave some fields empty, it seems like either PageForms is removing the empty fields (in this example, "OCAD Training" is one of the fields that is removed.

--Darenwelsh (talk) 15:13, 9 August 2017 (UTC)

Yes, empty fields get removed - which doesn't change the display or behavior of the template in any way, but it could lead to confusion. If you think that's a mistake, and that every form field, and/or every field that was previously in the template call, should show up in the template call on the page, let's talk about it. The relevant section of code that controls this, by the way, is lines 107-109 of includes/wikipage/PF_WikiPage.php. Yaron Koren (talk) 17:33, 9 August 2017 (UTC)

I think it's worth a discussion with some other admins and power users. I found a workaround for what led me ask this, but it does strike me a little odd that the extension removes fields that could be later populated just because they are currently empty. It seems like unnecessary changes that add to the amount of info to digest when reviewing a page revision diff. --Darenwelsh (talk) 17:49, 9 August 2017 (UTC)

It may indeed be a useful discussion. There certainly are arguments in both directions, for both kinds of fields. And I believe Page Forms (then called Semantic Forms) did it the other way until a few years ago. Feel free to start a discussion about this if you want, on a mailing list or other forum. Yaron Koren (talk) 17:59, 9 August 2017 (UTC)

Perhaps a parameter called "sticky" is a way out allowing to define fields that should always be added into the template no matter if they are already holding a value or not. Or add all fields by default and not just if they have or had values ore not. --[[kgh]] (talk) 22:01, 14 August 2017 (UTC)

Out of curiosity, would either of these be useful to you? Yaron Koren (talk) 17:42, 15 August 2017 (UTC)

Currently I am quite happy that unused fields get removed however I see the issue with VisualEditor, TemplateData (currently I have no experience with the two) and source editing Daren brought up. I came up with the "sticky" idea because sometimes there may be so many field definitions that soon a page can be full of unused fields. Think of a multi instance template with 20 fields or so mixing in show on select etc.

When it comes to a cleaner diff view I believe that the fields should always stay in the same order whatever this order may be in the first place. So if they are saved in some order this order should stay the same during consecutive editing. On some occasions I had the feeling that the fields are initially stored in one order and are being rearranged to another order during consecutive edits. However a version and behavior change may have been the reason for this. --[[kgh]] (talk) 07:07, 16 August 2017 (UTC)

I don't know why you mentioned VisualEditor - it works hard to avoid any "dirty diffs", as the WMF people call them, by keeping not just the order but the formatting of infobox calls the same, although maybe that's what you mean. Personally, I don't see a real problem with "dirty diffs" - they do make it harder to track changes, but at the same time they standardize infobox calls. Yaron Koren (talk) 12:06, 16 August 2017 (UTC)

How to set Category from an input field

In my MediaWiki site with Page Forms extension, I'm trying to set the Category of a form-generated page with the value that the user introduces in a Combobox in the Form.

The part of the code of the Form where I get the Category name is in the SupraEspecie field of the DatosEspecie Template:

{{{for template|DatosEspecie|label=Data}}}
{| class="formtable"
! Nombre Especie: 
| {{{field|NEspecie|mandatory|restricted|default={{PAGENAME}}}}}
|-
! Nombre Cientifico: 
| {{{field|NCientifico}}}
|-
! '''SupraEspecie''': 
| {{{field|SupraEspecie|mandatory|input type=combobox|namespace=Category|values from namespace=Category|existing values only}}}
|}

Then I try to call another template that defines the category with the parameter received.

Basically a template named "CategoryDefinition" containing: [[Category:{{{1}}}]]

The call I'm using (in the same form) is:

{{{for template|CategoryDefinition|SupraEspecie}}}
{{{end template}}}

But it is wrong as the template CategoryDefinition is called but without any parameter.

What is the correct way of passing a field of a MediaWiki Page Form (in this case SupraEspecie) to a template in the form ( in this case CategoryDefinition)??

--JBBGlorfindel (talk) 18:32, 11 August 2017 (UTC)

Shouldn't there be something like "{{{field|1}}}" in that second form? Yaron Koren (talk) 19:33, 11 August 2017 (UTC)

Yes Yaron, thanks for the hint and sorry for my novice question, it is being difficult for me to understand the logic of this sintax.

--JBBGlorfindel (talk) 23:34, 11 August 2017 (UTC)

Datatype for uploading files

I can't seem to get the upload to work. When I created my form via the Create a Class tool, the datatype of my property was a URL (Property:Slides). I want my users to be able to upload a PDF into the Slides field. Not sure if I choose URL as the type or if the tool did. The upload worked as far as uploading the file but the validation on the field complain that it needed to start with "http:"

I changed the datatype to text but the upload link disappeared even though it still has the uploadable parameter. Any ideas as to what is going on here?

Thanks.

You should change the property type to "Page". Yaron Koren (talk) 23:16, 13 August 2017 (UTC)

Hi Yaron - tried changing the Property HasType to Page and form type to "field|Slides|input type=page|rows=1|uploadable". This goes through

the upload process but it doesn't upload. I basically get a link within the form to a non-existent form. Any ideas? Konjurer (talk) 17:31, 16 August 2017 (UTC)

There's no "page" input type; it should be "input type=text", probably. (There's not a 1:1 correspondence between input types and property types.) What do you mean by a non-existent form? What does the non-working URL look like? Yaron Koren (talk) 18:54, 16 August 2017 (UTC)

I changed the input type back to text but the situation remains. The file does upload but the link doesn't work. It's a redlink http://my_url.com/mywiki/index.php?title=Design_thinker_tool_tryExperiments_en.pdf&action=edit&redlink=1 Konjurer (talk) 23:58, 16 August 2017 (UTC)

I'm confused - this seems like a different problem from the one you described before. Is this non-working link in the form, or on the page once it has been saved? Yaron Koren (talk) 11:50, 17 August 2017 (UTC)

Let me first explain what I am trying to do. I want to create a Page Form that my users can upload a file PDF or PowerPoint file into. The purpose of the form is to create an overview of conference presentations. For example, let's say I saw Yaron Koran give an awesome presentation at SMWCon 2016 and I am going to write a review using a Page Form to capture the session title, session abstract, authors name, conference name, and upload the slides in PDF of PowerPoint to the wiki. I created a Form with 4-5 fields, all where the Property hasType "Text" and the one field is uploadable for the PDFs, etc. The upload of the file works! But when I view the new article that was created by the form, the link to the uploaded file is not correct. Here is an example of the link that the form captures after the upload...

http://my_url.com/mywiki/index.php?title=Design_thinker_tool_brainstormIdeas_en.pdf&action=edit&redlink=1

Thanks Yaron for your assistance.

If you go to "action=purge" for that new page - either directly or by hitting the "refresh" tab - does the problem go away? Yaron Koren (talk) 02:55, 21 August 2017 (UTC)

It should be creating a file link to the file in the File namespace and not a red link to an article in the Main namespace, right? Here is what it should be doing...

http://epedia.rockwellcollins.com/wiki/File:Design_thinker_tool_tryExperiments_en.pdf Konjurer (talk) 13:18, 21 August 2017 (UTC)

Here is my Form...

{{{for template|Conference Report}}}
{| class="formtable"
! Full Session Name: 
| {{{field|Full Session Name|input type=textarea|rows=2}}}
|-
! Presenter: 
| {{{field|Presenter|input type=textarea|rows=1}}}
|-
! Conference Name: 
| {{{field|Conference Name|input type=listbox}}}
|-
! Slides: 
| {{{field|Slides|input type=text|rows=1|uploadable}}}
|}

Oh, now I get it - the issue is in the template; it should look like "File:{{{Filename|}}}" instead of just "{{{Filename|}}}". Yaron Koren (talk) 16:07, 21 August 2017 (UTC)

That fixed the issue! Thanks Yaron! Konjurer (talk) 01:58, 22 August 2017 (UTC)

Jumping to the right instance of a subform

Hi Yaron. Re: "Are you asking about having a form that only edits one instance of a multiple-instance template?". As you know, this question has come up before. If the purpose is to immediately direct editors to the right instance in the form (and return to the same page section?), without them having to scroll down the page, then a good alternative solution I think would just be to let the form jump to the right location, probably based on an anchor link for the id attribute. For this to happen, you'd need two things: (1) something to identify individual instances and (2) support for hashtag-based additions to the URL in PF formlinks.

So to illustrate all this, a link from the 24th template instance on the page, such as

[...]/Special:FormEdit/<formname>/<page>#instance24

(Autonumbering is easily achieved using the Variables extension)

would go to the 24th template instance in the form (not taking into account new instances added after page load)

<div id="instance24" class="multipleTemplateInstance multipleTemplate">...

Unless there's a better solution, it would be helpful if template instances in the form used autonumbered id attributes that can be referred to through the URL. Does that sound feasible to you? Cavila 07:11, 20 August 2017 (UTC)

This would probably be easy to implement technically, but I'm not sure about the benefit of it. I can see the benefit of an interface that lets you just add a new instance, but what's the benefit of being able to edit just the nth (like the 24th) instance? Yaron Koren (talk) 03:31, 21 August 2017 (UTC)

The main benefit is really just making life easier for editors: you're browsing a shopping list and realise that 2000 peaches ought to have been 20. Click edit, correct the intended instance (or whatever it is you want to do with it - move up/down, remove) and hit save. If you add this in, I'll create a working example so that other users will know what to do. Cavila 21:00, 22 August 2017 (UTC)

combine #ask and #formredlink

I want to set red links to results of an ask query to link directly to a form. How can this be achieved? I've set up an example with {{#formredlink:form=City|target={{#ask: [[Category:Event]] |?Has event location |headers=hide |mainlabel=- |format=list}}|new window}} on https://sandbox.semantic-mediawiki.org/wiki/MyPage Do I need a different approach? C Wagner (talk) 11:43, 22 August 2017 (UTC)

Try adding "|link=none" to the query. Yaron Koren (talk) 11:56, 22 August 2017 (UTC)

Thank you very much! This is a step forward. I had to add #arraymap otherwise all results together form a link to the form. This brought me to another consideration: If the ask query returns multiple values, how can I add #formredlink to only one of them? C Wagner (talk) 12:39, 22 August 2017 (UTC)

Great. Why only one? Yaron Koren (talk) 13:30, 22 August 2017 (UTC)

I'm sorry for the misunderstanding. If you look at my example, I want only the things in brackets to be a redlink to a form. It would be even better if the things outside the brackets would be linked to another forum than those within the brackets. How can this be done? C Wagner (talk) 13:57, 22 August 2017 (UTC)

By "brackets", do you mean parentheses? If so, the easiest way is to add "mainlabel=-" to the query. But if you really want a complex result where pages of different types get linked to different forms, you may need to use Scribunto, i.e. the Semantic Scribunto extension. (Or Cargo + Scribunto, but that's another story.) Yaron Koren (talk) 18:24, 22 August 2017 (UTC)

default_form:form_name not working properly

I have some problems:

• if i create an article and put {{#default_form:form name}} in it, I don't get a tab "Edit with form". Only if I run RunJobs.php it appears on the page.
• If I have a default form for one namespace and create an article in this namespace but put {{#default_form:another form name}}to edit this article with another form, I get "edit with form" tab, but the form is the default form of the namespace and not the form that I want to use on this page.

My mediawiki installation:

MediaWiki 1.27.1

PHP 5.6.31

MySQL 5.6.37

PageForms 4.1.2 JaNeIEEE (talk) 12:21, 24 August 2017 (UTC)

Add underscores where the spaces are in your form name --> {{#default_form:form_name}}

Dgennaro

Underscores shouldn't make a difference here, but who knows - I don't know why this is failing for JaNeIEEE. Yaron Koren (talk) 19:08, 13 September 2017 (UTC)

I am experiencing the same issue. I jumped from MediaWiki 1.26 to 1.29 and Job queue changes issue has had a serious impact. Category pages do not update immediately, and will usually take a day unless I runJobs. I thought that adding the default_form call to the page itself rather than going through the Category would help this, but apparently that is considered a job as well. I am looking at adjusting the Manual:$wgJobRunRate, despite the negative impact it may have on my wiki, just because waiting a day for Category pages to update, or the Edit form tab to appear is unacceptable. --Jcantroot (talk) 15:45, 5 January 2018 (UTC)

Sorry. To clarify: The specific instruction on config changes that will force jobs to process, but may negatively impact performance, is here: Manual:$wgRunJobsAsync. --Jcantroot (talk) 16:00, 5 January 2018 (UTC)

If you're talking about directly adding #default_form to a page (not a template, but the page itself), there are no jobs involved there. If that doesn't work right away, I'm guessing that something else is wrong. Yaron Koren (talk) 16:13, 5 January 2018 (UTC)

Thanks Yaron. I tried it both ways. Once through a template and then directly on the page and neither worked. I am using the scheme that renames the Edit with Form tab to Edit, and changes the Edit tab to Edit Source, so I figured maybe that update for the tabs would be consider a "job" either way. I'll keep digging on my end because there definately could be something else going on. --Jcantroot (talk) 16:32, 5 January 2018 (UTC)

How 'values dependent on' works

Hi!

Does the property queried in 'values dependent on' have to be associated with a particular template? I've created a simple example where the template Person has the fields Country and City. In the Person form I'd like to populate the City combobox with values appropriate for the Country previously selected:

{{{for template|Person}}}
{| class="formtable"
! Country:
| {{{field|Country|input type=combobox|values from category=Countries}}}
|-
! City:
| {{{field|City|input type=combobox|values dependent on=Person[Country]}}}
|}
{{{end template}}}

What I'd like is to be able to create pages within the Cities category, where the page has only a single property, Country, so I can pre-build the City pages and be able to select the city names from the Person form. I've found that to get this to work, the City page must have a property City, set to the same value as the page name. I've found that the cities that populate the combobox in Person can come from the City property in either the Person or City template.

So, two questions:

1. Is this the way it works, by looking up the City property regardless of the template it's in?

2. Is there any way that my City combobox could populate with page names rather than having to have a City property in my City pages?

Thanks!

Andrew

Unfortunately, the capability of "dependent autocompletion" is rather limited in Page Forms. For cases like yours, where the set of data is known in advance, ideally you wouldn't have to create data on the wiki at all - you could just put all the data in a CSV file somewhere, and the code could read that every time. Unfortunately, that's not possible. Yes - assuming your two SMW properties are named "City" and "Country", you just need joint calls to those two properties stored anywhere in the wiki - regardless of which template they're stored with, or whether it's a template at all. One other possibility is to create a single "dummy" page and put in lots of calls to #subobject on that page, each of which stores a different combination of city and country using those two properties. It would be the most space-saving option, and maybe the fastest way to do it. On the other hand, if you actually do want to have pages for each city, your current approach may be the best one. If you do that, then the answer to the 2nd question is "No" - you need to have the "City" property in there. It can be a hidden property, though, using #set, so users don't have to see it. Yaron Koren (talk) 12:08, 27 August 2017 (UTC)

hide checkboxSwitches in forms

If I add multiple checkboxes in my form there is an option to select all or none of them shown above (cf. https://sandbox.semantic-mediawiki.org/wiki/Formulaire:Book). How can I hide this option? C Wagner (talk) 09:32, 31 August 2017 (UTC)

I'm not sure if there's any way to hide it... why do you want to hide it? Yaron Koren (talk) 14:20, 31 August 2017 (UTC)

In one of my forms there are two groups of checkboxes right below each other. Only for the first group the checkboxSwitches are shown. This is confusing for most of my users. Clicking on “select all” selects only the items in the first group of checkboxes (which makes sense technically but not for lusers). I would rather like to show checkboxSwitches for all groups of checkboxes or for none of them. C Wagner (talk) 11:27, 1 September 2017 (UTC)

I see. It looks like I was mistaken - I looked at the Page Forms code, and I was surprised to see that there actually two ways to hide the checkboxes - you can add a "|hide select all" parameter to the relevant field tag, and you can set the variable $wgPageFormsCheckboxesSelectAllMinimum in LocalSettings.php - you can set it high enough that neither one will get the link, or low enough that both will. For some reason, I didn't add either of these to the documentation - I guess because I wasn't sure whether these features were useful or not. Evidently they are. Please let me know what you use, and if it works for you. Yaron Koren (talk) 18:23, 1 September 2017 (UTC)

Thank you very much! Both ways work excellent. C Wagner (talk) 11:19, 4 September 2017 (UTC)

Issue with $wgPageFormsUseDisplayTitle and values from concept

When I put

$wgPageFormsUseDisplayTitle = true

in my LocalSettings.php-file, autocomplete stopped working for all my fields relying on values from concept.

Tested with MW 1.28.1, PHP 7.0.22, SMW 2.5.1 and PF 4.1.2, using input types tokens and combobox.

--BMfly (talk) 11:07, 4 September 2017 (UTC)

"formredlink" parser function also adding in the free text of originating page

Heiya, I have a template holing the following code {{#formredlink:target=Glossary:{{{value}}} |form=GlossaryPage |create page }}. The corresponding form "GlossaryPage" looks like this (no free text field in the form:

{{{for template|GlossaryPage}}}
{| class="formtable"
! '''Description:'''
| {{{field|gdescription|input type=textarea|editor=wikieditor|rows=3|autogrow|placeholder=Try to use a maximum of 160 characters to describe this glossary term.}}}
|}
{{{end template}}}

What happens if a new glossary term is added to the a page the target page is created but the form also adds in the free text content on that originating page, i.e. the newly created glossary page gets the template as well as all the content of the originating page except for the template holding the "formredlink" parser function. Thus I have to go to every page and remove the superfluously added content. It will be nice if just the template {{GlossaryPage}} was added. My setup is: MediaWiki 1.27.3 (798ceea) 21:03, 30 April 2017 / PHP 5.6.31 (cgi-fcgi) and Page Forms 4.1.2 (f78c600) 18:10, 5 June 2017 Cheers --[[kgh]] (talk) 16:23, 6 September 2017 (UTC)

I'm not sure I understand... are you saying that you would want a form with no "free text" input to delete whatever free text there currently is on a page? Yaron Koren (talk) 19:50, 6 September 2017 (UTC)

Perhaps another example is more easier to understand: Currently I have a page e.g. called "Berlin" containing all the information about Berlin. This page contains a "formredlink" parser function allowing me to automatically create a page for points of interests, e.g. for the "Reichstag" which is not yet available. What happens is that the formredlink does not just create the page "Reichstag" by adding the template "Point of Interest" to it, it also adds the complete content of the page "Berlin" to the newly created page "Reichstag". What I would like to do is just add the template "Point of Interest" to the page "Reichstag" - nothing else. --[[kgh]] (talk) 21:49, 6 September 2017 (UTC)

Oh, now I get it. That sounds like a serious bug - I'll have to look into it. Yaron Koren (talk) 03:45, 7 September 2017 (UTC)

Section without heading

I'm trying to wrap some onlyincludes around two templates on a page to selectively transclude each template onto other pages.

So the form would look like this: [some code] [template] [some more code] [template 2]

Is there any way aside from using sections to do this? Sections seem to insist on me having a heading (even when I don't specify one, I get == as a heading), and I want to display the templates side by side (float:left) so headings look kinda strange/bad. Example here: https://grandorder.wiki/Test

Tried partial forms but it messed up my input and kept multiplying it. (2 templates would become 4, etc..) So I gave up on that... 49.192.16.3 10:44, 17 September 2017 (UTC)

I don't think so - I think you need to use sections, and those sections would need to have a header. Yaron Koren (talk) 02:40, 18 September 2017 (UTC)

Zoom on openlayers map

Can I specify the zoom level on an openlayers input field? Setting zoom=x doesn't seem to have any effect. I tried adding autozoom=off as well. I'm sure I remember that working on the old Semantic Maps. L Andy (talk) 11:31, 19 September 2017 (UTC)

Yes, I took out the "zoom" parameter, because it didn't seem useful. My feeling was that, if coordinates haven't been selected yet (like if it's a new page being created), the map should be zoomed out all the way; while if coordinates have been set, it should be zoomed in pretty closely. What's the problem with the current behavior? Yaron Koren (talk) 15:09, 19 September 2017 (UTC)

As an example, https://restorerivers.eu is focused mainly on Europe, so on our search forms and "new page" forms we like to start with maps centred and zoomed on Europe.

Also for editing existing co-ordinates, I think there are situations where it doesn't make sense to be zoomed in all the way, if the location represents something relatively high-level. Like if it's say a city, you'd want to see that the selected location is correct within the context of the area or country, rather than down at the street level. L Andy (talk) 15:29, 19 September 2017 (UTC)

Hm, that's interesting. For your case, then, it may be useful to have three new parameters, maybe called "center", "unselected zoom" and "selected zoom". Or maybe better yet, two parameters, "starting bounds" and "selected zoom", where "starting bounds" takes in a pair of coordinates specifying the default top left and bottom right for the map, like "starting bounds=70,-15;35,70". What do you think? Yaron Koren (talk) 15:47, 19 September 2017 (UTC)

For our specific requirements, just the old centre and zoom parameters are sufficient, because mostly we use separate forms for creating new pages and editing existing ones. But what you described sounds more flexible. L Andy (talk) 15:54, 19 September 2017 (UTC)

Oh, that's odd - there's no reason to use different forms. Anyway, I like my idea for "starting bounds" and "selected zoom", and they both do indeed make sense in certain contexts. I'll add that to the set of tasks for Page Forms. Yaron Koren (talk) 16:16, 19 September 2017 (UTC)

Thanks Yaron! By the way our use of separate forms is purely down to design and user requirements. We have a very brief form for creating a new page that asks for just a few key bits of information (including a location). Then when they edit the page they see much bigger forms where they can enter a lot more detailed information. We didn't want to intimidate the users with the complex forms when initially creating a page. L Andy (talk) 16:23, 19 September 2017 (UTC)

Oh, okay - I guess that's reasonable, then. One approach you could consider is using tabs, like with the Header Tabs extension, to split up the form so that it's less intimidating, but that's up to you. Yaron Koren (talk) 02:50, 21 September 2017 (UTC)

autocomplete on property for #forminput

Is there a way to add autocompletion to a #forminput, using the values of a property? C Wagner (talk) 10:21, 22 September 2017 (UTC)

I don't think so - there might be some way to do that as a hack using Special:RunQuery, though I can't think of how. Yaron Koren (talk) 21:14, 22 September 2017 (UTC)

Problem with file upload (PF 4.1)

There seems to be a problem with uploading files. The popup allows you to pick a different name for the file to be uploaded and if the user does not explicitly state the file extension, MediaWiki adds it automatically to the file page name. The link to the file in the page form, however, contains exactly what the user typed, without the file extension, so when the page gets saved, the user ends up with a red link. Cavila 08:33, 2 October 2017 (UTC)

Unicode error on Firefox, Chrome and Safari

I am using the PageForms extension and Cargo and PageSchema. After I create my forms and tables with PageSchema I am attempting to create a page using the form. When I go to save the new page I am getting an error that says my browser does not support Unicode. I have been banging my head into the wall for several hours on this. Any help would be appreciated.

Could you link to, or pastebin, the form definition? Yaron Koren (talk) 00:56, 5 October 2017 (UTC)

This is because of the new Unicode capability browser check (see https://phabricator.wikimedia.org/T67297 resp. https://gerrit.wikimedia.org/r/#/c/374422/). The solution would be for the form page to contain the hidden wpUnicodeCheck field like this in PF_FormPrinter.php, line 1549:

$form_text .= Html::hidden( 'wpUnicodeCheck', EditPage::UNICODE_CHECK );

This should do the trick.Janboehme (talk) 09:23, 18 October 2017 (UTC)

Thanks for this! I added a line like this into the code. Yaron Koren (talk) 16:49, 20 October 2017 (UTC)

Using page templates for links of uncreated pages

I try to describe what I really need. So I have some simple red links to uncreated pages at my navigation table. So I would like to use preloaded templates to create pages of this red links? How can I do it? Thank you

Create a form that holds all those templates, and then link to the relevant pages using #formredlink instead of just square brackets - see here. Yaron Koren (talk) 18:48, 13 October 2017 (UTC)

Combine #arraymap and <gallery>

Is it possible to build up a gallery out of files passed in #arraymap?

I was trying unsuccessfully the following:

<gallery mode="packed-hover">
{{#arraymap:{{{images|}}}|,|x|x|\n}}
</gallery>

and

<gallery mode="packed-hover">
 {{#arraymaptemplate:{{{images|}}}|Split on lines|,|\n}}
</gallery>

with some viriaties of both - bad luck. Any hint? Pavel Malakhov (talk) 10:33, 13 October 2017 (UTC)

Replacing <gallery> with "{{#tag:gallery|..." may help, if you know about the #tag function. Yaron Koren (talk) 18:46, 13 October 2017 (UTC)

- Thank you Yaron Koren! I did not know about this parser function. Now I've learned and the solution is:

{{#tag:gallery|{{#arraymap:{{{images|}}}|,|x|x|\n}}|mode="packed-hover"}}

More info on usage is on page for magic words. -- Pavel Malakhov (talk) 23:36, 16 October 2017 (UTC)

Labels in input type Tree

Hi , I would like to use the input type Tree in a way it shows a label for each item on the form, different of the value sent when selected.

For example, something like :

{{{field|Discipline|input type=tree|structure= * 611_612;Human biology ** 611; Anatomy. Human and comparative anatomy ** 612;Physiology. Human and comparative physiology *** 612.1_.8;Systematic physiology }} where the left side of the semicolon would be the values sent by the form while the right side would be the labels shown when editing with the form.

Is there a way to do it ? --Ludovic Strappazon (talk) 11:23, 18 October 2017 (UTC)

I think you can do this using mapping. Yaron Koren (talk) 13:16, 18 October 2017 (UTC)

Thanks, it is exactly what I was looking for. Unfortunately, I can't get it working with the input type tree. I have tried things like :

{{{field|Thème|input type=dropdown|mapping template=Trad|values=616,615,613.1}}}

or :

{{{field|Thèmes médicaux|input type=tree|mapping template=Trad|top category=61}}}

without success. Am I doing something wrong ?

--Ludovic Strappazon (talk) 15:13, 20 October 2017 (UTC)

What does the "Trad" template look like? Yaron Koren (talk) 16:48, 20 October 2017 (UTC)

Now, it is "Test {{{1|}}}".

Sorry, the first example is working with dropdown but not with tree type.

I see - oh well. It looks like this feature still needs to be implemented. For the time being, the only way I can think of to get this kind of mapping to appear is to create some JavaScript that separately modifies each of those pieces of text on the page, and add it to MediaWiki:Common.js. Yaron Koren (talk) 21:37, 20 October 2017 (UTC)

Many thanks. I'm going to try. Best regards. --Ludovic Strappazon (talk) 10:29, 25 October 2017 (UTC)

Form Input with Drop Down Menu Disaplaying Multi Forms, or Exclude Forms

Dear folks, If I use:

{{#forminput:form=|size=|default value=|button text=|query string=query string parameters|autocomplete on category=|autocomplete on namespace=|placeholder=Research project title}}

All forms in our wiki populate the drop down menu chooser. Is there a way to designate selected forms to display in the drop down menu? I know I can add one form after form= but what if I want two specific forms to show in the drop down? Thanks for any help! --John Morris (talk) 04:16, 19 October 2017 (UTC)

I don't think so, unfortunately. If it's a fairly small number of forms, probably the best solution is to to just show a separate #forminput for each form on the page. Yaron Koren (talk) 17:02, 19 October 2017 (UTC)

Thank you Yaron, I can do that, I was trying to save real estate on the page, but if that is the only option. Yaron, it seems there should be a way to display only the forms in a given category no? With one drop down menu. John Morris (talk) 04:27, 20 October 2017 (UTC)

Maybe. It might be easier to just have "form=" take in a comma-separated list. Out of curiosity, how many forms are involved in your case? Yaron Koren (talk) 16:48, 20 October 2017 (UTC)

Thanks yet again Yaron. In some cases I may have and will have up to a dozen forms for one category. Can you direct me to an example of a comma separated list for this case? Please? --John Morris (talk) 15:44, 21 October 2017 (UTC)

I just meant that it would be easier to use, if that were a feature - it's not a feature now. Sorry for the confusion. It does seem to make sense as a feature, though. Yaron Koren (talk) 17:18, 23 October 2017 (UTC)

Thanks a million Yaron. Is there a location I put in a feature request? Thanks again.--John Morris (talk) 17:21, 24 October 2017 (UTC)

Sorry, I thought I responded to this before. The best place to put feature requests is probably Phabricator. Yaron Koren (talk) 03:56, 10 November 2017 (UTC)

HTML character escapes not working

I am currently working on an upgrade from 1.26 to 1.29.1 and HTML character escaping is no longer functioning for my Page Forms. I've created templates, properly HTML escaped that were previously working in my forms, but now they just show as

{{{field|state|input type=dropdown|mandatory|values=Normal,Draft,Under Construction,Stub|default=Normal}}}

in the form itself. Anyone run across this as an issue?

• MediaWiki 1.29
• Semantic MediaWiki 2.5.4
• Page Forms 4.1.2

--Jcantroot (talk) 20:09, 20 October 2017 (UTC)

I don't know what the exact issue is, but it may work to instead do <nowiki>{{{field|...}}}</nowiki>. Yaron Koren (talk) 21:39, 20 October 2017 (UTC)

Thanks Yaron, I am going to give the <nowiki> method a shot. I saw that approach was also listed on the instruction and it's where I was going next, but we have quite a number of Form-based Templates in our instance, so I wanted to check in here first to see if there was a known issue before I went and updated them all. --Jcantroot (talk) 12:49, 23 October 2017 (UTC)

Just to follow up, if anyone else happens to run into this issue, switching to the <nowiki>{{{field|...}}}</nowiki> approach was a success for me. --Jcantroot (talk) 12:54, 23 October 2017 (UTC)

Locking Down certain fields for admins only.

Hey everyone, I am using Page Forms for bug reporting. I have seven fields, but only want three of them to be editable by the general user community, the remaining four will be edited only by admins.

Does anyone know if this can be done? If so, how can I do it?

Yes - see "restricted", here. Yaron Koren (talk) 20:44, 27 October 2017 (UTC)

Thanks Yaron.

Free text input not keeping text?

I'm using MW 1.29 with Pag Forms 4.2. I have a form with several templates and standard sections, defined here (it's in Hebrew, but I think you should be able to see the form definition just fine).

I shoved a free text input in the middle of it, before a couple of ending sections, with this definition:

{{{standard input|free text|autogrow|editor=wikieditor}}}

Ideally, I'd like to allow editors to put custom sections inside it, but right now it only saves text the first time; when entering the edit form again, there's nothing in it. You can see it here - nothing shows up in the free input, even though when you view the article there are a couple of custom sections currently there.

I also tried moving the free text input to the bottom of the form, just to see if it would help, but got the same result. I'm probably doing something wrong, but didn't see anything enlightening in the documentation. Any ideas?

Thanks, --FFS ^Talk 23:36, 8 November 2017 (UTC)

You uncovered a bug with the handling of a free text input between section inputs. I just checked in a fix, so if you get the latest Page Forms code, hopefully it will work now. Yaron Koren (talk) 19:17, 9 November 2017 (UTC)

Thanks for the extremely quick turnaround, Yaron! After updating the code my initial testing failed, but then I discovered it was due to me being a dumbass and looking at the wrong development environment. Your fix works wonderfully for me - thank you again! --FFS ^Talk 13:37, 20 November 2017 (UTC)

Great! Yaron Koren (talk) 21:26, 20 November 2017 (UTC)

Lead / Introduction

Is it somehow possible to add a lead / introduction section using Page Forms? Basically I want something like a section without a headline at the very top.

Julien.Schmidt (talk) 00:20, 9 November 2017 (UTC)

Only if you have that as the free text. Yaron Koren (talk) 02:46, 9 November 2017 (UTC)

If I put {{{standard input|free text}}} at the top of the form, that doesn't recognize existing lead texts. Thus they would be removed when the form is saved. Julien.Schmidt (talk) 09:47, 9 November 2017 (UTC)

There was a change I just added to the handling of free text inputs that may possibly fix the problem you're seeing - if you can, please get the latest Page Forms code from Git and let me know if that fixes things. Yaron Koren (talk) 19:20, 9 November 2017 (UTC)

Thanks, I just tried the current git master. Unfortunately it still doesn't work. Existing text is still not shown in the text input and would be overwritten on saving the form. Placing the free text input there also feels like a dirty hack. Proper support for lead text before the first section would be much appreciated! Julien.Schmidt (talk) 09:56, 10 November 2017 (UTC)

It's not good that it fails, but is it really that much of a hack (assuming it can be made to work)? Would you want a separate "free text" part in addition to the lead text? Or is one "free text" enough? Yaron Koren (talk) 13:47, 10 November 2017 (UTC)

I was hoping to achieve the same end, but had planned to use a separate Cargo field (e.g. "leadsection") and use the template output type to display this at the beginning of the page before the first heading. Page Forms could simply have "leadsection" as the first textarea. I wonder if this would work, and at the same time realise this doesn't help if you're just using Page Forms on its own... Jonathan3 (talk) 01:39, 14 November 2017 (UTC)

Let me repeat my question: why not use "free text" as the lead section? Would you want two different free text sections? Yaron Koren (talk) 03:06, 14 November 2017 (UTC)

Set Editor and Placeholder for Section Textareas

It would be great if we could also set a placeholder and editor for the textareas of sections, like we can set it for textareas for template fields.

--Julien.Schmidt (talk) 00:37, 9 November 2017 (UTC)

That was a bug (or really two bugs), which I didn't know about until now. Sorry about the problem; I just checked in fixes for these two bugs. Yaron Koren (talk) 15:24, 9 November 2017 (UTC)

Works fine in the current git master. Thank you! Julien.Schmidt (talk) 09:56, 10 November 2017 (UTC)

Sidebar link

I'm using Page Forms extension but when I add link to a form on the sidebar (Using #formlink) I get this string instead of a link on the sidebar: <a href="/Special:FormEdit/Timeline_post" class="popupformlink" title="" target="_self">New Timeline Post</a>

You can't use parser functions in the sidebar, unfortunately - only page names and URLs. Yaron Koren (talk) 03:05, 14 November 2017 (UTC)

using 'autocomplete on namespace' breaks autocomplete UI in other input fields (e.g. BlueSpice ExtendedSearch)

I don't know if this is your bug, but I assume some injected code/css when using autocomplete on namespace= breaks UI (drop down list is malformated, js-elements missing) for other intelligent input fields, if I leave out this option, all is well.

If I can file this bug somewhere else, please tell me.

--Garonenur (talk) 07:45, 20 November 2017 (UTC)

Hi - what version of Page Forms are you using? It sounds like this might be a problem with BlueSpice. Yaron Koren (talk) 11:46, 20 November 2017 (UTC)

"tree" input type issue when selecting 2 levels deep

On a MW1.29.2 wiki with PageForms 4.2, I have the following field: ...field |topic |input type=tree |top category=Topics |hideroot |depth=3 |height=150 |list |tooltip= Select at least 1 existing topic this post relates to |label=Topic

When using the form and selecting any subcategory of the top category (i.e. 1 level deep), all goes well. As soon as grandchildren of the top category are selected, the form replaces all those selections with a nonexistent category called Array!

I can't replicate this problem. Is this field in a multiple-instance template, or in something else that's unconventional? Yaron Koren (talk) 18:36, 3 December 2017 (UTC)

Free text as boilerplate with the Variables extension

Yaron, thank you for writing and maintaining this brilliant extension, which I now see I should have started using long ago. I am using it in a way which perhaps differs slightly from the approach set out in the documentation. I am sure many others are doing something similar, but I haven't really seen any recent discussion of it, and perhaps some users may find it useful.

I combine Page Forms with parser functions and Variables, another excellent and well-maintained extension, to turn Page Forms' "free text" standard input into a boilerplate text that contains {{#var:VARIABLENAME}} where a value supplied by the user through the input form is to appear. Variable VARIABLENAME is defined in a template called by Page Forms. This allows, for instance, showing or hiding H2 or H3 tags based on complex criteria; one can of course do all sorts of checks, computations and modifications to the data from the form. Via the variables, values from any template can be inserted anywhere in the boilerplate text or be used as parameters for template calls. Letting templates define variables instead of outputting text decouples the sequencing of templates referenced in the form from the order in which their parameters are used as output on the page. A variable defined directly in the page or by any template called in it remains in page scope from then on. Keeping variable definitions and computations in one or a few templates separates the logic from the presentation (the boilerplate). You can of course expose the "free text" (boilerplate) for modification in the form. Henryfunk

I'm glad you like Page Forms! If I understand what you're saying: you're talking about cases where the form is responsible for more than one template, and you want to mix together the data from the different templates - so that a field from template A affects the display of template B, etc. It certainly makes sense to use the Variables extension for that. I don't understand the need to use the free text, though. Why not put all that "boilerplate" text into another template, and have the form also output that (with no fields)? Or add the boilerplate to the bottom of the final template in the current form? That way users editing the page don't have to see any of it. As you note, putting it in the free text lets users modify the logic - but I don't know if that's an advantage or not. Yaron Koren (talk) 15:00, 14 December 2017 (UTC)

Yaron, you understood me perfectly. Adding the boilerplate in a template, as you suggest, hides it from the user. Using the free text as boilerplate makes it possible to expose it in the form. The choice boils down to whether the ability to make ad hoc changes is more important than hiding complexity from users and whether changing the layout of all pages at a stroke by changing a template is more important than the possibility of customising individual pages in the form. It all boils down to why one uses entry forms. I do so only when they make entry faster. But I think the important thing is that adding the Variables extension to the mix decouples the entry flow from the structure of the resulting page. It allows things like collecting input from several calls to one or more templates and generating a list (UL or OL) from them, then deciding whether or not to output, say, an H3 heading based on whether the said list exists or the user instead wrote a paragraph of text in a textarea in the form. Henryfunk

Conflict with extension FancyBoxThumbs

Sometimes when I load a page form I get the error message: "Uncaught TypeError: $.fancybox.init is not a function". I am using the FancyBoxThumbs extension. It seems the fancybox script gets loaded twice. Is this a Page Forms or a FancyBoxThumbs issue? Henryfunk

That's too bad. I don't know, and I'm not sure of the best way to fix this. I suppose if FancyBoxThumbs checked to see if Page Forms was installed, and used PF's own JS modules if so, that would work, though that extension hasn't been updated since 2013, so I don't know if you could get anyone to make that change. Yaron Koren (talk) 21:39, 14 December 2017 (UTC)

This is a hack, but it works until I find a better solution: FancyBoxThumbs uses a BeforePageDisplay hook handler to add 'ext.FancyBoxThumbs' to the page. I simply block this on Form "Edit " and "Create " pages. Henryfunk

Using “values dependent on” more than once and defined a set of properties values for all fields

I have two questions on this that I’m hoping someone could help me with.

1. Is there a way to use “values dependent on” more than once?
   I have four form fields that I would like to drilldown -- meaning the 2nd field values depend on what is chosen from the 1st, the 3rd on the 2nd and the 4th on 3rd. However, when using “values dependent on” it only restricts the values one level up. So at field 3, all values of 2 appear instead of just the values that belong to both 1 and 2.
2. Is there a way to have all page form field values be set to only those from a defined set pages (perhaps defined by a category or query)?
   For this use, there are a few large properties. I would like to create a form that would only include values from a set of pages. I hoping to not create a lot of duplicate properties based on the type of page. I rather keep them all in one property to allow values for all or a subset to be used on the form. However, I don’t know how to define the subset on page form. If I do separate them, how would I include all of the values on form? I've tried the "values from query", but I'm confused on how to use it as there's not much documented on its use. (Hazeldee0512) 15 December 2017

Hi -

1. What do you mean by "at field 3"? You've selected a value for field 1, then field 2, and then - what's the incorrect thing that happens? I didn't understand that part.
2. If I understand this correctly: you're using Semantic MediaWiki, and you have some property like "Has topic" that applies to more than one type of page. Now you want a dropdown in a form to only use the values for "Has topic" for some specific page type, i.e. for some specific category. Are these values themselves page names, i.e. does "Has topic" have type "Page"? If not, then probably you will indeed need to have a separate property for every page type. At least, that would be the easiest solution. Yaron Koren (talk) 04:02, 17 December 2017 (UTC)

Region	Department	Process
1	A	1
2	A	2
1	B	3
2	B	4
2	C	5

Hi Yaron -- thanks for you response! I'm not good at explaining what I'm trying to accomplish, so here's a detailed example.

1. Say I have pages that all have the following 3 properties. Region (field 1), Department (field 2), and Process (field 3). When selecting Region 1, only the values A, B, and C for Department are given (which is great). However, I would like for field 3 values to reduce to only Processes 1, 3, and 5 to represent the pages with both Region 1 and Departments A, B or C. Instead, the "values dependent on" only holds for the Departments, therefore all Process values for Departments A, B and C are given. So is there a way to hold field 1 dependency to both field 2 and field 3? I hope that's clearer.
2. That is exactly what I'm wanting and no the values are not pages. So that answers my question.
   Thanks! Hazeldee0512; 20 December 2017

For 1 - okay, that certainly clears things up. That isn't a strict hierarchy - a department can be part of more than one region - which is what is causing this problem. How about making the process field "dependent on" region, instead of on department? Or is that what you were asking about initially? If so, the answer is yes, I think it's possible. Yaron Koren (talk) 16:04, 20 December 2017 (UTC)

Actually, I don't believe my example was a complete accurate representation of what's happening. So having the process dependent on region isn't working either. Because (using the table), selecting Region 1 would give give values A and B for department. Selecting department B should only give #3 for my process. But having the process field depend on region would give process 1 and 3 and having it depend on department would give 3 and 4, as it's only depending on one field. So any ideas on how to allow it to depend on one than more field? Hazeldee0512; 20 December 2017

Okay, now I get it. No, you can't have "values dependent on" on more than one field at a time. The only solution I can think of for this to have department names like "1/A", "2/A", etc., instead of just "A" and "B" - that way, you would have a strict hierarchy. This would also allow you to have a page for each department, something which might not be possible now. Yaron Koren (talk) 04:50, 21 December 2017 (UTC)

OK, thanks for the help! I started to do the "1/A", "2/A", but thought there might have been another way. Hazeldee0512; 21 December 2017

Browser doesn't support unicode error

When running the Page Forms extension in MediaWiki 1.30, I started getting errors that I couldn't save changes in Edit with Form mode because my browser didn't support unicode. It looked very similar to this HotCat edit error. Digging around in the HTML and differences with plain Edit and Edit with Form modes, it looks like there's a new hidden field to demonstrate unicode support. The specific error message is:

"It appears that your browser does not support Unicode. It is required to edit pages, so your edit was not saved."

I added the following after line 1548 in includes/PF_FormPrinter.php and got it working again.

$form_text .= Html::hidden( 'wpUnicodeCheck', "\u{2133}\u{1D4B2}\u{2665}\u{1D4CA}\u{1D4C3}\u{1D4BE}\u{1D4B8}\u{2134}\u{1D4B9}\u{212F}");

Paulboal (talk) 16:51, 19 December 2017 (UTC)

Are you using the REL1_30 tag for Page Forms? If so, I'd recommend switching to the latest code - this was fixed a while ago, I think. (Or you could try just re-getting REL1_30 - someone just back-ported this fix into REL1_30 a few days ago, but I don't know if it worked.) Yaron Koren (talk) 19:11, 19 December 2017 (UTC)

Page form won't save all defined fields

Hi all,

I've developed a page form using the extension. The form consists of multiple components with sections, and fields. There are several input types in the fields including: datepicker, checkboxes, and dropdown.

When I go to save the form, the fields with different inputs don't save (i.e. are truncated in the final page creation).

Does anyone have experience with this issue who can help? Any input would be greatly appreciated!

What versions are you using of MediaWiki and Page Forms? Yaron Koren (talk) 04:50, 21 December 2017 (UTC)

Hi Yaron, I forgot to mention we have a development space setup, which has 1.29 installed, and Page Forms 4.1 installed. The same issue is occurring. Jgosian (talk) 16:06, 21 December 2017 (UTC)

Well, you should upgrade Page Forms, but that might not solve the issue. What did you mean by "different inputs"? Yaron Koren (talk) 19:12, 21 December 2017 (UTC)

Thanks for the response, Yaron! I'll certainly urge our admins to upgrade to the latest version. What I mean by "different inputs" is the input types. In other words "sections" will save, but "fields" with defined input types won't save

Is this a public wiki? If not, could you pastebin the form definition? Yaron Koren (talk) 21:54, 10 January 2018 (UTC)

Proper usage together with headertabs

Hi Yaron,

PageForm works great in our environment for almost 2 1/2 year now. Recently we tried to improve even further by using headertabs together with pageforms. Unforunately we get very "quirky" behavior when doing so. A typical form we use might have a first tab with the general information and use normal properties. Then on a second (and may be more tabs) there will be master/detail information using subobject. Last but no least there will be a Freetext tab.

Now what happens more often than not is that things get garbled. We found out that:

• a tab may not be empty if it is the saved result is "garbled" e.g. with Freetext headers being only partly saved
• the freetext handling does not function reliably - the content of the freetext might not be shown at all

We have put up with these quirks now for a few month thinking that this was all only because we were using an old pageforms version. Now we upgraded to pageforms 4.2 on MediaWiki 1.27.3 and the problems persist or partly even got worse. Are you aware of this kind of issues or should i provide more detailed information / a sandbox example?

Cheers

 --WolfgangFahl (talk) 09:25, 22 December 2017 (UTC)

I'm not aware of a general issue with Page Forms and Header Tabs working together. My guess is that the problem is due to some interaction of Header Tabs with the skin and/or another extension - there's a list of extensions and skins that don't work well with Header Tabs. But if you don't have any of those installed, then yes, a sandbox example would be helpful. Yaron Koren (talk) 12:58, 22 December 2017 (UTC)

Embedding query forms breaks headings

Hi,

Embedding query forms with {{Special:RunQuery/query form name}} breaks all headings on the page.
All headings get prefixed with something like '''"`UNIQ54127f73a82a5f87-h-4--QINU`"'''.

This seems to be an old issues because it was already reported in 2014. Embedding query forms is a very powerful feature so I'd really like to see this problem solved.

Best regards,
Frank

MediaWiki 1.23.15 | Semantic MediaWiki 2.4.1 | Page Forms 4.0.2 | PHP 5.3.3 | MySQL 5.1.73

--Nakohdo (talk) 13:20, 22 December 2017 (UTC)

Do you have an example page where you're trying to get it working? It works on my test page, and I'm on MW 1.27.0, SMW 2.5.2, Page Forms 4.1.2 (so all a bit more updated than yours ^^")..Jennkei (talk) 06:56, 27 December 2017 (UTC)

Thanks for this information. The wiki in question is on an intranet so I unfortunately don't have an example page for you. But as it is working for you it looks like the problem is caused by one or more outdated components. So I will further investigate in that direction. Nakohdo (talk) 19:44, 29 December 2017 (UTC)

JFTR, https://www.mediawiki.org/wiki/QINU_fix Nakohdo (talk) 16:30, 3 January 2018 (UTC)