Extension talk:Page Forms

weird behaviour with tokens

It’s been a while since the previous time I upgraded so I don't know how long this bug has been around. Page Forms (tested with 5.8 and 5.9.1) now seems to do some funky things with values that are submitted with tokens and 'values from property' [updated]. Instead of a page name for each value, it now saves a combination of what appears to be the display title and the page name between rounded brackets. That breaks a lot of things for me now. Rand(1,2022) (talk) 11:54, 4 July 2025 (UTC)

By "top category", did you mean "values from category"? Also, do you know if this happens with the comobobox input type too, or just with tokens? Yaron Koren (talk) 12:45, 4 July 2025 (UTC)

It's just tokens not comboboxes. More specifically, It happens with 'values from property' when a mapping template is used to control the displaytitle/label. There's another situation I found: 'values from url' is broken in 5.9.1 but if I manually apply the patch from v6, I get the same issue. The Action API output looks fine but something gets changed somewhere along the way (PHP or JS I don't know yet). And forget about the 'top category;; that was a mistake on my part! Rand(1,2022) (talk) 20:53, 4 July 2025 (UTC)

Okay, it sounds like the problem is that the value mapping, which is supposed to only show up in the form, somehow ends up on the generated page as well. Speaking of Page Forms 6.0 - I assume you are not using it because you are still on MW 1.39. But do you see any change to the "values from property" behavior after applying the v6 patch? Yaron Koren (talk) 13:41, 7 July 2025 (UTC)

By the way, we tried this out with Page Forms 6.0 and couldn't reproduce the problem, so maybe it has been fixed. Regardless - whatever value you have $wgPageFormsUseDisplayTitle set to (true or false), you could try setting it to the other value and see if that improves the situation. Yaron Koren (talk) 18:31, 17 July 2025 (UTC)

Apologies for the delay - real life and the Summer break and all that. I think it's best for me then to wait until I've managed to upgrade to MW 1.43. Until that time I have a modified version of Page Forms to keep things going. Rand(1,2022) (talk) 08:25, 7 September 2025 (UTC)

Autogrow textarea doesn't work on mobile

Have you noticed this? It displays a subset of the existing text but you can't scroll to see it all if there are more than a few lines.

(Pretending to be a mobile on Chrome using F12 is OK as you have cursor keys then...) Jonathan3 (talk) 10:45, 21 July 2025 (UTC)

I agree that scrolling within a textarea on a cell phone or other mobile device can be tricky, but that's not unique to Page Forms, is it? I have an Android phone, where the key is to click on the blue circular cursor thing, and then use that to scroll up and down - that works fine for me. I don't know if iPhones have something similar. Yaron Koren (talk) 16:07, 21 July 2025 (UTC)

I think it is unique to Page Forms, but only with "autogrow".

Without autogrow, holding and moving up/down scrolls the content of the textarea, so that you can then point at it and edit where you have pointed.

With autogrow, the same action moves the whole page. It's as though the autogrow textarea isn't telling the browser that it has text inside it (in layman's terms). Jonathan3 (talk) 16:27, 21 July 2025 (UTC)

I don't know - I just checked, and for me the scrolling behavior seems to be the same with or without "autogrow", using Google Chrome on an Android phone. Are you using an iPhone? Yaron Koren (talk) 16:42, 21 July 2025 (UTC)

Yes, iPhone, using Safari. Jonathan3 (talk) 18:13, 22 July 2025 (UTC)

Okay, I just tried this on an iPhone, with Safari. If I click on the cursor, the cursor moves up and down the textarea, from beginning to end. And if I click on anywhere other than the cursor, the entire textarea moves up and down, which essentially functions the same way, since there's autogrow - moving the form up and down scrolls through all of the text as well, since there's no hidden text. So what is the exact problem you're seeing? Yaron Koren (talk) 21:09, 22 July 2025 (UTC)

Sorry for the delay. I don't think I got a notification. Maybe I should do a video. But from memory (as I've got rid of all the autogrow fields) it might be that when the form for an existing page is shown it doesn't "autogrow" to display the whole content. Then the problem arises (you try to scroll within the box, to see the rest of the content, and the whole window scrolls). From memory again, I think when you're typing afresh into the box it maybe does autogrow. Jonathan3 (talk) 23:59, 1 September 2025 (UTC)

Using #formredlink in a templatedisplay call

Hello, could you please point out how to use the #formredlink parser function for a field contained in a template called via {{#template_display:}}?

This is how my template looks like:

<noinclude> {{#template_params:pagina(label=Pagina)|autore (label=Autore;display=nonempty)|titolo (label=Titolo;display=nonempty)|edizione (label=Edizione;display=nonempty)|luogo (label=Luogo di stampa;display=nonempty)|editore (label=Editore;display=nonempty)|stampatore (label=Stampatore;display=nonempty)|anno (label=Anno di stampa;display=nonempty)|identificativo (label=Identificativo;display=nonempty)|recordSBNedit (label=Record SBN modificato;display=nonempty)|wikibaseItem (label=Wikibase Item;display=nonempty)|supporto (label=Supporto;display=nonempty)|lingua (label=Lingua;display=nonempty)|tipologia (label=Tipologia;display=nonempty)|rifbibled (label=Riferimenti bibliografici sull'edizione;display=nonempty)|volumi (label=Opera in più volumi;display=nonempty)|numvol (label=Numero volumi;display=nonempty)}} <code>{{#cargo_declare:_table=opere|pagina=Page|autore=List (;) of Page|titolo=String|edizione=Text|luogo=List (;) of String|editore=List (;) of String|stampatore=List (;) of String|anno=String|identificativo=URL|recordSBNedit=Boolean (allowed values=Sì,No)|wikibaseItem=URL|supporto=List (,) of String (allowed values=Stampa,Manoscritto)|lingua=List (;) of String|tipologia=List (;) of String|rifbibled=String|volumi=Boolean (allowed values=Sì,No)|numvol=Text}} </noinclude>

<includeonly> {{#cargo_store:_table=opere}} {{#template_display:_format=table}} </includeonly>

I want to add {{#formredlink}} for the field autore, to create pages with the Form:Autore. I should have something like this {{#formredlink:target=|form=Autore}} but I don't know where.

Thanks for any help you can provide! Loman87 (talk) 19:12, 22 July 2025 (UTC)

I think I planned to add a "form=" subparameter to #template_params, so that you could specify the form for any template field, but I never got around to it - so I think you will need to replace that #template_display call with a big actual table to display all 15 fields, unfortunately. (Either that or implement handling for "form=" in the Page Forms code, which would be great.) Yaron Koren (talk) 21:39, 22 July 2025 (UTC)

Actually, I decided this was an important-enough feature that I should add it in already. I just made that addition in the Page Forms code - thankfully it was easy to, requiring adding just two lines to PF_TemplateField.php. If you are running MediaWiki 1.40 or higher, I suggest you just upgrade to the latest Page Forms code. Otherwise, the best thing to do, I think, is manually add those two lines within your own code. Once you've done either of those, I think you just need to change the "autore" part of #template_params to look like autore (label=Autore;display=nonempty;form=Autore). Yaron Koren (talk) 06:31, 23 July 2025 (UTC)

Thanks Yaron, this is wonderful and works perfectly! I wouldn't have beeen able to do it by myself. ~2025-25752-1 Loman87 (talk) 09:33, 24 July 2025 (UTC)

When adding more than five instances of the same template, Warning: Cannot modify header information - headers already sent

I have a form that uses the multiple tag on one of the templates. The code is:

{{{for template|Standard page body|multiple|label=Technical controls|add button text=Add a new technical control}}}

{| class="formtable"
! Section title:
|-
| {{{field|Section title|input type=text}}}
|-
! Section ID, this needs to be unique on this page: 
|-
| {{{field|Section ID|input type=text with autocomplete|size=50|property=Section ID}}}
|-
! Section body ('''note''': if left blank, this will not display):
|-
| {{{field|Section body text|input type=textarea|editor=visualeditor|cols=50|rows=10}}}
|-
! Stakeholders ('''note''': if left blank, this will not display):
|-
| {{{field|Stakeholders|input type=tokens}}}
|-
! Agile life cycle ('''note''': if left blank, this will not display):
|-
| {{{field|Agile life cycle|input type=tokens}}}
|}

{{{end template}}} 

When I add up to four of these templates it works as I would expect. But, when I add a fifth, it saves, but I get the error:

Deprecated: ord(): Passing null to parameter #1 ($character) of type string is deprecated in /mnt/data/html/wiki/includes/language/Language.php on line 2588

Deprecated: ord(): Passing null to parameter #1 ($character) of type string is deprecated in /mnt/data/html/wiki/includes/language/Language.php on line 2588

Deprecated: ord(): Passing null to parameter #1 ($character) of type string is deprecated in /mnt/data/html/wiki/includes/language/Language.php on line 2588

Deprecated: ord(): Passing null to parameter #1 ($character) of type string is deprecated in /mnt/data/html/wiki/includes/language/Language.php on line 2588

Deprecated: ord(): Passing null to parameter #1 ($character) of type string is deprecated in /mnt/data/html/wiki/includes/language/Language.php on line 2588

Deprecated: ord(): Passing null to parameter #1 ($character) of type string is deprecated in /mnt/data/html/wiki/includes/language/Language.php on line 2588

Deprecated: ord(): Passing null to parameter #1 ($character) of type string is deprecated in /mnt/data/html/wiki/includes/language/Language.php on line 2588

Deprecated: ord(): Passing null to parameter #1 ($character) of type string is deprecated in /mnt/data/html/wiki/includes/language/Language.php on line 2588

Deprecated: ord(): Passing null to parameter #1 ($character) of type string is deprecated in /mnt/data/html/wiki/includes/language/Language.php on line 2588

Deprecated: ord(): Passing null to parameter #1 ($character) of type string is deprecated in /mnt/data/html/wiki/includes/language/Language.php on line 2588

Deprecated: ord(): Passing null to parameter #1 ($character) of type string is deprecated in /mnt/data/html/wiki/includes/language/Language.php on line 2588

Deprecated: ord(): Passing null to parameter #1 ($character) of type string is deprecated in /mnt/data/html/wiki/includes/language/Language.php on line 2588

Deprecated: ord(): Passing null to parameter #1 ($character) of type string is deprecated in /mnt/data/html/wiki/includes/language/Language.php on line 2588

Deprecated: ord(): Passing null to parameter #1 ($character) of type string is deprecated in /mnt/data/html/wiki/includes/language/Language.php on line 2588

Deprecated: ord(): Passing null to parameter #1 ($character) of type string is deprecated in /mnt/data/html/wiki/includes/language/Language.php on line 2588

Deprecated: ord(): Passing null to parameter #1 ($character) of type string is deprecated in /mnt/data/html/wiki/includes/language/Language.php on line 2588

Deprecated: ord(): Passing null to parameter #1 ($character) of type string is deprecated in /mnt/data/html/wiki/includes/language/Language.php on line 2588

Deprecated: ord(): Passing null to parameter #1 ($character) of type string is deprecated in /mnt/data/html/wiki/includes/language/Language.php on line 2588

Deprecated: ord(): Passing null to parameter #1 ($character) of type string is deprecated in /mnt/data/html/wiki/includes/language/Language.php on line 2588

Deprecated: ord(): Passing null to parameter #1 ($character) of type string is deprecated in /mnt/data/html/wiki/includes/language/Language.php on line 2588

Deprecated: ord(): Passing null to parameter #1 ($character) of type string is deprecated in /mnt/data/html/wiki/includes/language/Language.php on line 2588

Deprecated: ord(): Passing null to parameter #1 ($character) of type string is deprecated in /mnt/data/html/wiki/includes/language/Language.php on line 2588

Deprecated: ord(): Passing null to parameter #1 ($character) of type string is deprecated in /mnt/data/html/wiki/includes/language/Language.php on line 2588

Deprecated: ord(): Passing null to parameter #1 ($character) of type string is deprecated in /mnt/data/html/wiki/includes/language/Language.php on line 2588

Warning: Cannot modify header information - headers already sent by (output started at /mnt/data/html/wiki/includes/language/Language.php:2588) in /mnt/data/html/wiki/includes/Request/WebResponse.php on line 250

Warning: Cannot modify header information - headers already sent by (output started at /mnt/data/html/wiki/includes/language/Language.php:2588) in /mnt/data/html/wiki/includes/Request/WebResponse.php on line 80

Warning: Cannot modify header information - headers already sent by (output started at /mnt/data/html/wiki/includes/language/Language.php:2588) in /mnt/data/html/wiki/includes/Request/WebResponse.php on line 80

Warning: Cannot modify header information - headers already sent by (output started at /mnt/data/html/wiki/includes/language/Language.php:2588) in /mnt/data/html/wiki/includes/Request/WebResponse.php on line 80

Warning: Cannot modify header information - headers already sent by (output started at /mnt/data/html/wiki/includes/language/Language.php:2588) in /mnt/data/html/wiki/includes/Request/WebResponse.php on line 80

Warning: Cannot modify header information - headers already sent by (output started at /mnt/data/html/wiki/includes/language/Language.php:2588) in /mnt/data/html/wiki/includes/Request/WebResponse.php on line 80

I also get the same errors when just editing with form as normal.

I'm running

What	Version
Mediawiki	1.43.1
Page Forms	6.0 (a534d55) 07:30, 3 June 2025
PHP	8.3.6

If you need any further information, please let me know.

I have tried to do this on the latest master but it still comes up with the same error.

Any help is appreciated. Squeak24 (talk) 14:00, 1 August 2025 (UTC)

I thought I'd see if it was the version, I downgraded to 5.8.1 (a534d55) 07:30, 3 June 2025 which gave the error:

:[1aaf66e12b1d27143fc16583] /wiki/index.php?title=WaaS:Passenger_travel_policy&action=formedit Error: Class "SMWDIProperty" not found :Backtrace: :from /mnt/data/html/wiki/extensions/PageForms/includes/PF_TemplateField.php(164) :#0 /mnt/data/html/wiki/extensions/PageForms/includes/PF_TemplateField.php(196): PFTemplateField->setTypeAndPossibleValues() :#1 /mnt/data/html/wiki/extensions/PageForms/includes/PF_TemplateField.php(53): PFTemplateField->setSemanticProperty() :#2 /mnt/data/html/wiki/extensions/PageForms/includes/PF_Template.php(232): PFTemplateField::create() :#3 /mnt/data/html/wiki/extensions/PageForms/includes/PF_Template.php(130): PFTemplate->loadPropertySettingInTemplate() :#4 /mnt/data/html/wiki/extensions/PageForms/includes/PF_Template.php(95): PFTemplate->loadTemplateFieldsSMWAndOther() :#5 /mnt/data/html/wiki/extensions/PageForms/includes/PF_Template.php(39): PFTemplate->loadTemplateFields() :#6 /mnt/data/html/wiki/extensions/PageForms/includes/PF_FormPrinter.php(1082): PFTemplate::newFromName() :#7 [internal function]: PFFormPrinter->formHTML() :#8 /mnt/data/html/wiki/includes/StubObject/StubObject.php(125): call_user_func_array() :#9 /mnt/data/html/wiki/includes/StubObject/StubObject.php(155): MediaWiki\StubObject\StubObject->_call() :#10 /mnt/data/html/wiki/extensions/PageForms/includes/PF_AutoeditAPI.php(953): MediaWiki\StubObject\StubObject->__call() :#11 /mnt/data/html/wiki/extensions/PageForms/includes/PF_AutoeditAPI.php(130): PFAutoeditAPI->doAction() :#12 /mnt/data/html/wiki/extensions/PageForms/specials/PF_FormEdit.php(113): PFAutoeditAPI->execute() :#13 /mnt/data/html/wiki/extensions/PageForms/includes/PF_FormEditAction.php(302): PFFormEdit->printForm() :#14 /mnt/data/html/wiki/extensions/PageForms/includes/PF_FormEditAction.php(32): PFFormEditAction::displayForm() :#15 /mnt/data/html/wiki/includes/actions/ActionEntryPoint.php(733): PFFormEditAction->show() :#16 /mnt/data/html/wiki/includes/actions/ActionEntryPoint.php(510): MediaWiki\Actions\ActionEntryPoint->performAction() :#17 /mnt/data/html/wiki/includes/actions/ActionEntryPoint.php(146): MediaWiki\Actions\ActionEntryPoint->performRequest() :#18 /mnt/data/html/wiki/includes/MediaWikiEntryPoint.php(200): MediaWiki\Actions\ActionEntryPoint->execute() :#19 /mnt/data/html/wiki/index.php(58): MediaWiki\MediaWikiEntryPoint->run() :#20 {main}

Squeak24 (talk) 14:17, 1 August 2025 (UTC)

The real issue there is those ord() call failures. Those are all warnings, though - do they actually cause the form save to fail? Also, does this happen with any five instances of the template, or do the contents matter? Yaron Koren (talk) 19:24, 1 August 2025 (UTC)

Hi Yaron,

I have put it in a video (apologies for the quality, it was just a very quick one). I have uploaded it to one of my websites so you can see whats going on. This is a local server.

https://dafoshowcase.com/PageForms%20Issue%20Aug%204%2025.mp4 Squeak24 (talk) 16:52, 4 August 2025 (UTC)

Okay, thanks. My guess is that those ord() calls, though unfortunate, are not related either. My new guess is that the issue is just too much data being sent by the form. It could be that changing some setting could fix the problem - I would look into increasing post_max_size for PHP. Yaron Koren (talk) 17:20, 4 August 2025 (UTC)

Thanks Yaron

Eventually, I have found the bug, I have had to update the includes/languages/Language.php

The issue surrounds:

       public function ucfirst( $str ) {
                $octetCode = ord( $str );
                // See https://en.wikipedia.org/wiki/ASCII#Printable_characters
                if ( $octetCode < 96 ) {
                        // Assume this is an uppercase/uncased ASCII character
                        return (string)$str;
                } elseif ( $octetCode < 128 ) {
                        // Assume this is a lowercase/uncased ASCII character
                        return ucfirst( $str );
                }
                $first = mb_substr( $str, 0, 1 );
                if ( strlen( $first ) === 1 ) {
                        // Broken UTF-8?
                        return ucfirst( $str );
                }

The problem line is

$octetCode = ord( $str );

To fix this, I have edited the code:

 public function ucfirst( $str ) {
                // Temp fix for the ord() issue
                 if ( !is_string( $str ) || $str === '' ) {
                   return '';
                }
                $octetCode = ord( $str );
                // See https://en.wikipedia.org/wiki/ASCII#Printable_characters
                if ( $octetCode < 96 ) {
                        // Assume this is an uppercase/uncased ASCII character
                        return (string)$str;
                } elseif ( $octetCode < 128 ) {
                        // Assume this is a lowercase/uncased ASCII character
                        return ucfirst( $str );
                }
                $first = mb_substr( $str, 0, 1 );
                if ( strlen( $first ) === 1 ) {
                        // Broken UTF-8?
                        return ucfirst( $str );
                }
                // Memoize the config table
                $overrides = $this->overrideUcfirstCharacters
                        ??= $this->config->get( MainConfigNames::OverrideUcfirstCharacters );

Squeak24 (talk) 12:33, 5 August 2025 (UTC)

That will fix the ord() warnings, but does it fix the saving issue? Yaron Koren (talk) 20:58, 5 August 2025 (UTC)

Yeah, it now allos me to save with this fix. Squeak24 (talk) 11:09, 12 August 2025 (UTC)

ah, but that fix breaks the update.php. I have reported it on phabricator, hopefully it will get fixed Squeak24 (talk) 16:38, 12 August 2025 (UTC)

I may have separately fixed this problem in the latest Page Forms code, with this change. Yaron Koren (talk) 20:00, 13 August 2025 (UTC)

The link "Create this page" does not point to formedit

Hi, on my wiki the settings make the redlink choose the right form to create/edit pages according to the namespace.

BUT, if I follow a page like "MyNamespace:Test" (directly, not from a redlink), I get the classic message "There is currently no text in this page. You can search for this page title in other pages, search the related logs, or create this page. "

and the link on "create this page" does not point to formedit, only to classic edit.

Is there any setting I am missing ? Beause I saw nothing about this in the help pages.

Varlin (talk) 16:49, 3 August 2025 (UTC)

No, there's no setting. What do you mean by "follow a page"? Yaron Koren (talk) 15:55, 4 August 2025 (UTC)

"Follow this page" was probably bad english (I'm french). I meant "type the URL https://mydomain/MyNamespace:Test". Varlin (talk) 19:04, 4 August 2025 (UTC)

Oh, I see. I'm guessing that there's no way for Page Forms to modify that particular red link, though I could be wrong. Yaron Koren (talk) 20:56, 5 August 2025 (UTC)

Copyright warning on PF forms

Is it possible to add the usual MediaWiki:Copyrightwarning to the bottom of a Page Forms page? Jonathan3 (talk) 13:08, 14 August 2025 (UTC)

I don't think there's any way to do it, unfortunately, other than just manually adding that text to each form. Yaron Koren (talk) 14:43, 19 August 2025 (UTC)

Through transclusion--and before the closing </div> in the form code: {{MediaWiki:Copyrightwarning}}. --Slgrandson (talk) 12:21, 20 August 2025 (UTC)

Oh, yes! I didn't think of that. Yaron Koren (talk) 13:13, 20 August 2025 (UTC)

Before seeing this, I had done the transclusion and it worked all right. Sorry for not posting here.

I don't know what's meant by the closing div of the form code. I used a new div of class editOptions. But would have preferred it to be incorporated within the same div as the save button etc. Is that possible? I suppose I would have to recreate the various buttons using standard input tags (as in Extension:Page_Forms/Defining_forms#Defining_the_bottom_of_the_form). If so, what's the best way to order/format those? @Slgrandson Thanks! Jonathan3 (talk) 23:54, 1 September 2025 (UTC)

customizing date input

Hello! Is there a way to customize the input for input type Date? (Currently it's three inputs day, month (spelled out), and year. I'd like to use year, month(number), day. I see a note about changing some other date related formatting on the common problems page like $wgPageForms24HourTime. Is there a list of other configurable settings like this for the date input? Thanks so much for such a wonderful extension!!! Armikur (talk) 17:16, 15 August 2025 (UTC)

The only other setting that modifies the date input is $wgAmericanDates. Try setting it to false - hopefully that's a good enough solution, but let me know if not. Yaron Koren (talk) 14:48, 19 August 2025 (UTC)

Error: Class "SMWDIProperty" not found

Error: Class "SMWDIProperty" not found with Version 5.9.1

How can i work around this? - Upgrade/Downgrade? This is for a MediaWiki 1.39.13 Seppl2013 (talk) 12:18, 19 August 2025 (UTC)

I assume that's due to this change. I assume there's a way to fix this by upgrading SMW (but not too much, since the latest doesn't support MW 1.39), but I would think the easiest fix is to downgrade Page Forms, so that you are using the exact version 5.9.1, released a month before this change. Yaron Koren (talk) 14:38, 19 August 2025 (UTC)

@Yaron Koren thx for the quick reply. https://github.com/WolfgangFahl/pymediawikidocker/issues/91 has tag map now for such cases. I assume i can also install from a git repo. Seppl2013 (talk) 16:23, 19 August 2025 (UTC)

https://github.com/wikimedia/mediawiki-extensions-PageForms/tags

::- name: Page Forms
::  url: https://www.mediawiki.org/wiki/Extension:Page_Forms
::  extension: PageForms
::  purpose: (known before 2016 as Semantic Forms) is an extension to MediaWiki that  
::allows users to add, edit and query data using forms
::  #composer: '"mediawiki/page-forms": "5.9.1"'
::  giturl: https://github.com/wikimedia/mediawiki-extensions-PageForms
::  tagmap:
::    REL1_35: "5.9.1"
::    REL1_39: "5.9.1"
::    REL1_43: "6.0"
::    REL1_44: "6.0"
::  wikidata_id: Q21678466
::  since: '2016-09-07T00:00:00'
::

Seppl2013 (talk) 16:30, 19 August 2025 (UTC)

That seems fine. Yaron Koren (talk) 16:48, 19 August 2025 (UTC)

Neither 5.9.1 nor 5.9 solved the problem i still got

[28747b0f43736a2d9c716b8c] [no req] Error: Class "SMWDIProperty" not found Backtrace: from /var/www/html/extensions/PageForms/includes/PF_TemplateField.php(164)

when trying to e.g. edit http://genwiki39.genealogy.net/index.php/Extension/CategoryTree. I had to downgrade Semantic MediaWiki itself to 4.2.0 Seppl2013 (talk) 04:58, 20 August 2025 (UTC)

Oh, never mind, I looked at the code wrong. The issue was that the Page Forms code you are using is too early, not too late - having that commit I linked to before would actually fix the problem. Although your solution of using an earlier SMW version seems fine as well. Ultimately, the ideal solution (and what you'll have to do at some point) is upgrading MW, SMW and PF, to versions that all work with each other. Yaron Koren (talk) 13:21, 20 August 2025 (UTC)

MWException: Could not find concept API crash

@Yaron Koren - the following bug has been hunting me for a few years now. After having upgraded to 5.9.1 in https://contexts.bitplan.com/index.php/Concept:Extension - the relevant pages are all generated via API and the API chokes on creating: https://contexts.bitplan.com/index.php/Form:Extension see stacktrace below - it is no problem to create this page in the Wiki directly.

it seems

|{{{field|wiki|property=Extension wiki|input type=dropdown|values from concept=Wiki}}}

is the culprit since it references a concept that does not exist. Such a situation may well happen often when there are cross references between concepts and a hen/egg situation is created - what is first the concept or the form... I think non existing concepts should create warnings at best but not crash the creation of Form pages.

2025-08-20 03:53:16 46a2539bc942 wiki: [306ba1417bbcfb41814d6961] /api.php   MWException: Could not find concept: Wiki
#0 /var/www/html/extensions/PageForms/includes/PF_ValuesUtils.php(685): PFValuesUtils::getAllPagesForConcept(string)
#1 /var/www/html/extensions/PageForms/includes/PF_FormField.php(525): PFValuesUtils::getAutocompleteValues(string, string)
#2 /var/www/html/extensions/PageForms/includes/PF_FormField.php(444): PFFormField->setPossibleValues(string, string, NULL, NULL, NULL, NULL)
#3 /var/www/html/extensions/PageForms/includes/PF_FormPrinter.php(1162): PFFormField::newFromFormFieldTag(array, PFTemplate, PFTemplateInForm, boolean, User)
#4 /var/www/html/includes/StubObject.php(120): PFFormPrinter->formHTML(string, NULL, boolean, NULL, NULL, string, NULL)
#5 /var/www/html/includes/StubObject.php(149): StubObject->_call(string, array)
#6 /var/www/html/extensions/PageForms/includes/PF_Hooks.php(386): StubObject->__call(string, array)
#7 /var/www/html/includes/HookContainer/HookContainer.php(338): PFHooks::showFormPreview(EditPage, DerivativeRequest)
#8 /var/www/html/includes/HookContainer/HookContainer.php(137): MediaWiki\HookContainer\HookContainer->callLegacyHook(string, array, array, array)
#9 /var/www/html/includes/HookContainer/HookRunner.php(1575): MediaWiki\HookContainer\HookContainer->run(string, array)
#10 /var/www/html/includes/EditPage.php(1365): MediaWiki\HookContainer\HookRunner->onEditPage__importFormData(EditPage, DerivativeRequest)
#11 /var/www/html/includes/api/ApiEditPage.php(484): EditPage->importFormData(DerivativeRequest)
#12 /var/www/html/includes/api/ApiMain.php(1904): ApiEditPage->execute()
#13 /var/www/html/includes/api/ApiMain.php(879): ApiMain->executeAction()
#14 /var/www/html/includes/api/ApiMain.php(850): ApiMain->executeActionWithErrorHandling()
#15 /var/www/html/api.php(90): ApiMain->execute()
#16 /var/www/html/api.php(45): wfApiMain()
#17 {main}

Seppl2013 (talk) 04:18, 20 August 2025 (UTC)

This could easily be "fixed", but I don't see the problem here - if you see this error, why not just create the concept page? Why do you need the form to be usable before that is done? Yaron Koren (talk) 13:58, 20 August 2025 (UTC)

Do "partial forms" still exist?

I hope they do, but seem to remember that they were discontinued for being unreliable at editing pages. Jonathan3 (talk) 23:47, 1 September 2025 (UTC)

No, they were removed for being unreliable, and also unnecessary - you can just create a form that contains all the relevant templates, but only those fields you want editable. Yaron Koren (talk) 14:37, 2 September 2025 (UTC)

What's the best way to do that? I've just noticed the "hidden" parameter to the field tag. I guess that's the way forward. Jonathan3 (talk) 15:22, 2 September 2025 (UTC)

Sorting values combobox

Is it possible to sort the values of a combox? I use this: "|input type=combobox|values from category=Stakeholder|". Waanders (talk) 10:15, 2 September 2025 (UTC)

No, I think they always just get sorted alphabetically. How would you want them sorted? Yaron Koren (talk) 14:38, 2 September 2025 (UTC)

Could you send it values from a Cargo query? Jonathan3 (talk) 02:42, 3 September 2025 (UTC)

We don't use Cargo, we use Semantic MediaWiki. Waanders (talk) 09:08, 3 September 2025 (UTC)

I want them to get alphabetically, but they are randomly sorted. Waanders (talk) 09:07, 3 September 2025 (UTC)

That's unexpected. What version of Page Forms are you using? And is this for local or remote autocompletion? (In local autocompletion the values show up right away, in remote you have to type something first.) Yaron Koren (talk) 14:13, 3 September 2025 (UTC)

We use version 5.7.2 and local autocompletion. I think I've already figured out the problem: I use the 'mapping property'-parameters, so the list is sorted by pagename, not the mapped property (which I see in the list). Waanders (talk) 19:35, 4 September 2025 (UTC)

Hm, it probably would be better to sort on the mapped value, yes. Yaron Koren (talk) 19:19, 8 September 2025 (UTC)

Error when editing content containing arrays

After upgrading Medaiwki to 1.43 I have tried to edit already existing content defined by Cargo extension but it displayed an error, see below. After some experiments I found that Page Forms in some cases ignores default separator for fields containing list of values in Page Schema for the category. If I specify the separator (",") and recreate template, I can edit again.

[aLwvyHSs8TuwZRntjnBSSwAAAo4] /wiki/index.php?title=Data:(book_info)_2017_Dead_Reckoning_(HarperCollins_Canada)&action=formedit ValueError: explode(): Argument #1 ($separator) cannot be empty

Backtrace:

from /storage/d943a45e/3ea35aea-658f-4970-ab22-7a4f67025839/franklinova-expedice.cz/www/public/wiki/extensions/PageForms/includes/PF_ValuesUtils.php(850) #0 /storage/d943a45e/3ea35aea-658f-4970-ab22-7a4f67025839/franklinova-expedice.cz/www/public/wiki/extensions/PageForms/includes/PF_ValuesUtils.php(850): explode() #1 /storage/d943a45e/3ea35aea-658f-4970-ab22-7a4f67025839/franklinova-expedice.cz/www/public/wiki/extensions/PageForms/includes/forminputs/PF_CheckboxesInput.php(52): PFValuesUtils::getValuesArray() Radouch (talk) 13:10, 6 September 2025 (UTC)

I'm glad you got it working. But how was this field originally specified in #cargo_declare? Yaron Koren (talk) 13:37, 8 September 2025 (UTC)

Can certain forms (e.g. search forms) be excluded when $wgPageFormsLinkAllRedLinksToForms = true;

I'd like to specify which forms to show and/or hide (without using CSS which could hide the "other forms" div). Jonathan3 (talk) 14:06, 10 September 2025 (UTC)

P.S. CSS doesn't work easily as the "Other forms:" p tag isn't within the div containing the list of forms. Jonathan3 (talk) 14:11, 10 September 2025 (UTC)

It would presumably be easy to add a CSS class to the "Other forms" box - would that be enough? Yaron Koren (talk) 18:34, 11 September 2025 (UTC)

Yes, it would be good to enclose the introductory text within the existing divs (mainForms and otherForms).

I was able to hide "Other forms:" by hiding the first p after the main div. But that's not ideal. Also I'd quite like to hide "Main forms:". Jonathan3 (talk) 23:39, 11 September 2025 (UTC)

Oh, I didn't realize until now that you were just talking about the labels. You can make those go away by just blanking the MediaWiki: pages for those messages - is that good enough? Yaron Koren (talk) 15:29, 12 September 2025 (UTC)

It was a mixture of both but between the class on the div, and the message pages, I can do what I need. Thanks yet again. Jonathan3 (talk) 16:05, 12 September 2025 (UTC)

How to prevent pressing return within combobox from saving form

If you type into a combobox and press return it saves the form but doesn't save what you have typed into the combobox.

To save what you have typed into the combobox you first have to "tab" or otherwise leave the combobox.

Is there a recommended way of preventing return in a combobox from saving the form?

I would try something in Common.js but don't want to reinvent the wheel or have unintended consequences. Thanks. Jonathan3 (talk) 21:26, 12 September 2025 (UTC)

How to use #formredlink via a Lua module

I can't get this to work but imagine it would be easy if I could just copy an example that works. I've been trying frame:callParserFunction but can't get it to work. Thanks. Jonathan3 (talk) 23:57, 13 September 2025 (UTC)

It might be easier to just replicate the logic manually, like:

local title = mw.title.new(pageName)
if title.exists()

Yaron Koren (talk) 14:00, 15 September 2025 (UTC)

tokens appears to follow links for presenting values

In a form, I like people to add their name via a form. The property "Hat Name Autor" is of type text.

{{{field|Autor|input type=tokens|size=90|delimiter=;|property=Hat Name Autor}}}

What is does is that on first edit it allows to add you name, e.g, "John Doe". If that page does not exist it gets created with

{{#if:
 {{{Autor|}}}
 |von {{#arraymap: {{{Autor|}}} |; |@@@@ |[[@@@@]]<span style="display: none">{{#formredlink: target=@@@@ |form=AutorSeite |create page }}</span>
 | und  }}<br><br>
}}<nowiki/>

On that author page "John Doe," one could add, e.g., M.A., which in return displays "John Doe, M.A." for that page.

Now, when I go to the original page where I added "John Doe", the form automatically presents the value "John Doe M.A. (John Doe)" instead of the entered "John Doe", and upon saving, I get "John Doe M.A. (John Doe)" as the new value.

I have also seen this if I use pages from namespaces (values from namespace=), i.e., instead of the page name token presents the combined form of page name and display title. I am unsure if other input types are affected.

To cut it short, Page Forms appears to be no longer usable for pages with differing page titles. Is there something that can be done about this?

• MediaWiki 1.43.3
• Page Forms 6.0

This did not happen on MediaWiki 1.39 with earlier versions of Page Forms.

-- [[kgh]] (talk) 16:09, 23 September 2025 (UTC)

Sorry about that - I just checked in what I think is a fix, here. Yaron Koren (talk) 00:52, 25 September 2025 (UTC)

Thank you for providing the code change that I have tested with current master of Page Forms. However the problem described is still there. "John Doe M.A. (John Doe)" is still shown on form edit and even if I remove this reenter the correct value Page Forms will still start to show "John Doe M.A. (John Doe)" for the next form edit. [[kgh]] (talk) 16:50, 25 September 2025 (UTC)

Just to clarify - does the "display name (actual name)" syntax show up in the generated wikitext, or just in the form? It is indeed supposed to show up that way in the form (though whether that's a good idea is a matter for discussion) - but if it that's how it's saved in the wikitext, that's clearly a bug. Yaron Koren (talk) 17:31, 25 September 2025 (UTC)

Yes. Prior to the edit the wikitext is just "actual name". The form shows "display name (actual name)" and after saving the wikitext gets changed from "actual name" to "display name (actual name)".

Since the property is of type "Text" I do not expect anything else than the plain value what was stored, even if some display name is sticking around for that page. The stored value is in a sense unrelated to the page. The only relation is that it was stored on that page.

If the property is of type "Page" it would indeed be cool to see either the "display name" or "display name (actual name)" and get only the "actual name" stored in wikitext. [[kgh]] (talk) 18:11, 25 September 2025 (UTC)

Oh, I didn't notice that the property was of type "Text". Okay, this sounds like two bugs in one - although they might be related. This might be a problem with SMW handling specifically, which would make it hard for me to debug, since I don't think I have access to an SMW-running wiki. Yaron Koren (talk) 18:31, 25 September 2025 (UTC)

It also happens if no property is involved, e.g., if I do |values from namespace= instead of |values from property=. Here SMW is not involved at all. -- [[kgh]] (talk) 18:44, 25 September 2025 (UTC)

Oh, man... testing it out with "values from namespace" uncovered a variety of bugs - I'm not sure I had ever tried "values from namespace" with pages that have display titles before. I just checked in fixes for the issues I found. Hopefully these improve the handling on your wiki as well - I doubt they will fix the problems you are seeing with "property=", but who knows. Yaron Koren (talk) 21:57, 25 September 2025 (UTC)

Regrettably neither |values from namespace= nor |values from property= are fixed. I now tried the combobox input type but the error is the same. I though having a page title differing from a page name is quite common on non-WMF wikis. -- [[kgh]] (talk) 17:16, 26 September 2025 (UTC)

That's unfortunate, especially since I can no longer reproduce any of these problems. Creating a Phabricator ticket might be the best approach at this point, so more people can look into it. Yaron Koren (talk) 20:46, 26 September 2025 (UTC)

It is not just unfortunate; it is an epic disaster for Page Forms. Anyhow, I just saw that Display Title is enabled for the wiki. I will test without it being invoked and see if things start to work. Perhaps this extension intercepts Page Forms. -- [[kgh]] (talk) 07:35, 29 September 2025 (UTC)

I still wonder which change in MediaWiki triggers this problem in Page Forms. Anyhow, I ended up creating a Lua module that takes whatever Page Forms saves and sets the intended value. I feel like doing the wrong thing for the right reason, but I was unable to come up with another solution. -- [[kgh]] (talk) 16:05, 17 October 2025 (UTC) PS The issue is unrelated to using the DisplayTitle extension.

parameter uploadable no longer works

After bringing in the display title-related fixes, uploading files via forms no longer works (MW 1.43.3 PF 6.0.2), i.e., the icon keeps spinning, and one does not get to the upload form:

Uncaught TypeError: can't access property "webkit", jQuery.browser is undefined
    adjustFrameSize PF_popupform.js:95
    handleLoadFrame PF_popupform.js:640
    handlePopupFormLink PF_popupform.js:791
    jQuery 2
PF_popupform.js:95:8 
JQuery
  dispatch
  handle

-- [[kgh]] (talk) 07:43, 29 September 2025 (UTC)

Yikes! Thanks for pointing that out. I wonder how long this has been a problem... anyway, I just checked in what I think is a fix for it. Yaron Koren (talk) 22:57, 29 September 2025 (UTC)

Okay, I figured out the issue: this problem actually happened due to a change to the file jquery.browser.js in Page Forms 6.0.2 - which means that it's a very recent bug (thankfully). I'll have to figure out what the ideal long-term solution is, but for now things seem to be working again. Yaron Koren (talk) 22:59, 1 October 2025 (UTC)

I am a bit late to respond. Correct, this started with 6.0.2. There is still an issue that I did not have before. With a wiki setting $wgBreakFrames = true;, which I do for all wikis, it is still no longer possible to do regular uploading. One needs to either switch to simple uploading or additionally set $wgApiFrameOptions = 'SAMEORIGIN';. Setting $wgEditPageFrameOptions = 'SAMEORIGIN'; is no longer good enough. -- [[kgh]] (talk) 16:01, 17 October 2025 (UTC)

Alright, good to know - feel free to add something to the documentation (maybe here) about it. Yaron Koren (talk) 16:16, 17 October 2025 (UTC)

I was thinking that you will probably add wgApiFrameOptions to the code base, as you already do with wgEditPageFrameOptions? Still, this can indeed be documented. -- [[kgh]] (talk) 16:20, 17 October 2025 (UTC)

Oh yes, I forgot about that. So are both needed now, or just $wgApiFrameOptions? Yaron Koren (talk) 16:22, 17 October 2025 (UTC)

In any case one needs $wgApiFrameOptions. I am not 100% about $wgEditPageFrameOptions since I am unsure if Page Forms overrides $wgEditPageFrameOptions = 'DENY'; if set in "LocalSettings.php" below invoking Page Forms. If it does not $wgEditPageFrameOptions is no longer needed. -- [[kgh]] (talk) 16:28, 17 October 2025 (UTC)

I believe the best approach is to remove $wgEditPageFrameOptions from the code and not add $wgApiFrameOptions. Changing these settings is a conscious decision that wiki system administrators need to make on their own. This is also how it is done for other extensions, such as UploadWizard. -- [[kgh]] (talk) 09:19, 19 October 2025 (UTC)

HTML "pre" tag within multi-instance template field?

I have no problems with pre tags in normal Cargo fields, but within multi-instance template fields I get "UNIQ" errors when using "pre" or "syntaxhighlight" tags. Is there any way round this? Thanks. Jonathan3 (talk) 20:22, 4 October 2025 (UTC)

P.S. Just noticed that the "tt" tag works fine, but I'm still interested in the answer. Jonathan3 (talk) 20:23, 4 October 2025 (UTC)

Deprecated: str_replace(): Passing null to parameter

Setup

• MediaWiki 1.43.5 (0699f46)
• Page Forms 6.0.3 (8324bda)
• PHP 8.2.29 (apache2handler)

Issue

When creating a class one get these deprecation warnings:

Deprecated: str_replace(): Passing null to parameter #1 ($string) of type array|string is deprecated in /../w/extensions/PageForms/specials/PF_CreateClass.php on line 81

Deprecated: str_replace(): Passing null to parameter #3 ($subject) of type array|string is deprecated in /../w/extensions/PageForms/specials/PF_CreateProperty.php on line 37

-- [[kgh]] (talk) 16:41, 17 October 2025 (UTC)

Sorry about that - I think I just fixed this here. Yaron Koren (talk) 14:29, 22 October 2025 (UTC)

Special:MultiPageEdit fails to add multiple new rows

Environment: MediaWiki 1.44.2, PHP 8.1.33, Page Forms 6.0.3, Cargo 3.8.4

If you try to add multiple rows, it writes all data only to the last new row's page.

Steps:

1. Visit Special:MultiPageEdit page for a template
2. Click Add Row button twice to insert 2 new rows
3. Fill out cells for both rows for 2 different pages
4. Click plus (save) button for the first new row
5. BUG 1: Inserts the data of row 1, but uses page title of the 2nd new row (verify at Recent Changes in a new tab).
6. Click plus (save) button for the 2nd new row
7. BUG 2: Overwrites the previous data by updating page title of row 2 with data of the 2nd new row (verify at Recent Changes in a new tab).
8. Refresh Special:MultiPageEdit and see only 1 row added

This occurs for any number of new rows. If you add 5 rows, they all save to the 5th row's page and overwrite each other.

You have to instead click Add row, enter data for that row, click + (save) button for that row, then click Add row and repeat for all other new rows, 1 at a time. This makes copy/pasting from an excel sheet impossible, and manually entered data is lost. This wastes time going through adding a lot of rows then saving them, to realize you only have 1 actually added with multiple edits with data from all the wrong rows. SuperNickno (talk) 18:17, 29 October 2025 (UTC)

Additional issues: If you Add a new row and edit an existing row before saving the new row, the data gets mixed up between the 2 as well. SuperNickno (talk) 01:08, 1 November 2025 (UTC)

This issue can also be found at this Phabricator ticket, if anyone wants to see updates. Yaron Koren (talk) 22:52, 4 November 2025 (UTC)

Think I may have finally figured out the input-type conundrum

It seems that whenever a user:

• clicks on a nonexistent form link on sites supporting PF (e.g. https://constantnoble.miraheze.org/wiki/Form:Sentence_page?action=edit&redlink=1 on my wiki);
• selects the "Create with form" tab above the standard input-prompt message (e.g. https://constantnoble.miraheze.org/wiki/Form:Sentence_page?action=formcreate);
• and proceeds after selecting the (eponymous) template to add in the form...

...then the problem I mentioned in previous correspondence returns: The default "text" menu stays in place no matter what gets chosen as the input type.

However, if they use "Special:CreateForm" directly, type in "Sentence page" as the form name, and add "Sentence page" as the template...then the input types correctly display the right respective menus with each selection (under "Other parameters").

If that isn't an overlooked cross-browser blog, then I don't know what else qualifies. To @Yaron Koren: Maybe you can look into resolving/addressing this in a future update? --Slgrandson (talk) 05:24, 4 November 2025 (UTC)

Yikes! It looks like this bug has been in place for a long time. I just checked in what I think is a fix for it, here. Thanks for doing the investigation. Yaron Koren (talk) 14:36, 4 November 2025 (UTC)

Use multiple-instance without creating a second table?

Is it possible to use the multiple-instance function, and multiple values for the same field, without creating a new template/table for those values? I have pages for each country and would like to add URLs with a custom link text to each page, but since the majority of the countries will only have one link, I don't want to store them in a separate table. I hope this makes sense. ~2025-32283-59 (talk) 06:45, 9 November 2025 (UTC)

If you don't want to create a new template and table (I assume you mean Cargo table), I think the only other option is to have dedicated fields. If you're fine with, for example, limiting countries to have no more than three links, you could have fields in the main template called "URL 1", "Link text 1", "URL 2", "Link text 2", "URL 3", "Link text 3". Yaron Koren (talk) 18:41, 10 November 2025 (UTC)

Special:MultiPageEdit does not work for templates containing a colon (:) in their title.

Data is not displayed and editing is not possible. The following message appears in the browser console: Uncaught Error: Syntax error, unrecognized expression: unsupported pseudo: <Template name>Grid Indeedfore (talk) 05:50, 14 November 2025 (UTC)