Extension talk:Page Forms

VisualEditor adding <references /> tag to text area

In one form, I have multiple textareas, each of which specify VisualEditor as the editor. I've found that if any of those textareas have <ref> tags, then upon editing the page with action=formedit, a <references /> tag is inserted at the bottom of that textarea (below the <ref> tag).

This occurs even if there is a <references /> tag (or a {{Reflist}} template) in the free text/bottom area of the page. This results in a footnotes list within the page section that corresponds to that textarea--not at the bottom of the page as desired.

The undesirable <references /> tag gets inserted any time somebody tries to edit the page using formedit.

Is there a way to disable VisualEditor from inserting the <references /> tag? Does anybody else experience this problem? Thanks in advance!--Lost Student (talk) 01:21, 1 June 2024 (UTC)

I didn't know VisualEditor/VEForAll did that, and I don't know how to disable it - hopefully someone here has more information.

By the way, what version of MediaWiki are you running? Yaron Koren (talk) 20:50, 3 June 2024 (UTC)

This is what I've got:

MediaWiki 1.39.5

|PHP 8.1.28 (fpm-fcgi)

MariaDB 10.4.34-MariaDB-1:10.4.34+maria~deb10-log

ICU 65.1

Lua 5.1.5

Pygments 2.11.2

VisualEditor 0.1.2

VEForAll 0.5.1 (7588b05) --Lost Student (talk) 06:08, 4 June 2024 (UTC)

---

BTW Yaron Koren, is this still the case?

Unfortunately, only one input within the form can have WikiEditor associated with it, due to a limitation in the WikiEditor extension.

For the form where I am having this problem, there is only very basic formatting needed so I'm trying to figure out if alternatives to VisualEditor would be worth it to solve the extraneous <references /> tag problem. I kind of wanted to avoid the hassle of installing TinyMCE but maybe that's what I gotta do.-- Lost Student (talk) 23:10, 4 June 2024 (UTC)

I have no idea if that WikiEditor problem still exists. It would be good to know! Yaron Koren (talk) 12:55, 5 June 2024 (UTC)

Combobox to act like dropdown

I have a form with different input types including comboboxes and dropdowns. The problem with dropdown is that it looks like a standard HTML <select> and doesn't get the same styling (height, padding, font, icon, etc.) as comboboxes and other input types. I know I can style the select dropdown with CSS, but it's tricky and doesn't look the same in all browsers.

I tried to display the dropdowns as comboboxes with "existing values only", but I want all options to appear when clicking on the input, without the user having to remove the text of the selected option.

Is there a way to remove the autocomplete function from a combobox, or alternatively, force the dropdown to use the same OOUI format as a combobox, with cross-browser compatibility? Tahoma403 (talk) 05:19, 4 June 2024 (UTC)

It's true that it would be better if all the input types had the same styling. The whole thing is a little tricky right now because OOUI is somewhat on its way out, being replaced by Codex. There's a task in place to convert all the Page Forms inputs - those using HTML, OOUI, etc. - to use Codex. Until then, I don't know what the best way is to accomplish what you're trying to do. I would think it's easier to change the dropdown input type to use OOUI, rather than get comboboxes to be able to mimic dropdowns. Yaron Koren (talk) 13:48, 5 June 2024 (UTC)

Protect Form namespace

I try to protect the form namespace from editing with the mediawiki method :

$wgNamespaceProtection[SF_NS_FORM] = ['edit-form'];

But I get an error that say that SF_NS_FORM is undefiend constant. (I also try the PF_NS_FORM constant)

Is it possible to protect the form namespace with this method or not ? 132.166.177.50 08:08, 5 June 2024 (UTC)

Well, SF_NS_FORM is definitely no longer defined, but PF_NS_FORM unfortunately gets defined only after LocalSettings.php finishes loading - it can be used in extension code, but not in LocalSettings.php. Probably the easiest solution is to just use 106 instead - it's not ideal, but it's probably fine. Yaron Koren (talk) 13:49, 5 June 2024 (UTC)

That's what I've done and it seems to work. Jonathan3 (talk) 22:35, 11 October 2024 (UTC)

Protect special pages with lockdown

I'm trying to protect Page Forms special pages with a lock extension with similar code: $wgSpecialPageLockdown['Forms '] = [ 'sysop' ];

This code doesn't work but I don't know if that's because 'Form' isn't the real alias of the page or if it's just not possible.

If it's possible, where can I find the list of aliases? 132.166.177.50 09:11, 6 June 2024 (UTC)

I don't know if the Lockdown extension can be used to lock down special pages from other extensions (as opposed to from core MediaWiki) - I hope so. In any case, you can find the aliases here. Yaron Koren (talk) 11:45, 6 June 2024 (UTC)

Making a field with autocompletion mandatory in form creation

