Extension talk:Page Forms

MW 1.45.1 - SMW 6.0.1 - PageForms 6.0.4: missing "edit with form" (formedit action)

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)

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)

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)

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

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)

Using many multiple instances of a template may cause form editing to max out after preview is selected

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)

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)

@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)

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)

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)

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)

@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)

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)

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)

UNIQ...QINU tag problem was not a Page Forms problem

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)

I want populate with one field and store corresponding values from another field

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)

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)

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)

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)

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)

Instances of "(wiki)editor" still produce errors if no text is added to them

"'|' 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)

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)

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)

#template_params and form

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)

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)

Boolean values in the wiki's language [answered]

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)

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)

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)

Autocomplete causes text field to jump to beginning when input is too long

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)

Creating new page with one step process, but with form input

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)

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)

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)

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)

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)

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

On 'values from url' and mapping current values

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)

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)

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)