Extension talk:Page Forms/Archive May to December 2021

How to easily rename a property value ?

I'm using Forms + SMW, and I have lots of pages on which I have set properties like {{Keywords=car,train,plane}}

Each keyword has a corresponding page on its namespace (Keywords:car, Keywords:train, Keywords:plane). Problem is that sometimes I want to rename a property, lets say, replace "train" with "railway".

Presently, I have to rename the page "Keywords:train" to "Keywords:railway", and replace its definition in every page that sets Keywords=train (with the help of more or less efficient search and replace operations with Special:ReplaceText).

Since I guess I'm not the only one who faces this kind of renaming necessities, I was wondering if anyone has a better advice on how to do that? --Varlin (talk) 10:43, 2 May 2021 (UTC)

Okay, you want to rename a property value, not a property. What's the downside of using Replace Text for that? Yaron Koren (talk) 23:43, 2 May 2021 (UTC)

First because using regex is technical and potentially dangerous, so not suitable for daily moderation tasks. Secondly because I never managed to find a correct regex working with ReplaceText. Though this one works out of the box when I test it on regex101.com : \|Keywords=(.*)train(.*)\n. When I try it in ReplaceText it seems it is greedy by default, but if I try to add (.*?) or (?m), I get a Fatal exception. --Varlin (talk) 17:31, 4 May 2021 (UTC)

Sorry, I didn't see your response before. How about just searching for "Keywords=(.*)train"? Maybe the greedy search would be less of an issue there? Yaron Koren (talk) 16:58, 12 May 2021 (UTC)

With Keywords=(.*)train there is a risk that is wrongly match part of a keyword (like "training" idk). But it's ok I found my solution: \|Keywords=(.*)train([\r\n,]). Thanks anyway! --Varlin (talk) 18:04, 12 May 2021 (UTC)

I'm glad you were able to get it working with Replace Text - that's really the only standard way to do a site-wide renaming. Yaron Koren (talk) 02:15, 13 May 2021 (UTC)

I did not found yet a universal regex pattern. It seems the regex engine used is capricious. There are some pages the pattern \|Keywords=(.*)train([\r\n,]) does not match. I also have to use \|Keywords=([^\n]*)train([^\n]*\n). --Varlin (talk) 14:34, 15 August 2021 (UTC)

When using ask request, how to get a link to the namespace ?

I use forms and i enter a username based on "from namespace User" autocompletion in the form. It's ok et i got the link to the user page inside the page. But when i use the ask feature, i have a redlink to an inexistant page because "ask feature" is not inserting the "user:" namepace before the link. Is there any solution to get the right link ? Here is an example :

{{#ask: 
[[Category:xxxx]]
|?User = Utilisateur
|format=datatables}}

You can have the template prepend "User:" to the value, when setting the property. Yaron Koren (talk) 23:44, 2 May 2021 (UTC)

Sorting values from property

in a form, when getting values from a property (thanks to input type=) I need a way to display values in a custom order and not alphabetically. Is it possible ? Nicolas NALLET Wiki-Valley.com (talk) 06:57, 19 May 2021 (UTC)

I don't know of a way to do that, unfortunately. Yaron Koren (talk) 18:05, 19 May 2021 (UTC)

Page forms #queryformlink Button Styling

In previous MW (1.33.1) + PageForms (not sure) version I was using, the button used to be a rectangle shaded with a grey gradient. Now in MediaWiki 1.35.2 I see bluish text with a ">" prefix to the button text.

That's a totally different issue. That's the new display of the #formlink button, which is now using MediaWiki's OOUI JavaScript library. Yes, there are ways to change the display using CSS. Do you not like the current display? Yaron Koren (talk) 17:48, 19 May 2021 (UTC)

Great that it is not a real issue. I really liked the previous button since it looked like a button and took less screen space. If you let me know the CSS class I could try to return the appearance to the previous style. Ideally I would like buttons like the green ones shown. --GMShimokura (talk) 21:20, 21 May 2021 (UTC)

Desired Button Style In Green

Related to this it seems that the OOUI based Button Text cannot include any Styling or inline images.. in my case I need to have the playing card suit images as part of the button text (Spades, Hearts, Diamonds, Clubs).. Is this possible? --GMShimokura (talk) 10:47, 25 May 2021 (UTC)

Not at the moment, I don't think, unless you override the CSS. Yaron Koren (talk) 16:11, 25 May 2021 (UTC)

I am going back to Version 4.6 of Pageforms to get back the shaded grey button style without the icons and the ability to have html/inline image button text. GMShimokura (talk) 01:08, 26 May 2021 (UTC)

Special:MultiPageEdit edits more than only inside the template

Hello Yaron,

I'll write my question again since it might have been overlooked and I think it's severe enough to hinder the usability of the Special:MultiPageEdit page.

I edited a lot of pages through Special:MultiPageEdit today and it's really working wonderful and saving a lot of time. Except for the following thing.

For some reason that I ignore, the variable "cat2" in template "Article ACGM 2" is getting completely deleted when I edit things in "Article" template. Here's what got edited, as an example, when I was working on "def" in "Article" template.

"Funny" thing is that other variables, like classe2 and def2, in the same template, stays untouched, as it should.

Kind regards. (original post from 12:29, 20 March 2021 (UTC)) DSwissK (talk) 09:20, 25 May 2021 (UTC)

I remember looking at this before... this is clearly a bug, but did it have to do with the similarity of the template names "Article" and "Article ACGM 2"? There was, and maybe still is, a problem with Page Forms' parsing of templates whose names are substrings of one another. Yaron Koren (talk) 16:11, 25 May 2021 (UTC)

Hello @Yaron Koren: , thank you for your answer. I tried with lastest Page Forms version (5.2.1), the bug is still happening. Kind regards. DSwissK (talk) 12:12, 7 June 2021 (UTC)

Runquery: Links to pages do not work with format=template

Page Forms / Cargo performs differently if a query is ran from the Runquery option rather than running the query in a standard page.

I have the following setup: Template1 - holds the cargo query that returns me the field values I wish to display. If I run this with format=table then links to pages work correctly. In my case I use format=template, template=Template2. Template2 - holds the code to put the results of the cargo query into a table format. The table formatting is perfect with no issues.

