Extension talk:Page Forms

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

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 : . When I try it in ReplaceText it seems it is greedy by default, but if I try to add   or , 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  there is a risk that is wrongly match part of a keyword (like "training" idk). But it's ok I found my solution:  . 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  does not match. I also have to use  . --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 :


 * 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)

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, 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 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 ( |&#91;&#91;&#124;&#93;&#93; ). If I use the ASCII I get the ( 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)

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:

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)

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)

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

<ǃ--contains the starting div for the flex container-->

<ǃ--creates multiple boxes within the flex container-->

<ǃ--conains the ending div for the flex container-->

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

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)

"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
I have some pages of the type "Collection" (of texts), that have

On them, I'd like to transclude some "Text" pages, that have

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, being transcluded and positionned after the  , 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:}}}|,|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: where "PrintoutDelimiter" is the said template just delivering |?. (the |? at the start of this line is needed for the first printout property)
 * ? {{#arraymap:{{{field_measuretype|}}}|,|x|x|{{PrintoutDelimiter}}}}

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

.

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

(or spreadsheet or calendar)

to for template tag with multiple?

I mean - this code would print nothing:


 * 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)

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 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)