Extension talk:Page Forms

I installed Semantic Wikibase (Mediawiki + Wikibase + Semantic Mediawiki6.0) in a mw1.43 version based on the wikibase docker image. PageForms was installed via Composer with version:"*". Installed PageForms version is 6.0.6. When opening Special:SpecialPages i get the following error:

/Special:SpecialPages Error: Failed opening required /var/www/html/extensions/PageForms/includes/../specials/PF_CreateProperty.php

Same error occurs also on pure Wikibase 1.43 installation. It seems, that in version 6.0.6 the filenames changed from PF_CreateCategory.php to PFCreateCategory.php but somewhere theres seems still a reference to the old names. PageForms version 6.0.5 worked without problems. My Solution was to restrict PageForms version on composer.json to version: "<= 6.0.5"

Sorry about that - I just checked in a fix for it. (And I'll probably have to release a new version of Page Forms soon.) By the way, I should note that I think using External Data to query Wikibase is easier than Semantic Wikibase, but that's a whole separate discussion. Yaron Koren (talk) 14:11, 6 May 2026 (UTC) Reply

Thanks for the fast fix! I rely heavily on SemanticResultFormats in my projects but will definitely have a look at ExternalData Extension. Baillyk (talk) 06:18, 7 May 2026 (UTC) Reply

Issue appeared after migration+update from MV1.40.0+SMW4.1.1-PF5.6.1 to MV1.45.1+SMW6.0.1+PF6.0.4:

Issue:

1) "Edit With Form" trab and related action=formedit not visible.

2) Using ../Special:FormEdit/<form_name>/<article_name> resulting in a database error..

Error 1054: Unknown column 'cl_to' in 'WHERE' Function: PFValuesUtils::getAllPagesForCategory Query: SELECT page_title,page_namespace,pp_displaytitle.pp_value AS `pp_displaytitle_value`,pp_defaultsort.pp_value AS `pp_defaultsort_value` FROM `<prefix>categorylinks` `categorylinks`,`wikipage` `page` LEFT JOIN `<prefix>page_props` `pp_displaytitle` ON ((pp_displaytitle.pp_page = page_id) AND (pp_displaytitle.pp_propname = 'displaytitle')) LEFT JOIN `<prefix>page_props` `pp_defaultsort` ON ((pp_defaultsort.pp_page = page_id) AND (pp_defaultsort.pp_propname = 'defaultsort')) WHERE (cl_from = page_id) AND cl_to = '<category_name>' ORDER BY cl_type, cl_sortkey LIMIT 1000

Probable cause:

It seems that since MW1.42+ the standard cl_to column (which stored the category name as a string) has been deprecated in favor of cl_target_id (which links to a centralized linktarget table for better performance). Database has migrated to this new structure, but Page Forms v6.0.4 (or a specific component of it) is still trying to run an old-style SQL query looking for cl_to.

Quick "DIRTY!!!" fix

in case someone confirms and fix the bug or in case you have same problem but not due to a bug and you need a quick fix while applying proper fix

NOTES:

A) SQL SINTAX you are using mysql/mariadb

B) REPLACE <prefix> with your $wgDBprefix from LocalSettings if any

C) If installing Page Forms with composer, aftr applying the fix the update would fail due to the change of the table (you would need to remove the column t update)

1) add missing old field:

ALTER TABLE <prefix>categorylinks ADD COLUMN cl_to varchar(255) NOT NULL DEFAULT '';

2) update fields with category taken from cl_target_id:

UPDATE <prefix>categorylinks JOIN <prefix>linktarget ON <prefix>categorylinks.cl_target_id = <prefix>linktarget.lt_id SET <prefix>categorylinks.cl_to = <prefix>linktarget.lt_title WHERE <prefix>categorylinks.cl_to = '';

3) add a trigger on DB to be sure that new article and change have updated legacy "cl_to" field updated:

DELIMITER // 
CREATE TRIGGER tr_fix_cl_to 
BEFORE INSERT ON <prefix>categorylinks 
FOR EACH ROW 
BEGIN 
IF NEW.cl_to = \'\' OR NEW.cl_to IS NULL THEN 
SET NEW.cl_to = (SELECT lt_title FROM <prefix>linktarget WHERE lt_id = NEW.cl_target_id LIMIT 1); 
END IF; 
END; // 
DELIMITER ;

Michele.Fella (talk) 22:51, 11 January 2026 (UTC) Reply

Sorry about that - I had fixed one call to cl_to in the Page Forms code, but had not noticed this other call. I just checked in what I think is a fix for it, so if you get the latest code, it might work normally. Yaron Koren (talk) 17:46, 12 January 2026 (UTC) Reply

Hi Yaron,

Removed my "dirty fix", cleaned/removed extension folder and update, then pulled the latest version from git but unfortunately it seems that the patch did not work (at least in my case -> edit with form still does not showing)

...extensions/PageForms# git log

commit fea7bc59b97b0da8d28d2df84b1cd2535804fcfb (HEAD -> master, origin/master, origin/HEAD)

Author: Yaron Koren <yaron57@gmail.com>

Date: Mon Jan 12 15:39:04 2026 +0000

Further removal of categorylinks.cl_to for MW 1.45+

Bug: T412536

Change-Id: Ie2d09fb0cee85613b23c21c2d7b90f6429681c7e Michele.Fella (talk) 06:11, 13 January 2026 (UTC) Reply

Is the error message the same as before? Yaron Koren (talk) 15:30, 13 January 2026 (UTC) Reply