However if I run the query in Template1 using Runquery it does not display any page links in the results. I have tried using CONCAT in Template1 which doesn't work, but my preferred option is to use [[Field1|Field2]] within Template2. Neither option works in Runquery. If I use the characters [[|]] I get a blank column returned. If I use the Template1 in a normal page it works perfectly with the links appearing as expected. It is only when the Cargo Query is called from the Form through Runquery that it does not work. I tried switching to using the ASCII (|[[{{{Field1}}}|{{{Field2}}}]]). If I use the ASCII I get the ([[New0005|Implement April's Law]]) but not the link. Using ASCII doesn't work on a normal non-form page either. Also I've usesd {{!}} instead of pipe in one test. It doesn't solve the issue though

Michaeldakin (talk) 25 May 2021

Hi Yaron, The problem this creates for me is that more and more of my users are on mobiles / notepads. This means that I need to use a template for displaying the results of runquery and of course if you are querying data it is natural to wish to drill down and see further information. I've got about 15 queries which are used for answering questions on policy. I've switched all my cargo queries to table format, but being able to have links to pages on runquery results where a template is used to format would be a massive help. Michaeldakin (talk) 17:30, 12 August 2021 (UTC)

Solved: I put a cargo query in the template called by the 1st cargo query Michaeldakin (talk) 11:55, 14 September 2021 (UTC)

File type and data

Hello again, Yaron! I'm currently using Page Forms on my wiki (alongside Cargo) and I will make my wiki public soon, however, some of the forms have a upload form and I wonder if it's possible to restrict the selection of files to upload to a specific file type (like .mp3 or .gif).

Another question I have related to this is: is it possible to get some "parameters" (such as metadata) for files selected with Page Forms? Currently I have a module tracker player (old PC music) on my wiki and I wonder if it would be possible for the JS "get" some of the file data and input that automatically to the available fields (such as title, length, author, etc.).

Thanks! Lakelimbo (talk) 14:07, 26 May 2021 (UTC)

"mapping property" fails when used on multiple comboboxes

Version: 5.1 (9eeed94) 14:43, 10 February 2021

In a example similar to the following:

{{{field|Combobox1|input type=combobox|values from category=Foo|mapping property=Bar1}}}
{{{field|Combobox2|input type=combobox|values from category=Foo|mapping property=Bar2}}}
{{{field|Combobox3|input type=combobox|values from category=Foo|mapping property=Bar3}}}
{{{field|Combobox4|input type=combobox|values from category=Foo|mapping property=Bar4}}}

Only combobox4 functions properly. CBs 1-3 have Bar4 as their mapping property, which does not tie back to the "Foo" item correctly. When changed from combobox to dropdown, it functions as expected.

Thanks in advance.

---

I'm seeing this problem too. Revansx (talk) 16:56, 1 July 2021 (UTC)

Blank field after uploading media

Mediawiki version 1.35.1. PageForm version 5.2.1. When trying to upload any media from the forms blank page appears (clicking Upload File). Adt it's name does not appear in the field. But the file is loaded. So I have to paste it's name to the field manually. It worked correct in previous version of MediaWiki.

Same problem with MW 1.36.1 and Pageforms 5.2.1. This is a critical bug for a standard user. Megajoule (talk) 06:22, 26 August 2021 (UTC)

Just an update here, upgrading to 1.35.5 resolves this issue for PageForms 5.3.4. 70.105.241.218 15:21, 24 January 2022 (UTC)

Problem with previewing

On any of the forms I have set up, when trying to preview I get "EditPage does not have a context title set" and no preview. Recently upgraded to MW 1.36 and PageForms from git--Cody3647 (talk) 02:47, 4 June 2021 (UTC)

Seems to be some kind of conflict or issue with Code Editor and Page Forms, I've disabled Code Editor and previewing works again. --Cody3647 (talk) 19:39, 14 June 2021 (UTC)

Thank you for that detective work! And sorry about the problem. I just added a note about that to the "Known bugs" page. Yaron Koren (talk) 20:17, 14 June 2021 (UTC)

Menu bar for WikiEditor not showing up

After upgrading to MW 1.35.2 we found also encountered the issue of the missing WikiEditor toolbar / menu bar as it is described here (T284307). Bmulckhu (talk) 08:00, 9 June 2021 (UTC)

I have this issue too. I do not think that there will be a fix. Broken for such a long time now. [[kgh]] (talk) 21:00, 24 September 2021 (UTC)

Multiple with partial form

I have a form that includes a "multiple" template where I try to create flex-boxes. It looks like thisː

{{{for template|Portal flex/Start}}}
<ǃ--contains the starting div for the flex container-->
{{{end template}}}
{{{for template|Portal_flex/Box|multiple|add button text=New box}}}
<ǃ--creates multiple boxes within the flex container-->
{{{end template}}}
{{{for template|Portal_flex/End}}}
<ǃ--conains the ending div for the flex container-->
{{{end template}}}

I would like to have regular text above and below this flex container. For that, I addedː

{{{info|partial form}}}

After adding the "partial form" instruction to the form, I get the problem that each time the form is saved, the existing flex boxes get duplicated, although no boxes were added. So if 3 boxes exist, after saving the form, I suddenly have 6 boxes. Is there any way to avoid this or do I need to take the "partial form" part out of the page which would mean the boxes can only be displayed at the beginning of the page? --MLRodrigue (talk) 09:18, 10 June 2021 (UTC)

"Partial form" functionality never worked that well, and it was actually removed completely from Page Forms a few weeks ago. Unfortunately there's no good way, given Page Forms' parsing, to have free text at both the top and bottom of the page; you'll have to choose one. Yaron Koren (talk) 16:59, 11 June 2021 (UTC)

Textarea too wide

Hi Yaron, I have a minor responsiveness issue happening with textareas using rows= and autogrow. Css classes are used to make sure that they are 100% wide and no wider than 100%, but on mobile views the textarea extends its allotted space, forcing a horizontal scrollbar for the entire screen, which is ugly. Apparently, Page Forms overrides the width setting with a value set to "auto" (perhaps because of this). One solution on the user end is to force width:100% with !important, but maybe there's a more elegant solution. Cavila 18:42, 16 June 2021 (UTC)

Same here. [[kgh]] (talk) 21:01, 24 September 2021 (UTC)

"Multiple" function not working

Hi! I reported this bug on Phabricator here, but since it hasn't been addressed yet, I hope you don't mind me putting it in here as well.

