Extension talk:Page Forms

Auto-generated unique page title w/ auto increment ids
Hi, I am struggling with this extension. What I want to create is an issue tracker. If a user visits Form:Issue, there should be an only button that says "New issue" without any text field. If the user clicks the button, Special:FormEdit/Issue/Issue:1 (or Special:FormEdit/Issue/Issue:2 If the page exists) should be opened. I thought, or  are the key, but now I'm not sure about anything.

Regards. Lens0021 (talk) 08:41, 11 January 2022 (UTC)


 * You're close - you need and, but  instead of  ; see here. Yaron Koren (talk) 15:47, 11 January 2022 (UTC)
 * Thank you!! Lens0021 (talk) 02:42, 12 January 2022 (UTC)

[RESOLVED] Cannot save form after invalid URL entered
When I type an invalid URL (for a URL input type) the  message appears correctly but the "Save page", "Show preview", "Show changes", and "Cancel" buttons/links are all greyed out. When you click on the first three (buttons) they return the screen to the top of the page, but do nothing else. The "Cancel" link does work though.

This is on a MW 1.35 wiki (same result for REL1_35 and master branches) using Vector. I don't have the same problem on a MW 1.34 wiki. Disabling the extra extensions from the 1.35 wiki made no difference. Any ideas? Jonathan3 (talk) 09:43, 11 January 2022 (UTC)


 * I tried this out, and saw some strange behavior that's not quite the same, but maybe due to the same cause. I just checked in a fix - if you can, please get the latest code and let me know if that fixes the problem for you. Yaron Koren (talk) 19:11, 11 January 2022 (UTC)


 * I'm afraid not. Jonathan3 (talk) 22:03, 11 January 2022 (UTC)


 * Just tried a blank mandatory field and it had the same effect. Jonathan3 (talk) 22:09, 11 January 2022 (UTC)


 * Yes, okay - there were two separate problems, and the first one prevented me from seeing the second one. I just checked in another fix; please try it out if you can. Yaron Koren (talk) 18:18, 12 January 2022 (UTC)


 * It's an improvement, thanks, but still doesn't work... They're not greyed out any more, and "Show preview" works. "Save page" clears the error messages (page, and field-specific) if the field content is now valid, but the fields remain red-coloured, and the page doesn't get saved. "Show changes" does nothing. "Cancel" still works. Jonathan3 (talk) 23:22, 12 January 2022 (UTC)


 * Sorry again! This was sort of three problems in one. (Well, at least three.) I just checked in another fix - please let me know if that solves the problems. Yaron Koren (talk) 18:54, 13 January 2022 (UTC)


 * No problem! Thanks for the quick responses. It works well now :-) Jonathan3 (talk) 22:36, 14 January 2022 (UTC)

Textarea input type with "Edit with form" doesn't work as well on mobile as the normal "Edit" box
On the normal MediaWiki "Edit" box you can make the text scroll up and down by moving your finger up and down the mobile screen. The input box itself doesn't move.

On a PF textarea input type, this works the same when no parameters are set (or if only  is set).

But as soon as you set, it's the input box that moves, taking the (unchanged) text with it. So if you go to edit a page which has 100-lines of text in a box smaller than that, it's not easy to scroll through the text.

Is there any way to fix this, or is it just part of how "autogrow" works? Thanks. Jonathan3 (talk) 10:21, 11 January 2022 (UTC)


 * I don't know. Maybe "autogrow" should just be disabled in the mobile view? Yaron Koren (talk) 19:14, 11 January 2022 (UTC)


 * I've stopped using it entirely now. It was a pain on the desktop too when it was the wrong size for the text already in the field. It's probably good for a field containing just a few lines. Jonathan3 (talk) 12:11, 17 January 2022 (UTC)

