Extension talk:Page Forms

From MediaWiki.org
Jump to: navigation, search

"Run query" does not ask for user input[edit]

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?[edit]

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[edit]

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[edit]

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[edit]

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?


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...


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[edit]

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


(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[edit]

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[edit]

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}}
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)

How 'values dependent on' works[edit]


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?



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[edit]

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[edit]

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[edit]

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[edit]

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... 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[edit]

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[edit]

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)[edit]

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[edit]

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[edit]

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>[edit]

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

I was trying unsuccessfully the following:

<gallery mode="packed-hover">


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

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:

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

Labels in input type Tree[edit]

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[edit]

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[edit]

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.[edit]

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?[edit]

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[edit]

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[edit]

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[edit]

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)[edit]

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)