Extension talk:Page Forms

Display field values on Form Page?
Is it possible to display the value of a field on a Form Input Page without it being an input? For example, I have a Base Page (My Page) that contains a FormLink:

The Form:Form_Name page contains the following to create a unique page:

The Form:Form_Name page also contains:

When the FormLink is clicked, the field above (if not hidden) shows the correct value for "Base Page Name" as the PAGENAME from the original page (My Page). However, if I try to display this value like the following, it always shows up exactly like below without being interpreted as the value (My Page).

Ultimately, the original page has a warning stored by Cargo I'd like to display on the Form Input page and I think I need the original page name to query for it. I can display the warning as a field input:
 * (restricted so it doesn't act like a form)

This seems like a hack. Is there a correct way to do this? --Bryandamon (talk) 08:17, 2 September 2019 (UTC)


 * I didn't follow everything, but what about adding a Cargo query to the form to display whatever it is you need? Jonathan3 (talk) 22:22, 4 September 2019 (UTC)

Adding "editor=visualeditor" prevents "restricted" from working
It seems that adding "editor=visualeditor" prevents "restricted" from working. If the field had "restricted", only admins/sysops are able to edit, however if "editor=visualeditor" is also added, the field is editable by anyone. --Bryandamon (talk) 01:38, 3 September 2019 (UTC)

PHP 7.2: Warning: count: Parameter must be...
Datepicker triggers the following warnings Warning: count: Parameter must be an array or an object that implements Countable in /srv/dml-wiki/extensions/PageForms/includes/forminputs/PF_DatePickerInput.php on line 391

Warning: count: Parameter must be an array or an object that implements Countable in /srv/dml-wiki/extensions/PageForms/includes/forminputs/PF_DatePickerInput.php on line 410

Warning: count: Parameter must be an array or an object that implements Countable in /srv/dml-wiki/extensions/PageForms/includes/forminputs/PF_DatePickerInput.php on line 415

Warning: count: Parameter must be an array or an object that implements Countable in /srv/dml-wiki/extensions/PageForms/includes/forminputs/PF_DatePickerInput.php on line 391

Warning: count: Parameter must be an array or an object that implements Countable in /srv/dml-wiki/extensions/PageForms/includes/forminputs/PF_DatePickerInput.php on line 410

Warning: count: Parameter must be an array or an object that implements Countable in /srv/dml-wiki/extensions/PageForms/includes/forminputs/PF_DatePickerInput.php on line 415 TiltedCerebellum (talk) 17:39, 22 September 2019 (UTC)


 * What version of Page Forms are you running? Yaron Koren (talk) 17:53, 22 September 2019 (UTC)
 * Page forms 4.5 (fe9dcc2) 09:23, 23 March 2019 on MW 	1.33.0 (62dc614)TiltedCerebellum (talk) 18:10, 22 September 2019 (UTC)
 * Could you upgrade to the latest Page Forms? It could be that this problem has been fixed already. Yaron Koren (talk) 20:29, 22 September 2019 (UTC)
 * When I checked earlier today for a new download it provided the link to 4.5 as the latest version. Ah, nevermind it was from the download link in the right bar under Download that went to extension distributor link. Will look manually for a zip, install from there, turn error reporting back on and re-check. TiltedCerebellum (talk) 23:11, 22 September 2019 (UTC)
 * Yes, thank you that issue is resolved after the update. My apologies, I didn't know we couldn't rely on the right infobox links. I will be sure to check that in future. :) The other (separate) issues unfortunately still remain (as noted in the next topic). TiltedCerebellum (talk) 23:44, 22 September 2019 (UTC)

