Extension talk:Page Forms/Archive July to December 2022

_run doesn't populate default values when using #queryformlink

I have a form with a field called "Author" with "default=current user". If I access this form with #queryformlink, my username is automatically filled in the Author field, as expected. However, I still have to click "Run query" to see the results. When I add "query string=_run", the query is executed without populating the Author field. Is this a bug or is there something else I should be doing? Wulfda02 (talk) 21:08, 19 July 2022 (UTC)

That does sound like a bug, yes. Yaron Koren (talk) 13:51, 22 July 2022 (UTC)

Form properties after upgrading from Semantic Forms to Page Forms.

MediaWiki - 1.35.6

PHP - 7.4.25 (cgi-fcgi)

Postgresql - 10+

PageForms 5.4

Upgrading from Mediawiki 1.27;

I have a Special Page query which looks for page properties, most importantly, the Geometry: property; My forms (PF_NS_FORM) are each built off a template. Each page has a relative Template page (NS_TEMPLATE) which contains the Has default form:: which I go through every page with that using a script and adding {{#default_form:}} as outlined in Page Forms (https://www.mediawiki.org/wiki/Extension:Page_Forms/The_%22edit_with_form%22_tab);

However, after doing this, my Form no longer displays the CategoryLinks to some of the properties, most noteably Geometry and DTG (which is a date time thing). All forms before updating the template (and running runJobs.php) query properly and show Geometry but after the template update, it no longer works. Is there another way I should be doing this? Rijvirajib (talk) 04:06, 22 July 2022 (UTC)

Sorry, what do you mean by "no longer displays the CategoryLinks"? Yaron Koren (talk) 13:50, 22 July 2022 (UTC)

Thanks for getting back to me so quickly! In my form using [\[Page has default form]\], I have a property at the bottom [\[Geometry:POINT(some numbers)]\]. I want to query Page Forms form for all properties for that form, including Geometry. This works fine BEFORE I update my Page Form Template and append {{#default_form}} to the bottom so that the form itself will show "Edit with form" when viewing it. However, when I update the Form Template, the properties that I once queried to get Geometry and others like [\[Has DTG:]\] no longer display.

The query to grab all properties for a form/template:

SELECT DISTINCT T1.smw_sortkey AS pname FROM mediawiki.smw_object_ids T1, mediawiki.smw_object_ids T2, mediawiki.smw_di_wikipage page WHERE page.s_id IN (SELECT smw_id FROM mediawiki.smw_object_ids WHERE smw_title IN (SELECT page_title FROM mediawiki.page, mediawiki.categorylinks WHERE cl_from = page_id' AND cl_to = 'Bridge_Assessment' )) AND T1.smw_id = page.p_id AND T2.smw_id = page.o_id ORDER BY pname; Rijvirajib (talk) 15:55, 22 July 2022 (UTC)

Sorry, I still don't understand. Are you putting properties like "Geometry" in the form, or the template? I'm guessing in the template, but if so - does this issue actually have to do with Page Forms? Yaron Koren (talk) 21:57, 22 July 2022 (UTC)

Correct, they are stored in the template. We are trying to discover all the properties used in a particular template. For example, if you create a page form based on a template there are properties generated on the newly created form for the user to populate. We need to get these properties.

We have been using the above database query but since moving to MW 1.35.5 (SMW 3.2.3) we have noticed the query no longer returns back the correct properties. Some are missing (Geometry, DTG, etc.).

Do you know of a way to get these list of page form template properties using an endpoint API (https://www.semantic-mediawiki.org/wiki/Help:API, https://www.mediawiki.org/w/api.php), direct DB query or a using the any of the classes (https://doc.wikimedia.org/mediawiki-core/master/php/annotated.html) ? 2601:191:8400:9E0:30F4:BCF9:8D80:85B4 15:20, 23 July 2022 (UTC)

I don't know, but this does sound like a Semantic MediaWiki, not a Page Forms, question - it seems like this issue would exist even if you were editing pages manually, not with forms. Yaron Koren (talk) 17:35, 24 July 2022 (UTC)

How does PageForms know what properties to use for a category/template(s)? Ckapop (talk) 22:00, 27 July 2022 (UTC)

Do you mean, for example, how it knows where to get the autocompletion values for some field? It parses the template page to see what SMW property (if any) is attached to each template field. Yaron Koren (talk) 22:47, 27 July 2022 (UTC)

Just a small update:

We've identified where Semantic Mediawiki stores form categories. They exist in smw_qi_* tables. Doing a complex query to grab them all worked based off the Category name. Thank you 70.109.152.21 14:28, 30 July 2022 (UTC)

Remote autocompletion when using mapping property

SMW : 4.0.1 // MW : 1.38.1 // PF : 5.4

Hello,

It seems that remote autocompletion doesn't work when using mapping property. Is ther a way to active it ?

Thanks !

Paul LEMPERIERE (talk) 19:33, 23 July 2022 (UTC)

Wrong value displayed using token input type and {{DISPLAYTITLE:...}} magic word

SMW : 4.0.1 // MW : 1.38.1 // PF : 5.4

I use the magicword {{DISPLAYTITLE}} for a page category.

When i feed the list of a token input type with this category, here is what happen :

- The list displayed is the original name of the page

- If i search a word that must be in the alias of the page title, the results filtered are good, like if the alias thas hidden. So the alias is searchable

- When i click on a result to display it, the alias appear in the box !

See here the use case : https://gifyu.com/image/SNlJ7

Is it possible to show the display title in the list of the token input ? Paul LEMPERIERE (talk) 20:04, 23 July 2022 (UTC)

Added it in Phabricator and already suggested a fix (see https://phabricator.wikimedia.org/T329928). YOUR1 (talk) 09:54, 17 February 2023 (UTC)

Prevent resorting of input-type tokens (textarea with autocomplete)

Hej-hej,

is it possible for extension Page Forms 5.1 (SMW 3.2.2) to prevent the resorting or rearrangemet of input-types tokens (former textarea with autocomplete)? My goal is to input words in a (semicolon separated) list but keep the order of input values as it was entered by the user. I found no possibility yet to prevent that reordering when the form is loaded—is it possible and how can it be achieved? Thank you for any help on this. -- Andreas P. 11:48, 24 July 2022 (UTC)

You should definitely upgrade to the latest Page Forms version - I'm not sure this bug has been fixed, but I think it has. Yaron Koren (talk) 17:35, 24 July 2022 (UTC)

How do you create a category (or select an existing one) from a field value on a Page Form in MediaWiki?

I created a form to allow users to input data about scientific topics, references and categories in an organized manner. Problem is, I am unable to automatically categorize the page (by either creating a new category or using an existing one) when a user fills the form with the appropriate category information.

Here is the template page from my Mediawiki site:

<noinclude>
{{#template_params:Summary (label=Topic Summary (In point form, as a numbered list. Include references between <ref></ref> tags.))|User_Category}}
</noinclude><includeonly>
{{#template_display:_format=sections}}
[[Category:Summary Article]]
[[Category:{{#arraymap:|,|@@||}}]]
</includeonly>

Here's my form code:

<noinclude>
This is the "Summary Article" 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=Summary Article}}

</noinclude><includeonly>
<div id="wikiPreview" style="display: none; padding-bottom: 25px; margin-bottom: 25px; border-bottom: 1px solid #AAAAAA;"></div>
=Summary=
{{{section|Summary|level=1}}}

==Category==
{{{field|User_Category|level=2}}}

</includeonly>

I attempted to assign the field value to the category variable `User_Category` in order to create a category in the template page, but was unsuccessful. Any assistance would be greatly appreciated. 114.73.149.245 13:28, 25 July 2022 (UTC)

You should change this line in your template:

[[Category:{{#arraymap:|,|@@||}}]]

...to something more like:

[[Category:{{{User Category|}}}]]

(Assuming the user is only supposed to enter one category, not a list of them.) Yaron Koren (talk) 14:30, 25 July 2022 (UTC)

Yeah, I made the changes, but it still doesn't work as the category information doesn't turn up on the page that is created (I only entered one category). 114.73.149.245 23:21, 25 July 2022 (UTC)

See Topic:Wzwhzgwbn1bv73fw. Jonathan3 (talk) 13:28, 26 July 2022 (UTC)

How do you transclude user input from a form into a page without the section heading?

I have a form that takes user input and creates a page. Unfortunately, the page that is created includes the section heading, which I wish to avoid. I only wish to keep the name of the page, user input and nothing else.

Here is the template page from my Mediawiki site:

<noinclude>
{{#template_params:Summary (label=Topic Summary (In point form, as a numbered list. Include references between <ref></ref> tags.))|User_Category}}
</noinclude><includeonly>
{{#template_display:_format=sections}}
[[Category:Summary Article]]
</includeonly>

Here's my form code:

<noinclude>
This is the "Summary Article" 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=Summary Article}}

</noinclude><includeonly>
<div id="wikiPreview" style="display: none; padding-bottom: 25px; margin-bottom: 25px; border-bottom: 1px solid #AAAAAA;"></div>
=Summary=
{{{section|Summary|level=1}}}

==Category==
{{{field|User_Category|level=2}}}

</includeonly>

The page that is created has it's name on top, then the label 'Summary' as the next heading, followed by the user input. I wish to remove the 'Summary' heading altogether. How do I accomplish that? 114.73.149.245 10:32, 26 July 2022 (UTC)

I think you'd have to replace the {{#template_display:_format=sections}} line and find another way to display the {{{Summary|}}} field. Maybe have it as a field rather than a section? Jonathan3 (talk) 13:33, 26 July 2022 (UTC)

That doesn't work 114.73.149.245 14:02, 26 July 2022 (UTC)

The error I get is "EditPage does not have a context title set" 114.73.149.245 14:03, 26 July 2022 (UTC)

Edit the page (by this I mean any content page you have created using the form) to remove the section heading =Summary= and the text below. Then change the form to have a field instead of a section. Then edit the template to show the summary field. (By the way it's confusing to have a PF field called Summary when wiki pages have a Summary field already.) Note that in the following I've made changes from your original code, so you might have other changes to make.

Form:

<noinclude>
This is the "Summary Article" 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=Summary Article}}

</noinclude><includeonly>
<div id="wikiPreview" style="display: none; padding-bottom: 25px; margin-bottom: 25px; border-bottom: 1px solid #AAAAAA;"></div>
{{{for template|Summary Article}}}
==Summary==
{{{field|Summary|input type=textarea}}}

==Category==
{{{field|User Category|input type=tokens|list}}}

</includeonly>

Template:

<noinclude>
{{#template_params:Summary|User Category}}
</noinclude><includeonly>
{{{Summary|}}}
[[Category:Summary Article]]
{{#arraymap:{{{User Category|}}}|,|@@|[[Category:@@]]|}}
</includeonly>

Jonathan3 (talk) 22:29, 28 July 2022 (UTC)

Uploading a duplicate file

It seems since MW v1.33 we are having issues uploading a duplicate file. We used to be able to ignore warning and choose to upload anyway.

Now there is some code in LocalFile.php that prevents this from working anymore.

LocalFile.php:

if ( $row && $row->img_sha1 === $this->sha1 ) {
   $dbw->endAtomic( __METHOD__ );
   wfDebug( __METHOD__ . ": File " . $this->getRel() . " already exists!" );
   $title = Title::newFromText( $this->getName(), NS_FILE );
   return Status::newFatal( 'fileexists-no-change', $title->getPrefixedText() );
}

This returns an error and we never get the option to ignore the warning and upload anyway like before. Is this a known issue or change? Any workarounds? We tried commenting out the code above and it all seems to work like it used to. Just not sure this is the best decision. Ckapop (talk) 14:15, 2 August 2022 (UTC)

[SOLVED] How to make content of embedded template show as parsed wikitext

When I use the approach in Extension:Page_Forms/Defining_forms#Embedded_templates the embedded template is displayed as unparsed wikitext (e.g. [[Pagename]] instead of Pagename). When I call the same template from a normal content page the wikitext is parsed. It also works when I use the normal method (i.e. not the "embedded templates" method). What am I doing wrong? Thanks. Jonathan3 (talk) 21:59, 2 August 2022 (UTC)

I think I have the answer. It was a new template so I was using the new standard {{#template_display:_format=infobox}}. When I changed to the old way of doing things (writing code to display each parameter separately) the wikitext parsing worked fine. Jonathan3 (talk) 22:12, 2 August 2022 (UTC)

[SOLVED] Get "values from category" to work with category with about 5000 pages

I vaguely remember that there are some extension settings, and something about in-browser vs remote autocompletion, but thought it better to ask here instead of experiment. What would be the best settings for this? Thanks. Jonathan3 (talk) 22:16, 4 August 2022 (UTC)

The standard settings should work fine, with $wgPageFormsMaxLocalAutocompleteValues equal to 100, ensuring that you have remote autocompletion for this input. Yaron Koren (talk) 23:27, 4 August 2022 (UTC)

I have that setting. Not sure about "ensuring that you have remote autocompletion for this input". I have two problems when using {{{field|fieldname|input type=tokens|values from category=categoryname}}}: (1) when it finds something, it highlights it in the long list (e.g. Cheese) but I have to scroll all the way down to select it; (2) some things aren't in the list that I think should be. Jonathan3 (talk) 21:39, 8 August 2022 (UTC)

I should add that it highlights several words (e.g. Cheese, Cheeky, Cheers) but because it still displays the unhighlighted words it's not as easy to find them. I'd expect the unhighlighted words to disappear from the dropdown, leaving only the matching words. Jonathan3 (talk) 23:00, 8 August 2022 (UTC)

It's odd that it's showing non-matching values. Is this viewable on a public wiki? Yaron Koren (talk) 23:21, 8 August 2022 (UTC)

I'll email you. Jonathan3 (talk) 15:42, 9 August 2022 (UTC)

I updated PF to the latest version, at your suggestion, and it all works now :-) Thanks Jonathan3 (talk) 09:54, 10 August 2022 (UTC)

Can't enter just year for date field using Date input type

I used to be able to add, for instance, "2007" in a date field, and leave the day and month fields blank.

I upgraded PF to the most recent version a day or so ago, and now I get the " There were errors with your form input; see below." and "cannot be blank" error messages.

What can I do? Or is this a bug? Jonathan3 (talk) 21:58, 12 August 2022 (UTC)

I assume this is a mandatory date field. I just looked it up, though, and it looks like the code that handles mandatory date fields hasn't changed since 2016 or so. You could certainly argue that mandatory date fields should be allowed to just hold a year, although I think no one has complained yet about the current behavior (before now, that is), for whatever reason. My guess is that there was some JS bug in the handling of this form before, which prevented validation from taking effect, and now, with this upgrade, you're finally seeing the validation happening. The easiest solution for now is to just get rid of the "mandatory" part (although, if the field is always meant to hold just a year value, the best solution is to switch to the "year" input). But for the future, maybe it indeed makes sense to allow just the year - or just year + month, for that matter. Yaron Koren (talk) 15:45, 15 August 2022 (UTC)

Thanks. I definitely think that month/year or just year should suffice for a mandatory date field. Especially as Cargo is set up specially to handle that sort of thing, with the extra "precision" field. Jonathan3 (talk) 17:16, 15 August 2022 (UTC)

Edit summary disappears on page preview

Usually the edit summary remains after a page preview, but with PF if you type an edit summary, then view page preview, the edit summary box is blank. Jonathan3 (talk) 20:19, 18 August 2022 (UTC)

Thanks for letting me know about that - I checked in what I think is a fix for that, earlier today. Yaron Koren (talk) 01:07, 23 August 2022 (UTC)

Query Form | having field that depends on other field text

Hi!

I want to have a Query Form with two fields, one of them will allow to choose "main category" and the other will allow to choose "sub category" (but the sub category should depend on the user choose and don't show everything).

Let's assume I have a Cargo table with subcategories and the Main category choose will be 'select main_category from table' and the sub_category should be 'select sub_category' from table where 'main_category'={user_choose}', this is possible somehow?:)

Koshob (talk) 21:06, 31 August 2022 (UTC)

Yes, I think so - for the first field, you should have something like "input type=combobox|cargo table=table|cargo field=main_category", while for the second field, you should have something like "input type=combobox|cargo table=table|cargo field=sub_category|values dependent on=TemplateName[Field Name]", where TemplateName is the name of this template, and FieldName is the name of the first field. Yaron Koren (talk) 21:56, 31 August 2022 (UTC)

Thanks! Koshob (talk) 18:22, 1 September 2022 (UTC)

[SOLVED] Embed selectable images

Hi!

I'm trying to embed images in a template with Page Forms from a checkbox, I've had a hard time but I've managed to do it by parsing the text and conditioning it.

But I have encountered a problem in Semantic Mediawiki, when I insert the array into the string parsing function the property does not consider that it is being used, which is logical but it does work in the template.

Is there any way to do what I'm trying to do?

Template div code:

<div><span class="ods-iconos">{{#ifexpr: {{#invoke:String|find|{{#arraymap:{{{ODSini|}}}|,|x|[[ODSini::x]]}}|01}} > 0 | [[Archivo:ODS1.png|92px|link=]]}}</span><span class="ods-iconos">{{#ifexpr: {{#invoke:String|find|{{#arraymap:{{{ODSini|}}}|,|x|[[ODSini::x]]}}|02}} > 0 | [[Archivo:ODS2.png|92px|link=]]}}</span><span class="ods-iconos">{{#ifexpr: {{#invoke:String|find|{{#arraymap:{{{ODSini|}}}|,|x|[[ODSini::x]]}}|03}} > 0 | [[Archivo:ODS3.png|92px|link=]]}}</span></div>

Link to the property

Link to a page

Thank you very much JaviRoCultur (talk) 20:57, 19 September 2022 (UTC)

I'm not sure I understand the question, or what this code is trying to do, but my guess is that passing that whole #arraymap call into the module is somehow causing the problems. I would suggest separating the SMW storage from the display - by calling #set in one #arraymap call, and putting regular links in another #arraymap call (the one that gets passed in to #invoke). Yaron Koren (talk) 02:01, 20 September 2022 (UTC)

Thank you very much, you made me realise that simply putting the array outside the function but hidden would make Semantic Mediawiki index it. JaviRoCultur (talk) 20:27, 20 September 2022 (UTC)

Page Forms Internal Error

Hello,

We're seeing the error and stack trace below when attempting to create a new page form. We're using 1.37 version of MediaWiki and Page Forms. We also have Semantic Mediawiki 4.0. PHP version is 7.4.

Any ideas what is causing this?

[ea03a8f552203a1338fa005c] /Special:FormEdit/Paper TypeError: Argument 1 passed to ParserOptions::__construct() must implement interface MediaWiki\User\UserIdentity, instance of StubGlobalUser given, called in /var/www/html/includes/parser/ParserOptions.php on line 1088

Backtrace:

from /var/www/html/includes/parser/ParserOptions.php(1057)

#0 /var/www/html/includes/parser/ParserOptions.php(1088): ParserOptions->__construct()

#1 /var/www/html/extensions/PageForms/includes/PF_AutoeditAPI.php(688): ParserOptions::newFromUser()

#2 /var/www/html/extensions/PageForms/includes/PF_AutoeditAPI.php(968): PFAutoeditAPI->generateTargetName()

#3 /var/www/html/extensions/PageForms/includes/PF_AutoeditAPI.php(121): PFAutoeditAPI->doAction()

#4 /var/www/html/extensions/PageForms/specials/PF_FormEdit.php(103): PFAutoeditAPI->execute()

#5 /var/www/html/extensions/PageForms/specials/PF_FormEdit.php(44): PFFormEdit->printForm()

#6 /var/www/html/includes/specialpage/SpecialPage.php(647): PFFormEdit->execute()

#7 /var/www/html/includes/specialpage/SpecialPageFactory.php(1366): SpecialPage->run()

#8 /var/www/html/includes/MediaWiki.php(314): MediaWiki\SpecialPage\SpecialPageFactory->executePath()

#9 /var/www/html/includes/MediaWiki.php(930): MediaWiki->performRequest()

#10 /var/www/html/includes/MediaWiki.php(564): MediaWiki->main()

#11 /var/www/html/index.php(53): MediaWiki->run()

#12 /var/www/html/index.php(46): wfIndexMain()

#13 {main} Dancabcaltech (talk) 17:33, 26 September 2022 (UTC)

You should switch to the latest version of Page Forms, which works fine with MW 1.37. In general, the "REL" branches of Page Forms - and for that matter, my other extensions - should be avoided. Yaron Koren (talk) 14:12, 28 September 2022 (UTC)

@Yaron Koren thanks for your help. That worked. I'll be more wary of using the REL branches. Dancabcaltech (talk) 22:29, 28 September 2022 (UTC)

Pages in Form NS struggle to render if MediaWiki:Edittools is embedded

That much I've discovered for the past hour and change on my creative-venture wiki. If {{MediaWiki:Edittools}} is placed or detected in any page in the Form namespace, then the page will take several minutes to try rendering the preview before it gives a "504 Gateway Time-out" message in some instances. (Even attempts to start a new page via form--thanks to that embed--go absolutely nowhere.) This does not happen with any other system-message transclusion in the Form NS, nor does this problem occur elsewhere.

For now, the only way out is to comment out the embed (<!-- {{MediaWiki:Edittools}} -->) while editing the form itself. (On the downside, I'll be missing out on a ton of features unavailable in the "wikieditor" toolbar above the textbox--at least where I am.) Either that, or maybe I might as well resort to creating my next FTA (form-dependent) via MW's standard editbox.

To @Yaron Koren: Likely an upstream bug from either the latest update or interference with the latest MW version; I doubt this is a local Miraheze issue.

P.S. Minor edits still can't be saved via form--but as always, that's for another time.

(MW 1.38.4/PF 5.4) --Slgrandson (talk) 09:31, 2 November 2022 (UTC)

On the other hand, this might be a coding issue as pertains my own site--because {{MediaWiki:Edittools}} worked just fine when I tested it out at AVID (formerly Closing Logos). Further investigation/diagnosis pending; might as well take it up to MH Phabricator in due course. --Slgrandson (talk) 10:07, 2 November 2022 (UTC)

To @Yaron Koren: (if you've got some spare time this holiday): This issue might be related to the inclusion of <inlcudeonly></includeonly> in my Edittools, which causes the rendering below the input box on form pages to run amok when the raw code from the MW page is used. Tried removing it minutes ago, but my FTA form's interface still won't load.

Confirmed by MH Phab as an upstream issue last Wednesday (in the words of Universal Omega (talk · contribs), "This seems to be an issue with PageForms and how it parses"), and might as well qualify for "High"/"Unbreak Now!" status (to use two Phab security levels). Maybe I'll have to create a separate Edittools for the Form NS and see how it plays out--or maybe I'll have to open a WM Phab account just to bring up the matter? (Sent from my new Dell Inspiron.) --Slgrandson (talk) 20:21, 24 December 2022 (UTC)

Error: #autoedit cannot be called on pages in the "Books" namespace on this wiki.

Trying to use #autoedit for pages not in the main namespace and always get this error. The same #autoedit is working when using pages in the main namespace. Did I overread something?

{{#autoedit:form=Books|target=Books:testbook|link text=add|link type=link|query string=Book[Authors]+=test1|minor|confirm}}

RacingRalf (talk) 12:44, 8 November 2022 (UTC)

Yes - you need to add the "Books" namespace to $wgPageFormsAutoeditNamespaces. Yaron Koren (talk) 18:54, 8 November 2022 (UTC)

Thanks a lot Yaron!

Custom template display format possible?

Hi Yaron,

Is it possible to define a custom display format for templates? I see that several different display formats can be set with the _format parameter in the #template_display parser function. However, none of the available display formats fits my use-case. Is there a way to customize the template display format, similar to how the output of Cargo queries can be customized with format=template?

Kind regards,
Devaroo (talk) 12:31, 14 November 2022 (UTC)

There's no "_format=template" option, so you'll just have to set the display manually, instead of calling #template_display - which is really not that different a solution. Yaron Koren (talk) 14:15, 14 November 2022 (UTC)

Omg of course. I totally didn't think of that. I guess I somehow forgot that we're still working with regular templates and can style them as such. Thank you for the tip, and for the extension! It's super useful and works as expected. Devaroo (talk) 16:30, 14 November 2022 (UTC)

Sort order for inputs

I have a field {{{field|Credential|property=HasCredential|input type=tokens|delimiter=,|size=40}}}. Property HasCredential has a list of allows value entries that is alphabetically sorted. When I start typing in the input field the options come up as driven by the property, but they are not sorted. I had a similar problem with a field {{{field|Section|input type=listbox|size=19|property=HasSection|list|values from property=HasSection|default=N/A}}} which sorted all but one value correctly. I replaced that one with a manual list but that's obviously not desirable. Is there anything I can do to sort the values alphabetically? I searched the discussion pages and similar things have come up occasionally but I didn't find a solution. Tenbergen (talk) 16:22, 24 November 2022 (UTC)

About @Megajoule's "Uninitialized string offset" above

The error points to line 995 of PF_FormPirnter.php. It seems to happen when Page Forms tags are written without a break, e.g. to prevent wikitext from introducing unwanted line breaks or paragraphs. Something like

{{{info|...}}}<!--
-->{{{for template|...}}}

triggers the error warning, but it can be rewritten as e.g.

{{{info|...}}}<!--
--><span></span><!--
-->{{{for template|...}}}

FWIW!

(P.S. I did see an error warning from the console (ReferenceError: pf is not defined), but I don't think it's related) Cavila 21:43, 24 November 2022 (UTC)

Can confirm.

Error when:

{{{for template|Hinweis neuer Server}}}{{{end template}}}

No error when putting a line break between }}} and {{{. RacingRalf (talk) 08:57, 5 December 2022 (UTC)

Happens since v5.5.1. No error with v5.5. RacingRalf (talk) 08:58, 5 December 2022 (UTC)

What's the error that happens since 5.5.1? Yaron Koren (talk) 13:41, 5 December 2022 (UTC)

Notice: Uninitialized string offset: 55 in /var/www/html/extensions/PageForms/includes/PF_FormPrinter.php on line 995 RacingRalf (talk) 10:14, 6 December 2022 (UTC)

When there's no break between tags? Yaron Koren (talk) 14:01, 6 December 2022 (UTC)

Exactly

It's hard to show here, because this curly brackets get converted. But the example I wrote above produces this error. As soon as there is a line break between "for template" and "end template" the error is gone. RacingRalf (talk) 14:08, 6 December 2022 (UTC)

A whitespace is enough. Doesn't have to be a line break.

Working:

{{{for template|Hinweis neuer Server}}} {{{end template}}}

RacingRalf (talk) 14:10, 6 December 2022 (UTC)

Bilingual forms

Hello,

How can I have forms using two languages depending on the language of the user ? 2001:861:4745:7590:39B5:B7F5:B3EA:3ACC 07:39, 1 December 2022 (UTC)

Use the Translate extension, I guess? Yaron Koren (talk) 18:59, 1 December 2022 (UTC)

Bug in extension/includes/PF_AutoeditAPI.php:setHeaders ?

Hi!

I think I've spotted a problem with this function.
It defines some HTTP headers − I don't know what they are for but that's not the problem −, using without any check or sanitizing, the name of the form and the title of the page. Those two may contains non ASCII characters (especially in French), that are thus passed as is and not encoded, which is apparently forbidden in headers according to the rfc. The characters, if I get it, must be encoded according to rfc2047. The consequence of this is that a chromium based browser of one of our user simply rejects the request (protocol error) when the page's title contains "è". Disabling the faulty http header fixes the problem.

Would it be possible to add proper encoding to those header? Best regards, Raphoraph (talk) 13:43, 4 December 2022 (UTC)

unique not working with combobox

{{{field|Username|input type=combobox|values from property=Username|unique}}}

does not complain, when using a value that already exists.

{{{field|Username|input type=text|values from property=Username|unique}}}

here it's not possible to enter an already existing value

Tested with v5.5 and v5.5.1 RacingRalf (talk) 10:47, 6 December 2022 (UTC)

Frontend: cannot add new field

Adding a new field with any button (which means both "Add field" and "Add another field above this one" are affected) fails because of a TypeError: element.attr(...) is undefined.

I found out that the function is defined in /libs/PF_CreateTemplate.js through the following PowerShell commands (I'm localhosting a test MW 1.39.1 instance with Laragon):

cd C:\laragon\www\MW1.39.1\extensions\PageForms\libs
dir -rec | where {(cat $_.fullname) -match "createTemplateAddField"}

Will there be a fix for this bug soon? --Keyacom (talk) 19:53, 29 December 2022 (UTC)

Wow - the JS in Special:CreateTemplate was indeed broken; I don't know when that happened. Sorry about that, and thanks for letting me know - I just checked in a fix for it. Yaron Koren (talk) 20:47, 29 December 2022 (UTC)

I see that you successfully fixed this. Thank you! --Keyacom (talk) 18:37, 31 December 2022 (UTC)