Extension talk:Page Forms

From MediaWiki.org
Jump to navigation Jump to search

Display field values on Form Page?[edit]

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:

{{#formlink:form=Form_Name|query string=Form_Name[Base Page Name]={{PAGENAME}} }}

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

{{{info|page name=Form_Name-<unique number;start=1001>}}}

The Form:Form_Name page also contains:

{{{field|Base Page Name|}}}

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 ({{{Base Page Name|}}}) without being interpreted as the value (My Page).

{{{Base Page Name|}}}

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:

{{{field|Base Page Name|restricted}}} (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[edit]

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...[edit]

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[edit]

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:

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.[edit]

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[edit]

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:
{{#formlink:form=Add note|new window|link text=Add note|link type=button|target=User:{{#USERNAME:}}/Notepad/{{PAGENAME}}}}
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:

if( !defined( 'MEDIAWIKI' ) ){
        die( "This is not a valid access point.\n" );

$wgHooks['SkinTemplateNavigation'][] = function ( SkinTemplate &$skin, &$links) {  
        $addNote = Title::newFromText( 'Special:FormEdit/Add note/User:{{#USERNAME:}}/Notepad/' . $skin->getTitle()->getText() );
// Add an additional link
        $links['views']['main'] = array(
                'class' => false, // false or 'selected', defines whether the tab should be highlighted
                'text' => "Add note", // what the tab says
                'href' => $addNote->getInternalURL(),  // where it links to
                'context' => 'main',
        return true;

But obviously it's not working since I can't use variables like {{#USERNAME:}} 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:
        global $wgUser;
        $addNote = Title::newFromText( 'Special:FormEdit/Add note/User:' . $wgUser->getName() . '/Notepad/' . $skin->getTitle()->getText() );
Yaron Koren (talk) 16:45, 15 October 2019 (UTC)
You can get the user via the skin too, and avoid the global, e.g.:
$addNote = Title::newFromText( 'Special:FormEdit/Add note/User:' . $skin->getUser()->getName() . '/Notepad/' . $skin->getTitle()->getText() );
Sam Wilson 00:22, 16 October 2019 (UTC)
Even better. Yaron Koren (talk) 15:43, 16 October 2019 (UTC)
Thanks for your help guys and sorry if this was a bit out of topic here. Your code works perfectly, anyway it seems like it would be better for my purpose to use the {{#formlink}} parser function (e.g. to open the form in a popup window and to pre-fill some fields). Would it be somehow possible to link it from a tab, like the 'Discussion' tab as I described in my first post? Thanks again for your help! Loman87 (talk) 07:28, 23 October 2019 (UTC)
That's basically what you're doing now, no? Yaron Koren (talk) 14:16, 23 October 2019 (UTC)
Well not exactly. Thanks to your help I can link to my form via Special:FormEdit/... from a tab present on every page of my wiki. But I finally found out that a {{#formlink}} call would be more useful for my needs (e.g. I want the form opened in a popup and some fields prefilled). So I was wondering how include the {{#formlink}} call on every page of my wiki as it has been done with the Special:FormEdit/... link. I don't know if I explained myself... Loman87 (talk) 09:41, 24 October 2019 (UTC)
It's strange to have a tab that, when clicked, brings up a popup window - that's not really a tab at all. What about instead having a link somewhere on the page itself? Then you could have the relevant template(s) add it, without the need for any custom coding. Yaron Koren (talk) 16:11, 24 October 2019 (UTC)

Update a template in another page from form[edit]

Is it possible to update another pages template without adding the #autoedit button? When submitting a form I would like to also update a dependent property in another Page.

If I have a Page of Category Collection with a multiple instance template member, and a Page of Category Concept (which has a form Concept) which has a property memberOf I would like to also populate the Collection[member] with the pagename of the current submitted item.

I've looked at partial forms, but was unsure if I could start two info tags (One partial, followed by regular) and have one submit button for both.

Thank you very much! Øyvind

Before we get to the mechanics of what's possible with forms - it sounds like you're storing the same information (a relationship between two pages) twice, once in each page. Is that true? If so, that's a bad idea. You should only store the relationship once, in one page or the other. Yaron Koren (talk) 20:26, 17 October 2019 (UTC)

According to the model I'm implementing from the relationship should be present in Collection (Begrepsamling nb) only. However I placed the property on Concept (Begrep nb) to create a working prototype. I use the following forminput on "Collection" view to add or edit a "Concept" and to go to its form:

{{#vardefine:ns_from_identifier|{{#ask: [[{{FULLPAGENAME}}]]|?Dct:identifier= |mainlabel=-}} }} {{#forminput:button text=Legg til nytt Begrep|form=Begrep|link type=button|query string=Begrep[medlem]={{PAGENAMEE}}|namespace={{#var:ns_from_identifier}}|autocomplete on namespace={{#var:ns_from_identifier}}|reload|new window|no autofocus }}

"Collection" has it's own form, which defines which tabs (HeaderTabs) and namespace (for user rights) should be present and used on the "Concept" form, and I needed a relationship to query, so I'll have to do some rewriting if I manage to move the relationship :)

I enjoyed reading your Working with Mediawiki as an introduction to MW.


Additional Query Button creating Invalid Request[edit]


I have upgraded from Mediawiki 1.27.5 to 1.31.5 and am using Page Forms version 4.5.

When I run the Additional Query button at the bottom of my #queryformlink I do not get a valid page and it sends me back to my site home page.

I have a simple form that has one parameter.

The browser URL text that is produced is as follows:


Is there a need for different syntax in MW 1.31.5?

Thank you,


I run into the same problem. Comparing the URL to the original URL, it seems the pagename is missing
so instead of ..../index.php?pfRunQueryFormName=...

it hould probably look like ..../index.php/pagename?pfRunQueryFormName=...

Everything about that URL looks wrong... is this query form contained in Special:RunQuery, or on some other page (which transcludes Special:RunQuery)? Yaron Koren (talk) 20:45, 25 October 2019 (UTC)
Hi Yaron.
The URL is what I see after I click on the additional query button that is available on the page that is produced from a #querylinkform. In other words:
Step 1: From Homepage run #querylinkform -> Works fine, New Page is produced with query results
Step 2: Attempt to run Additional Query at bottom of page in Step 1 with new or existing value
User is returned to Home page and the URL in the Home page browser address bar as a result of Step 2 is what I have shown above.
I can provide more data as needed.
Thanks, Gregg
What does the URL of the query form look like? Yaron Koren (talk) 21:32, 25 October 2019 (UTC)
Happy to provide:
Step 0 #queryformlink code for completeness:

{{#queryformlink:form=Convention Card|link text= Display Convention Card|link type=button| query string=Convention Card[SystemID]=1&_run}}

Step 1 URL - Query Resulting Page


Step 2 URL - Return to Homepage - Query not completed


Let me know if you would like anything else. Gregg
Yaron, I am having other problems with my installation, I think related to the fact that my MW installation is operating is behind a reverse proxy. Would this setup cause the erroneous behaviour I've shown? If so, do you know a work around? Gregg
I don't know. The value you listed now for pfRunQueryFormName looks a lot more normal than what you listed before ('Field'='Value'). Did something change? Or was it just described in an unclear way before? Yaron Koren (talk) 17:07, 27 October 2019 (UTC)
Hi Yaron. Before I was removing my specific values and replacing with 'generic' ones. In the last I cut and paste verbatim what I observed. Are there any experiments I can try?
Okay, I just wanted to make sure. I think upgrading to the latest version of Page Forms will fix this problem. Yaron Koren (talk) 23:18, 27 October 2019 (UTC)
Hi Yaron, I had some problems with my setup and so could not tryout PageForms 4.6 until today. You are correct in that Version 4.6 works as expected (works correctly now) and I have since only tested on MW 1.33.1 since I moved up a version as an experiment but will stay there for now. I am back to business as I had it in MW 1.27.5. Thanks for your patience.

Multiple choice in listbox doesn't work when reediting while using mapping template[edit]

Hi Yaron,

I'm using PageForms 4.5. Currently I have the following problem:

  • the form contains a listbox which is mapped with a mapping template => works fine
  • while creating a page with the form I can choose multiple values from the listbox
  • the values are stored well with #arraymap
  • reopening the page with the form there are no values selected in the listbox
  • this way only works when ONE item from the listbox is selected
  • when I use the form without the mapping template all former chosen values are shown correctly.

What is to be done?

Hi Yaron, any idea?
Sorry for not responding before. Is this still a problem with the latest version of Page Forms? Yaron Koren (talk) 14:14, 30 October 2019 (UTC)

$wgRawHtml = true not working in Forms namespace[edit]

Hi, it seems it is impossible to allow $wgRawHtml in the Form namespace ? --Varlin (talk) 13:17, 1 November 2019 (UTC)

I don't know why that's happening, but it seems good... allowing raw HTML in the form sounds dangerous. Why would you want that? Yaron Koren (talk) 14:14, 1 November 2019 (UTC)
I needed to insert <label> tags, cause the default automatic insertion of labels is not flexible. Dangerous? If the form definition is only editable by sysop I think it's not. (Ew, of course I hope the html is not allowed inside the fields) --Varlin (talk) 14:40, 1 November 2019 (UTC)
That's true - if only admins can edit form definitions, and you know what you're doing, it should be fine. However, this would probably require a change to Page Forms' parsing. I do want to better support labels in the future. If it's just the label tag, by the way, one option is to use the Widgets extension and create a "label" widget - that should work, I think. Yaron Koren (talk) 15:37, 1 November 2019 (UTC)
Thanks for the advice. I'll try it. In fact I could have stick to default labels with display=table (it has the advantage of a cleaner wikitext code), but it seems it does not work with embedded fields, so I had to construct manually the table, and so the fields have no labels. --Varlin (talk) 11:43, 2 November 2019 (UTC)
What do you mean by embedded fields? Yaron Koren (talk) 15:59, 3 November 2019 (UTC)
I mean using embed in field= like defined here. --Varlin (talk) 16:36, 3 November 2019 (UTC)
Oh, okay... that's too bad; it sounds like a bug. Yaron Koren (talk) 18:31, 3 November 2019 (UTC)

Fields with 'values from category' display html markups[edit]

Upgraded from PageForms 4.2.1 to 4.6 and experienced strange behavior with fields which are using 'values from category='. (on MediaWiki: 1.30 and SemanticMediaWiki: 2.5.6)

Eg. {{{field|businessArea|input type=textarea with autocomplete|values from category=Business Areas|remote autocompletion}}}

All such input fields in the form display expected value but wrapped with html markups: <span style="display:none">VALUE</span>. Also autocomplete works when you start typing '<span' ...

How to fix this behavior? --Mourawi (talk) 4 November 2019 (UTC)

After some more debugging I realized that in order to remove displaying titles on these pages I used {{DISPLAYTITLE:<span style="display:none">{{FULLPAGENAME}}</span>}} on all of them ... which apparently influenced how selection of these pages works now.

I guess in order to fix this new not desired behavior I have to find another way to hide a title on the pages (this applies to only some categories, so I can't use css approach). Any other hints ? --Mourawi (talk) 4 November 2019 (UTC)

Try adding "$wgPageFormsUseDisplayTitle = false;" to LocalSettings.php. Yaron Koren (talk) 02:59, 5 November 2019 (UTC)
That is what I did and it's working fine. Thanks

Bug in multiple instances with fields using "textarea with autocomplete", "list"/"delimiter=;" and "values from category/concept"[edit]

PF 4.5 + 4.6. Saving new instances with the above field appears to be working fine. However, the trouble starts when I reload the form and notice that these textarea fields are empty if they contain more than one value and so naturally, their content gets removed after I save the page. I'm afraid that in this way I've unwittingly thrown away some work over the course of several months. Curiously enough, but probably unrelated, if these fields contain one value only, the value itself is preserved fine (in the form) but the delimiter at the end has disappeared. Cavila 15:59, 7 November 2019 (UTC)

What about using the "tokens" input instead? I think that's generally the better choice anyway. Although maybe it has the same bug. Yaron Koren (talk) 16:47, 7 November 2019 (UTC)
Thanks for the quick reply. The issue does not happen with "text" or "tokens" as input types I think. I'm definitely using "tokens" in many, perhaps even most other situations where value arrays are concerned, but they are not a one-size-fits-all solution. In this case, textareas proved to be the user-friendlier (lightweight?) option, as it became easier for users to copy/paste and edit lots of data. Also, Select2 tokens are more unwieldy if you need to fit them in a tight space while I have workable solution using expandable textareas, and editing tokens can be a little buggy sometimes. Hope that makes sense. Cavila 17:29, 7 November 2019 (UTC)
That all makes sense except for the buggy editing part - I didn't know about that. Anyway, I guess the "values from ..." bug will have to be fixed, although it's good to know that it's restricted to just this one input type (well, maybe "text with autocomplete" too). Yaron Koren (talk) 04:57, 8 November 2019 (UTC)
I just tried reproducing this bug, by the way, and couldn't. What is the exact tag for that input in the form definition? And do you see any JS errors in the console? Yaron Koren (talk) 05:42, 8 November 2019 (UTC)

$wgPageFormsSimpleUpload uploads image before page save[edit]

After some testing, I figured out the following:

If you set

$wgPageFormsSimpleUpload = true;

then the image gets already uploaded to the wiki before the user saves the form. I guess this is somewhat intended/needed behaviour since an impage preview is displayed in the form. However, I think this has to be clearly identified since it breaks the default behaviour of a wiki/page forms.

A user has to be sure that nothing gets entered in the wiki unless he/she hits "save".

BTW: it does not matter of you set

|image preview

in the form field definition or not, the preview is there always when $wgPageFormsSimpleUpload ist set to true and the image always gets uploaded to the wiki at the time the user selects it from the PC.

--Krabina (talk) 14:48, 11 November 2019 (UTC)