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)

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)

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)

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)

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)