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)