Thanks Yaron, I confirm that the error previously mentioned has disappeared. My understanding from your code is that PF is now retrieving the Form from page properties, in my case I have the parser function #default_form:<my_form_name> declared in the category (declared in the template) and adding debug line in PF_FormLinker it seems that neither PFDefaultForm or SFDefaultForm are retrieved by getDefaultForm function and this is the reason why the "Edit With Form" tab did not show in the articles.

I added #default_form:<my_form_name> directly int he template and after clearing the job queue the edit with form tab worked as expected.

The fact that recreating and filling the field cl_to on DB had fixed the problem, I assume is due to additional legacy code which targets cargo compatibiolity. Michele.Fella (talk) 01:53, 16 January 2026 (UTC) Reply

On my wiki this weekend, I launched a new form which makes extensive use of multiple-instance templates. It's worked so far, so good--up till late this afternoon. Long story short: I'm using a one-row template, {{Docket listing}}, whose instances are embedded within a {{Docket}} shell for track-archive listings of mine. The more {{Docket listing}} instances used, and the more data entered, the more strain it apparently puts on the preview renderer--to the point where the latter happens to give up saving anything that can be previewed. This is now happening with the three most recent instances I manually added in on this track-lineup page.

Not too sure where to go from here--and I'm not sure if this is a bug or feature (to use a tech-dev cliché) or if maximum instances= can be declared to remedy this. --Slgrandson (talk) 01:15, 12 January 2026 (UTC) Reply

That's a lot of data on one page! In theory, it's possible that Page Forms' performance can be improved so that it can handle that much content. (I don't know whether this is a PHP or JavaScript issue, but either way.) For now, I would think the best solution is to allow docket listings to be defined on their own page, via a separate form - and then move all these docket listings to their own page. (I think the only change you would need to make to the "Docket listing" template would be adding a "Docket" field.) You can then mandate this approach by removing the "Docket listing" template from the "Docket" form - or keep it there, allowing for either approach, depending on the page. Yaron Koren (talk) 17:56, 12 January 2026 (UTC) Reply

@Yaron Koren: Retooled the system so that docket listings--up to 20 at any given moment per the technical limitations--are accorded their own queue page. Once they are ready to be processed, the listings then move ahead to the "Track" form already in place.

But now, there's another gotcha: On track-form pages, the "Notes" field isn't rendering embedded template data and wiki markup as well as they should, and leave behind lint such as {{Place|Area}} → <!--LINK'" 3008:0-->, ''Text'' → <i>Text</i>, and [https://example.com Example] → <a rel="nofollow" class="external text" href="https://example.com">Example</a>. Wonder what's causing this to happen; wonder if there's a workaround? --Slgrandson (talk) 18:32, 14 January 2026 (UTC) Reply

Evidently there's some unnecessary HTML-escaping happening. Where is a page, or form, where this can be seen? Yaron Koren (talk) 19:52, 14 January 2026 (UTC) Reply

Exhibit A, reserved for "A New Era" by Australian singer Sandy Louise. (Sorry for the long, long MH URL!) Slgrandson (talk) 23:30, 14 January 2026 (UTC) Reply

Oh, I see this text is coming directly from the URL. But the URL itself contains all this HTML-escaping - so the problem presumably lies with whatever is generating that URL. Yaron Koren (talk) 00:47, 15 January 2026 (UTC) Reply

@Yaron Koren: Everything's passing through {{#formlink:}}. (Using {{#formredlink:}} instead would hardly make any difference.)

Even tried to "de-format" the Notes text--and eponymous docket parameter itself--with a <nowiki></nowiki> wrap. However, that leads to an "UNIQ/QINU" error in the track form.

