Extension talk:Page Forms/Archive June to July 2018

Date input type struggles with fragmentary dates

Hello again. I'm still using Mediawiki 1.30.0 with the page forms extension 4.3.1 on a Synology NAS. This system is still not public. Cargo or Semantic Mediawiki is still not installed. The PHP version is still 5.6.34 and MariaDB 10.0.32 serves still as database.

Now I created a form using the combox field: {{{field|Day of birth|input type=date}}}. Three input field are diplayed. One for the day, the next for the month and the last for the year. If I enter a full scale date with day, month and year, all is fine. If I enter only a day or only a month and if I save the article, the input has been dumped. The template call in the article shows no Day of birth parameter. So far, so good. If I enter a year only, the articles template call shows this year at the Day of birth parameter. And if I want to edit this article by using its form, the input fields for the day and the month are blanked and the input field for the year shows the before prompted year. This is fine, too. But if I blank the day field and fill only the month and the year field, I get the month in full text, followed by the year as value at the Day of birth parameter. So far, no error. But if I edit this article now, using its form, the day is blank, as anticipated, but the month and the year field shows January 1970 at all times and not the month and date value from the template call.

Maybe the localisation is the problem? Since it is a german environement, in case of the month and year only input the month name is saved in german language. This is in accordance with the month dropdown. The month to choose from are also displayed in german language. If I change the parameters value directly without using the form from, for example, the german Februar 1950 to the english February 1950, this "english" value works.

And again many thanks for a note on my struggle with Page Forms in advance! Wgkderdicke (talk) 02:46, 2 June 2018 (UTC)

There's no real need to list all the things that do work... I think you could have just described the problem as "Page Forms does not parse dates correctly if they are of the form 'month-name year' when the month name is in a non-English language". Thankfully, I was able to reproduce the problem - I just checked in a fix. Sorry about that. Yaron Koren (talk) 18:50, 4 June 2018 (UTC)

Well, that's me. On the one hand, I've always got a knack for making it more complicated than necessary. On the other hand I try to improve my English a little bit on such occasions. So one thing gets to the other and zack, there is the litany... ;-) Thanks for the fix. Wgkderdicke (talk) 21:04, 4 June 2018 (UTC)

monolingual text and input type textarea with autocomplete

I use PF 4.3.1 and have set the form field “keywords” to autocomplete by a monolingual text property “Has keyword”:

{{{field|keywords|input type=textarea with autocomplete|list|delimiter=,|values from property=Has keyword|rows=2|placeholder=Comma separated list of key words|remote autocompletion|autogrow}}}

… but in the form I only get the page to be selectable. If I use a property with normal data type text, then it works as expected. See also https://phabricator.wikimedia.org/T196447. Thank you for resolving this. --Andreas P. 11:15, 5 June 2018 (UTC)

formredlink "create page" bug

Hi, I'm trying to use formredlink in a template with the "create page" option (PF 4.3.1 MW 1.29) with the code:

{{#formredlink:target=Batch:{{{batch|}}}|form=Batch|create page|link text={{{batch|}}}}}

The template will only display properly after the page is created by the job, but since it is not created, the output is the following:

 
MWException from line 264 of /var/www/html/lab/includes/parser/ParserOutput.php: Bad parser output text.

Backtrace:

#0 [internal function]: ParserOutput->{closure}(array)
#1 /var/www/html/lab/includes/parser/ParserOutput.php(274): preg_replace_callback(string, Closure, string)
#2 /var/www/html/lab/includes/OutputPage.php(1879): ParserOutput->getText()
#3 /var/www/html/lab/includes/OutputPage.php(1900): OutputPage->addParserOutputText(ParserOutput)
#4 /var/www/html/lab/includes/page/Article.php(601): OutputPage->addParserOutput(ParserOutput)
#5 /var/www/html/lab/includes/actions/ViewAction.php(68): Article->view()
#6 /var/www/html/lab/includes/MediaWiki.php(499): ViewAction->show()
#7 /var/www/html/lab/includes/MediaWiki.php(293): MediaWiki->performAction(Article, Title)
#8 /var/www/html/lab/includes/MediaWiki.php(862): MediaWiki->performRequest()
#9 /var/www/html/lab/includes/MediaWiki.php(523): MediaWiki->main()
#10 /var/www/html/lab/index.php(43): MediaWiki->run()
#11 {main}

Any clue??? Steph.

Sorry, I don't understand - where are you seeing that output? And does it show up every time you view that page(s)? Yaron Koren (talk) 01:20, 7 June 2018 (UTC)

Hi, the error message is the page output, it appears until the redlinked page is created by the job queue. After the redlink page is created, the page output is normal. Steph.

Hi Yaron, After extensive tests, I finally found what's triggers the error. And it is weird! It appears that when you have a formredlink with create page option inside a template and that the rendered page has a H1 title (I mean =Title X= ), you end up with an MWException!

Let {{SomeTemplate | param= foo }} be a template that contains:

<includeonly>
=FOO=
foo bar, {{#formredlink:form=SomeTemplateForm|target={{{param|}}}|create page}}
</includeonly>

Any call to this template in a page crashes MW parser until the target is created.

Remove =FOO=, it works!!! Steph.

Wow! I'm glad you discovered that, because I had no idea what could be causing the error. Are you using Header Tabs or some other extension that does some processing to H1-style headers? Yaron Koren (talk) 18:24, 8 June 2018 (UTC)

Indeed, Headertabs is installed on this wiki, but the crash appends even without a <heardertabs/> tag in the page. I'm not aware if the extension triggers some script even when not invoked... Steph.

I disabled headtabs and tried again: exception is still fired. I also noted that if the title is set after the formredlink, everything works fine! Steph.

It was actually already known : Extension_talk:Page_Forms/Archive_September_2015... Steph.

Dynamic Section Name?

i need:

• A form to add new sections to an existing page.
• New section name is passed into form as a parameter (like a template parameter, with 3 curly braces)
• New section content is entered into form by user.

Are you asking about having functionality like the "Add topic" tab in talk pages? If so, Page Forms unfortunately can't provide that. Yaron Koren (talk) 01:21, 7 June 2018 (UTC)

Hi, thx for reply.

Doc says: "A form allows a user to populate a pre-defined set of templates, as well as page sections"

That's what I want. Only difference is, I want to pass the section name to the form, instead of hard coding the section name.

Can the form receive parameters?

Like this:

{{{section|{{{1}}}|level=1|hidden}}}

Or

{{{section|{{#urlget:Tag}}|level=1|hidden}}} 

Perhaps called with something like:

{{#formlink:form=MyForm|link type=post button|query string=SectionXYZ}}

No - none of those will work, unfortunately. Yaron Koren (talk) 04:07, 7 June 2018 (UTC)

How to exclude Class?

Your sample form definition contains:

{| class="formtable" ! Author....

If I don't want to include Class, how should that code begin? Like this?

{|Author....

Johnywhy (talk) 02:54, 7 June 2018 (UTC)

I think it needs to be:

{|
! Author....

Yaron Koren (talk) 04:08, 7 June 2018 (UTC)

template-name in info tag vs "for template" tag?

What's difference between template-name in info tag, and for template tag?

Johnywhy (talk) 03:25, 7 June 2018 (UTC)

I'm not sure I understand the question. The "info" tag and the "for template" tag do different things... Yaron Koren (talk) 04:09, 7 June 2018 (UTC)

template-name is defined here- https://www.mediawiki.org/wiki/Extension:Page_Forms/Linking_to_forms#The_one-step_process

for template tag is defined here- https://www.mediawiki.org/wiki/Extension:Page_Forms/Defining_forms#'for_template'_tag

What's the difference?

Johnywhy (talk) 04:33, 7 June 2018 (UTC)

The template name in the "info" tag is only used to set the page name... if that helps. Yaron Koren (talk) 04:50, 7 June 2018 (UTC)

If "template name is used to set thepage name", then how is that different than the "page name" parameter?

Johnywhy (talk) 05:08, 7 June 2018 (UTC)

The "template-name" you're referring to is part of the "page name" parameter, no? Yaron Koren (talk) 13:55, 7 June 2018 (UTC)

How To Retrieve Query String Parameters?

i see some examples here of how to load query string. eg

 query string=namespace=User&User[Is_employee]=yes 

and

|namespace=User|User[Is_employee]=yes

But i don't see example of syntax to retrieve the value of Query String parameters inside the form def.

Johnywhy (talk) 04:32, 7 June 2018 (UTC)

Query string values like the ones in those examples get automatically retrieved by the software. But in general, you could use #urlget - it won't necessary work within tags, though. Yaron Koren (talk) 13:57, 7 June 2018 (UTC)

FormStart Page Name vs Info Tag Page Name?

Special:FormStart requires user to enter name of page to edit.

How is that "name of page" different from page name in info tag? Johnywhy (talk) 1:28, 7 June 2018 (UTC)

It's the difference between the one-step and two-step processes for page creation, which are covered here. Yaron Koren (talk) 13:58, 7 June 2018 (UTC)

Ah, ok, so i would use one or the other, but not both, correct? Johnywhy (talk) 14:28, 7 June 2018 (UTC)

Usually - there could potentially be forms that have a page-name formula and usually set the page name themselves, but also sometimes get a page name manually passed in. Yaron Koren (talk) 16:17, 7 June 2018 (UTC)

Can #arraymap or #arraymaptemplate split string on pairs?

Is it possible to make a variable in template with complex value = "Key1: Value1; Key2: Value2; Key3: Value3", then using arraymap split it on pairs and pass to template which will return formatted string?

For example, if one call template like

{{Make list
 | string = Key1: Value1; Key2: Value2; Key3: Value3
}}

The one get result like:

• Key1 = Value1
• Key2 = Value2
• Key3 = Value3

May be there is a trick? Or is it possible to use #arraymap and #arraymaptemplate for single values only?

Not sure to understand your needs, but I guess a combination of explode function and arraymap should do the trick.

{{#arraymap:{{{string|}}}| ; | @@@@ | {{FormatingTemplate| key = {{#explode:@@@@|:|0}} | value = {{#explode:@@@@|:|-1}} }} }}

Steph.

Thank you, Steph! This is just what I need! #explode is the answer, but to make it work we need to set $wgPFEnableStringFunctions = true; for ParserFunctions extension.

To make the answer complete and for the ones who may search for such an example, there are two additional templates below to make it work:

• Template:Make list:

{{#arraymap:{{{string|}}}| ; | @@@@ | {{Make list item| key = {{#explode:@@@@|:|0}} | value = {{#explode:@@@@|:|-1}} }}| \n}}

• Template:Make list item:

* {{{key|}}} = '''{{{value|}}}'''

I put this answer with some more examples to my site. Thanks again! Pavel Malakhov (talk) 03:19, 9 June 2018 (UTC)

defining readonly inputs

In html, it is possible to create a form input that the user can not edit. For example:

<input id=Foo type="text" value="Bar" readonly> 

I'd like to do this in Page Forms however, in PF, this doesn't work:

{{{field|submitted on|input type=text|default={{LOCALTIMESTAMP}}|readonly}}}

What can/should I do?

The closest you can get is putting "restricted" instead of "readonly" - admins will still be allowed to edit the field, but no one else will. Yaron Koren (talk) 21:54, 7 June 2018 (UTC)

As an alternative, you can make the field "hidden" and show a {{LOCALTIMESTAMP}} in the form outside of a field definition, so that the date will be seen by user but no input field will. Steph.

How to stop existing sections loading into new section input-box?

1. Create a form call Form:AddItem. Paste in the following:

   {{{section|Monkeys|level=1|rows=2|cols=150|autogrow|strict}}} {{{standard input|save}}}

2. Create a page called Launcher. Add the following code:

   {{#formlink:form=AddItem|link text=Add Item|link type=post button|query string=Unused|target=MyList|popup}}

3. In read-mode, click that link, enter some test text, click Save.
4. Browse to page MyList. See new section created with your test-text.
5. Edit Form:AddItem. Change

   section|Monkeys

   to

   section|Pies

   and save the form.
6. Browse to Launcher. Click the "Add Item" button.
7. At this point, the input box contains the text of the previously entered section.

How to stop the text of the previously entered section from showing up in the new form? Johnywhy (talk) 03:50, 11 June 2018 (UTC)

I don't know - this may possibly be a bug, since text under a different section header should probably be counted as "free text", not as section contents. You could always just delete the text, though... Yaron Koren (talk) 03:59, 11 June 2018 (UTC)

But, i don't want to delete the text, i don't want to touch the text. I want the form to add a new section to the page, without touching the existing sections. Is it possible? Johnywhy (talk) 04:04, 11 June 2018 (UTC)

The only way I can think to do that is by adding a new section to the form, instead of changing an existing one. Yaron Koren (talk) 14:40, 11 June 2018 (UTC)

Ok, thx, that makes sense. Johnywhy (talk) 15:20, 11 June 2018 (UTC)

Some very long page name that will etc.

Hi, I experienced the infamous page name. Seems to me to be related to the info tag "page name" with <unique number> feature. In my case, a page is created by a form with this tag. Then from the page, other pages are created with a semantic property filled with a reference to the initial page → template parameter are filled with {{FULLPAGENAME}}. In the secondary pages, this reference sometimes ended with "Some very long etc...". I switched to Extension:IDProvider to manage automatic page numbering, and things seems to have settled. I'm a bit frightened by this bug anyway. Is there a known root cause to this? Steph.

After more careful study, looks like this is another strike of my old formredlink friend, which seems to randomly disrupt the parser. Steph

[Solved] Stop Category-tag Loading Into Form?

The more general question is, how to load something into the page, without it showing up in the edit fields when you click "edit with form"?

I use free-text with a preload page, to load a category-tag into pages created with my form.

{{{standard input|free text|hidden|preload=Category:Dogs/Preload}}} 

The preload page contains: [[Category:Dogs]]

The form contains 3 sectional fields, which user fills in when running the form.

==Dog Name==
{{{section|Dog Name|level=2|rows=2|cols=150|autogrow}}}

The page gets created fine. The hidden free-text field correctly loads the category tag.

But when i click "Edit with form", the Category tag gets loaded into the last input-box. Then the user could delete or corrupt it.

How can i prevent the Category loading into the last input-box on 'edit with form'?

Is there a better way to set the category of the created page?

Unfortunately, if a form has a "section" followed by the free text, there's no way for the code to know which one the text should go into. But if your form has a template, you could just put that category tag in the template. If there's no template, then there might not be a good solution. Yaron Koren (talk) 14:37, 21 June 2018 (UTC)

Making some progress. I moved the freetext above all the section tags, and the hidden tag is no longer loading into the input boxes on edit-with-form!

But new problem: When i click "edit with form", i get "page already exists, but doesn't use this form". Which makes no sense.

How can i get rid of that error message, while keeping the free-text above the section tags?

Getting the same error with all three codes below:

{{{standard input|free text|hidden|rows=1|preload=Category:Dogs/Preload}}} 
{{{info|page name=Draft}}}
__NOEDITSECTION__
==Dog Tip==
{{{section|Dog Tip|level=2|rows=2|cols=150|autogrow}}}

{{{info|page name=Draft}}}
{{{standard input|free text|hidden|rows=1|preload=Category:Dogs/Preload}}} 
__NOEDITSECTION__
==Dog Tip==
{{{section|Dog Tip|level=2|rows=2|cols=150|autogrow}}}

{{{info|page name=Draft}}}
__NOEDITSECTION__
{{{standard input|free text|hidden|rows=1|preload=Category:Dogs/Preload}}} 
==Dog Tip==
{{{section|Dog Tip|level=2|rows=2|cols=150|autogrow}}}

I can't put the category-tag in a template, because i include part of the page with DPL on a DPL page:

• if i put the for template tag above the section tags, then the template-tag gets pulled into the DPL page. That causes the same category to be applied to the DPL page, which i don't want.
• if i put the for template tag below the section tags, then the template-tag gets pulled into the input field on "edit with form", which i don't want.
• wherever i put the for template tag, it causes the form itself to be added to the category `Dogs`, and displays the "edit with form" tab on the form itself-- which makes no sense.

I also tried the following, with a template-tag {{Dogs}}, but the template tag doesn't go into the page source. It gets lost-- doesn't go into the created page.

How to prevent it from getting lost?

{{{info|page name=Draft}}}
{{Dogs}}
__NOEDITSECTION__
==Dog Tip==
{{{section|Dog Tip|level=2|rows=2|cols=150|autogrow}}}

Johnywhy (talk) 17:10, 21 June 2018 (UTC)

I don't understand how the form definition page would get added to the category... I was talking about putting the category tag in the template itself, i.e. in "Template:Dogs" within the "includeonly" section. Is that what you tried? Yaron Koren (talk) 17:55, 21 June 2018 (UTC)

Solved.

• i must have manually applied Dogs category to the form itself (the form def isn't causing that). I removed the category from the form-page to get rid of "edit with form" tab on the form itself.

• The Fix: to keep template-tag from getting loaded into input box, put the for template tag ABOVE all the section tags. If you put the for template tag below the last section tag, then the stuff transcluded from the template will get loaded into the last input field on "edit with form". Nota bene.

{{{info|page name=Draft}}}
{{{for template|Dogs}}}
{{{end template}}}
__NOEDITSECTION__
==Dog Tip==
{{{section|Dog Tip|level=2|rows=2|cols=150|autogrow}}}

Johnywhy (talk) 18:20, 21 June 2018 (UTC)

What do you mean by "input fields", by the way? Yaron Koren (talk) 18:26, 21 June 2018 (UTC)

By "input fields", i meant the "section" tags. Edited above. Johnywhy (talk) 18:31, 21 June 2018 (UTC)

BUGS? How To Put Static WikiText into Created Page?

The following does display the default value when creating a new page, but then the value does NOT get inserted into the created page.

{{{field|input type=text|default=[[Category:Dog]]}}}

Any fix?

Johnywhy (talk) 18:29, 21 June 2018 (UTC)

Putting "nowiki" tags around the category tag may help; I'm not sure. Yaron Koren (talk) 18:37, 21 June 2018 (UTC)

'nowiki' didn't work. Any other ideas? i noticed that, without the 'nowiki' tags, my form got added to the Dog category.

Not really... although, if that field will always hold a category name, then the template itself can put the category tag around the name entered by the user. Yaron Koren (talk) 19:16, 21 June 2018 (UTC)

But the user won't enter a category. I want to hardcode the category, and hide it like this:

{{{field|input type=text|hidden|default=[[Category:Dog]]}}}

Does that give you any ideas?

I'm just experimenting for a way to avoid using a template. Seems to me that hardcoding the category into a page-creation form should be a feature built-into the form, without requiring a template. Too complicated, too many moving parts. Thx Johnywhy (talk) 19:20, 21 June 2018 (UTC)

I see. Well, you can't have a "field" tag without a template. Yaron Koren (talk) 19:32, 21 June 2018 (UTC)

Then how about a "standard input" tag? Johnywhy (talk) 19:34, 21 June 2018 (UTC)

Within the "free text" field, you can preload a category tag... didn't you already do that before? Yaron Koren (talk) 19:40, 21 June 2018 (UTC)

Yep, that causes problems, described in topic above:

• Free-text invades section - With `free text` after the last section-tag: when i click "Edit with form" on the new page, the free-text Category tag gets loaded into the last section-box. Then the user could delete or corrupt it. That's a bug, right? Category tag should NOT get loaded into a section-box.
• Free-text causes error - With `free text` before the first section-tag: when i click "edit with form", i get error message "page already exists, but doesn't use this form". That's a bug, right? Your code mistakenly assume the category tag will be at the bottom.

Johnywhy (talk) 20:17, 21 June 2018 (UTC)

I wouldn't call the first one a bug (it's inevitable); the second one does sound like a bug. I haven't done much testing of forms with no template. Yaron Koren (talk) 20:49, 21 June 2018 (UTC)

Ok, since that's "inevitable", I've updated your manual Extension:Page_Forms/Defining_forms#Free_text_input_combined_with_section_input -- Johnywhy (talk) 21:03, 21 June 2018 (UTC)

IMO i would call the first one a bug too. Free-text invading the section should reasonably not happen. You offer free-text as a separate entity. Therefor, your extension should mark-off the free-text in some way. Or at least ignore category tags! Your extension should respect MW standards. By MW standards, when a page is normally rendered, category-tags at bottom of source are never included in last section. MW KNOWS they are NOT part of the last section. But your extension doesn't know they are not part of the last section. Your extension breaks MW.

I don't see how it breaks MediaWiki... even core MediaWiki considers category tags part of sections, when doing section-based editing. Of course, core MediaWiki doesn't have the concept of a "free text" area. I don't know how the free text could be marked off, but you make a reasonable point that category tags should automatically be put into the "free text" input, if they're at the end of the page and the form ends with a section input and then a free text input. I should note that this probably doesn't happen often, since I think very few people put free-form category tags in pages that use forms. Yaron Koren (talk) 23:48, 24 June 2018 (UTC)

How to match a particular namespace to a particular form?

I would like to match a namespace to a form. This here I have read. Now I'm a little bit puzzled. Usuallay I create new namespaces by adding them to the $wgExtraNamespaces global variable in my LocalSettings.php file. Initially there is no page in that namespace. How can I locate the page defining that namespace? The projects name is WGKCollect. Lets assume, the new namespace is named Person. If I navigate to the WGKCollect:Person page, I find no page. I have to create this page. How does this needed property look like and what have I to type into that WGKCollect:Person page to add this property? And after typing the property of whatsoever kind, I have to add only this here: {{#default_form:Person}}?

Please let me know, what I do not understand here. Thanks for that in advance!--Wgkderdicke (talk) 12:22, 23 June 2018 (UTC)

Sorry about that - that documentation was outdated, from the days when an SMW property was used to define the default form. I just updated it, so now hopefully it's clearer. But yes, you just need to add that #default_form code. Yaron Koren (talk) 23:58, 24 June 2018 (UTC)

Reusing form elements with HTML escaping doesn't work

Hi, when I include templates into my form and characters are HTML-escaped, forms don't work anymore. However it works with <nowiki> tags, but I would have to replace a lot of templates to get things going again. We recently updated from MediaWiki 1.16 to 1.29.1 with page forms 4.3.1. Is this simply not supported anymore or did I miss something else? For example we used templates like this before we updated:

 {{{for template|Publication Tool|multiple|label=more tools}}}

'''Tool:''' {{{field|Tool|mandatory|autocomplete on category=Tool}}}

{{{end template}}}

Thanks in advance!  --Yochn (talk) 11:05, 26 June 2018 (UTC)

Checkboxes + display if not emtpy conflict

If i use the inpute type "checkboxes" (eg. values xyz, abc, def, ghi) in combination with "Display if not empty" and I want to choose more than one value I get the error "xyz, abc, def is not in the list of allowed values".

That sounds like a bug in the Page Schemas extension, where it's outputting the wrong thing for the form or template (I'm guessing that the template is lacking an #arraymap call for that field). Yaron Koren (talk) 15:21, 29 June 2018 (UTC)

Actually, it was a bug in the Page Forms code that integrates with Page Schemas, so you put this in the right talk page. I just checked in a patch that I think fixes this problem. Yaron Koren (talk) 17:25, 2 July 2018 (UTC)

Query Form example?

Could someone please post an example query form? (Or a link to a site where I can see one in action?) I need to create a form that allows users to narrow results based on 3 or 4 of 9 fields. I can write the query on a case by case basis, but would like a single form to handle this. I feel like all I need is to see an example Query Form as a jumping off point. May214 (talk) 17:33, 29 June 2018 (UTC) May214 (talk) 17:33, 29 June 2018 (UTC)

You can see one in action here: https://sandbox.semantic-mediawiki.org/w/index.php?title=Sp%C3%A9cial:RunQuery/BooksQuery Cavila 18:57, 30 June 2018 (UTC)

Thanks, Cavila. It looks like there is a BooksQuery form calling the BooksQuery template. All of this is done via Semantic. My case uses Cargo and PageForms; are the processes different? Also, one of my search parameters needs to be a range, (like published from 2003-2007). How would you do this in the query form? May214 (talk) 13:56, 1 July 2018 (UTC)

The overall structure is the same but the syntax for your queries in the output template and some data-dependent form elements such as autocomplete would be different. I don't recall that Page Forms offers inputs with type="range", although you could just have two text inputs for start and end year and do some "greater/lesser than" filtering in the template that receives the data from your form - see Extension:Cargo/Querying_data#Date_filtering for an example. Yaron is your man for both Page Forms and Cargo. Cavila 21:26, 1 July 2018 (UTC)

By the by, if anyone wants to see the form query in a Cargo/PageForms implementation, here's what I've learned. First step, Template for the query. I re-used the variable names from the template declaring and storing the cargo table that I'm querying. Of course, the query template does not require the cargo declaration or storage calls. Then I built a long chain of parser #if statements inside the where clause of the cargo query. Each #if statement is terminated by AND. Then I added a final always true argument to cap off the last AND. Sharing here:

{{#if:
  {{{MeasuresLo|}}}
  |Measures > '{{{MeasuresLo|}}}' AND
}}
{{#if:
   {{{MeasuresHi|}}}
   |Measures < '{{{MeasuresHi|}}}' AND
}}
{{#if:
   {{{Length|}}}
   |Length= '{{{Length|}}}' AND
}}
{{#if:
   {{{Mood|}}}
   |Mood = '{{{Mood|}}}' AND
}}
{{#if:
   {{{Techniques|}}}
   |Techniques HOLDS '{{{Techniques|}}}' AND
}}
{{#if:
   {{{Sources|}}}
   |Sources HOLDS '{{{Sources|}}}' AND
}}
_pageID > '0'
|format=dynamic table
}}

Second step is the straightforward process of building the Form for the template. Again, for the most part, I just reused the Form to add data to the page, slightly tweaked for including a range of variables (MeasuresLo, MeasuresHi in above, for example). Workin' like a charm! May214 (talk) 13:06, 3 July 2018 (UTC)

About autoedits in content namespaces

I don't think I understand why this change was introduced but I added it to the documentation here. Please be ruthless and correct me if I'm wrong. Best, Cavila 20:35, 30 June 2018 (UTC)

Yes, that's right - thanks for adding that in; I forgot to add it before. It's a security measure, to prevent people from accidentally overwriting pages in the "MediaWiki:" namespace, etc. Yaron Koren (talk) 01:20, 2 July 2018 (UTC)

"touch" page to update Cargo Row?

With the help of Ike and Yaron at WikiWorks (unpaid plug!), I have a fantastic system whereby users can rate a level of difficulty for piano pieces. The users rating is averaged via a cargo query, and the average also stored using a cargo query in the #cargo_store part of the template. The system works beautifully, especially when querying the database to find pieces.

There is a small problem, though. When a user posts a rating, the display of the template on the page automatically updates the new difficulty average. However, the page has to be re-saved (or the entire table recreated) for that new average to update in the cargo table. Is there a way, maybe adding a button to the User rating and review sub-page that will "touch" the page and cause it to be resaved and reture the user to the repertoire page? Maybe trigger an auto-edit that adds a single space to the free text area? Or is there a better way to do this?May214 (talk) 12:55, 3 July 2018 (UTC)

Thanks for the plug! This is indeed a tricky problem - getting "calculated results" to get updated automatically, or semi-automatically. The only solution I can think of at the moment is not to store those averages at all - instead, you should be able to display averages by re-calculating them every time. If you want to display a whole table of pieces and their average difficulty level, you should be able to do it using "group by=", if that makes sense. It's a little wasteful in terms of database usage, but probably not that bad, given that there will be caching of the results. Yaron Koren (talk) 19:58, 3 July 2018 (UTC)

Previewing a form while editing it disables edit/save hotkeys

If you preview a form while editing it, alt+shift+S and alt+shift+P hotkeys get disabled, though other hotkeys still work. I verified on two different Gamepedia wikis so I think probably a bug with the extension? --RheingoldRiver (talk) 04:26, 5 July 2018 (UTC)

These shortcuts work for me, on one of my test wikis... I'm guessing that the different behavior is due to the skin that Gamepedia is using, but I'm not sure. Yaron Koren (talk) 15:28, 5 July 2018 (UTC)

Ok, I'll try and look into it more on my end then, thanks. --RheingoldRiver (talk) 18:19, 5 July 2018 (UTC)

URLs when running queries

When using Special:RunQuery, the URL prediction doesn't work so well for longer forms and I was wondering if it could be improved a bit.

First, would it be possible to remove any checkbox param that's still at its default value from the prefill? One of my forms is giving me this url - URL (it's about 3300 characters long) but the vast majority of it is telling the form that checkboxes aren't checked or text fields are empty. The URL that my module generates for the same query is just https://lol.gamepedia.com/Special:RunQuery/MatchHistory?MH%5Bshowpermalink%5D=Yes&MH%5Btext_Date%5D=Yes&MH%5Blimit%5D=50&MH%5Bmhtype%5D=Player&MH%5Bplayer%5D=Bjergsen&pfRunQueryFormName=MatchHistory.

Also, what's the reason for the syntax MH[textonly][is_checkbox]=true instead of MH[textonly]=Yes? Are checkbox yes/no values going to be changed? Should I update my own URLs? In general I'd prefer the latter syntax just because it takes up fewer characters.

And finally, in that same query, the first time I run it, the URL doesn't change; I have to run it a second time (to replicate, go here and say player = Bjergsen and run with no further inputs). If you run the query once the URL will be the same, and then it's only when you run it a second time that it gives you the prefill. Not sure if this is intended behavior or a bug.

Sorry for all the requests recently, but thanks for everything! --RheingoldRiver (talk) 18:27, 5 July 2018 (UTC)

What do you mean by "URL prediction"? Is the issue that the URL is too long, and is getting chopped off? If so, it seems like the easiest solution would be to have the query form use POST instead of GET, so that the values don't show up in the URL at all. Would that work for this case? Yaron Koren (talk) 03:08, 6 July 2018 (UTC)

Sorry I meant to write URL prefilling, since it gives you a URL you can go to in order to see the same query run again. I actually like this feature a lot, but yeah, the URLs it's generating are way too long, in this case I wanted to be able to send it in a Discord message but it was over the 2k character limit. So I would like the values to still show up, but only if they're non-default values. --RheingoldRiver (talk) 03:33, 6 July 2018 (UTC)

Oh, I see. I don't think there's an easy way to have the URL get automatically shortened to only its essential elements, unfortunately. "is_checkbox" is there, if I recall correctly, because HTML forms for some reason don't submit a value at all if a checkbox is unchecked, so this is a way for the form to know that this checkbox was submitted. I think there are other ways to do it, but that's how Page Forms handles it at the moment. If it's only a handful of URLs that you want to publish, you could always shorten them manually, removing the perhaps 90% of the URL that's unnecessary... Yaron Koren (talk) 11:53, 9 July 2018 (UTC)

Would entering into URL only if non-empty work, even if that still captured some default values? That would still shorten by a ton. --RheingoldRiver (talk)

(To add some context, these are dynamic pages that I encourage people to use when they want a query that we don't have a good page for. Currently I construct a prefill URL as part of the template for every query people can run so they can bookmark it, but being able to copy from location bar instead is more intuitive for people I think, but the URLs as-is aren't really usable at all -- and even if I keep creating URLs for people I don't want anyone to think that something broke if they copy the location bar URL on accident. Also there's still the issue where you only get the permalink URL the second time you run a query, not the first.) --RheingoldRiver (talk) 14:49, 9 July 2018 (UTC)

Stop display label/section heading from showing on page created with forms

Is there a way to remove the display label or section headings from parts of forms so I can create an area of "free text" at the start of my articles (on most Wikipedia pages there is some introductory text without a section).

Introduction with display label

I want to stop the display label in the red box from being created

My current work around is creating a section with a section level of 6 and then using css display:none to hide h6 tags on the page although this isn't ideal.

--JoshHarry (talk) 10:58, 8 July 2018 (UTC)

You can have the "free text" input go above section inputs, if that's the question - it can be placed anywhere in the form. As for these images: where is the word "Introduction" coming from? Yaron Koren (talk) 11:34, 9 July 2018 (UTC)

Hi Yaron, thanks for the reply, I had a bit of difficulty wording the question. So what I was asking is how could I have a field labelled as introduction without "Introduction" appearing on the page itself, for example how this page on Wikipedia has some introductory text without appearing as part of a section. When I create a template to use for my form I am given the option of Sections or Plain Text (which is the picture from my previous example) as the output format.

Basically what I'm trying to say is how can I get a field with the label "Introduction" on the edit screen and then when the page is viewed there is the text inputted to the field at the top but without a Section title or label --JoshHarry (talk) 18:54, 9 July 2018 (UTC)

I'm trying to use page forms to create a similar editing experience to on The Movie Database (you have to sign up to edit and so also to see the editing style (let me know if you want any screenshots of what I am after)) Cheers --JoshHarry (talk) 19:04, 9 July 2018 (UTC)

I assume the word "Introduction:" is somewhere in the template you're using - you can just remove it from there. Yaron Koren (talk) 19:54, 9 July 2018 (UTC)

That worked, thanks for all your answers! --JoshHarry (talk) 20:55, 9 July 2018 (UTC)

Is it possible to remove the "free text" field from forms?

Is there a way to remove the free text field from the bottom of a form --JoshHarry (talk) 16:20, 9 July 2018 (UTC)

Yes - remove it from the form definition page. Yaron Koren (talk) 19:54, 9 July 2018 (UTC)

Can you edit forms once they have been created?

Can you edit a form after you have created it using Special:CreateForm without re-creating the form? --JoshHarry (talk) 16:22, 9 July 2018 (UTC)

Yes - go to "Form:name of form". Yaron Koren (talk) 19:55, 9 July 2018 (UTC)

Integrating Visual Editor into Page Forms

I was wondering if there was any way to integrate a reduced version of Visual Editor into Page Forms a bit like Structured Discussions does to make adding links easier for users that don't know wiki markup. I'm guessing this isn't possible but just thought it was worth an ask, cheers --JoshHarry (talk) 22:00, 9 July 2018 (UTC)

Maybe not even Visual Editor just something that allows users to use bold and italics and add links without showing wiki markup

You're in luck! Please see the VEForAll extension, which was just recently completed. If you have both VE and VEForAll installed, and use the latest Page Forms code, you can add "editor=visualeditor" into any textarea input and VE should show up there. If you try it, please let me know if it works for you... Yaron Koren (talk) 13:09, 10 July 2018 (UTC)

Wow I really wasn't expecting that to be possible, I'll try and get Visual Editor installed tomorrow hopefully if being on shared hosting doesn't cause too many problems and then I'll give it a try! Thanks again! --JoshHarry (talk) 20:11, 10 July 2018 (UTC)

Creating individual forms for each page

Would creating each page it's own unique form on a large wiki cause any issues?

No, although I assume it would be a ton of work. Yaron Koren (talk) 13:09, 10 July 2018 (UTC)

How to handle editing collisions

Problem: when a lot of users work with a wiki it's unavoidable that sometimes two edit the same page concurrently. As most of our pages are form-based we are especially looking for a way to handle this gracefully in Page Forms.

IMO the best solution would be that whenever someone tries to edit a page that is already edited by another user she/he get's a warning that editing is not save or something like that.

Can this be done? Or do you have a better suggestion? HermannSchwärzler (talk) 09:38, 12 July 2018 (UTC)

I don't think so - Page Forms uses the same editing-collision detection system as MediaWiki, which is to say, you only find out about a collision when you go to save the page. I assume that if it were possible (and made sense) to notify the user sooner, core MediaWiki would have done it already. Yaron Koren (talk) 19:41, 12 July 2018 (UTC)

Uploadable fields and file extension

When using the uploadable parameter for allowing users to upload an image, I'm running into an issue. I want to specify the filename, and I'm using default filename=image for <pageID>. (I'm substituting the parser for pageid). However, the file pagename also gets the extension appended to the pagename. ("File:Image for 97.jpeg" not "File:Image for 97") So when I go to link to that file page in the associated template, the appended file extension after upload is not referenced, and no image appears. If I hardcode ".jpeg" I can get it to work, provided I actually uploaded a jpeg. But what if the upload is a png? or a tiff? or a pdf?

In my template declaring the cargo table, I have the image set as string. I tried setting the field as a File, but that never worked because the extension did not come along with the default file name from the form. I always got a red link instead of the image (because what made its way into the table was just the filename without the extension.)

Am I doing it completely wrong? May214 (talk) 19:49, 13 July 2018 (UTC)

I should also note the uploads are coming from an iPhone. Don't know if that makes any difference. May214 (talk) 19:55, 13 July 2018 (UTC)

Yes, the hard-coded filename extension is the big weakness in the "default filename" feature, and makes it much less useful - or maybe not even useful at all. It would probably be better to not use "default filename" and just put in some text above or below the input recommending how best to name the file. Yaron Koren (talk) 15:58, 15 July 2018 (UTC)

Question

Maybe someone already asked such a question but, could you add a function that would work like "arraymap" but would show a default option. (Oleksiy) 212.80.62.177 12:47, 18 July 2018 (UTC)

• arraymap: t, v, g, |,| | switch: | a = 1| c = 2 |#default = 3 → 3 3 3
• arraymap: t, v, c, |,| | switch: | a = 1| c = 2 → 2

Is there a reason a standard #switch with a default case wouldn't work for that? E.g. {{ #arraymap: t, v, g, |,| | {{ #switch: a = 1 | c = 2 | 3 }} }}, which would output 3, 3, 3. 「ディノ奴千？！」^{? · ☎ Dinoguy1000} 13:27, 18 July 2018 (UTC)

If nothing found to return the default option, and not replace everything. I need 3, not 3, 3, 3. (Oleksiy) 212.80.62.177 13:38, 18 July 2018 (UTC)

I'm not sure what you're trying to do, but could it work to put a 2nd #switch call, around #arraymap? Yaron Koren (talk) 17:29, 18 July 2018 (UTC)

The problem with that is that it would require the #arraymap call to be repeated - once for the #switch input, and again for its output - unless the #arraymap only ever results in a manageably small set of known possible outputs (which in practice is far from guaranteed). This can be circumvented if Extension:Variables is installed, or by calling the #arraymap from a Lua module and storing the result in a variable there (though in the latter case, it begs the question of why you wouldn't just use native Lua functionality instead of #arraymap). 「ディノ奴千？！」^{? · ☎ Dinoguy1000} 05:52, 19 July 2018 (UTC)

I just looked at the original question more carefully - wouldn't it work to just put #arraymap within an #if call? No need for #switch calls at all, as far as I can tell. Yaron Koren (talk) 15:00, 19 July 2018 (UTC)

That still has the problem of having to repeat the #arraymap call if you actually want to pass its output along. 「ディノ奴千？！」^{? · ☎ Dinoguy1000} 18:04, 19 July 2018 (UTC)

I don't understand - why wouldn't just #arraymap within #if work? IF the value is non-empty, #arraymap gets called and the result is displayed; otherwise, a default value gets shown. Yaron Koren (talk) 01:25, 20 July 2018 (UTC)

Because you probably don't know ahead of time whether #arraymap is going to actually produce any output. Say for example you're running it on a parameter and you're only interested in a subset of the parameter's accepted values; there will be transclusions of the template, therefore, where that parameter doesn't have any interesting content, but you can't know that ahead of time (you might be able to check with StringFunctions or similar extensions, but that requires having such an extension installed/enabled and ultimately just moves the problem out one step, and in any case there are situations where even that wouldn't work).

Basically, this would be similar to the #default case for #switch: yes, you could implement the functionality of #default external to the #switch function, but it's going to be hacky and fragile. 「ディノ奴千？！」^{? · ☎ Dinoguy1000} 10:48, 20 July 2018 (UTC)

Right, that's true. Yaron Koren (talk) 21:21, 20 July 2018 (UTC)

Defining new inputs...

I've read this here. Now I'm a little bit puzzled. Well, I admit I'm a little bit half-baked when it comes to PHP, but one has to start somewhere...

• Does To create a new input type, you need to define a class for that input mean, that I have to create a file named PF_NewInputType.php?
• Does There are a number of methods that this class can or should define; the following are the crucial ones: mean, that this file has to contain at least four functions named getName(), getParameters(), getHtmlText() and getResourceModuleNames() and all of them need to be public and static?
• Do I have to put this PHP file in the \includes\forminputs folder of the Page Forms extension?
• What does Finally, once your new input is defined, it needs to be registered. You do that by using the 'PageForms::FormPrinterSetup' hook. You need to register with that hook a function that looks like the following: mean? Do I have to add

public static function onFormPrinterSetup( &$pfFormPrinter ) {
    $pfFormPrinter->registerInputType( 'NewInputType' );
}

to the LocalSettings.php file? Or the PageForms.php file?

• Where does the filename PF_NewInputType.php joins the game in the above-mentioned code snippet?
• In the PageForms.php file this looks different:

$GLOBALS['wgAutoloadClasses']['PFDateInput'] = __DIR__ . '/includes/forminputs/PF_DateInput.php';

Thanks for some advice in advance! --Wgkderdicke (talk) 00:40, 20 July 2018 (UTC)

Hi - well, the big question you first have to answer is whether this would go into the Page Forms code, or elsewhere. If the hope is to actually integrate this new input type into Page Forms, please talk to me about that. Otherwise, it would be much better to create a new extension for this input type - so that you don't run into issues when updating the Page Forms code.

In any case, yes, you need a file for that input type, and it should define a class and those four methods, and they should all be public and static (I think). If it's a new extension, then you need a hook function like the one above. And in either case, the file needs to be registered with 'wgAutoloadClasses'. I don't know if this is enough information for someone new to PHP and MediaWiki programming - I hope so... Yaron Koren (talk) 01:40, 20 July 2018 (UTC)

Hi. I've added a new topic to your talk page. --Wgkderdicke (talk) 23:48, 20 July 2018 (UTC)

Combining `values from namespace=` and mapping a cargo field

Hello

I have a Cargo table(Member details) used to store profile information about my members, including their real name (MemberDetails.full_name). On events page forms i'd like to display a drop down form that displays their real names, not their usernames.

I've defined my form field like this:

{{{field|attendees|input type=tokens|values from namespace=User|mapping cargo table=Member details|mapping cargo field=full_name|existing values only|size=30}}}

...but it doesn't work; the autocomplete still takes the titles of the User pages (i.e. their usernames) as the values.

Any thoughts on how to fix this? Thank you in advance!

PS I've also tried using the DisplayTitle and SemanticTitle addons, but that doesn't seem to work either.

Melat0nin (talk)

In theory, that should work... I wonder if the issue is that the "values from namespace" values lack a "User:" prefix, while the values in the mapping table have one. This seems like a hack, but instead of getting the main values from the namespace, you could get them from Cargo, by replacing "values from namespace=User" with "cargo table=Member details|cargo field=_pageName". Yaron Koren (talk) 20:06, 25 July 2018 (UTC)