Multiple issues in 4.6
This is an awesome extension, it will be even more awesome if the following issues are addressed: (Pageforms 4.6 on MW 1.33 issues, PHP 7.2)


 * 1) Template lines are not imported into the Create a Form page in the correct order
 * 2) The Values from Category option only works in the default namespace, otherwise it includes the namespace in the page name, even though the page name is displayed without namespace on the page itself.
 * 3) the following fields don't display their help/description/instruction text below the fields as they should, instead showing the following (looks like) template call text: ⧼pageforms-timepicker-mintime⧽, ⧼pageforms-timepicker-maxtime⧽, ⧼pageforms-timepicker-interval⧽
 * 4) DISPLAYTITLE property does not work when Values from Category is selected, instead the name shows up as "0"
 * 5) When pageforms is saved with the items out of order, the inputs are all assigned to the wrong fields (as if the mapping order of what input was entered for what field is modeled after the template order, but the form order itself is different. This renders the Create a Form function unusable. As an example, if my template contains:

When I go to create the form and attach a template it appears as:

Form field order: b c a

I ignore the incorrect order and assign form types: a: text b: dropdown c: combobox

And instead upon saving the form it appears like this:

a=dropdown b=combobox c=text

With forms with many parameters, it makes it impossible to use the Create a Form feature.

Also, is there any way to get Pageforms to stop displaying namespaces in page titles? I'm using page names in a category to populate drop-down lists and other inputs and the values are all showing with the namespace (undesired). The think documentation says it the page name can be overriden by setting a different page name however I've already tried overriding this with and rather than showing "desiredname" it shows a 0 instead. I love this extension but my values are not usable if they can't be displayed without the namespace being included. The default namespace is not an option in this particular setup. Pulling values from a category is exceptionally useful when multiple forms populate data off the same categories as adding a page in that category will update the fields in all forms. Currently I can't share templates, forms and category page name values across namespaces and this is a real drag. :'( Even if the DISPLAYTITLE issue was fixed to display only the page title and not namespace:title, that would make this usable. Please consider fixing!

I also don't want to have to go to the trouble of mapping a bunch of values for something that already exists. The idea of populating the form data from categories was for the form to be auto-updated every time a page was added to that category but I can't do that if the namespaces are included in page names and title override does nothing. Or in other words, currently it looks like this can only be used in the default namespace or both your forms and the values for it from categories are not unusable :c

The goal of "(page name) Values from category" is to get just the page names, or perhaps it is best to add a note in the documentation that this does not work as expected outside the default namespace. Some help getting around the DISPLAYTITLE issue would be extremely helpful (pretty please). I can't imaging that page forms category values are only useful in the default namespace?

TiltedCerebellum (talk) 05:22, 22 September 2019 (UTC)
 * I'm messing around with the different templates and input types to try to determine which is causing the issue. No idea yet on the first, seems to be something to do with parameters whose names appear inside of other parameters (for example one of them is just "s" while another is "s1" and "s2" and the "s" suddenly is out of place on import and causing an issue with jumbling perhaps. The second issue with mismatch in controls may also be caused by changing the input type... it would look like that you have to blank every field when changing your mind on input type or once an input type is picked it is appended rather than cleared out and switched? Not sure, will have to test again to see. When inspecting the final result code, some inputs had multiple input type settings, which would lead me to believe the second is correct. It seems it is more detrimental than helpful to use the Create a Form feature currently.

Some parts of the edit form did not reach the server; double-check that your edits are intact and try again.
When attempting to preview pages, I see the following error: "Some parts of the edit form did not reach the server; double-check that your edits are intact and try again."

There appears to be a patch in-progress at https://gerrit.wikimedia.org/r/522605 however it doesn't work when applied unfortunately. PF 4.6 on MW 1.33, php 7.2 TiltedCerebellum (talk) 06:02, 5 October 2019 (UTC)


 * Does it happen with every form? And every time? Yaron Koren (talk) 17:15, 6 October 2019 (UTC)

Linking to form via navigation tab
Hello, I'm using PF to create a form that allows users to add structured notes to pages. To do that I decided to use a very simple way, linking to the form via 'formlink', which saves each note as a subpage of the page 'User:Username/Notepad'; each note/subpage has the name of the page which the note is referring to. So the form call is something like this: Everything works fine with this, but now I want to add the call to this form on almost all the pages of my wiki. To do that I would like to add a new tab named 'Add note', next to the Discussion and History tabs. I've seen several guides to create a new tab (like this and this) via hooks, but seen that I am pretty a dummy in php ,I am not able to properly deal with it. So I wrote this code: But obviously it's not working since I can't use variables like  in php. So, do you think it's possible to do what I need in a simpler way using PF linking functions? Or I have to find a solution to do that via hooks? Thanks for your collaboration, any help is really appreciated. --Loman87 (talk) 13:56, 15 October 2019 (UTC)


 * This isn't a Page Forms question per se, but I think you can get that "$addNote =" line working by replacing it with these two lines:


 * Yaron Koren (talk) 16:45, 15 October 2019 (UTC)


 * You can get the user via the skin too, and avoid the global, e.g.:
 * Sam Wilson 00:22, 16 October 2019 (UTC)
 * Sam Wilson 00:22, 16 October 2019 (UTC)