In creating a form, I would like a field to have input type with autocompletion and at the same time be mandatory. If I select both options and create a page with the form, if I also leave the field blank it creates the page and just gives me a warning. If I choose input type without autocompletion (e.g., text), and select mandatory this does not happen: if I create a page using the form and leave the field blank, then the page is not created and "cannot be blank" appears under the field. I would like the same thing to happen with input type with autocompletion. Is there a way to do this?

PaoloPedinotti (talk) 07:23, 25 June 2024 (UTC)

I've got a field like {{{field|fieldname|input type=tokens|mandatory}}} and it works all right - autocompletion works, but also it refuses to save the page if the field is blank. Jonathan3 (talk) 22:27, 11 October 2024 (UTC)

Where in the code, do you get the autocompletion for a property ?

I'm trying to list on my properties pages, all the values possible for a given property, I have tried this code (for the property "Type d'événement", that has 30k+ usages) :

{{#arraydefine: my.array | {{#ask: [[Type d'événement::+]] |mainlabel=- |headers=hide |?Type d'événement |limit=10000|searchlabel= }} |, | print=list, sort=asc, unique }}

and this code :

{{#ask: [[Type d'événement::+]] |headers=hide |?Type d'événement |limit=10000|format=valuerank }}

but both of those solutions don't work, they are very slow and can't scale up to properties that have tens of thousands of usages.

So I tried coding my own extension to copy the way you do it in js and php, but I did not understand where you do it and how you do it.

Because, for exemple, I have an advanced search form that uses a combobox for "Type d'événement" and when I drop down the list of possible values, everything is there in an instant. It's like the possible values are stored somewhere in a list and I can't find it.

(I use semantic mediawiki and not cargo) Aphfug (talk) 13:18, 25 June 2024 (UTC)

There are two relevant functions: PFValuesUtils::getAllValuesForProperty() (which gets all values for a property), and PFAutocompleteAPI::getAllValuesForProperty() (which gets all property values that match some substring). I assume the first one is more relevant to you. Yaron Koren (talk) 03:06, 26 June 2024 (UTC)

Why is mapping template=template name done in such a convoluted way?

Why does it need a hidden input element? You can save the amount of data sent by just having each option's value attribute be different from its content. 87.120.102.74 16:17, 14 July 2024 (UTC)

I'm not sure I understand the question, probably because I barely remember how any of the "mapping" functionality is implemented! But if you want to try your hand at simplifying the code, feel free - I would be happy to accept such a patch. Yaron Koren (talk) 01:14, 15 July 2024 (UTC)

Mandatory and existing values seem to not work when using input type combobox

I'm writing to report some issues regarding form creation in the PageForms extension.

- Mandatory parameter seems to not work when using input type combobox. On "Create a form", if I add a template and for a field I set Input type: combobox and mandatory, then I save the form and create a page with that form, the page still get saved. If I do the same with input type text (creating a form, adding a template and for a field setting input type: text), the page is not saved and a message "cannot be blank" is shown.

- Existing values only seems to not work when using input type combobox. If I do the same above and I select "existing values only", the page still is saved even if enter a field value which is not in the list (For example, if I select values from category: person (which has possible values "italians", "french") and then, when creating the page I enter the value "spanish"), then the page is saved. PaoloPedinotti (talk) 09:05, 16 July 2024 (UTC)

I'm not seeing either of those problems. The second of those is actually more unexpected - because I would expect, with "existing values only", that the input would immediately become blank if you typed in a different value and then clicked outside of that input. My guess is that there is some JavaScript error that is preventing the combobox JS from working correctly. Can you look in the browser console to see if any JS errors appear on the form page? Yaron Koren (talk) 01:42, 17 July 2024 (UTC)

I checked the browser console while creating the form and a page with the form and no issue was raised. Also tried updating my MediaWiki version to the latest and nothing changed: now I'm using MediaWiki 1.42.1, SMW 4.2.0 and PageForms 5.7.2. Are there any other possible reasons why I'm seeing the problem while you aren't? PaoloPedinotti (talk) 08:14, 22 July 2024 (UTC)

I can't think of any. By the way, does "mandatory" work for other input types? I'm especially curious about "tokens". Yaron Koren (talk) 14:26, 22 July 2024 (UTC)

I just gathered a few additional pieces of information about the issue, and my previous description didn't capture what actually happens. It seems like "mandatory" is not set when an input type different from the default one is chosen. This can be seen just by looking at the form text: |mandatory does not appear in that case. A workaround would be to change the default type so that it is the same as the input type I want to use, but it's not really clear how default type is chosen. PaoloPedinotti (talk) 13:51, 23 July 2024 (UTC)

Sorry for the delay; I missed this before. I'm not sure I understand this. Are you saying that the input is not mandatory when "mandatory" does not appear in the form definition? That would be true, of course, but it seems unlikely that that's what you're saying. Yaron Koren (talk) 04:29, 30 July 2024 (UTC)

No, what I was saying is that mandatory does not work when an input type different from the default one is chosen. PaoloPedinotti (talk) 14:52, 1 August 2024 (UTC)

Okay, I got confused when you talked about the form text. So, just to be clear: you have a form input that would not normally be a combobox, but you have both "|input type=combobox" and "|mandatory" in its "field" tag, but then the input is not actually mandatory when you use the form. Is that the case? And if so, which other input types have you seen this happen with? Yaron Koren (talk) 16:18, 1 August 2024 (UTC)

Is there a way to support using Wikidata as a lookup service for Page_Forms?

Is there a way to support using Wikidata as a lookup service for Page_Forms?

Use case: someone is filling in a form and it automatically suggests a relevant Wikidata item

Worked example: When completing a STARDIT report, it would save the Wikidata ID and display the label

More info about STARDIT for context:

1: https://wikimedia.org.au/wiki/STARDIT_and_Wikimedia_Australia

2: Standardised Data on Initiatives – STARDIT: Beta Version Jacknunn (talk) 06:30, 18 July 2024 (UTC)

Hi Jack, here is the documentation you probably overlooked. If you need something more customisable, then maybe the use of the External Data extension (documented on the same page) is worth looking into. Cavila 06:59, 18 July 2024 (UTC)

Amazing, I had overlooked that - thank you @Cavila :) Jacknunn (talk) 03:45, 30 July 2024 (UTC)

autoedit removes all fields from template

After upgrading MW to 1.39.8 (from 1.35) and Page Forms to 5.7.2 (from 5.4) noticed that autoedit functionality is broken (worked fine in the previous configuration).

After running autoedit all fields which were not referred to in querystring are removed from the template.

We observe that behavior in all cases:

• changing only one field value (the simplest possible case)
• changing only one field value and adding subobject with a few fields

Any suggestions how to solve the problem would be welcome. .... for now it seems that we need to go back to 5.4 Mourawi (talk) 06:59, 18 July 2024 (UTC)

Yikes, that problem has been around for a while (since version 5.7). Thanks for letting me know about it. I just checked in what I think is a fix, here. Yaron Koren (talk) 20:23, 19 July 2024 (UTC)

Is this part of REL1_39 (that is what I was using)? 5.173.176.99 19:40, 22 July 2024 (UTC)

No, it's in the master branch. Yaron Koren (talk) 20:10, 22 July 2024 (UTC)

Thank you for a quick reply! Any plans to

merge the change (fixing significant capability) to current LTS branch (I understand that it’s REL1_39 at this moment )? 2A00:F41:4870:2B55:559B:C561:2797:8430 13:02, 23 July 2024 (UTC)

No - I tend not to modify any of the REL branches, for any of my extensions. (Though I'm always willing to accept patches to any of them.) I recommend you switch to the master branch, which still supports MW 1.39. Yaron Koren (talk) 13:20, 23 July 2024 (UTC)

Ok. Thank you for the explanation. 5.173.176.99 16:03, 23 July 2024 (UTC)

HTML attribute value can not contain a list of values

Setup

• MediaWiki 1.39.8 (6d0b9ef) 2024-08-12T08:41:10
• PHP 8.1.2-1ubuntu2.18 (apache2handler)
• MariaDB 10.6.18-MariaDB-0ubuntu0.22.04.1

After upgrading from version 5.7.2 to 5.8.0, the wiki gets the "HTML attribute value can not contain a list of values" for form editing. Unfortunately, the error log remains silent. Do you know of a change that may have caused the issue since the last release, and is something potentially wrong with it that could be improved? [[kgh]] (talk) 10:17, 16 August 2024 (UTC) PS In the meantime, we will also try to track down the part of the form that is causing the issue.

I have no idea. Yes, if you could figure out what tag(s) are causing the issue, that would be very helpful. Yaron Koren (talk) 15:04, 16 August 2024 (UTC)

We will try to identify what causes the issue. This may take a bit. [[kgh]] (talk) 13:49, 27 August 2024 (UTC)

TypeError: strtr(): Argument #1 ($string) must be of type string, array given

Setup

• MediaWiki 1.39.8 (6d0b9ef) 2024-08-12T08:41:10
• PHP 8.1.2-1ubuntu2.18 (apache2handler)
• MariaDB 10.6.18-MariaDB-0ubuntu0.22.04.1
• Page Forms 5.8.0

Backtrace

from /../w/includes/Html.php(240)
#0 /../w/includes/Html.php(240): strtr()
#1 /../w/extensions/PageForms/includes/forminputs/PF_TextAreaInput.php(273): Html::element()
#2 /../w/extensions/PageForms/includes/PF_FormPrinter.php(2047): PFTextAreaInput->getHtmlText()
#3 /../w/extensions/PageForms/includes/PF_FormPrinter.php(1413): PFFormPrinter->formFieldHTML()
#4 /../w/includes/StubObject.php(120): PFFormPrinter->formHTML()
#5 /../w/includes/StubObject.php(149): StubObject->_call()
#6 /../w/extensions/PageForms/includes/PF_AutoeditAPI.php(944): StubObject->__call()
#7 /../w/extensions/PageForms/includes/PF_AutoeditAPI.php(130): PFAutoeditAPI->doAction()
#8 /../w/extensions/PageForms/specials/PF_FormEdit.php(113): PFAutoeditAPI->execute()
#9 /../w/extensions/PageForms/includes/PF_FormEditAction.php(302): PFFormEdit->printForm()
#10 /../w/extensions/PageForms/includes/PF_FormEditAction.php(32): PFFormEditAction::displayForm()
#11 /../w/includes/MediaWiki.php(542): PFFormEditAction->show()
#12 /../w/includes/MediaWiki.php(322): MediaWiki->performAction()
#13 /../w/includes/MediaWiki.php(904): MediaWiki->performRequest()
#14 /../w/includes/MediaWiki.php(562): MediaWiki->main()
#15 /../w/index.php(50): MediaWiki->run()
#16 /../w/index.php(46): wfIndexMain()
#17 {main}

Here I am also unsure what caused this to show for the form. [[kgh]] (talk) 13:51, 27 August 2024 (UTC)

When do you see this error? Yaron Koren (talk) 14:41, 27 August 2024 (UTC)

I am just passing on the issue. However, it showed when trying to use a form. [[kgh]] (talk) 15:39, 28 August 2024 (UTC)

Alright. Do you know if it's when creating a new page vs. editing an existing page? And do you happen to know the form definition (if it just happens in one form)? If you could link to, or pastebin, the definition, that would be ideal. Yaron Koren (talk) 00:04, 29 August 2024 (UTC)

Editing page with form causes template fields to be removed if they are not defined in the form

Hello, I have an issue which may be related to the one described above in #autoedit removes all fields from template.

I have a template with many fields, and I want some of them to only be edited in "Edit source" mode. Therefore, I have a form to only edit a subset of the template's fields. However, when I edit the page in "Edit with form" mode, and save, all the fields that are not listed in the form with the {{{field|...}}} syntax are removed from the page's source code.

Strangely, if I click "Show changes" before saving, the diff view does not show any fields being removed, which I believe whould be the correct behaviour. However, after saving, much of the page's source code disappears.

I was using Page Forms 5.6.3 with MediaWiki 1.39.5. I upgraded to Page Forms 5.8, but this did not solve the problem.

Thanks! MLWatts (talk) 13:12, 9 September 2024 (UTC)

That's definitely a bug; I don't know when that started happening. For now, I think you can get around the problem by declaring any such a field as "hidden", i.e. putting {{{field|FieldName|hidden}}} anywhere within the {{{for template}}}...{{{end template}}} section. Yaron Koren (talk) 16:45, 9 September 2024 (UTC)

Thanks so much for the feedback, the workaround was effective. MLWatts (talk) 12:39, 10 September 2024 (UTC)

Multiple-Instance Forms Are Blank

After upgrading to SMW 4.2.0 (from 4.1.3) and Page Forms 5.8 (from 5.7), my multiple-instance fields are blank in Form edit mode. If I create/edit the page using the Form, all is well and saves/renders correctly, but invoking the Form blanks out the fields again. If I save at this point, I get my template calls but without any data (so '{{{name}}}' instead of 'name'). Source editing works fine as well, so Page Forms are not populating the existing template data when invoking the Form editor.

Any help would be appreciated. Thanks ~z929669 Talk 00:46, 25 September 2024 (UTC)

Could you link to, or pastebin, or just paste here, the form definition? Yaron Koren (talk) 03:43, 25 September 2024 (UTC)

Date dropdown corrupt

Having upgraded my wiki to 1.39.10 with php 8.2.24 and updated PageForms to the latest version for 1.39 I have some errors.

1. This markup (triple bracket) field|Start date|input type=date(triple bracket) produces a date dropdown that is corrupted. It is partly in English and partly in Turkish. January is Ocak, May is Mayis and June is Haziran.
2. I can also see some erorrs in the php Log that I do not understand. As follows:
3. PHP Deprecated:  htmlspecialchars(): Passing null to parameter #1 ($string) of type string is deprecated in /home/customer/www/wiki.mraths.org.uk/public_html/includes/parser/Sanitizer.php on line 857 PHP Deprecated:  str_replace(): Passing null to parameter #3 ($subject) of type array|string is deprecated in /home/customer/www/wiki.mraths.org.uk/public_html/extensions/PageForms/includes/PF_FormPrinter.php on line 1938 PHP Deprecated:  str_replace(): Passing null to parameter #3 ($subject) of type array|string is deprecated in /home/customer/www/wiki.mraths.org.uk/public_html/extensions/PageForms/includes/PF_TemplateField.php on line 186.

Any Help much appreciated.

Regards

Roger App RogerApp (talk) 07:52, 8 October 2024 (UTC)

Please don't use the REL1_39 branch of Page Forms, which is what I assume you are using - please just get the latest/master version of the code, which still supports MW 1.39. Yaron Koren (talk) 14:04, 8 October 2024 (UTC)

Hi Yaron,

I uploaded to the latest version of the code REL1_42 and cleared the cache but some of the months are still in Turkish. I am also still getting the same depracted errors.

Regards RogerApp (talk) 19:43, 8 October 2024 (UTC)

Please use the master branch, not any of the REL branches. If you're still seeing any deprecation warnings after that, please list them here. For the Turkish/English thing - I'm guessing that it's supposed to be all English. Do you have any idea why some of the months are showing up as Turkish? Did this wiki used to be in Turkish, or something? Yaron Koren (talk) 19:57, 8 October 2024 (UTC)

Hi Yaron,

I uploaded the master and the depracted errors are gone. This has always been an English wiki so not sure why I have three Turkish months! Where is the date picking up its drop down months from? That would be worth me checking. This is not urgent as it is usable but it would be good to fix it. Any other test I can do let me know.

Regards RogerApp (talk) 08:40, 9 October 2024 (UTC)

Hi Yaron,

Looking on Goggle this seems to be associated with SMW localisation efforts and is due to be addressed in November at MediaWiki Users and Developers Conference Fall 2024 see Issue/1533 on GitHub. I am happy to wait for this to resolve in future.

SMW is upto date.

Regards RogerApp (talk) 10:34, 9 October 2024 (UTC)

I'm glad to hear the Page Forms issues are gone! Yaron Koren (talk) 14:28, 9 October 2024 (UTC)

ModSecurity issue on autocomplete on category

Hello, this is a strange one, I guess, and I am not sure this is the right place to post. I have a form with a very basic #forminput configuration:

{{#forminput:form=Autori|autocomplete on category=Autori}}

The autocomplete on category parameter looks like calling something that trigger my modsecurity configuration and I get the following error in the apache log:

[Wed Oct 09 16:56:49.012856 2024] [security2:error] [pid 1733007:tid 140655632258816] [client 2.42.57.15:0] [client 2.42.57.15] ModSecurity: Access denied with code 403 (phase 2). Match of "contains /wp-json/yoast/" against "REQUEST_URI" required. [file "/etc/apache2/modsecurity.d/rules/comodo_free/22_SQL_SQLi.conf"] [line "17"] [id "211540"] [rev "14"] [msg "COMODO WAF: Blind SQL Injection Attack||libmovitprin.it|F|2"] [data "Matched Data: substr found within REQUEST_URI: /mw/api.php?action=pfautocomplete&format=json&substr=%3CWrigh&category=Autori"] [severity "CRITICAL"] [tag "CWAF"] [tag "SQLi"] [hostname "libmovitprin.it"] [uri "/mw/api.php"] [unique_id "Zwa10cqDpTnL@Go6wkMM-QAAABI"], referer: https://libmovitprin.it/mw/index.php?title=Form:Autore

The log is really strange since it seems to be relate to yoast, but I am not an expert in reading log files. Does anyone have any idea about this? Do you think is somehow page forms related?

Thanks in advance for any help! Loman87 (talk) 14:48, 10 October 2024 (UTC)

I forgot to add that without the autocomplete on category everything works fine! Loman87 (talk) 14:52, 10 October 2024 (UTC)

I had never heard of Yoast, but it sounds like Yoast requires, or at least recommends, some kind of security-related configuration that prohibits anyone from making an HTTP request that does not go through Yoast. Is that true? Is that true? If so, hopefully it can be disabled, or modified. Yaron Koren (talk) 17:14, 10 October 2024 (UTC)

Thanks Yaron! I have no idea about how Yoast works, it's something related to wordpress, but on my server I didn't install anything like that. It must be a bad Plesk configuration, which I use to manage my wiki server. Loman87 (talk) 09:22, 11 October 2024 (UTC)

Input type that shows radio/checkboxes plus "Other" text box

I'd like to have an input box that shows a list of potential answers, but also allows the user to type their own answer. I'd be using this in conjuction with Cargo.

It's possible to create a separate "Other" field entirely, but I'd like to be able to have just one Cargo field.

In Cargo terms, I suppose I'm looking for something for "List (,) of String" along the lines of what combobox is for "String". Tokens is nearly what I need. Jonathan3 (talk) 09:26, 11 October 2024 (UTC)

It's an interesting idea - I've had that thought too, but only for single-value fields. How would it work for a multiple-value field, though - wouldn't you need to allow the user to add a potentially endless number of "Other" values? Yaron Koren (talk) 13:29, 11 October 2024 (UTC)

Yes I guess so. For lists it could be like checkboxes + tokens, and for single-value fields it could be like radiobuttons + tokens. Jonathan3 (talk) 14:58, 11 October 2024 (UTC)

But you only want the one for list fields? Yaron Koren (talk) 16:54, 11 October 2024 (UTC)

It would be cool for both. But the combobox does a similar thing for single-value fields. So my initial idea was something new for lists. Jonathan3 (talk) 18:40, 11 October 2024 (UTC)

It's an interesting idea. Presumably it would only really make sense to use this in conjunction with a "values=" parameter, i.e. a semi-fixed set of recommended values, rather than getting the values from previously-entered values for that field, so that every user's "Other" becomes the next user's standard option. I'm curious, though: why do you see "combobox" as a suitable replacement for this sort of interface, while "tokens" is not? Yaron Koren (talk) 19:10, 11 October 2024 (UTC)

It's embarrassing to admit but I had never realised you could use values= with tokens the way you can with a combobox. Does that override autocompletion?

Anyway, in my defence, I still think the checkbox/radiobuttons plus "Other" text box would be nice :-) Jonathan3 (talk) 22:21, 11 October 2024 (UTC)

Well, it's still autocompletion, but it would override the default values from Cargo/SMW. Yaron Koren (talk) 23:06, 11 October 2024 (UTC)

Remember we made it so you can have an text address field linked to a map coordinates field using a feeds to map parameter? Could we do something similar (not the same admittedly) here, where a "checkboxes" input field and a "text" input field both provide values for the same (Cargo) field name? You could do the same for "radiobuttons" + "text" though you'd have to refuse to save the page if both have content. Jonathan3 (talk) 06:50, 12 October 2024 (UTC)

Grey area of multi-instance template is too wide on small screens

It doesn't fit properly into its surrounding div. Through trial and error, this seems to fix it.

table.multipleTemplateInstanceTable {
  table-layout: fixed;
}

td.instanceMain {
  width: 100%; 
}

Jonathan3 (talk) 21:48, 12 October 2024 (UTC)

[SOLVED] Require value to be integer

Is is possible to require that a value for a String (or any) field be an integer? Jonathan3 (talk) 14:53, 14 October 2024 (UTC)

You can use the "regexp" input type for that. Yaron Koren (talk) 17:24, 14 October 2024 (UTC)

That is perfect. I don't know why I'd never noticed that one! Thanks. Jonathan3 (talk) 21:16, 14 October 2024 (UTC)

Embedded template and spreadsheet style editing with show on select parameter

Hi Yaron,

I have a problem solving this issue. I have a form with three templates to store different bibliographic data. Each template is called via the for template tag (link). The first template holds a field ("Opera in più volumi") with the show on select parameter, based on a boolean value; if the user select "sì", another field appears; if the user select "no", the other two templates are called. One of these, "esemplare", has the |multiple|display=spreadsheet parameters set in the for template tag. Everything works fine here and when the page is saved, a table is generated for each row of the spreadsheet. I would like to have all the rows displayed in a single table, instead. If I understood the documentation, to do so I should use the embed template function, is that correct? I followed the instructions but using them break the show on select parameter of the aforementioned field. I hope I have been clear...

Thanks for any help! Loman87 (talk) 16:40, 14 October 2024 (UTC)

I'm not sure if "show on select" can work with "holds template" - I don't know if I've ever tried that. If it doesn't work, one other option (other than fixing the bug) is to have the page query its own data, via Cargo or SMW - which might allow for more flexibility in the display anyway. Yaron Koren (talk) 17:30, 14 October 2024 (UTC)

Thanks Yaron! I tried querying the data calling a #cargo_query via the same template "Esemplare":

{{#cargo_query:

tables=esemplare

|fields=biblioteca,fondo

|format=dynamic table

}}

but I still have three different tables, not one. Is there a parameter to join all together? Loman87 (talk) 20:44, 14 October 2024 (UTC)

Yes - "join on". Although it depends on how the data is structured. Yaron Koren (talk) 23:07, 14 October 2024 (UTC)

"Show select all" doesn't work within multi-instance template

On a form, {{{field|fieldname|input type=checkboxes|list|values=x,y,z|show select all}} does not display the "select all/select none" links, when it is part of a multi-instance template. The same code in the main "for template" part of the form shows those links fine. Jonathan3 (talk) 15:12, 15 October 2024 (UTC)

Just seen this: https://github.com/wikimedia/mediawiki-extensions-PageForms/blob/bf23bd20bd7121fd9f896769a5239d70839dddc7/includes/forminputs/PF_CheckboxesInput.php#L102

:		// @HACK! The current "select all/none" JS code doesn't work
:		// when this input is part of a multiple-instance template, so
:		// if that happens, just don't display those links.
:		// Unfortunately, there's no easy way to know if we're in a
:		// multiple-instance template, so look at the input name - if
:		// it contains "[num][", we can assume that we are.
:		// @TODO - get the JS working in multiple-instance templates -
:		// this will probably require rewriting the checkboxes JS
:		// to some extent, so the relevant part can be called each
:		// time an instance is added.
:

Jonathan3 (talk) 23:21, 16 October 2024 (UTC)

Change color of combobox value text

I have two comboboxes and want to change the input text to red if the values are identical, both on load and when changing one of the input values. From what I understand, the "unique" parameters are only for the same Cargo field, namespace, etc. and cannot be used to compare two different input values. This JS code works, but not when applying it to the Page Form. Is there a better way to alert users of identical values in two comboboxes, or to prevent them from being submitted as such? Tahoma403 (talk) 07:56, 16 October 2024 (UTC)

Maybe something like that code, but using the specific classes/IDs for that form? Yaron Koren (talk) 15:01, 16 October 2024 (UTC)

Redirect on query

How to provide a sort of API for external users, so if they put a volume and page numbers of a book in URL, they will get the wikipage, the name of which is unknown for the user, but generated by query. Like this:

https://en.teopedia.org/lib/Special:RunQuery/Goto_book_page?Goto_book_page[volume]=2&Goto_book_page[page]=45&_run=

Currently the result of such query is a page with the link to the desired wiki-page, but not that wiki-page itself. An example with more details could be found here: https://en.teopedia.org/lib/User:Pavel_Malakhov/test_auto_form

May be there is a way how to put <meta> tag to result page, where we can set redirection? Pavel Malakhov (talk) 01:10, 19 October 2024 (UTC)

I think I asked this question some years ago and unfortunately the answer was no. I was thinking about it again recently, and think maybe the answer is for the external website to use Cargo's API and interpret the results of that, e.g. display a link to the book page if the book is present in the database. Jonathan3 (talk) 22:22, 19 October 2024 (UTC)

You could always create a separate parser function that does a redirect. Yaron Koren (talk) 15:21, 25 October 2024 (UTC)

Do you mean to create an extension? This will involve one in supporting such extension for every MediaWiki update. I thought, if there could be a build-in possibility that I have not noticed.

As for Gargo. It looks like it could only provide the same ability as Special:RunQuery does -- a page with the link to the desired one, without redirecting. So the user still needs to click on that link to go to wanted wiki-page. Pavel Malakhov (talk) 22:59, 26 October 2024 (UTC)

"displayed fields when minimized" not working

This isn't working for me. It still shows every field, not the ones specified. Jonathan3 (talk) 21:15, 24 October 2024 (UTC)

"values from query=" in form tag: syntax

I need a combobox in a form, which takes the values from a query. So, I tried to use the "values from query=" option but without success.

I used:

{{{field|PatternStructure|input type=combobox|values from query=values from query={{#ask: ((Category:FWIN:Sample)) %?Has FWIN:SampleID %format=plainlist %headers=hide %mainlabel=- %valuesep=,}} }}}

any help on the syntax appreciated

KilianLenz (talk) 14:19, 28 October 2024 (UTC)

You definitely shouldn't have "values from query=" in there twice. That might be the whole issue; I don't know. Yaron Koren (talk) 20:46, 28 October 2024 (UTC)

Oh, this was only a copy/past error to the talk window here. I didn't put in the wiki like that, though. But is the syntax like I wrote it, i.e. including the curly braces and ask statement? 2A01:C23:5C9C:4200:358A:7B8:307:252D 22:05, 28 October 2024 (UTC)

Oh, okay. It's been a while since I looked at "values from query", but I think you need to take out the "{{#ask:" and "}}" at the beginning and end. Yaron Koren (talk) 17:05, 29 October 2024 (UTC)

Is it possible for autocomplete on field B to be based on a Cargo query involving the current value of the form's field A?

I don't think "values dependent on" stretches to this. But is there any way? Thanks. Jonathan3 (talk) 21:13, 30 October 2024 (UTC)

Only with "values dependent on". Yaron Koren (talk) 22:43, 30 October 2024 (UTC)

Thanks. I couldn't quite get my head round the description of that one. Was it that the autocomplete shows previous values for the same field on the same form, when some other field of that form had a specific value? Jonathan3 (talk) 01:53, 31 October 2024 (UTC)

That sounds right, yes. Yaron Koren (talk) 02:33, 31 October 2024 (UTC)

Page Form Upload File - Mixed Content HTTPS error.

I've got a mediawiki site setup that we recently turned HTTPS on for. Now when I'm in Page Forms and go to upload a flle in one of the forms I get this error when checking debug/console:

Mixed Content: The page at 'https:/.../Special:FormEdit/Temp_Dispatch?returnto=FE%3AList&reload=1?debug=true' was loaded over HTTPS, but requested an insecure form action 'http:/.../index.php?title=Special%3AUploadWindow&pfInputID=input_8'. This request has been blocked; the content must be served over HTTPS.

I'm still a little bit of a novice with this so if someone could help me figure out what I need to change to get Upload File working again in a form, I'd appreciate it. The form is also a Cargo form, if that makes a difference. Doc224s11 (talk) 11:29, 1 November 2024 (UTC)

I figured out the issue, in case anyone else has a similar problem. The issue was $wgServer still had the address as http://. Once I swapped it to https://. the issue was resolved. Doc224s11 (talk) 12:10, 1 November 2024 (UTC)

Aliases for token suggestions

Moving discussion from Extension talk:Cargo:

Regarding token auto-suggest: One concern I see with a similar feature on a forum I use. People make different tags for synonyms or different spellings of the same word (e.g. "CBT", "cognitive behavioral therapy", "cognitive-behavioral therapy", and "cognitive behavioural therapy"). Different people put different tags for the same thing. I wonder if it'd be possible to have "aliases" for tokens. Where I might store "CBT" as an alias for "cognitive behavioral therapy", so that if I start typing the former, the latter appears in suggestions. And maybe if I submit the former as is, it is equivalent to submitting the latter. (Though maybe not in this case since CBT can be an acronym for many things.)

I don't know how this could be accomplished. Maybe interfacing with a new Cargo table meant just for different tokens. This table would have every token that has been used on any template, along with a "main" boolean column, and an "alias" column linking it to the main token it is an alias of.

Maybe something like this:

ID	Token	Main	Alias
1	cognitive behavioral therapy	1	NULL
2	cognitive behavioural therapy	0	1
3	CBT	0	1

Or maybe this:

ID	Token	Main	Alias
1	cognitive behavioral therapy	1	NULL
2	cognitive behavioural therapy	0	cognitive behavioral therapy
3	CBT	0	cognitive behavioral therapy, cincinnati bell telephone

And Page Forms displays all aliases for tokens that match the typed text. "CB" would suggest "cognitive behavioral therapy" and "cincinnati bell telephone".

And maybe there could be a system for combining tokens into aliases. One could list all current tokens, then "pair" them if they mean the same thing, setting their values in the above table. Dimpizzy (talk) 15:50, 1 November 2024 (UTC)

@Dimpizzy: I've been wondering about this too. Are these values page names? I often have forms with a multi-value page reference, such as a 'tags' field that references pages on the wiki. In that situation, it seems like it could be a good idea to format redirects differently in the autocomplete dropdown and show their target page name (or even switch to a MultiselectLookup, which supports showing a label and description in the dropdown). That doesn't help if your values aren't page names though, because as you say you'd need somewhere else to store the mapping of aliases! Sam Wilson 00:12, 2 November 2024 (UTC)

In my case, I haven't yet decided, as I'm still in the early stages, but I don't think they'll be page names. Just keywords to help search for relevant pages. For example, if it's a page for a research paper about climate change, it might have keywords for "machine learning", "carbon dioxide", "methane", and "fracking". Probably won't want to make whole pages for every possible keyword.

Interesting thought about redirects though!Dimpizzy (talk) 00:19, 2 November 2024 (UTC)

the input type textarea ignores the specification of the maxlength

I have created the following form:

{{For Template|Test}}
{| class="“wikitable”"
! style="“width:30%”" |text:
| style="“width:70%”" |{{field|text|input type=text|maxlength=5|placeholder=Maximum 5 characters (incl. spaces)}}}
|-
! style="“width:30%”" |Textarea:
| style="“width:70%”" |{{field|TextArea|input type=textarea|maxlength=5|placeholder=Maximum 5 characters (incl. spaces)}}}
|}
{{end template}}

Here I check the input maxlength for the input type text and the input type textarea. In the form, I can only enter 5 characters in the text type. In the input type textarea I can enter many more characters. Can I work around this error? 212.77.172.210 10:36, 21 November 2024 (UTC)

I just tried this, and it works fine for me. If you look in the browser console, do you see any JavaScript errors? If not, what versions of MediaWiki and Page Forms are you using, and what browser? Yaron Koren (talk) 14:21, 21 November 2024 (UTC)

Many thanks for the great tip!

The console shows that there are problems with the CSP Header. I will check this further. 212.77.172.210 16:28, 21 November 2024 (UTC)