Currently, the "multiple" parameter does not work -- it makes the template form disappear on the form page. Removing the "multiple" parameter does make it work, but that does not have the functionality of "multiple" forms. This function has been really helpful for our wiki, so I hope it gets fixed soon. Thank you! Kiwibasket (talk) 17:21, 21 June 2021 (UTC)

Special:RunQuery generating invalid http-requests?

In an otherwise perfectly functioning wiki (1.34) with PF v5.1, using Special:RunQuery occasionally provides clients with a "400 Bad Request" response from the server. In trying to understand this seemingly random behavior, we have confirmed that A) the "400 Bad Request" is generated from our Haproxy front-end, and B) Haproxy is notoriously strict [1] about the adherence to RFC7230 in terms of message parsing and (from the haproxy documentation):

This means that invalid characters in header names are not permitted and cause an error to be returned to the client. This is the desired behaviour as such forbidden characters are essentially used to build attacks exploiting server weaknesses, and bypass security filtering.

Sometimes, a buggy browser or server will emit invalid header names for whatever reason (configuration, implementation) and the issue will not be immediately fixed. In such a case, it is possible to relax HAProxy's header name parser to accept any character even if that does not make sense, by specifying this option.

Similarly, the list of characters allowed to appear in a URI is well defined by RFC3986, and chars 0-31, 32 (space), 34 ('"'), 60 ('<'), 62 ('>'), 92 ('\'), 94 ('^'), 96 ('`'), 123 ('{'), 124 ('|'), 125 ('}'), 127 (delete) and anything above are not allowed at all. Haproxy always blocks a number of them (0..32, 127). The remaining ones are blocked by default unless this option is enabled. This option also relaxes the test on the HTTP version, it allows HTTP/0.9 requests to pass through (no version specified) and multiple digits for both the major and the minor version.

Is it possible that PF Special:RunQuery is constructing an http-request in some situations which is not in strict compliance with RFC7231 section 4.3.6? [1]

[1] https://stackoverflow.com/questions/39286346/extra-space-in-http-headers-gives-400-error-on-haproxy

X-frame handling in PageForms

Don't know if somebody encountered this before - couldn't find at least.

In LocalSettings.php, normally one can control iFrame behaviour (on external sites wanting to frame the MediaWiki) setting $wgEditPageFrameOptions. Eg. by setting this to false it's also possible to edit pages via iFrames (which is prevented by MediaWiki default, allowing only reads).

However, this setting seems to be disabled or overridden somehow when I activate PageForms extension. After doing this, the behaviour is as if $wgEditPageFrameOptions would not have been set. Deactivating PageForms, the $wgEditPageFrameOptions behaviour is as expected.

My question is how and where (couldn’t find it anywhere in the code) this happens and if I could configure or at least hack it somehow.

I’m using PageForms 5.2.1. I was installing it using Composer and requiring "mediawiki/semantic-forms-select": "~3.0" which installed also PageForms 5.2.1. Don’t know if this matters; anyway, semantic-forms-select I've never activated so far so it seems not to be related to the above question.

MediaWiki: 1.36.0 SMW: 3.2 PHP: 7.4 Browsers for testing: Firefox, Chrome

Any help would be extremely appreciated.

Best Regards

Lukas

Yes, Page Forms overrides the value of that setting, on this line. I don't know if that line is still needed - it has been there for a long time. Yaron Koren (talk) 14:29, 6 July 2021 (UTC)

Thanks Yaron for clarifying. Should have found this myself but made a stupid mistake when searching the code. Commented out this line and do not see negative side effects so far. Lukas, 8 July 2021

Use Displaytitle or Subpagename in "values from namespace" Parameter?

Hi! I'm currently using Page Forms without Cargo or Semantic on Miraheze. I use the extension primarily for quick infobox creation. I have a namespace called "Platforms" where some pages have subpages. When I use a combobox that gets its values from Platforms, the value I get for subpages is the pagename and not the subpagename (e.g. Sega Genesis/32X rather than just 32X). Is there any way I can have the value (not the mapping) be "32X" while also hiding the "Sega Genesis/32X" option? I've had some ideas for ways I could do this, but I'm not sure if they're possible or feasible:

• Some way of forcefully hiding specific values
• Setting the subpagename be pulled instead of the pagename
• Setting the DisplayTitle to be pulled instead of the pagename

The last option would be to just manually specify each platform or make some kind of workaround for the infobox fields (the infoboxes do some automation to make creating them easier). But before I do that, I wanted to know if there was another option. Sorry if this was poorly explained or formatted, I don't communicate too much on talk pages or the internet in general. Thanks for the assistance. Njsmooth2600 (talk) 13:06, 6 July 2021 (UTC)

With neither Cargo nor Semantic MediaWiki installed, I can't think of any way to do that. Yaron Koren (talk) 15:30, 7 July 2021 (UTC)

Conflict when a transclusion adds another {{#default_form:form-name}}

I have some pages of the type "Collection" (of texts), that have {{#default_form:Collection}}

On them, I'd like to transclude some "Text" pages, that have {{#default_form:Text}}

The issue is that it after the transclusion, if I try to edit the page with "Edit with tabs", it says that the pages uses another form type.

I guess that the tag {{#default_form:Text}}, being transcluded and positionned after the {{#default_form:Collection}}, has precedence.

Do you have an idea of a workaround?

--Varlin (talk) 16:20, 6 July 2021 (UTC)

See the third item here. Yaron Koren (talk) 20:56, 6 July 2021 (UTC)

Oh yes, thanks, sounds a perfect solution! --Varlin (talk) 21:24, 7 July 2021 (UTC)

Handling of multiple form selections in Special:RunQuery

I use the RunQuery special page for executing #ask queries based on form selections. Within the form, I enable multiple selections based on Listboxes. The task now is how to pass the correct syntax to the #ask query from the template.

Multiple selections for filtering properties need to be separated by || in an #ask query. I could solve this using the #arraymap parser, like this (where "Measure Type" is a property and "field_measuretype" is passed from the form and is a string like "A_value, B_value" as I did not change the standard delimiter in the form):

{{#ask:
...
other filtering conditions
...
{{#arraymap:[[Measure Type::{{{field_measuretype|}}}]]|,|x|x|{{!}}{{!}}}}
...
printout properties
...

This works.

What I'm struggling with is to do something similar with the printout properties. I want to produce a query like

{{#ask:
...
some filtering conditions
...
|? A_value
|? B_value

as A_value, B-value are properties themselves. To do this, I need to translate the comma delimiter sent from the form into: |?

Unfortunately, I just don't manage this - tried everything, also using a seperate template wich just delivers the |? string., like this:

|? {{#arraymap:{{{field_measuretype|}}}|,|x|x|{{PrintoutDelimiter}}}} 

where "PrintoutDelimiter" is the said template just delivering |?. (the |? at the start of this line is needed for the first printout property)

It seems that somewhere during the parsing process the |? is swallowed and does not arrive at the #ask query.

I hope this is understandable - any help greatly appreciated. It would also already help to know how I can catch the explicit #ask query how it is sent to the engine, to see what's in there. I know that I can use format=debug but this only gives information about the filtering properties, not the printout properties.

Apart from this issue, I also want to say that I'm quite happy with using PageForms as it provides the features I need at the moment.

MediaWiki: 1.36.0 SMW: 3.2 PF: 5.2.1 PHP: 7.4 Browsers for testing: Firefox, Chrome

Lukas

This sounds like a Semantic MediaWiki question, really - you want to display a query within a template. The fact that the template call is being generated by a form is not that relevant to the issue. So I would ask in some SMW forum. Yaron Koren (talk) 20:50, 5 August 2021 (UTC)

I have to click the "Save page" button twice

Exactly as the title says, clicking it once does nothing, clicking again (regardless of time between clicks) works. Not a major issue, but somewhat annoying nonetheless. Njsmooth2600 (talk) 20:13, 5 August 2021 (UTC)

What version of Page Forms and MediaWiki are you running? And does this happen with every form? Yaron Koren (talk) 20:50, 5 August 2021 (UTC)

Here's Suggest how to fix it

Unable to embed wiki pages that use form fields or runQuery

I'm trying to embed a page from our wiki that uses a runQuery in another website, but I keep getting the refused to connect error. I tried $wgEditPageFrameOptions = "SAMEORIGIN"; and adjusting $wgBreakFrames, but it still doesn't work. Any thoughts? Thank you! -Emilio Madrigal

Sorry, I don't know. Yaron Koren (talk) 02:38, 6 August 2021 (UTC)

#forminput Error XXX is not a valid form ?

I used this parse function

{{#forminput:form= Formclass|button text=New Form Class}} .

It shows the form, but it will hit the error message: Formclass is not a valid form even though I can use it from Special page Forms.

Any mistake that I have make ?

Just to be clear: do you have a page called "Form:Formclass" on your wiki? (And is it really called "Formclass", or is that a placeholder?) Yaron Koren (talk) 03:01, 10 August 2021 (UTC)

Yes, I have a page called"Form:Formclass" . It can be accessed from here https://tbpedia.org/demo/index.php/Form:Formclass

Okay, I see it - but that #forminput call seems to be working fine. Did this problem go away? Yaron Koren (talk) 14:38, 15 August 2021 (UTC)

for template tag: is display=table mandatory in 1.36?

Am I right that in 1.36 you must add

display=table (or spreadsheet or calendar)

to for template tag with multiple?

I mean - this code would print nothing:

{{{for template |Person |add button text=add more |embed in field=Everyone[Person] |multiple }}}

No, you don't need to set a display. If you look in the browser console, do you see any JavaScript error there? Yaron Koren (talk) 03:02, 10 August 2021 (UTC)

But look at this condition. If $tif->getDisplay returns nothing, no field would added, so nothing would printed (and $tif->getDisplay have no default value). --Anysite (talk) 11:59, 10 August 2021 (UTC)

Here's a suggest how to fix. --Anysite (talk) 13:35, 10 August 2021 (UTC)

I understand that that code seems suspicious, but actually TemplateInForm::addField() only needs to be called if there's some kind of automated display of the fields; otherwise the storage is not necessary. Maybe that method should be named better or something. Yaron Koren (talk) 13:54, 10 August 2021 (UTC)

That's not just the code, that's a bug we have just yesterday: the "add more" not displayed until we add display=table to the wikitext.

What version of Page Forms are you running? And do you see any JS errors in the console? I don't know if the original question was yours. Yaron Koren (talk) 21:44, 10 August 2021 (UTC)

Using REL1_36 branch. no JS error - the html just won't printed. My guess the code coused the bug maybe removed in master branch - see here. And yes, the original question is mine. --Anysite (talk) 05:07, 11 August 2021 (UTC)

The REL1_36 thing might be the issue - I would try switching to the latest code. Yaron Koren (talk) 18:05, 11 August 2021 (UTC)

Unable to hide fields when using the |hidden parameter + display=spreadsheet

I would like to use the spreadsheet-style editing of a multiple-instance template, but there are several fields that collect data in the background and should not be shown to the user. When I use the |hidden parameter for a field, it still shows up in the spreadsheet. Is this a known issue?

MW version: 1.35.0 PageForms version: 5.2.1 (85927bc)

That does sound like a bug... although another option is to simply keep those fields out of the form definition altogether. I think PF will then ignore those fields in the page. Yaron Koren (talk) 15:24, 16 August 2021 (UTC)

TinyMCE not working with PageForms

I'm having problems when I have a form with a free text box that specifies editor=tinymce

My setup:

Mediawiki 1.35.3

PageForms 4.9.5

TinyMCE 1.1

On any forms where the free text specifies editor=tinymce, that text area opens as a plain text input box with no toolbars, and the text showing raw wikitext markup.

This problem is not present in an older setup with the following versions:

MediaWiki 1.33.0

Page Forms 4.9

TinyMCE 0.3

Since I have no idea if the problem lies with TinyMCE or PageForms, I posted something on the other extension talk page as well.

Any ideas on the cause of this? I appreciate any help!--Lost Student (talk) 23:20, 19 August 2021 (UTC)

Can you open the browser console and see if there's a JavaScript error there? Yaron Koren (talk) 03:02, 20 August 2021 (UTC)

There are several warnings related to deprecated jquery calls (and a few other warnings) but no errors.--Lost Student (talk) 07:06, 21 August 2021 (UTC)

Please refer to TinyMCE extension talk page. I think a fix is included in the latest release 1.1.1 DuncanCrane (talk)

Is it just me, or is this a Miraheze issue?

Hello again. Filing a new case here, because...

On my recently-(re)launched creative-venture wiki (recall my struggles with form subpages on the original ByetHost iteration), creating Page Forms is now hit and miss—no thanks to several hangups that have put the launch of its next form on hold for the time being.

1. If you're using Special:CreateForm on mobile, pressing "Add" after supplying the name and template to be used has no effect, and you're looped back to the beginning.
2. Back on the desktop interface, adding the name and template successfully goes through--but once you select an input type other than "text", the "Other parameters" sections are immediately disabled, and you can't unhide them with the little "[+/-]" button on the top left. Javascript issues, I assume? Or maybe this began with last month's update?

Honorable mention: When one hits "Preview" after specifying the input options, the resulting output is occasionally scrambled up in places—i.e. the wrong parameter titles are in the right positions, and the wrong options in the wrong fields. For example, a duplicate "Added on" header (in what I'm trying to launch) takes hold in the "EN" (for English) field section, and the settings for a certain text field land in another that never had any in the first place. (This sort of thing also happened when I was on Referata ages ago.)

To @Yaron Koren: Any idea what's really going on at this point? And can you supply an ETA for a possible fix?

P.S. Thanks for coming up with the "MultiPageEdit" feature, but in future, there should be a variant for page-title selection (because too many uses of a form's parent template will bog things down even on desktop systems, the way it's currently set up [i.e. editing all pages using the template]). While we're on the subject, how about introducing a "MultiPageCreate" counterpart?

P.P.S. See also my recent filings at Extension talk:DynamicPageList3 (a separate utility), which could really use a good deal of attention as the original developers/maintainers have apparently been AWOL in recent months. --Slgrandson (talk) 23:06, 25 August 2021 (UTC)

To @Yaron Koren: Bumping this filing per Miraheze T8382 from this weekend. If you have any time on your hands soon, feel free to check. --Slgrandson (talk) 20:40, 6 December 2021 (UTC)

Sorry about the problems, and the long delay. That second issue - which seems to be by far the biggest one - was indeed a real bug, and I wish I had looked into it sooner. I just checked in a fix for it. I hope to look into the other issues as well. Yaron Koren (talk) 17:20, 14 December 2021 (UTC)

Creating a Template with Special:CreateTemplate throws ArgumentCountError from PF_CreateTemplate.php L337

I'm getting an error when trying to add a new template using the Special:CreateTemplate page added by the PageForms extension.

[YSdN4MJyReBx7rxUuytKjgAEwg8] /index.php?title=Special:CreateTemplate ArgumentCountError from line 195 of /<redacted>/htdocs/extensions/PageForms/includes/PF_Utils.php: Too few arguments to function PFUtils::printRedirectForm(), 10 passed in /<redacted>/htdocs/extensions/PageForms/specials/PF_CreateTemplate.php on line 337 and exactly 11 expected

Luckily (and strangely), adding templates and forms using the Special:CreateClass page works just fine.

I would be happy to submit a bug report to Phabricator if this is really a bug and not something I'm somehow causing :-)

Thanks! Igorabsorto (talk) 08:35, 26 August 2021 (UTC)

Sorry about that! This was a bug added in about a week ago. I just checked in a fix for it. Yaron Koren (talk) 17:30, 27 August 2021 (UTC)

Rendering links on pages created with Form

Hello, I'm searching for a way to render links in the final output of pages created with a Form.

My template 'parameters' and 'display' are as follows:

{{#template_params:
Body
|URL (label=Source URL)
|Subject (label=Category/Subject)
|Region (label=Country/Region)
}}
{{#template_display:_format=sections}}

This results in a nice page with all the expected sections and their values. The only issue is that the values are not clickable.

If I add this to my template, outside the {{#template_display=}} call, I will have the clickable content I wish to have in the resulting page:

* URL: {{{URL|}}}
* Subject(s): {{#arraymap:{{{Subject|}}}|,|x|{{#formredlink:target=x|form=Subject|}}}}
* Region: {{#arraymap:{{{Region|}}}|,|x|{{#formredlink:target=x|form=Region|}}}}

I have also tried adding the #arraymaps inside the #template_display, like so, with no luck:

{{#template_display:
_format=sections
|URL={{{URL|}}}
|Subject={{#arraymap:{{{Subject|}}}|,|x|[[x]]}} 
|Region={{#arraymap:{{{Region|}}}|,|x|[[x]]}} 
}}

Most example source codes I'm seeing are defining tables in their Template instead of relying on the parser functions #template_params and #template_display to customize data display. Is this the way to go? Am I missing something here? Should I create individual templates for each section field just to have clickable links?

Thanks!

Igorabsorto (talk) 09:23, 26 August 2021 (UTC)

You can of course simply display the values manually, instead of using #template_display; but if you are using Cargo, and you have a Cargo table declared for that template, and the relevant template fields have Cargo fields of type "Page", then #template_display should display the links correctly. Yaron Koren (talk) 17:32, 27 August 2021 (UTC)

Bug combobox with a number

If I start a word with a number in the combobox, there is an ERROR the next time I load it. It is strange, the case does not always apply. But often.

Uncaught Sortable: `el` must be HTMLElement, and not [object Undefined]

Josua Koenig (talk) 15:19, 18 September 2021 (UTC)

What version of Page Forms are you using? Yaron Koren (talk) 02:35, 20 September 2021 (UTC)

The latest one: 5.2.1

Please help me, I have no idea what else to try. Josua Koenig (talk) 19:48, 21 September 2021 (UTC)

I can't reproduce this problem - my guess is that this issue has been solved already. I would recommend upgrading to the very latest Page Forms code, if that's not what you are using already. Yaron Koren (talk) 03:03, 23 September 2021 (UTC)

Sorry, another one about 'values dependent on'

Hi,

I have been over all the posts related to 'values dependent on' on the archives and even though there are a lot of them I still could not solve this. Most of the solutions found for the topics are related to SMW (perhaps because most posts are pretty old) but this parameter does also work with regular Mediawiki, right?

What I'm trying to accomplish here is rather simple, I have a Form called "PostForm" and an equally named Template. The PostForm is used to add new pages to the wiki, one of its fields is 'Country' and the other is 'Region'. The 'Region' field should show the regions (states, provinces, regions...) depending on the Country selected. I have a test page that uses the Template and have a few regions, however I always get 'No matches' on the combobox. Below are the relevant parts of each of this pages.

Template:PostForm

<noinclude>
{{#template_params:
Body
|URL (label=Source URL)
|Subject (label=Category/Subject)
|Country (label=Country)
|Region (label=Region)
}}
{{#cargo_declare:
_table=Articles
|Body=Text
|URL=URL
|Subject=List (,) of Page
|Country=List (,) of Page
|Region=List (,) of Page
}}
</noinclude>
<includeonly>
{{#cargo_store:_table=Articles}}


===Source URL===
{{{URL}}}

===Subject(s)===
{{#arraymap:{{{Subject|}}}|,|x|{{#formredlink:target=x|form=Subject|}}}}

===Country===
{{#arraymap:{{{Country|}}}|,|x|{{#formredlink:target=x|form=Country|}}}}

===Region===
{{#arraymap:{{{Region|}}}|,|x|[[x]]|\s}}

{{{Body}}}

[[Category:Articles]]
{{#arraymap:{{{Subject|}}}|,|x|[[Category:x]]|\s}}
{{#arraymap:{{{Region|}}}|,|x|[[Category:x]]|\s}}
</includeonly>

Form:PostForm

{{{for template|PostForm}}}
{| class="formtable"
! Body: 
| {{{field|Body}}}
|-
! Article origin URL: 
| {{{field|URL}}}
|-
! Category/Subject: 
| {{{field|Subject|input type=listbox|values from category=Subjects|existing values only|}}}
|-
! Country: 
| {{{field|Country|input type=listbox|values from category=Countries|existing values only|height=25px}}}
|-
! Region: 
| {{{field|Region|input type=combobox|values dependent on=PostForm[Country]}}}
|}
{{{end template}}}

Test page

{{PostForm
|Body=test
|URL=https://test.io
|Country=Brazil
|Region=Acre, Alagoas, Rio de Janeiro
}}

Any help is appreciated, thanks in advance!

15:17, 21 September 2021 (UTC)Igorabsorto (talk)

"values dependent on" works with SMW, and it works with Cargo, but unfortunately it doesn't work with neither, i.e. with regular categories - it could, but it doesn't. I think that is the issue you are seeing. Yaron Koren (talk) 15:42, 21 September 2021 (UTC)

Thanks for the quick response, Yaron. I didn't mentioned Cargo (I didn't know it was needed for "values dependent on" to work). However, I'm using Cargo with this Template/Form, I have edited the section containing the Template content in my original post above so it includes the cargo declaration. Hopefully you can spot something quirky on what I have there :) Igorabsorto (talk) 11:36, 22 September 2021 (UTC)

Okay, that's good to know. There may be two issues here: first, "values dependent on" only works if both inputs are of type "combobox", unfortunately. It's possible, also, that "values dependent on" won't work when using "values from category"; I'm not sure about that. In general, though, I don't think it makes sense to have this much use of categories, when you are already using Cargo; it's better to just have one category per page, and do all other data storage within Cargo. (The same would be true when using Semantic MediaWiki.) Yaron Koren (talk) 17:23, 22 September 2021 (UTC)

Well, still no go, even changing both to "combobox" and not using "values from category". Anyway, the tip about storing and querying everything from Cargo instead of relying so much on Categories was great, thanks a lot! Igorabsorto (talk) 13:11, 24 September 2021 (UTC)

Oh, sorry, I just looked again at your template definition and realized that both "Country" and "Region" can hold a list of values. In that case, neither one should be have input type "combobox", since that can hold one value. But this seems like a strange setup anyway - there will be a list of countries, and a list of regions, but no way to know which region corresponds to which country. What I would recommend instead is having a multiple-instance template in the form, which has "Country" and "Regions" fields, where "Country" can only hold one value. I don't know if "values dependent on" would work in that case either, but it seems like a more logical structure. Although maybe I don't fully understand your setup. Anyway, I'm glad it's working better with fewer categories. Yaron Koren (talk) 14:08, 24 September 2021 (UTC)

Is it possible to set size of Infobox?

I have created Template/Form/Category using 'Class a class'. But I see the Infobox is kind of big. It takes about 80% of the page.

• Is it possible to adjust the size of the Infobox?
• Is it possible to set the position of Infobox? For example, Right/Left/Center/Top/Bottom.

Thanks, Bruce

---

I found the .css file and change the size. extensions/PageForms/skins/PF_templateDisplay.css

Page Forms subcategory selection field

Hi,
For example, I have a category of Animals. Subcategories Of Cats, Dogs and etc. The project participants want to add a page of "Sphinx" breed Cats not by creating a page by write hand, but by filling out a form.
So I need to create a form separately for Cats, separately for Dogs (the parameters of the values are the same, such as, for example, "breed height", "breed color", etc.) or can I create it in "Animals" and there they choose which subcategory the page will fall into?
I tried, but everything is displayed and shown until it comes to subcategories. Whatever version of the code I wrote in the form, after saving the page, it is still placed in the Animals category, but not in the subcategory.
If there are 100 animals, should I make 100 forms ? I thought that in the form you can make an item and select a subcategory (via tree-a tree of categories), as in the example here
Or:Template

<includeonly>
{{#arraymap:{{{Categories|}}}|,|x|[[Category:x]]}}
</includeonly>

Form

{{{for template|TestCat}}}
'''Category:''' {{{field|Categories|input type=tree|top
category=TestROOT|mandatory|height=200}}}
{{{end template}}}

I also tried the option as in the example here and Template
Yesterday I tried to make various options all day, but these codes and with the correct prescribed values for them do not display anything in the subcategory line ( the line is also not displayed in the page preview) and do not refer the page to the subcategory and save it in the category "Animals" . I need to make 100 forms for 100 subcategories? Or maybe I'm writing something wrong? It doesn't give out any errors, maybe a bug.... (?) Please help me figure out how this really works?
Data:
MediaWiki 1.35.0-rc.0
PHP 7.4.23 (litespeed)
Semantic Bundle 4.0.0
Semantic Drilldown 2.1
Semantic Extra Special Properties 2.1.0
Semantic MediaWiki 3.2.3
Semantic Forms Select 3.0.0
Page Schemas 0.6
Page Forms 5.2-alpha (290eccb)

Hi!

Yes, you don't need multiple forms for that, you could use only the Animal form. For this you should define the Template and the Form with the fields you want, let's say "Type of Animal" where the people could choose if they want to input a Cat, a Dog or a Whale, and based on that other fields defined by you would get displayed. You may find useful to have a look at this example, you will see that for the field type in this form there are multiple possibilities of fields that will get displayed depending on the user's choice. Hope that helps, it is surely a bit challenging at first, but dive deep in the docs and you shall get the hang of it - more or less, I'm still struggling with some parts myself :-) Igorabsorto (talk) 13:07, 24 September 2021 (UTC)

Return value of Parser::getTitle() must be an instance of Title, null returned

Setup

• MediaWiki 1.35.0
• PHP 7.2.24
• Semantic MediaWiki 3.2.3
• Page Forms 5.2.1

Issue

[1f86e5749173294303dcdb2f] [no req] TypeError from line 1007 of /../w/includes/parser/Parser.php: Return value of Parser::getTitle() must be an instance of Title, null returned

Backtrace

#0 /../w/extensions/PageForms/includes/PF_FormUtils.php(473): Parser->getTitle()
#1 /../w/extensions/PageForms/includes/PF_FormPrinter.php(937): PFFormUtils::getFormDefinition(Parser, string, integer)
#2 /../w/extensions/PageForms/specials/PF_RunQuery.php(88): PFFormPrinter->formHTML(string, boolean, boolean, integer, NULL, NULL, NULL, boolean, boolean)
#3 /../w/extensions/PageForms/specials/PF_RunQuery.php(28): PFRunQuery->printPage(string, boolean)
#4 /../w/includes/specialpage/SpecialPage.php(600): PFRunQuery->execute(string)
#5 /../w/includes/specialpage/SpecialPageFactory.php(635): SpecialPage->run(string)
#6 /../w/includes/specialpage/SpecialPageFactory.php(693): MediaWiki\SpecialPage\SpecialPageFactory->executePath(Title, RequestContext, boolean, MediaWiki\Linker\LinkRenderer)
#7 /../w/includes/parser/Parser.php(3144): MediaWiki\SpecialPage\SpecialPageFactory->capturePath(Title, RequestContext, MediaWiki\Linker\LinkRenderer)
#8 /../w/includes/parser/PPFrame_Hash.php(253): Parser->braceSubstitution(array, PPFrame_Hash)
#9 /../w/includes/parser/Parser.php(2887): PPFrame_Hash->expand(PPNode_Hash_Tree, integer)
#10 /../w/includes/parser/Parser.php(1556): Parser->replaceVariables(string)
#11 /../w/includes/parser/Parser.php(651): Parser->internalParse(string)
#12 /../w/includes/content/WikitextContent.php(374): Parser->parse(string, Title, ParserOptions, boolean, boolean, integer)
#13 /../w/includes/content/AbstractContent.php(590): WikitextContent->fillParserOutput(Title, integer, ParserOptions, boolean, ParserOutput)
#14 /../w/extensions/SemanticMediaWiki/includes/ContentParser.php(161): AbstractContent->getParserOutput(Title, integer, ParserOptions, boolean)
#15 /../w/extensions/SemanticMediaWiki/includes/ContentParser.php(128): SMW\ContentParser->fetchFromContent()
#16 /../w/extensions/SemanticMediaWiki/src/MediaWiki/Jobs/UpdateJob.php(197): SMW\ContentParser->parse()
#17 /../w/extensions/SemanticMediaWiki/src/MediaWiki/Jobs/UpdateJob.php(137): SMW\MediaWiki\Jobs\UpdateJob->parse_content()
#18 /../w/extensions/SemanticMediaWiki/src/MediaWiki/Jobs/UpdateJob.php(94): SMW\MediaWiki\Jobs\UpdateJob->doUpdate()
#19 /../w/extensions/SemanticMediaWiki/src/SQLStore/Rebuilder/Rebuilder.php(239): SMW\MediaWiki\Jobs\UpdateJob->run()
#20 /../w/extensions/SemanticMediaWiki/src/Maintenance/DataRebuilder.php(470): SMW\SQLStore\Rebuilder\Rebuilder->rebuild(integer)
#21 /../w/extensions/SemanticMediaWiki/src/Maintenance/DataRebuilder.php(383): SMW\Maintenance\DataRebuilder->doUpdateById(integer)
#22 /../w/extensions/SemanticMediaWiki/src/Maintenance/DataRebuilder.php(222): SMW\Maintenance\DataRebuilder->rebuildAll()
#23 /../w/extensions/SemanticMediaWiki/maintenance/rebuildData.php(198): SMW\Maintenance\DataRebuilder->rebuild()
#24 /../w/maintenance/doMaintenance.php(107): SMW\Maintenance\rebuildData->execute()
#25 /../w/extensions/SemanticMediaWiki/maintenance/rebuildData.php(294): require_once(string)
#26 {main}

[[kgh]] (talk) 20:59, 24 September 2021 (UTC)

Reported with task T291734. [[kgh]] (talk) 09:44, 25 September 2021 (UTC)

Apparently fixed in master. Will be released with the next version of Page Forms. -- [[kgh]] (talk) 19:29, 27 September 2021 (UTC)

Default text for section

Hi,

I would like to add a default text to sections that can then be tweaked a bit every time a page is created using the form. Default values seem to only be available for inputs, not for sections. Is there a way to make this work?

Thanks in advance!

DavidPape (talk) 12:28, 1 October 2021 (UTC)

ID to value relation in Page Forms text field

Hi,

I want to build some ID to value relation in Page Forms and SMW. First idea would be to use subobjects. The subobject contains a property with a variable value and a property with a unique fixed value (the ID). The generated article should only call the template with the fixed value property but the editing with the form should always list the belonging variable values (using the remote autocompletion switch in a text with autocomplete field). Example:

{{#subobject:- |Has fixed value=Foo |Has variable value=Bar}}

Field in form autocomplete to value ‘Bar’ but the template is called with ‘Foo’

Subobject changes to

{{#subobject:- |Has fixed value=Foo |Has variable value=Baz}}

Editing the article with the form should now display ‘Baz’ in the autocomplete field

Is it possible to realize something like this with Page Forms? Any hint is appreciated.

Franz Schoenberg (talk) 12:20, 7 October 2021 (UTC)

I'm not sure I understand what you're trying to do here. Is the #subobject call part of a multiple-instance template? Yaron Koren (talk) 12:59, 7 October 2021 (UTC)

Hi Yaron, thank you for your reply. The whole problem is related to translations. An article links to a translation table with several thousand options. Each translation has a unique identifier in this table. In the setup I try to build, someone add an article using a form with autocompletion on the translations. Later a misspelling in the translation get corrected. All articles should automatically update in this situation. I solved this by adding the identifier to the autocomplete string so far. But in this scenario an edit with the form will result in a misspelled preset value. Franz Schoenberg (talk) 14:28, 7 October 2021 (UTC)

Are you using multiple-instance templates (if you know what those are)? Yaron Koren (talk) 14:51, 7 October 2021 (UTC)

Yes I use multiple-instance templates Franz Schoenberg (talk) 06:08, 8 October 2021 (UTC)

I just solved it using the "mapping template" setting (overlooked it in the past), thank you very much. Franz Schoenberg (talk) 07:32, 8 October 2021 (UTC)

Preview of Forms not working when $wgRawHtml=true;

Hello,

There seems to be an issue with PageForms and the Manual:$wgRawHtml setting. When $wgRawHtml=true; is enabled previews when using forms give the following error message:

Sorry! We could not process your edit due to a loss of session data.

Because "Wiki" has raw HTML enabled, the preview is hidden as a precaution against JavaScript attacks.

If this is a legitimate edit attempt, please try again. If it still does not work, try logging out and logging back in, and check that your browser allows cookies from this site. 

Code Editor is disabled.

The message only appears when using forms to create or edit a page. Logging in and out hasn't helped me and cookies are enabled for the wiki.

Best regards

Does anyone encounter the same issue? Or has someone figured out a fix?

AID-PMBD (talk) 13:52, 29 November 2021 (CET)

Filter content of a Dropdown based on previous selection

Hi, I'd like to have a Dropdown's values filtered, based on a previous selection (for example, a previous Dropdown). Is it possible? Thank you. --Carloposo (talk) 09:20, 26 October 2021 (UTC)

It's not possible with dropdowns, but it is possible with the "combobox" input, using "values dependent on". Yaron Koren (talk) 18:23, 26 October 2021 (UTC)

Inconsistency of Dropdown css/layout

Hello Yaron, I have noted a layout inconsistency of the new ooui dropdown of PageForms, please check the pictures below. The first picture shows the standard ooui layout, the second how the dropdown appears on a create form page. Is that happening only on my wiki or is an issue with css ? It appears to be related with border, font-size and line-height. (Thomas)

correct

wrong

This doesn't happen for me; see here, for instance. Does it happen for you in multiple skins? It could be an issue with one skin in particular. Or maybe there's some custom CSS and JS on your wiki that is messing things up. Yaron Koren (talk) 15:05, 27 October 2021 (UTC)

Customizing Display of Individual Multiple Instance Handles/Buttons

I've got a form with 2 multiple instance template elements. I'd like to remove display of the add/remove/move button-handle thingys on ONE of them. I'm able to generally customize their display using Extension:CSS and something like {{#css: td.instanceAddAbove, td.instanceRemove, td.instanceRearranger, input.multipleTemplateAdder {display: none; } }} but I'm curious to know if there's a way I could apply different rules for each set of instances. This might be more of a css question (though I'm super weak there, so any pointers would be helpful).

We sometimes have data structures that clearly need multiple-instance templates, but occastionally the ability to add/remove them in the form is NOT what we want (we'll preload some instances with a #formlink query string and don't want any more/less instances than we make). Thanks! - Lbillett (talk) 01:54, 11 December 2021 (UTC)

I think you could put a <div> or <span< tag around the entire "for template...end template" bit in the form definition, and add a "class" attribute to it, and if that works then you could just modify that particular set of elements in the CSS. Although I have to note that an unmodifiable number of instances seems strange... but I don't know what your exact use case is. Yaron Koren (talk) 15:42, 14 December 2021 (UTC)

Oooo, so it might work? I tried mucking about with it but I don't think I understand css enough to do the proper references (I went to make an example in the smw sandbox but it appears to be offline for a bit). So, if I encapsulate some of the form definition in something like a <div class="nobutton">, what might I put in the css statement? Something like {{#css: nobutton.td.instanceRemove {display: none; } }} I think? Thanks. - Lbillett (talk) 16:52, 17 December 2021 (UTC)

"div.nobutton td.instanceRemove" might work. Yaron Koren (talk) 17:46, 17 December 2021 (UTC)

IT WORKED! I added div.nobutton td.instanceRemove, div.nobutton td.instanceAddAbove, div.nobutton td.instanceRearranger, div.nobutton input.multipleTemplateAdder {display: none; } to my css call and it took the buttons/handles off the multi-instance template only where the field with holds-template was encapsulated by the nobutton div. This is awesome. I know it sounds like a weird use-case, but this allows us to pre-populate a dynamic set of information into a muliple-instance set of fields and not allow removal/adding of items that are expected to be there. The approach helps reduce the number of fields/parameters in the form/template for elements that have repeating structure but are subject to random changes in the future. I should probably do a video about it or something... Cheers. Lbillett (talk) 13:56, 17 January 2022 (UTC)

Mapping documentation needs clarification about remote autocompletion

The mapping function for input fields work just fine in my test environment. After it came to production I recognised some strange effects if the number of options go above the number of the local autocompletion parameter. After some research it seems that not a single mapping option is compatible with the remote autocompletion. In my opinion this should be clearly stated in the documentation. Franz Schoenberg (talk) 13:55, 17 December 2021 (UTC)

Run Query - do you want to leave page.

Hi,

Since Miraheze upgraded to the latest version of MediaWiki (MediaWiki 1.37.1 Upgrade: 18 December 2021), I get the leaving unsaved page message everytime I run a forms query:

Or I suppose it could be this 5.3.1 (installed 10 December 2021) version of page forms causing the issue?

Best regards,

Michaeldakin (talk) 21:31, 19 December 2021 (UTC)

Oh, somehow I never noticed that before... I just checked in a fix for this problem. Yaron Koren (talk) 17:04, 21 December 2021 (UTC)

Sorry for my very late reply. Was off doing Christmassy things. Excellent news. Many thanks Michaeldakin (talk) 16:36, 5 January 2022 (UTC)