Extension talk:Page Forms

Form input autofocus attribute
Is there a way to disable the 'autofocus' attribute from the text form inputs without manually hacking it out of the source code? I have issues on long forms where the autofocus shifts the page to the bottom of the form as soon as it is loaded because of that attribute (on pages using the #forminput parser functions). Removing it after the fact with jQuery doesn't work because by the time the jQuery call kicks in, the page has already been shifted down from the autofocus. --Lalquier (talk) 14:35, 4 April 2017 (UTC)


 * Nevermind - Answering my own question. I reviewed the list of parameters for #forminput and found I missed the 'noautofocus' parameter. --Lalquier (talk) 14:42, 4 April 2017 (UTC)

Pipes are not working with wikitable format
I get the following error when using a simple wikitable in a textarea box. Actual error message is "|" is not allowed, except within or ...

I see this was reported previously here: https://www.mediawiki.org/wiki/Extension_talk:Page_Forms/Archive_January_to_March_2016#Pipes_are_not_allowed

But it seems to be not working for us now. Version used: PageForms 4.0.2 (f0816ba) 22:12, 6 January 2017

MediaWiki	1.28.0 PHP	5.5.9-1ubuntu4.20 (apache2handler) MySQL	5.5.53-0ubuntu0.14.04.1

--Nischayn22 (talk) 07:29, 7 April 2017 (UTC)


 * A naked pipe will be interpreted as the end of the parameter you are trying to set with your field. Did you try transcluding the pipes with | ? - Lbillett (talk) 09:30, 7 April 2017 (UTC)


 * I am trying to use the WikiEditor to insert a table. The basic format of the table has pipes. I don't think I can transclude them, maybe tables just don't work with page forms?--Nischayn22 (talk) 13:27, 5 June 2017 (UTC)

Nested Forms with Multiple Instances
I'd like to have a form that allows multiple instances and has an optional sub-form that can go with each instance. For example, you may have a main form (form "Item"), which can have an "Item Detail" sub-form. And you can have multiple "Item" instances, each with its own sub-form. Is this possible? I think this is what the partial forms are for, but I cannot figure out how to use it. Thanks in advance. Gstupp (talk) 20:12, 9 April 2017 (UTC)


 * Are you asking about having a form that only edits one instance of a multiple-instance template? If so, unfortunately that's not possible. Yaron Koren (talk) 22:41, 9 April 2017 (UTC)

Autocomplete not working
Can you think why autocomplete isn't working with the following?

I am sure it used to work, but I can't think what's changed. Thanks. Jonathan3 (talk) 14:15, 28 April 2017 (UTC)


 * Someone else said this was a problem too, but I can't reproduce it. Do you see any JavaScript error message in the browser console? Yaron Koren (talk) 17:35, 28 April 2017 (UTC)


 * Yes. This is from Firefox:

TypeError: this.source is not a function[Learn More] load.php:6:984 ._search http://www.mydomain.com/load.php:6:984 $.widget/</prototype[prop]</< http://www.mydomain.com/load.php:78:450 .search http://www.mydomain.com/load.php:6:853 $.widget/</prototype[prop]</< http://www.mydomain.com/load.php:78:450 ._searchTimeout/this.searching< http://www.mydomain.com/load.php:6:590 handlerProxy http://www.mydomain.com/load.php:84:579
 * Jonathan3 (talk) 20:48, 28 April 2017 (UTC)


 * Could you add "?debug=true" (or "&debug=true") to the URL, to see if a more helpful error message can be seen? Yaron Koren (talk) 14:37, 30 April 2017 (UTC)


 * That didn't make any difference. It may be because I'm still using PF 4.1 (7f1cec5). I can't easily upgrade, as I haven't written that map/coordinates code for you yet, so have to add it each time... I'll get back to you when I do get the latest version. Jonathan3 (talk) 22:27, 1 May 2017 (UTC)


 * Ah - I'm pretty sure that upgrading will fix the problem, but until then, implementing these two changes directly in your code should hopefully fix the problem as well. Yaron Koren (talk) 01:58, 2 May 2017 (UTC)


 * I have reproduced the problem here, can you see it ? Nicolas NALLET Wiki-Valley.com, Semantiki.fr (talk) 09:40, 2 May 2017 (UTC)


 * This might be a different issue - in the JS console for that page, there's a Chameleon skin error that might be blocking the rest of the JS. Yaron Koren (talk) 13:36, 2 May 2017 (UTC)


 * Ok it's working now with Page forms version 4.1 (bb3327e) avril 27 2017 both here and vector skin based wikis. Thanks Yaron Nicolas NALLET Wiki-Valley.com, Semantiki.fr (talk) 07:04, 7 May 2017 (UTC)


 * The two changes mentioned above did the trick, thanks. Jonathan3 (talk) 01:27, 8 May 2017 (UTC)

Different list behaviour between dropdown and combobox
I have a property that has a set of allowed values defined using Allows value::xyz. If I put a field on a form related to this property, and I set the input type to dropdown, the dropdown list displays all the allowed values. In older Semantic Forms versions, the combobox input type also displayed the same list. Now, though, the combobox input type only lists the values that are actually assigned to the property on other pages. Is there any way to get the combo box to list all the allowed values? L Andy (talk) 15:57, 2 May 2017 (UTC)

Empty hidden field
Hello,

I'm trying to use an empty hidden field like this:

I want the form to automatically add  to the template on the new page. But it does not seem to work, this parameter is not added to the new page.

Is there any way to do that?

--Rudloff (talk) 17:17, 5 May 2017 (UTC)


 * I don't know of any. Yaron Koren (talk) 01:44, 8 May 2017 (UTC)


 * I don't know why you would want to have an empty parameter, but off the cuff, have you tried wrapping nowiki tags around an empty value or space? Cavila 17:04, 8 May 2017 (UTC)

Issue with two datetimepickers in the same form
Hi, I have an issue when two datetimepickers are used in the same form. The datepicker-part is missing, but the time-part is shown. The problem disappears when I reduce to only one datetimepicker in the form.

Tested with both PF 4.1 and PF 4.1.1, MW 1.28.1 and SMW 2.5.1.

--BMfly (talk) 06:42, 11 May 2017 (UTC)


 * I can't reproduce this problem. What browser(s) are you using? And if you can get to see the JavaScript console, do you see any errors there? Yaron Koren (talk) 17:46, 11 May 2017 (UTC)


 * Tested with Chromium 58, Firefox 53 and Chrome 52, problem exists in all three browsers. Output from JS console:

This page is using the deprecated ResourceLoader module "jquery.effects.core". This page is using the deprecated ResourceLoader module "jquery.ui.position". This page is using the deprecated ResourceLoader module "jquery.ui.widget". This page is using the deprecated ResourceLoader module "jquery.ui.core". Please use "mediawiki.ui.button" or "oojs-ui" instead.
 * --BMfly (talk) 06:06, 12 May 2017 (UTC)


 * Those are all warnings that should be fixed (most of them come from Page Forms, I think), but I don't think any of them are preventing the JavaScript from running. This isn't on a public wiki by any chance, is it? Yaron Koren (talk) 14:13, 12 May 2017 (UTC)


 * I made a test on the sandbox SMW, which generates the same result: . The form consists of two datetimepicker fields, but only the time picker part is visible. BMfly (talk) 18:07, 12 May 2017 (UTC)
 * I can confirm that this still is an issue. The problem is, that PageForms loads the modules with  which does not resolve the declared dependency of   to  . A solution would be to use, but that would also mean that CSS that is needed on pageload needs to be placed in dedicated modules. --Osnard (talk) 11:06, 2 August 2017 (UTC)


 * What if you replace the calls to the $output->addModuleStyles and $output->addModuleScripts with $output->addModules - does it work better? And what CSS are you talking about? Yaron Koren (talk) 16:03, 2 August 2017 (UTC)
 * Yes, replacing with  with   will work. You can also leave the   call even if that means that the CSS will be loaded twice (directly on page load and via javascript before the actual module code is being executed) --Osnard (talk) 12:35, 17 August 2017 (UTC)


 * I have the same issue, two datetime pickers and I can only see the clock icon (I just checked and I have same problem with single datetimepicker instance...). Also, if I have default dates set in proper format, upon Preview or Save, if time is set, dates become undefined. MW 1.29, SW 2.5.4, PF 4.1. Blaz Malnersic (talk) 17:53, 10 August 2017 (UTC)

does no longer work on 4.1.1 for "free text"
I just realized that after upgrading from Page Forms 4.1 to 4.1.1 the WikiEditor no longer shows up for the "free text", e.g. . It continues to work for   but still I had to pull the new version. Cheers --&#91;&#91;kgh&#93;&#93; (talk) 19:47, 14 May 2017 (UTC)


 * There is a live example and the respective form definition is in this spot Cheers --&#91;&#91;kgh&#93;&#93; (talk) 07:29, 23 May 2017 (UTC)


 * Thanks for following up on this. I just checked in what I think is a fix. Yaron Koren (talk) 16:26, 23 May 2017 (UTC)

Is there a limit on number of values in a dropdown when populated from cargo fields?
I am trying to populate a dropdown (or combobox) using tokenized data stored as a single "List of String" in a Cargo table.

The dropdown works - in that it populates, and I can select individual list items - but it looks like it's stopping at around 100 entries. Is this a limitation of values dependent on using Cargo, or is this a limitation with using a tokenized single list?

Here is the field declaration in the muti-instance template:

The data is stored as in a separate template.

Before I look to structuring the data differently (ie, store ThirdPartyCollect as separate rows instead of a delimited single entry), I'd like to know if this would solve the issue. FYI, the real goal is actually to combine several Cargo fields into a single, alphabetized dropdown in the spreadsheet-style view. I've almost got this in place, but it's konking out at 100 entries in the dropdown.

--Bgrenon (talk) 02:17, 16 May 2017 (UTC)


 * Is this happening in the spreadsheet display, or in a standard display? Or both? Yaron Koren (talk) 15:17, 16 May 2017 (UTC)

It looks like both. --Bgrenon (talk) 15:48, 16 May 2017 (UTC)


 * The fact that it's happening in the spreadsheet is not that surprising, but with the standard display it's quite surprising. What versions are you using of Page Forms and Cargo? Yaron Koren (talk) 17:49, 16 May 2017 (UTC)

Cargo 1.1.1 and Semantic Forms 3.7 --Bgrenon (talk) 18:19, 16 May 2017 (UTC)


 * Oh... those are both old, as I'm guessing you know. Maybe upgrading to the latest versions would fix the problem? Yaron Koren (talk) 18:31, 16 May 2017 (UTC)

Same settings, different resulting fields
I am not sure if it is a PF issue, but here we are: I have these two form fields:

the only difference between the two is the name field. But when the form loads, it looks like different. See. We can see from the URL that both of the fields are sending the same information: Institution[Has hierarchical superior]=Configuração:Institution 003 & Institution[Has parent page]=Configuração:Institution 003

It seems like a bug. I am using PF 4.0.2 (fbecc9f). Jaider msg 20:28, 18 January 2017 (UTC)


 * That does look like a bug, yes. Yaron Koren (talk) 20:41, 18 January 2017 (UTC)
 * Cindy.cicalese maybe you have an interest in this bug. Jaider msg 13:53, 26 May 2017 (UTC)
 * That is indeed strange. Try removing the "|mapping property=Display title of", which is no longer necessary. You may need to update to a more recent version of Page Forms. Cindy.cicalese (talk) 14:16, 26 May 2017 (UTC)
 * Cindy.cicalese, done + errors:

Jaider msg 14:30, 26 May 2017 (UTC)
 * Warning: asort expects parameter 1 to be array, object given in /mw-REL1_28/extensions/PageForms/includes/PF_ValuesUtils.php on line 588
 * Warning: array_unique expects parameter 1 to be array, object given in /mw-REL1_28/extensions/PageForms/includes/PF_ValuesUtils.php on line 589


 * (Just a brief note, to anyone reading this and confused - the first few lines, from January, were copied over from the archives.) Yaron Koren (talk) 16:21, 26 May 2017 (UTC)

Autocompetion on Category
Hi, I am using PageForms to create pages with sequential names, e.g. 'PageName 0001', 'PageName 0002' etc. To avoid duplications I used the argument 'Autocomplete on category', so users can check if a page name already exists. This is very useful until there are few pages, but when they become hundreds, users are obliged to guess which will be the next 'free' page name. I didn't find anything in Page Forms user guide to solve this problem. While I was searching for a solution I have a simple idea about how to solve it: it would be enough to set 'Autocomplete on category' to show page names in a reverse alphabetical order (Z to A), so users would immediately see the last page name used. Does anyone know if this could be a possible solution?

Update: I have found something here.

Thanks,

--Loman87 (talk) 08:11, 5 June 2017 (UTC)


 * You may be in for a treat - see The one-step process; it may make your life a lot easier. Yaron Koren (talk) 14:29, 5 June 2017 (UTC)
 * Wow! This is really helpful Yaron, thanks a lot! --Loman87 (talk) 09:29, 6 June 2017 (UTC)

Value delimiter
Hi, there is an issue that I am not able to fix by myself.

I have a very simple form to create bibliographical pages; in the template I set the field 'Name' as follows:

The same field in the form is set as follows:

When I start typing the field, autocompletion appears as expected; but if I select one of suggested values, a comma is automatically added after the value. If I add a new value, the same happens; after saving, the whole field contains a unique value composed by all the values that I have added, separated by a comma. Now, I understand why this happens, since in the template the delimiter is semicolon. If I come back to the field and I manually change comma with semicolon, the values are actually processed as two different values, but, after saving, I see them separated by comma not semicolon. This is one issue.

Secondly, when I am filling the form and I use semicolon to separate the values, autocompletion doesn't work; otherwise, it works if a I use a semicolon.

Am I missing something very basic? Please help!

Thanks,

--Loman87 (talk) 12:11, 6 June 2017 (UTC)


 * I didn't really understand the second issue, but I'm guessing that both would be fixed if you added "|delimiter=;" to the field tag in the form definition. Normally the form would be able to figure that out from the template, but somehow it's failing here - maybe because of the parentheses in the field name. It seems like a Page Forms bug, in any case. Yaron Koren (talk) 13:37, 6 June 2017 (UTC)
 * I meant 'otherwise, it works if a I use a comma', sorry. However I added "|delimiter=;" to the field tag in the form definition and everything works fine, both visualization and autocompletion. Thanks for the help. --Loman87 (talk) 14:06, 6 June 2017 (UTC)

Dollar symbol issue
I have a form with a price input, but for some reason whenever I enter say "$100" it becomes "0" or "$9.55" becomes ".55". am I doing something wrong? or is something else affecting this? -- Cy be r XR ef ☎ 06:39, 8 June 2017 (UTC)


 * That was a problem a while ago, but I thought it was fixed already. What version of Page Forms are you using? Yaron Koren (talk) 14:10, 8 June 2017 (UTC)


 * Page Forms 4.1.1, Semantic MediaWiki	2.5.0 -- Cy be r XR ef ☎ 16:52, 8 June 2017 (UTC)


 * Well, there's a slightly newer version of PF, but I doubt that's the issue. What version of MediaWiki are you running? What is the input type of that field? And what is the type of the corresponding SMW property? Yaron Koren (talk) 18:34, 8 June 2017 (UTC)


 * We're using MediaWiki 1.28.1 and the input is just "text". The problem occurs in any field I enter a number starting with a dollar symbol actually.
 * If I enter "$123.456" in pretty much any field. When I click the "Show changes" the value shows up as:.
 * This is true even if I disable JavaScript, Just to make sure I don't have some conflicting library. -- Cy be r XR ef ☎ 20:36, 8 June 2017 (UTC)


 * I just tested it some more and discovered this only happens when I work on pages with existing template. If I try to create a new page with the form, it saves the value correctly (e.g., "$123.456"). Maybe this can help pinpoint the exact issue. -- Cy be r XR ef ☎ 22:21, 8 June 2017 (UTC)


 * I can't reproduce this issue, with either new pages or existing pages. Is this a public wiki, by any chance? Also, I would try upgrading to the latest version of PF - who knows, maybe that will fix it. Yaron Koren (talk) 15:42, 9 June 2017 (UTC)


 * Problem persists in . And naa, the wiki is internal only. I'll try to see if I can find something on wikiapiary. -- Cy be r XR ef ☎ 18:37, 9 June 2017 (UTC)


 * Hey Yaron, I found the issue (or at least one). Line 1363 of PF_FormPrinter.php. preg_replace is eating that "$12". Here is a minimal reproducer on codepad. -- Cy be r XR ef ☎ 05:50, 10 June 2017 (UTC)

Thanks for finding that, that's very helpful. Is this a "partial" form, by any chance? Yaron Koren (talk) 15:27, 14 June 2017 (UTC)


 * Yes this is a partial form. -- Cy be r XR ef ☎ 21:26, 14 June 2017 (UTC)


 * Okay, that explains it - this only happens for partial forms, which is why I couldn't reproduce it. I just checked in what I think is a fix. Yaron Koren (talk) 17:11, 15 June 2017 (UTC)


 * Looks like it's fixed! -- Cy be r XR ef ☎ 13:18, 17 June 2017 (UTC)

Two forms in one Page
Is there a way to edit two forms in the same time on the same page ? --Paul LEMPERIERE (talk) 19:29, 9 June 2017 (UTC)


 * Sorry, I don't know what you mean exactly. Yaron Koren (talk) 15:43, 9 June 2017 (UTC)


 * For exemple, I want to create a page "Project 0001" and a page "Event 0001", using a form called "Project" and a form called "Event". But I don't want to call successively this two forms. I want to create the two pages in the same time. Is it possible ? --Paul LEMPERIERE (talk) 19:29, 9 June 2017 (UTC)


 * Alternatively, I'd say you want to use a single form - not two - to create as well as edit two separate pages, right? What you could do is use the AutoCreatePage extension to create your second page (Event 0001) automatically as soon as the first page (Project 0001) is created. Secondly, ensure that the first page contains the source data for both pages but only show the information relevant for each page. This requires that your second page contains calls to your master page - clever transclusion or use of queries through the Semantic MediaWiki extension or Cargo could help you with that. Cavila 06:45, 11 June 2017 (UTC)


 * Thanks a lot, it seems that this is the good way to solve my problem ! But I have another question : in a standard form, you can use the "page name=" parameter combined with the tag to generate incremental and unique page name. That's what I use to define the name of my "Project" pages (Project 0001, Project 0002,Project 0003,...). Unfortunately, when I use the parser provided by the AutoCreatePage extension to create my event pages, I can't use this way to name the pages, and so I can't name incrementally my events (Event 0001, Event 0002,...). Do you know a way to solve this problem ? Thanks ! --Paul LEMPERIERE (talk) 09:25, 5 July 2017 (UTC)


 * I don't know. Talk to the author of that extension (Markus), I guess? Yaron Koren (talk) 14:44, 5 July 2017 (UTC)

Image in a combobox
I'd like to know if it is possible, in a form, to use images as list of values for a combobox ? Something like this : ? When I try to do this, images appear in the list, but when I select one of them, it's a tag who is displayed... --Paul LEMPERIERE (talk) 21:58, 10 June 2017 (UTC)


 * I think you can do this only in a roundabout way, via the External Data extension - see here. It's somewhat confusing, especially if the image data comes from MediaWiki itself - let me know if any of it doesn't make sense. Yaron Koren (talk) 03:05, 12 June 2017 (UTC)

formlink variable doesn't get parsed through (SOLVED)
Hi, I following direction from: https://www.mediawiki.org/wiki/Extension:Page_Forms/Linking_to_forms#Using_.23formlink to parse through a value to a variable using formlink. In the example the 'pagename' gets assigned to 'Author' in the cargo table Quote. I'm trying something similar for example: http://csdms.colorado.edu/wiki/Model:HydroTrend#References. The 2 buttons ( "Automatically enter Reference by DOI" and "Manually enter Reference" ) are defined at: http://csdms.colorado.edu/wiki/Template:AddReferenceUploadButtons. The formlink contains the table name, variable and value (pagename) as indicated, but the value doesn't get passed. Is this because the template in the form is set up to hold multiple values ? This is how the URL looks when trying to parse through the variable: http://csdms.colorado.edu/wiki/Special:FormEdit/Reference-auto1?RefsInt2%5BPublicationMultipleModelsCargo%5D=HydroTrend so seems like almost working to me. Tested this in Chrome.

Thanks, --Albert Ke (talk) 16:16, 14 June 2017 (UTC)


 * Yes, the query string for multiple-instance templates needs to be different - if you replace "RefsInt2[PublicationMultipleModelsCargo]" with "RefsInt2[1][PublicationMultipleModelsCargo]", it should work. By the way, if you only have one field in the template, it doesn't seem worth it to have that template... you can just replace it with a field that holds a list of values, like a "tokens" input. Yaron Koren (talk) 17:45, 15 June 2017 (UTC)
 * Works!! That was a simple fix, thank you! I'll look into the "tokens" input, thanks, --17:53, 15 June 2017 (UTC)

Is it possible to hide empty sections?
Hi, is it possible to not add to the page the heading for sections left empty? I see the extension does this for empty template parameters, and I'm looking to have the same happen with empty sections. Is it possible? If not, could you point me in the right direction to accomplish this in code? Thanks, FFS Talk 12:48, 21 June 2017 (UTC)


 * It's not possible, but it sounds like an interesting idea. You would have to modify lines 171-178 of includes/wikipage/PF_WikiPage.php - and possibly more if you wanted to make it a true form option. Yaron Koren (talk) 18:55, 21 June 2017 (UTC)


 * Thanks for pointing the way! Since I definitely do not want to keep a fork of my own, I ended up doing it as an option (editing PFPageSection, PFWikiPageSection, PFFormPrinter and PFWikiPage). It was really easy to dive into your code! I'll try to clean it up and submit as a patch soon, so you can behold in horror the result of my horrendous naming skills. And maybe even merge it, eventually :-) FFS Talk 23:54, 21 June 2017 (UTC)


 * Actually, I have a question - I currently have it implemented as a section-by-section option ("hidewhenempty"). I'm not sure if that makes any sense; do you think it makes more sense to have it as a global configuration option, or maybe a form-level one? For my use case it doesn't matter at all (I will always hide empty sections on my wiki). FFS Talk 11:02, 22 June 2017 (UTC)


 * That's an interesting question. I agree that this would be a useful feature, but I think you're the first person who has asked about it, which means that I don't know what all the potential use cases for it would be. But it seems to me that a section-based option, like you have it, is the safest approach. Though maybe calling it "hide when empty" (with spaces) is better... Yaron Koren (talk) 15:00, 22 June 2017 (UTC)


 * OK, so I submitted 361238 and added you as a reviewer. I'd love your feedback and to know what mistakes I made along the way :-) FFS Talk 20:25, 24 June 2017 (UTC)

datepicker not usable
Hi Yaron,

i'm using PageForms 4.1.2. Fields with a a datepicker-type and a datetimepicker-type appear like usual fields. Here's the code from the form: There's no error on js-console. This is the html-code generated by the system: Wunschdatum:  What's wrong? --217.234.159.235 09:11, 26 June 2017 (UTC)
 * valign="top" | Wunschdatum:
 * valign="top" | Wunschdatum:
 * Sorry, sometimes the ideas came while writing. There was a mediawiki:common.js. Seems to be the problem. I've deleted this and datepicker works :-)

"Show on select" not working properly
I maintain the website where, among others, one can find information about locomotives. A locomotive can have status "scrapped", "in running order", "exhibit" and so on. Depending on the status the form displays some fields, and some fields not. In some cases the fields are the same - only instructions shown to the editor differ. When an editor uses the form to create a new record everything is fine. But when he wants to update information a problem appears. The form shows values in fields only when the fragment of the code responsible for displaying them is in the first block of conditional code. Example:

. ..

. ..

. ..

So when the status of the locomotive is "Złom" (which means scrapped) or "Ostawiona" (out of order) and the user wants to edit an existing page fields in the form are empty (values are not shown though they exist in the code of the page). When the status of a locomotive is "Sprawna" (in running order) values in the fields of the form are shown properly. Shortly said: data are shown in fields of the form only if the div responsible for displaying them is first in the code. When it is second, third and so on - fields of the form are empty. Is it a bug or it is me doing something wrong?

I use MediaWiki 28.2, SMW 2.5.2 and PageForms 4.1.1. But the problem also existed when I used slghtly older versions of MW, SMW and PF. Regards Pawel Niemczuk (talk) 17:02, 1 July 2017 (UTC)


 * Could you link to (if it's on a public wiki) or pastebin the entire form definition? Yaron Koren (talk) 02:35, 3 July 2017 (UTC)
 * Yaron, thank you for your prompt reply. In the meantime I've analyzed the code and rethought it. And I've come to the conclusion that it is my mistake and wrong way of thinking. So apparantly the code, though it is not displayed, is still parsed. And this produces unforseen or unwanted behaviour. Shortly said: if there are several divs which are displayed (or not) depending on selected value they should not use the same names of fields. So in order to avoid unwanted behaviour one should either carefully design the code of the form or, what is way more complicated, cumbersome, not elegant and obfuscates the code, redesign it changing names of the fields which are repeated in different divs (and, consequently, redesign templates, queries etc.).


 * To make a long story short: I think I've found the solution and once the form is ready I'll post links to both old and not working version and the new working one. Pawel Niemczuk (talk) 23:36, 3 July 2017 (UTC)


 * I just read this again, and I realized I missed the part before where you mentioned using the same field names in different divs. Yes, that doesn't work, and it's a frequent complaint of people using "show on select". The "values dependent on" option is a way to try to achieve something similar - where the value selected for field A affects the allowed values for field B - but it doesn't work exactly the same, so it may or may not be helpful for your case. Yaron Koren (talk) 14:13, 21 July 2017 (UTC)

openlayers input over https
When using openlayers input on a server running https, I get the following JS error:

Mixed Content: The page at 'https://myserver/index.php?title=Building:9cd73c9a-f238-4757-b4d2-5e91554daa59&action=formedit' was loaded over HTTPS, but requested an insecure script 'http://openlayers.org/api/OpenLayers.js'. This request has been blocked; the content must be served over HTTPS.

The funny thing: changing  ~Line 59 to   and flushing all caches still returns the above error...


 * ...ah, it seems, that the openlayers.org is always redirecting to http


 * ... using the recent version of Extension:OpenLayers fails with the following JS error:


 * Mmm, I remember seeing the same error in another situation (using a widget with OpenLayers v2.x). It worked for a moment by replacing it with a call to https://cdnjs.cloudflare.com/ajax/libs/openlayers/2.13.1/OpenLayers.js but after a day or so, this, too, failed. Cavila 07:19, 17 July 2017 (UTC)

Special:CreateClass over rides property pages with no warning
It appears that when I use Special:CreateClass and input properties that already exist, I edit the property pages with no warning. A user kept changing my properties page type from Has type::Page to Has type::Text and they didn't realize it because they were using Special:CreateClass. --Mav-Tek (talk) 17:09, 5 July 2017 (UTC)

Default filename when using "uploadable" parameter
Is it possible to base the default filename on the current contents of one of the form's own fields? Thanks. Jonathan3 (talk) 00:41, 16 July 2017 (UTC)


 * No, unfortunately. Yaron Koren (talk) 22:52, 16 July 2017 (UTC)

Autocomplete in forminput only works once
I use this to create or edit a page with autocompletion on a category (PageForms 4.1.2):

Strangely, autocompletion in this input field only works one single time after I change something in the LocalSettings.php (regardless of what I change, can be just a new line). When I reload the page, it's not working anymore (until I change again the LocalSettings). Any idea, what's going on there? The autocompletion in the search bar works. Marccreal


 * When it's not working, do you see any errors in the JavaScript console? Yaron Koren (talk) 17:39, 19 July 2017 (UTC)


 * No, there are no errors (in Chrome the console under "More Tools/Developer tools" is the correct place to look, right?). The only thing, that shows up there are these warnings, but they always show up (and already when loading the page):
 * VM13225:70 This page is using the deprecated ResourceLoader module "jquery.ui.position"


 * VM13225:81 This page is using the deprecated ResourceLoader module "jquery.ui.widget".


 * This page is using the deprecated ResourceLoader module "jquery.ui.core". Please use "mediawiki.ui.button" or "oojs-ui" instead. Marccreal (talk) 22:15, 19 July 2017 (UTC)


 * More puzzling findings: The behaviour is "page-wise". Even when there are two different forminput with autocomplete to different categories, autocompletion works for both of them but only until I reload the page. But if I then go to another page with a forminput, it works there again (but again only until reload). Marccreal (talk) 22:37, 19 July 2017 (UTC)


 * Alright. I know about those JS warnings - I need to fix those, but they're unrelated to this issue. I'm pretty sure the problem is the MediaWiki cache - you don't need to edit LocalSettings.php to get the autocompletion temporarily working, you just need to add "?action=purge" to the URL, I think. I don't know why this is happening for you, though. Do you have some unusual MW caching setup? And what version of MediaWiki are you using? Yaron Koren (talk) 03:54, 20 July 2017 (UTC)


 * You are right, adding "?action=purge" makes the autocompletion work. I also suspected some problem with caching. The setting after installation was $wgMainCacheType = CACHE_NONE; I tried CACHE_DB, but this did not change anything (or do I have to do additional steps besides setting the variable?). During installation, the following warning was displayed: "Warning: Could not find APCu, XCache or WinCache. Object caching is not enabled." Marccreal (talk) 08:14, 20 July 2017 (UTC)


 * What version of MediaWiki are you using? Yaron Koren (talk) 11:50, 20 July 2017 (UTC)


 * Sorry, forgot to answer that: 1.29.0. I now changed to $wgMainCacheType = CACHE_ANYTHING; With that, autocompletion seems to work!


 * Oh - very interesting. It's great that you found a solution. I'll have to look into that; ideally this can work with any caching type. Yaron Koren (talk) 12:17, 20 July 2017 (UTC)


 * Bad news, it still does not work reliably. The functionality is not gone by a simple reload but for example after modifying the page. As before, ?action=purge brings back the autocomplete. Also when I load other pages and load then again the page with the forminput, autocompletion might stop working (not every time, but when it once stops working, it does not come back until a purge) Marccreal (talk) 13:29, 20 July 2017 (UTC)
 * Ok with this setting: $wgParserCacheType = CACHE_NONE; it seems to work. Which is very puzzling, because was set to $wgMainCacheType = CACHE_NONE; from the start, and the documentation says, that this setting is inherited by $wgParserCacheType, nevertheless autocompletion didn't work with this setting. By the way, I am not sure, if this page is suitable for communication about this problem so if you feel this should move to somewhere else, please let me know. Marccreal (talk) 12:30, 21 July 2017 (UTC)

No, here is fine. It's not surprising that turning off caching will fix this problem for you, given that caching was causing the problem. I'll have to look into it - it may be a new issue due to changes in MW 1.29. Yaron Koren (talk) 14:08, 21 July 2017 (UTC)


 * I have a 1.28.2 installation on the same server, it's the same issue there. Manual:$wgParserCacheType is unclear or wrong imho because it states: "If you set Manual:$wgMainCacheType then the values for $wgParserCacheType and Manual:$wgMessageCacheType will inherit it." Marccreal (talk) 14:42, 21 July 2017 (UTC)


 * What happens if you remove (or comment out) all caching-related settings from LocalSettings.php? Yaron Koren (talk) 04:13, 25 July 2017 (UTC)


 * Then it shows the "working once" behaviour again. Marccreal (talk) 10:53, 25 July 2017 (UTC)

Edit with Form Tab
Hello, what is the correct way to disable the edit with form-tab on a single page within a category with default_form. Example: i Have a category "countries" with {#default_form:country} in category-page. The pages are "Germany, Italian, etc.". Also there exist one page "merged country's" with some explanations, but this page can't use the form "country". In Previous versions of Page forms i use Has default Page::None on this special page to disable the edit with form tab. But this doesn't work anymore. --TomyLee (talk) 11:19, 31 July 2017 (UTC)


 * I don't remember if that previous behavior was intentional, or just an accident (by the way, it didn't have to be "None" - you could just put in any string that was not a form name), but it does make sense to have behavior like that - so that if someone adds " " to a page, it won't get an "edit with form" tab. I'll have to look into that. Yaron Koren (talk) 02:55, 1 August 2017 (UTC)


 * I just added that feature, so now " " works for this, if you get the latest code. Yaron Koren (talk) 20:02, 1 August 2017 (UTC)

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

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

Error: No form was found on page "". --David Hedlund (talk) 21:25, 6 August 2017 (UTC)


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

Validation about data submitted by users?
Hi everyone!

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

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

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

Thanks a lot :)


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


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


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


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

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

Am I missing something or is this a bug?

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


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

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

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


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

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

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

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


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

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


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


 * Perhaps a parameter called "sticky" is a way out allowing to define fields that should always be added into the template no matter if they are already holding a value or not. Or add all fields by default and not just if they have or had values ore not. --&#91;&#91;kgh&#93;&#93; (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. --&#91;&#91;kgh&#93;&#93; (talk) 07:07, 16 August 2017 (UTC)


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

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

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

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

Basically a template named "CategoryDefinition" containing:

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

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 " " in that second form? Yaron Koren (talk) 19:33, 11 August 2017 (UTC)
 * Yes Yaron, thanks for the hint and sorry for my novice question, it is being difficult for me to understand the logic of this sintax.
 * --JBBGlorfindel (talk) 23:34, 11 August 2017 (UTC)

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

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

Thanks.


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


 * Hi Yaron - tried changing the Property HasType to Page and form type to "field|Slides|input type=page|rows=1|uploadable". This goes through
 * the upload process but it doesn't upload. I basically get a link within the form to a non-existent form. Any ideas? Konjurer (talk) 17:31, 16 August 2017 (UTC)


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


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


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


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

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

Thanks Yaron for your assistance.


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


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

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

Here is my Form...


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


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

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

So to illustrate all this, a link from the 24th template instance on the page, such as [...]/Special:FormEdit/ / #instance24 (Autonumbering is easily achieved using the Variables extension)

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

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)