[RESOLVED] Rename Special:RunQuery when embedding form
When a form is embedded on a wiki page using, is there any way to rename the results page from Special:RunQuery? Thanks. Jonathan3 (talk) 22:34, 14 January 2022 (UTC)


 * Sorry, I don't understand this question. Yaron Koren (talk) 00:45, 17 January 2022 (UTC)


 * When a query form is run, including let's say on a page called "My search", the results are shown on a page called "Special:RunQuery". But I've worked out the answer - using DISPLAYTITLE is possible after all, once Manual:$wgRestrictDisplayTitle is changed. I should have checked before asking! Jonathan3 (talk) 12:00, 17 January 2022 (UTC)

[RESOLVED] Modify "This category uses the form" text
I know it's possible to hide and replace it with other text, but is there any way of editing this message site-wide? This would also avoid the problem where spam blacklist objects to hiding via a CSS style Jonathan3 (talk) 19:00, 20 January 2022 (UTC)


 * Yes - you just need to edit the page MediaWiki:pf_category_hasdefaultform. Yaron Koren (talk) 14:12, 26 January 2022 (UTC)


 * That worked, thanks. For some reason I didn't see the message page name when using . Jonathan3 (talk) 17:45, 26 January 2022 (UTC)

Comma-separated field from External Data
When a List of String field with a tokens input type takes its values from an External Data variable (e.g.  ) and the external data is comma-separated the whole thing gets tokenised (e.g.  ). When the page is saved and re-edited, the form correctly shows the field (e.g.      ). Is there any way of getting the field to be tokenised as soon as the external data value is selected? Thanks. Jonathan3 (talk) 09:24, 26 January 2022 (UTC)

Multiple "free text" boxes
I am interested in making a page with several forms on it (call them form A, form B, etc.), each of which can appear zero or more times. I was trying to make section titles appear in the published page above the forms, i.e. I would have one section title above all the forms of A, and another for all the forms of B. In addition, I wanted each title only to appear if the form was instantiated at least once.

An idea I had to do this was to add a category or property to the template of A, B, etc. Then, I could show the titles by querying if the published page with all the forms on it has the desired property/category.

The main issue I am encountering is that I cannot figure out how to put text above each one of the forms automatically. I can't put it into the form template, because then the section titles could occur multiple times. I tried using hidden "free text" boxes, but they do not cooperate, I guess I cannot have free text boxes in all these positions unambiguously.

Is there a good way to solve this issue?


 * By "forms", I think you mean templates, and specifically multiple-instance templates. But you're right that a section can't be put in a multiple-instance template, because there can't be more than one section with the same name - and similarly, you can't have multiple "free text" inputs either. The only thing you can really do is have a template field that's edited with a "textarea" input. Which is not quite as flexible as a section or free text input, but hopefully it's good enough. Yaron Koren (talk) 04:57, 28 January 2022 (UTC)

Namespace integration in multi-word NS titles
Happy New Year, Mr. Koren. As I return to extension bug reporting:

A few days ago, I created a project page for a namespace entitled "From the Author". (Abbreviated as "FTA", this feature serves as a continuation of my long-running social-media feeds, once hosted elsewhere.) Per PF's guide, an "Edit with form" tab should appear above its pages, but doesn't at this writing. (All other namespaces covered by this scheme have single-word titles and display it just fine.)

Unforeseen bug, or lack of support?

P.S. Just letting you know that Referata's been offline since last Thursday, and that's getting in the way of an urgent, months-long import-rescue campaign (slow servers or not). New DNS holdup, I assume?