The encoding/escaping issue apparently lies in the template markup, which needs to be HTML-compliant (i.e. { → &#123 ; / | → &#124 ; / } → &#125 ; , as recommended by Extension:Page Forms/Defining forms#Reusing form elements). --Slgrandson (talk) 05:19, 15 January 2026 (UTC) Reply

I have to ask - why put all the text into a #formlink call? Why not just create the page (with a form), and put the text directly into the form? Yaron Koren (talk) 22:21, 15 January 2026 (UTC) Reply

After several hours this morning, I've settled on a DPL-based approach whereby the notes are stored inside a {{#dpl:}} call--keeping the escape-code substitutes in mind. (Not to mention this is pretty much the only way to go about it.) Excerpt as follows (remove the spaces for the correct markup):

{{#if:{{{Notes|}}}|&Track box[Notes]{{=}}&#123 ;&#123 ;safesubst:#dpl:namespace=Portal&#124 ;title=VIMU Vault/Queue&#124 ;include=&#123 ;Docket listing&#125 ;:Notes&#124 ;includematch=/VIMU{{#switch:{{{Stage}}}|Candidate=-C|Archived=-A}}={{#switch:{{{Stage}}}|Candidate={{{VIMU-C}}}|Archived=-{{{VIMU-C}}}|{{{VIMU}}}}}/&#125 ;&#125 ;}}

...where include fetches all instances of {{Docket listing}} from the Queue page, and includematch=/VIMU=0001/ (as an example) selects the instance with "0001" as the value for the "VIMU" parameter.

Now that I've straightened things out, here's take two of the "New Era" form--actually works! That said, I'll get that page saved in a couple of hours. --Slgrandson (talk) 16:20, 16 January 2026 (UTC) Reply

My previous questions (see Extension_talk:Page_Forms/Archive_July_to_December_2025#"UNIQ...QNIU"_errors_when_include_Cite_ref_within_multi-instance_template_field) described the problem wrongly. I thought it was a problem with Page Form's multi-instance templates because that happened to be where I noticed the problem. The actual problem is that when you save to Cargo a text field containing the HTML pre tag, or Cite's ref tag, Cargo gets them half-parsed so saves them to the database with the UNIQ...QINU strip markers. If you then query the database it'll display those markers instead of what's displayed normally on the page. Jonathan3 (talk) 20:51, 13 January 2026 (UTC) Reply

It seems such an obviously common thing want to do, that someone must be doing it and know how to do it: I want to populate a combobox (or dropdown) with values from a field containing the names of people (which users will recognize, but which might change) from the Cargo _pageTitle field; when users select one of the names, I want the form to write the corresponding value (which users will not recognize, but will always point to the right page) from the _pageID field of the same table (to another table, where it will serve as a foreign key). I tried this:

'''Indexed Subject:''' {{{field|subject_page_id|input type=combobox|existing values only|cargo table=Indexed_Subjects|cargo field=_pageTitle|mapping cargo table=Indexed_Subjects|mapping cargo field=_pageID|cargo value field=_pageID}}}

And I tried every other permutation of the parameter names and values, both using and leaving off the "mapping cargo" parameter set and the extra "cargo value field". But whenever I used the "mapping cargo table/field" parameter set, I got numbers 1, 2, ... 10 in the combobox (and those are not page ID numbers). When I use just the "cargo table=Indexed_Subjects|cargo field=_pageTitle" parameters, I get the names in the combobox, but it writes the selected name to the page ID field instead of the ID. If I use _pageID in place of _pageTitle, then the page IDs will show in the combobox, and it will write the page ID, but I need to have names in the combobox, not IDs. I can use a module to take the page name and query for the corresponding page id, but it would better (and more reliable, I hope) if PageForms/Cargo could do that. I have been doing this sort of thing long enought to know intuitively that I must be misunderstanding something, and someone else (probably lots of people) need to do the same sort of thing and have figured out how to do it. So someone help me please. Bmcfann (talk) 00:53, 15 January 2026 (UTC) Reply

If what you want is the page title to show up in the form, but the page ID to show up in the generated page, then I think what you need is "|cargo table=Indexed_Subjects|cargo_field=_pageID|mapping cargo value field=_pageTitle". I don't know for sure if that will work, but I think theoretically that's the right set of parameters. Yaron Koren (talk) 22:28, 15 January 2026 (UTC) Reply

In order to get names into the dropdown, it evidently needs "cargo field=_pageTitle" (not _pageID). Then (I am guessing) it needs "mapping cargo value field=_pageID" to use the corresponding value from the _pageID field. But when I set it that way, it writes the name instead of the page ID as the value for the "Subject_Page_ID" parameter in the #cargo_store call, and so the name gets written to the data table instead of the page id (if I set the data type in the table to "string" instead of "integer"). Someone wrote about this exact same problem about a year ago in this "talk", and I don't see that the problem was solved in that discussion. Surely, multiple people out there are doing this and know how to do it. Bmcfann (talk) 21:24, 18 January 2026 (UTC) Reply

Okay, I looked into this more (including looking into the code) - I made a mistake in my recommendation, and it looks like there's a bug in the Page Forms code as well, which is probably why you couldn't get it working with any combination. I believe the correct set of parameters is |cargo table=Indexed_Subjects|cargo field=_pageID|mapping cargo table=Indexed_Subjects|mapping cargo field=_pageTitle|mapping cargo value field=_pageID. I know that's a lot, and probably the code could be better about getting default values. As for the bug: you can get around it by adding the following line to LocalSettings.php:

$wgPageFormsUseDisplayTitle = false;

I'm pretty sure the code should not be checking the value of that setting in this case - I'll have to fix that. Yaron Koren (talk) 18:11, 19 January 2026 (UTC) Reply

Thank you for taking the time to look into this. The parameter setting that you recommended did work (after I set $wgPageFormsUseDisplayTitle = false), and it is a great relief to have that little problem solved. (And DisplayTitle seems to still be working everywhere that I need it to be). Bmcfann (talk) 04:50, 20 January 2026 (UTC) Reply

"'|' is not allowed, except within {{...}}, [[...]], or special tags"

...in PF 6.0.4 and later. See also this October 2018 filing. --Slgrandson (talk) 18:00, 17 January 2026 (UTC) Reply

If it helps, I've never seen that problem, so maybe it's something funny about your form. Jonathan3 (talk) 01:50, 18 January 2026 (UTC) Reply

I couldn't reproduce this issue either, but I looked into the pipe-checking code due to a different issue that I could reproduce, and it turned out that there were various bugs in the code. I just checked in some fixes, and I wouldn't be surprised if they fix this problem as well. If you try upgrading to the latest code, please let me know! Yaron Koren (talk) 17:16, 23 January 2026 (UTC) Reply

According to the documentation, the "parameter of parameters" "form" can be used to create a missing page using the correct form. I have tried both "form=foo" and "form=Form:foo", but in no case this seems to work. Is this eventually related to the previous bug report?

I am using MW 1.43.6, SMW 6.0.1 and Page Forms 6.0.4. I did update the latter a few days ago after reading the previous bug. OTOH "Create Class" generates parameters of parameters (eg. "list"), that are also not documented, so maybe that's part of the problem? Joernc unibi (talk) 06:47, 20 January 2026 (UTC) Reply

If you specify "form=" in #template_params, then red links for that field should point to that form, in the output of #template_display. Are you not seeing that? Yaron Koren (talk) 19:22, 20 January 2026 (UTC) Reply

Question. I have been editing away at my Page Forms fork (more on that later) and I found some lines of code, e.g. in the classes for comboboxes and tokens, that attempt to find boolean values in the wiki's language - if none were provided. They end up doing nothing because the $possible_values variable is not called afterwards. Is this still something waiting to be implemented somehow? Not that I intend to work on those booleans myself (other priorities), but right now the status of these lines is somewhat ambiguous. Rand(1,2022) (talk) 18:18, 20 January 2026 (UTC) Reply

That does look like code that should be removed, yes. Or perhaps that functionality should be restored in some way - though I can't imagine anyone ever using a "combobox" or "tokens" input for a boolean field. Yaron Koren (talk) 19:28, 20 January 2026 (UTC) Reply

No, those inputs do not seem like the most obvious tools for simple yes/no answers. Or is there anyone anyone reading who disagrees? For now I'll comment out those lines with a brief note. Rand(1,2022) (talk) 20:19, 20 January 2026 (UTC) Reply

I'm having a problem with the autocomplete function. If the text in a form's text field is longer than the designated space, the display keeps jumping back to the beginning of the input. The cursor stays at the end, and I could continue typing, but I can't see the text I'm typing because the display keeps jumping back to the beginning. ~2026-61323-5 (talk) 13:14, 28 January 2026 (UTC) Reply

I'm trying to setup a form input, with the a input form similar to #forminput, and the 1-step-process feature of #autoedit

Basically, it will have at least 1 form field (input box) on the page.

When I type in that input box, the form can take the value that I typed, put it as a variable for the query string=.

Then instead of go to second step of Special:FormEdit, it can create the new page Immediately (like in the #autoedit)

Is it possible with the current feature of PageForms alone?

I also tried with Extension:InputBox but cannot think of any solution. Duyhungwiki (talk) 17:54, 28 January 2026 (UTC) Reply

It sounds like you're just talking about the one-step process - no? What's the difference? Yaron Koren (talk) 20:35, 28 January 2026 (UTC) Reply

I see the one step process only has #formlink and #autoedit.

These options do not allow to get the value from a user-inputted input box.

Let talk the contact form (for example purpose only, I see there are better options for contact page):

- It have 2 fields: name of submitter, message, and a Send button

- The "name of submitter" field can get automatically thanks to <pre>{{currentloggeduser}}</pre> of Extension:MyVariables

- The Contact Page shall have "message" and Send button

- After click on the send button, PageForms shall made a new page with address Username/message immediately (without a second step)

- Let say I used the #forminput feature, then the form shall be

{{#forminput:form=Contact|super_page={{currentloggeduser}}|query string=|button text=Send|query string=Contact[User]={{Currentloggeduser}}|popup|reload}}

- However, after user click, they still need to retype the message in the popup Form:Contact page

- In case I used #formlink or #autoedit, it do not have the input box "message" to type in

Hope it clear. Thanks for your support.Duyhungwiki (talk) 00:31, 29 January 2026 (UTC) Reply

It still sounds like you're describing the one-step process... please look again into the use of #formlink, in conjunction with a page name formula. Yaron Koren (talk) 01:29, 29 January 2026 (UTC) Reply

Hello. I re-looked the #formlink, but cannot find how to make an input box that can transcluded to another page (similar to we transclude Message input box into the Contact Page.

Formlink only provide a link/ or a button, not a input box.

Could you please advise? Duyhungwiki (talk) 23:28, 29 January 2026 (UTC) Reply

The input box would go into the form. Yaron Koren (talk) 03:24, 30 January 2026 (UTC) Reply

For context, an update first: nearly 50 commits in and you can imagine I'm sort of dreading the gerrit process of having to re-package these changes as new patches, starting with the actual fixes; I went beyond trying to fix the issues I experienced and introduced some new features.

Now a target for some of these new features is 'values from url', which I have been using to query the API of the local wiki, more precisely through API modules enabled by the ReconciliationAPI extension. It now supports descriptions, shown below each label, in dropdown options but that's for another occasion.

One issue I had with 'values from url' is that 'current values', i.e. values already submitted, lack any URL-based mechanism for being mapped to labels when the form loads. This may not be so simple: the API should support substring matching, suggesting data in response to a substring, but may not necessarily support 'entity name matching'. Fortunately, this is precisely what services like Wikidata and those that have adopted the Reconciliation API specs (common in the OpenRefine world) let you do. A Wikidata/Wikibase API, for instance, accepts Q21678466 as a substring and returns relevant data such as an English label, which is "Page Forms".

What I did was to create an opt-in feature: let Page Forms make a call to the URL source if the form field uses a new parameter, 'mapping from url', in addition to 'values from url', e.g.

{{{field|MyFormField |input type=tokens |list |delimiter=; |values from url=myAPIService |mapping from url |existing values only }}}

After a false start (a PHP implementation, which was potentially quite slow), I added the functionality to the combobox and tokens inputs so that any mapping for these input fields is done in deferred mode.

Everything works, at least on my machine, but some small questions remain:

• I'm open to suggestions for a better name; 'mapping from url' is not a functional equivalent of the other 'mapping from...' parameters so maybe go instead for 'map values from url', which has more of a boolean feel?
• Alternatively, and probably this would be my preferred approach, let users explicitly set 'mapping from url' to a shorthand for an URL source in the same way as this is done for 'values from url'. This would help if the data provider supports 'label mapping' via a different URL - other than that used for 'values from 'url', e.g.

{{{field|MyFormField |input type=tokens |list |delimiter=; |values from url=myAPIService |mapping from url=anotherAPIService |existing values only }}}

What do you think? Rand(1,2022) (talk) 23:17, 28 January 2026 (UTC) Reply

It sounds like a great feature. If the mapping information comes from a different URL than the actual values do, then you'd have to use that 2nd type of syntax, no? Yaron Koren (talk) 01:32, 29 January 2026 (UTC) Reply

That's the idea, and the result should be in the same format required by the pfautocomplete API module (although in time, a more established, richer format to replace the bespoke one we have now would be nice). If the mapping information comes from the same URL, you would use the same syntax but you'd just have to name the same URL source (the shorthand defined in local settings) twice, in 'values from url' as well as 'mapping from url'. I think that approach is both more flexible and more transparent to users. Rand(1,2022) (talk) 09:39, 29 January 2026 (UTC) Reply

The wikiparser was wrapping the middle element (month) of the date input in paragragh tags, so that it wrapped under the day element (in a table cell). I don't know why. The table validated, so there was nothing irregular that would have triggered the parser to insert its unneeded paragraph element. I solved the problem with the following CSS: span.dateInput p {display: inline; margin: 0;padding: 0;}, recommended by Google AI. (The date input is wrapped in <span class="dateInput" ...> tags not by me, but probably by the Page Forms extension.) Maybe someone here knows a better way to prevent this or deal with it? Bmcfann (talk) 23:06, 23 February 2026 (UTC) Reply

Hello

I have updated to MediaWiki 1.44 and updated PageForms and Cargo and DisplayTitle.

There is a page template with has the following snippet:

{{#forminput:form=BookComment|query string=BookComment[Books] = Page Forms }}

This part calls a form which includes the following:

<noinclude>
This is the 'Book Comment' form. 
{{#forminput:form=BookComment|autocomplete on category=Comment_heading}}
</noinclude>
:
:
:
'''Comment:''' {{{field|comment text|input type=textarea}}}
'''References:''' 
{{{field|Books|input type=tokens}}}
'''Comment Date:''' {{{field|Date|input type=datetime|default=now}}}
'''Meta Comment:''' {{{field|Comment}}}
:
:
:
</includeonly>

In Mediawiki 1.41 when this template/form was called it simply expanded to the page name as expected.

In version 1.44 it insists on expanding Page Forms to DISPLAYNAME (PAGENAME). As an example, if the page name is "smith" and the DISPLAYNAME is "John Smith" it expands to "John Smith (smith)"

I am trying to make it behave as in the past but I have no idea where even the problem is.

Any help is appreciated, thanks. Lbundle (talk) 22:48, 25 February 2026 (UTC) Reply

Do you mean that the value shows up that way in the form, or the resulting page, or both? Yaron Koren (talk) 19:55, 27 February 2026 (UTC) Reply

The value shows up in the form. The output in the resulting page is okay. What is also weird is that it happens only for some fields and not others. The misformatting happens with the Authors, Publisher, Owner. It does not happen with Genres or location. I am not seeing a pattern. Authors, genres and locations can take multiple values.

Here is the Book Form and template (clearer if you view source, nowiki not working properly):

This is the "Book" form.

To create a page with this form, enter the page name below;

if a page with that name already exists, you will be sent to a form to edit that page.

{{#forminput:form=Book}}

The Book template code is below

This is the "Book" template.

{{#cargo_declare:_table=Books

|Pretitle=String

|Title=String

|Subtitle=String

|Authors=List (,) of Page

|Genres=List (,) of Page

|Publishers=List (,) of Page

|Year_of_publication=Date

|Number_of_pages=Integer

|ISBN=String

|Owners=List (,) of Page

|Locations=List (,) of Page

|Files=List (,) of String

|Comment=Wikitext

}}

Lbundle (talk) 05:58, 2 March 2026 (UTC) Reply

That's actually the intended behavior, for better or worse - you can make it go away by adding $wgPageFormsUseDisplayTitle = false; to LocalSettings.php. Yaron Koren (talk) 06:10, 2 March 2026 (UTC) Reply

Thank you, I will try it tomorrow.

So why do the the different fields show differing behaviors for similar configurations? Is that a bug in PageForms? Lbundle (talk) 03:40, 3 March 2026 (UTC) Reply

It might be a bug... or could it be that the display name for certain fields' values is the same as their page name? Yaron Koren (talk) 17:14, 3 March 2026 (UTC) Reply

The display names in my setup are all different from the page names.

Another possibility I'm considering is that perhaps there is an update process which takes time and I caught it between fields? Lbundle (talk) 06:21, 4 March 2026 (UTC) Reply

I doubt that. It might just be a bug - or perhaps it has something to do with what's in the form definition. Yaron Koren (talk) 15:00, 4 March 2026 (UTC) Reply

It worked, thanks! Lbundle (talk) 06:51, 6 March 2026 (UTC) Reply

I would like to use tokens as type of input field for Cargo column which contains wikitext (quite simple, just wiki links like [[aaa]], [[bbb]]).

I can enter such wikitext items to token input, they are stored to Cargo and retrieved for display correctly, but I do not see them in edit form never again: input field looks empty.

Is it known problem or even feature? Radouch (talk) 19:06, 26 February 2026 (UTC) Reply

The issue is probably the brackets - the "tokens" input is expecting to see strings like "aaa, bbb" instead. Do those brackets need to be there? Could you instead use #template_display, or #arraymap, within the template to display them as links? Yaron Koren (talk) 19:58, 27 February 2026 (UTC) Reply

Well, I had an intention to use brackets if it should be wikilink and not to use them if it should not be.

But that is not really critical, I can live with such limitation. Just wanted to know if it is something "built-in".

Thank you for your swift reply and for your work! :-) Radouch (talk) 21:17, 27 February 2026 (UTC) Reply

Sure! I do think doing it without brackets is better in general - it makes things easier for editors. Yaron Koren (talk) 00:23, 28 February 2026 (UTC) Reply

As I reported at the Miraheze Issue Tracker this mid-February, "The 'Edit with form' tab does not appear on pages where it is declared via category (e.g. ad from Category:Tovasala words [on my wiki])." However, it does show up if declared from Project:Namespace pages (e.g. on track listings). 55% certain it's an extension issue rather than a platform issue... Slgrandson (talk) 02:12, 27 February 2026 (UTC) Reply

Well, that particular word, "ad", seems to be in two different languages, with two different forms defined for it, which seems like a problem - but that's just a data design issue, that I don't think is related to this problem. I don't know what's causing this particular problem - I haven't heard about it on other MW 1.45+ wikis. Could you try resaving one or more of the relevant category pages? Maybe that will be enough to restore the tabs. Yaron Koren (talk) 20:17, 27 February 2026 (UTC) Reply

More language-specific example: Tovasala mé , corresponding to English I. Slgrandson (talk) 20:32, 27 February 2026 (UTC) Reply

Two months and change later, the tab is still absent (i.e. on this FTA edition, whose parent category has {{#default_form:FTA post}} as the declaration). --Slgrandson (talk) 11:59, 13 May 2026 (UTC) Reply

I suggested resaving the category pages - did you try doing that? Yaron Koren (talk) 13:08, 14 May 2026 (UTC) Reply

Already did (by way of dummy edit); nothing yet. --Slgrandson (talk) 10:33, 26 May 2026 (UTC) Reply

As stated in documentation of #formlink,

Note: popup forms may not work if you have the ConfirmEdit extension installed - users might not see the CAPTCHA they need to fill out.

However, I tried #formlink without popup, only the most basic configuration (without reload or popup/new window, but the Captcha still haven't shown up. {{#formlink:form=FORM_NAME|linktext=New Page|link type=button}}

Only after clicking the Submit button in Form Edit view, it will lead Captcha error page in Source Edit view, with the ConfirmEdit captcha in the below near the Submit button and Summary field. Duyhungwiki (talk) 05:00, 13 March 2026 (UTC) Reply

@Yaron Koren hello sir. Could you please take a look and advise? Thanks for your support. Duyhungwiki (talk) 06:41, 25 March 2026 (UTC) Reply

Whenever a user edits a page with a form and saves, the wiki text adds a line break after the stored data, which results in an empty line at the top of the page. I would like to avoid this empty line.

For example, the top of the page has:

{{Hausstätte info|Ortsteil={{AutoOrtsteil}}
... more fields...
|Hausnummer1901={{AutoHausnummer3}}
}}First sentence of the visible text outside of the infobox...

When the page is edited with the form, this turns into:

{{Hausstätte info|Ortsteil={{AutoOrtsteil}}
... more fields...
|Hausnummer1901={{AutoHausnummer3}}
}}
First sentence of the visible text outside of the infobox...

This change results in an empty line at the top of the page. My users have to go back into text editing mode to erase this line after every form edit. Is it possible to avoid the creation of this line break? Dumpstar (talk) 17:14, 13 March 2026 (UTC) Reply

I don't see any difference between your two examples (even in the wikitext), but I think I understand the issue - you want the free text to be on the same line as the end of the template call. But a single newline between the curly bracket ending and the free text should not result in an empty line at the top. Could it be that there's something in the template causing this? Yaron Koren (talk) 17:24, 13 March 2026 (UTC) Reply

Yes! Thank you! Apparently I had added one line break too much to close an includeonly and add a category call. But I could fix it now. Dumpstar (talk) 17:37, 13 March 2026 (UTC) Reply

For example, if the string is O'Hara you'd type O, it'll suggest O'Hara, but what goes in the combobox is

O'Hara

Also, once you type as far as O' it'll not autocomplete at all.

MW 1.43, PF 6.0.5 Jonathan3 (talk) 16:08, 31 March 2026 (UTC) Reply

Does this happen with a specific source for the autocompletion values, i.e. "values from ..." or "values="? Yaron Koren (talk) 20:39, 7 April 2026 (UTC) Reply

In this case, cargo table=/cargo field= Jonathan3 (talk) 14:12, 8 April 2026 (UTC) Reply

Does this happen for you with "local" or "remote" autocompletion, or both? (If it's remote, it will say "Please enter 1 or more characters" before you type anything.) Yaron Koren (talk) 23:24, 8 April 2026 (UTC) Reply

It happens with remote autocompletion only. Local works fine (i.e. autocomplete continues to work after you type ' and if you click on a suggestion the ' is not converted to '). I hadn't thought to check that before you asked. Jonathan3 (talk) 00:31, 9 April 2026 (UTC) Reply

Okay, I see the problem - thanks for pointing it out. I just checked in a fix. Yaron Koren (talk) 16:51, 9 April 2026 (UTC) Reply

It works! Thanks. Jonathan3 (talk) 17:01, 9 April 2026 (UTC) Reply

I think this started when I upgraded Page Forms to 6.0.5 after upgrading from MW1.39 to 1.43. Jonathan3 (talk) 12:52, 7 April 2026 (UTC) Reply

What version of WikiEditor are you using? Yaron Koren (talk) 21:44, 7 April 2026 (UTC) Reply

1.5.4, the version bundled with MW1.43.

In response to your question, I downloaded it using git, but the most recent branch that works is REL1_43 (as later branches' extension.json require later MW versions). It also shows up as 1.5.4 and has the same problem. Jonathan3 (talk) 13:48, 8 April 2026 (UTC) Reply

Alright, I see. It appears that this was a bug in WikiEditor that was fixed before the REL1_45 version. Though there's probably a way for the Page Forms code to undo the problem. Yaron Koren (talk) 15:48, 8 April 2026 (UTC) Reply

What caused/fixed the bug? I might patch my WikiEditor code for now. Though it'll be affecting everybody using WikiEditor and Page Forms on MW 1.43, so might be worth fixing at the Page Forms end too. Jonathan3 (talk) 00:34, 9 April 2026 (UTC) Reply

I don't know - it looks like the WikiEditor code had quite a few changes related to preview handling around May-June 2025, so I'm guessing one or more of those fixed the problem. It would be nice to fix the problem in Page Forms, yes. Yaron Koren (talk) 15:36, 9 April 2026 (UTC) Reply

$wgWikiEditorRealtimePreview = false; fixed it for now! Jonathan3 (talk) 16:41, 9 April 2026 (UTC) Reply

Oh, great! Yaron Koren (talk) 16:52, 9 April 2026 (UTC) Reply

In a form for books, the field publication_date holds a page from Category:Year. A year is a 4 digits number. When using combobox, the form freezes and we get TypeError: str.toLowerCase is not a function. (In 'str.toLowerCase()', 'str.toLowerCase' is undefined) in the console.
We changed the input type to tokens, with max values=1, and it worked fine but it's a bit ugly, we would like to continue using combobox as before. Is it because of a new version of JavaScript? Amahiant (talk) 13:37, 13 April 2026 (UTC) Reply

If it helps narrow down the problem, I've got a combobox for years with max values=1|cargo table=...|cargo field=YEAR(...) and it works fine. Jonathan3 (talk) 13:48, 13 April 2026 (UTC) Reply

Thanks for letting me know about that - I just checked in a fix, here. Yaron Koren (talk) 20:14, 13 April 2026 (UTC) Reply

NameName

It ignores the desired uniqueness of the value. ~2026-34421-12 (talk) 13:48, 11 June 2026 (UTC) Reply

<tr><th>Name</th><td>{{{field|Name|input type=text|mandatory|placeholder=Please enter name here|unique}}}</td></tr>

It ignores the desired uniqueness of the value. ~2026-34421-12 (talk) 13:48, 11 June 2026 (UTC) Reply

Done. It needs cargo table and cargo field. ~2026-34421-12 (talk) 13:52, 11 June 2026 (UTC) Reply

When using {{#formredlink}}, one can fetch the entire raw contents of a page or template using |preload=Page name or |preload=Template:Name in the free-text box. Is there a way to use just {{Name}} as the lone value in said box instead? --Slgrandson (talk) 21:38, 23 June 2026 (UTC) Reply

What's the advantage of that? Yaron Koren (talk) 22:24, 23 June 2026 (UTC) Reply

@Yaron Koren: Similar to Preloader, in that the tag should be loaded into the free-text field. --Slgrandson (talk) 02:31, 24 June 2026 (UTC) Reply

Oh... I get it, you want that template call to go into the page. What about just putting something like {{{for template|Name}}}{{{end template}}} in the form? That should accomplish the same thing. Yaron Koren (talk) 05:01, 24 June 2026 (UTC) Reply

Hello, I was never able to get the mapping template working with "Tree" type fields (I had reported this malfunction a few years ago). Since I don't have development skills, I asked an AI to make it work, and it now works for me. I don't know if this could be useful to anyone else, and I'm not sure how to submit a patch, especially since I'm not its author. However, if it can be of use to someone, I'm happy to make the patch available. L. ~2026-38165-07 (talk) 15:07, 3 July 2026 (UTC) Reply

That's great! Please put the patch anywhere online - pastebin.com, here, or anywhere else. Yaron Koren (talk) 15:49, 3 July 2026 (UTC) Reply

Hi Yaron, thanks for your answer. Here is the patch :

diff --git a/includes/forminputs/PFTreeInput.php b/includes/forminputs/PFTreeInput.php index 422214c1..77a82a2b 100644 --- a/includes/forminputs/PFTreeInput.php +++ b/includes/forminputs/PFTreeInput.php @@ -111,6 +111,11 @@ class PFTreeInput extends PFFormInput { } $cur_value = implode( $delimiter, $pftree->current_values ); + + $allValues = self::collectTreeValues( $pftree->tree_array ); + $mappedValues = PFMappingUtils::getMappedValuesForInput( $allValues, $other_args ); + $pftree->tree_array = self::applyTreeMapping( $pftree->tree_array, $mappedValues ); + $params = [ 'multiple' => self::$multipleSelect, 'delimiter' => $delimiter, @@ -122,12 +127,12 @@ class PFTreeInput extends PFFormInput { 'class' => 'pfTreeInput', 'style' => 'height: ' . $height . 'px; width: ' . $width . 'px; overflow: auto; position: relative;', 'data' => json_encode( $pftree->tree_array ), - 'params' => json_encode( $params ) + 'params' => json_encode( $params ), + 'data-version' => 'v3' ]; - $text = Html::element( 'div', $treeInputAttrs, '' ); - $text .= "<input type='hidden' class='PFTree_data' name='" . $input_name . "'>"; - + $text = Html::rawElement( 'div', $treeInputAttrs, '' ); + $text .= Html::hidden( $input_name, $cur_value, [ 'class' => 'PFTree_data' ] ); $wrapperClass = 'pfTreeInputWrapper'; if ( $is_mandatory ) { $wrapperClass .= ' mandatory'; @@ -210,4 +215,33 @@ class PFTreeInput extends PFFormInput { return $t; } + private static function collectTreeValues( array $tree ) { + $values = []; + foreach ( $tree as $node ) { + if ( isset( $node['text'] ) ) { + $values[] = $node['text']; + } + if ( isset( $node['children'] ) ) { + $values = array_merge( $values, self::collectTreeValues( $node['children'] ) ); + } + } + return array_values( array_unique( $values ) ); + } + + private static function applyTreeMapping( array $tree, array $mappedValues ) { + $newTree = []; + foreach ( $tree as $node ) { + $rawValue = $node['text'] ?? ''; + $node['value'] = $rawValue; + if ( array_key_exists( $rawValue, $mappedValues ) ) { + $node['text'] = $mappedValues[$rawValue]; + } + if ( isset( $node['children'] ) ) { + $node['children'] = self::applyTreeMapping( $node['children'], $mappedValues ); + } + $newTree[] = $node; + } + return $newTree; + } + } diff --git a/libs/PF_tree.js b/libs/PF_tree.js index 07a0142b..7823b3a5 100644 --- a/libs/PF_tree.js +++ b/libs/PF_tree.js @@ -91,12 +91,15 @@ $.fn.extend({ $(this).jstree(options); $(this).bind('select_node.jstree', (evt, data) => { - tree.check(data.node.text); + const val = ( data.node.original && data.node.original.value !== undefined ) ? data.node.original.value : data.node.text; + tree.check(val); }); $(this).bind('deselect_node.jstree', (evt, data) => { - tree.uncheck(data.node.text); + const val = ( data.node.original && data.node.original.value !== undefined ) ? data.node.original.value : data.node.text; + tree.uncheck(val); }); tree.setCurValue(); + console.log('PF_tree.js version v3 loaded'); } }); ~2026-38165-07 (talk) 19:52, 3 July 2026 (UTC) Reply

Is there any way you can put that on multiple lines instead of just one? Yaron Koren (talk) 17:36, 6 July 2026 (UTC) Reply

As stated in the docs:

If any part of your query string — such as a page name or anything else — contains characters such as apostrophes ('), ampersands (&), or plus signs (+), you will need to URL-encode that value. For that, you can use the urlencode function from the ParserFunctions extension. The example above, for instance, would need to change to: Quote[Author]={{urlencode:{{PAGENAME}}}}.

However, when we used the {{urlencode:}} to pass the {{PAGENAME}} to the form, it cannot return to the original wording of PAGENAME in the form, but space becomes +; & becomes %38 and so on.

I tried {{PAGENAMEE}} instead of {{PAGENAME}}, but it also is not good.

Could you help any ways to workaround? Duyhungwiki (talk) 12:29, 6 July 2026 (UTC) Reply

Hello, I'm using Page Forms 6.0.9 on MediaWiki 1.43.1. I have a template with one field holding multiple templates. The template and corresponding form have been in use for more than a year and worked fine. A few weeks ago (maybe after upgrading to 6.0.8, but I'm not sure) this problem started presenting itself: using the form for adding one new template to the field which holds multiple templates deletes the content of some fields in other templates in the same multi-instance field.

To clarify: the result I expect when I edit the page with Page Forms:

{{Scheda formazione addetto
|Sessioni di formazione seguite=
 {{Sessione di formazione seguita
 |Titolo=Altro
 |Titolo libero=Formazione ISO 9001:2015
 |Categoria corso=Formazione sistemi di gestione
 |Data=2021年01月13日
 |Ore corso=2
 }}
 {{Sessione di formazione seguita
 |Titolo=Altro
 |Titolo libero=Formazione Parità di genere
 |Categoria corso=Formazione sistemi di gestione
 |Data=2024年04月19日
 |Ore corso=1
 |Note=Online
 }}
 {{Sessione di formazione seguita
 |Titolo=Altro
 |Titolo libero=I sistemi di gestione integrati - Qualità e parità di genere
 |Categoria corso=Formazione organizzata da W.Training
 |Data=2026年05月28日
 |Ore corso=1
 }}
}}

The result I get:

{{Scheda formazione addetto
|Sessioni di formazione seguite=
 {{Sessione di formazione seguita
 |Titolo=Altro
 |Data=2021年01月13日
 |Ore corso=2
 }}
 {{Sessione di formazione seguita
 |Titolo=Altro
 |Data=2024年04月19日
 |Ore corso=1
 |Note=Online
 }}
 {{Sessione di formazione seguita
 |Titolo=Altro
 |Titolo libero=I sistemi di gestione integrati - Qualità e parità di genere
 |Categoria corso=Formazione organizzata da W.Training
 |Data=2026年05月28日
 |Ore corso=1
 }}
}}

Important note: the fields that get emptied (Titolo libero and Categoria corso) are displayed conditionally by the form using Show on select, based on the value of the dropdown-field Titolo.

Upgrading from 6.0.8 to 6.0.9 did not solve the problem. Editing via source editor works fine. Thanks for any help! MLWatts (talk) 08:48, 20 July 2026 (UTC) Reply

What version of Page Forms were you using before? It would be helpful to know when the problem started, to whatever degree is possible. Yaron Koren (talk) 12:03, 20 July 2026 (UTC) Reply

When I noticed the problem I was using Page Forms 6.0.8. Before upgrading to 6.0.8 I was using 6.0.1 and everything was working well. MLWatts (talk) 09:55, 21 July 2026 (UTC) Reply

Hey! Just to provide some additional information: I tried upgrading from Page Forms 6.0.8 to 6.0.10 and this did not solve the problem. Then I downgraded from 6.0.8 to 6.0.5 and the problem is not there: 6.0.5 works well. Cheers, MLWatts (talk) 10:36, 3 August 2026 (UTC) Reply

• Talk pages with syntax highlighting errors