P.P.S. Another bug report should be forthcoming, entering February.--Slgrandson (talk) 08:17, 28 January 2022 (UTC)


 * To Bumping (half a month later) with URL details so that this issue might be looked into at some point (as well as Referata's current absence):
 * NS project page: https://constantnoble.miraheze.org/wiki/Project:From_the_Author
 * Specimen target page: https://constantnoble.miraheze.org/wiki/From_the_Author:2021/End-of-year_report
 * NS alias: FTA
 * --Slgrandson (talk) 22:40, 16 February 2022 (UTC)

Token field does not filter value list
Hi, I created form with a token field, with values from category. Unfortunately, when I start typing, I see the correct list of values but it is not filtered by my input. Moreover, whatever I typed, when I press enter the value is always the first element of the list...
 * PF version 5.3.4, MW 1.35
 * Tested with Firefox and Yandex browser
 * Javascript console contain a warning : JQMIGRATE: jQuery.fn.offset requires an element connected to a document

problems with autocomplete on property
Hi there, after a very long time my company finally updated our used Wiki thus switching from Semantic Forms to Page Forms. Now we have the problem that "autocomplete on property" stopped working. Furtheremore the Extension isnt listed on Special:Versions of our BlueSpice driven Installation. So sadly i cant name the extensions version. Here is the inputs code: Is the behavior intended? Is there a workaround? Kind regards Ciannicay (talk) 16:37, 3 February 2022 (UTC)


 * Yes, "autocomplete on property" was removed a while ago. Try "input type=combobox|values from property=..." instead. (Or "tokens" in place of "combobox", if the field is meant to hold multiple values.) Yaron Koren (talk) 17:09, 3 February 2022 (UTC)


 * Thats a bummer. As the number of values exceeds 200 a combobox or similar is not an option. And it is supposed to hold a single value only. Is there any hope this option might come back? Kind regards Ciannicay (talk) 08:30, 4 February 2022 (UTC)


 * Furthrtmore the code does not work either *sigh* any ideas what might be wrong? The site is company internal only so i cant give a link. Kind regards Ciannicay (talk) 08:44, 4 February 2022 (UTC)


 * What's the option that you're hoping will come back? And "autocomplete on category" was similarly replaced with "values from category". Yaron Koren (talk) 14:11, 4 February 2022 (UTC)


 * Never mind, i just didnt get it earlier. As i have properties with more than 300 values that were used for autocomplete I dont see that this will be usable with a combobox. Let alone that there wont be the ability to still enter unmatched entries. So i take it there will be no autocoplete anymore at all and no hope that it might come back in future? kind regards Ciannicay (talk) 09:09, 8 February 2022 (UTC)


 * The "combobox" input type should work fine with any number of autocompletion values - as should "tokens", for that matter. Yaron Koren (talk) 14:44, 8 February 2022 (UTC)

[RESOLVED] Troubleshooting 'Create with form' tab
I couldn't setup the 'create with form' tab. Could anyone help me?


 * My wiki: https://wordles.miraheze.org/ (Hosted by Miraheze, thus on MW1.37 and PHP7.4 etc) (verify)
 * The targets should show 'Create with form' tab but don't: All pages on the main namespace.
 * The parsed content of MediaWiki:pf_blank_namespace :  (verify)
 * The content of Project:Main :  (verify)
 * The content of MediaWiki:Blanknamespace :  (verify)
 * The pageprops of Project:Main :  (verify)
 * Examples don't show 'Create with form' tab: link and link
 * Note:
 * and  are.
 * The content language of the wiki: English (verify)
 * I am using  as a metaNamespace by explicitly defining

Lens0021 (talk) 09:26, 8 February 2022 (UTC)


 * Thanks for this detailed layout. It looks like the problem is those slashes in the page names - e.g., "https://test.url/" - by default, MediaWiki considers any page whose name contains a slash to be a subpage, and Page Forms doesn't apply the default namespace forms to subpages. So, I see two possible solutions to this: (1) Disable subpages in the main namespace, by adding "$wgNamespacesWithSubpages[NS_MAIN] = false;" to LocalSettings.php; or (2) Change page names to be something other than a URL. Either one should work. Yaron Koren (talk) 14:53, 8 February 2022 (UTC)
 * First one works for me, Thank you very much! Lens0021 (talk) 15:09, 8 February 2022 (UTC)

Field labels and tab index
I am missing a label-field association as well as a tabindex to get through completing a form using the keyboard. Is there any technique I could use to accomplish this with page forms?


 * Is tabindex not working for any of the inputs, or just some of them? And if it's just some, are there certain input types that seem to lack it? Yaron Koren (talk) 20:06, 14 February 2022 (UTC)

#forminput: autocomplete on category= is not working
MediaWiki	1.35.2 PHP	7.4.27 Semantic MediaWiki	4.0.0 Page Forms	5.3.4 forminput: autocomplete on category= is not working properly When I start typing the list displays, however is doesn't filter the list based on the characters I'm typing. Is there something I'm missing?


 * Wow! This was a bug introduced a few months ago, but somehow no one pointed it out until now. Sorry about that; I just checked in a fix for it. Yaron Koren (talk) 20:05, 14 February 2022 (UTC)


 * All good now, thanks Plegault3397 (talk) 12:48, 15 February 2022 (UTC)

Ordering radio inputs
How does one order radio-inputs ? The labels seem to be displayed in alphabetical order from what is outputted by my, but that order does not follow the logic of the form. Rather, it would make sense for the radio inputs to follow the order given by the  field parameter. Thanks ! Tinss (talk) 04:09, 16 February 2022 (UTC)

Size parameter is not included in #forminput
Hi. In Page Forms 5.3.4, I am trying to set the size of a #forminput element and it seems it is being ignored at the moment. The size remains the same (default: 25) regardless of the size value I use in my parser function call. Inspecting the form input element on the page doesn't show any size parameter in the HTML element. --Lalquier (talk) 15:17, 16 February 2022 (UTC)


 * Yes, "size" is no longer handled for #forminput, since the changeover to OOUI about a year ago; that's a bug. Yaron Koren (talk) 17:26, 16 February 2022 (UTC)

Extremely slow form rendering using autocomplete from large namespace
I have a form field defined as. This pulls in all files as an option in my input. In previous versions of Page Forms, the form would render in a reasonable amount of time, with autocomplete working. In the current version of PF, however, this form takes a very long time to load (over 60s). I tracked it down to a change that causes PF to loop through all possible values for an input server-side (commit: https://github.com/wikimedia/mediawiki-extensions-PageForms/commit/d5c5194107efed2dde70a77c3630a133722eea4c). If I comment out the  block, the form renders fast again, and autocomplete still works. I'm curious if there's a reason for this block to exist, and if there's a better solution than just commenting out code. Sazpaimon (talk) 20:02, 17 February 2022 (UTC)


 * Given a large-enough number of autocompletion values, the code is supposed to switch from "local" to "remote" (API-based) autocompletion, so that it shouldn't need to cycle through all the values. So this sounds like a bug. However, you're using the "text with autocomplete" input type, which is deprecated - so if you just switch to "input type=combobox", I assume the problem will go away. Yaron Koren (talk) 21:34, 17 February 2022 (UTC)


 * No luck, even with a "combobox" type it still tries to iterate through every option. I should also note that the resulting final HTML excludes all the options in the output, so something is indeed stripping it out, but it's still doing some sort of processing of the options on the backend request before that. Sazpaimon (talk) 21:54, 17 February 2022 (UTC)


 * So I looked a bit deeper, and it seems that  does not take into account the   setting, unlike, for example,  . Adding in that limit improves the performance, but I don't know enough about PF internals to know if that's the correct change. Sazpaimon (talk) 22:03, 17 February 2022 (UTC)


 * What version of Page Forms are you running? Yaron Koren (talk) 00:55, 18 February 2022 (UTC)
 * I'm running 5.3.4 Sazpaimon (talk) 01:25, 18 February 2022 (UTC)


 * Wow, yes! Indeed, that whole loop is unnecessary - and so is the equivalent one for the "tokens" input. I just removed that loop from both, so now loading of forms should go faster for inputs with a huge number of possible values. I don't know how this problem went undiscovered for so long, but I'm glad you caught it; thanks. Yaron Koren (talk) 21:09, 18 February 2022 (UTC)
 * Thanks! I tested it out, and while it does indeed fix the loading time, it's now not showing a pre-set value when editing an existing page via form. I believe it's because you're now no longer adding the option tag for the selected option because of the $isValueInPossibleValues check. You can probably remove that check altogether. Sazpaimon (talk) 23:17, 18 February 2022 (UTC)