Extension talk:Page Forms

Automatic Javascript/jQuery when autoedit is used
I'd like to be able to swap a tick with a cross when an autoedit link is clicked. Is there any way to do this? I guess if some Javascript could be run automatically this could be made to work.

Thanks Jonathan3 (talk) 09:59, 1 March 2021 (UTC)


 * Sorry, I don't know what this means. Yaron Koren (talk) 14:21, 1 March 2021 (UTC)


 * I've got a "tick" (what a teacher does to your work when it's right) icon I'd like to swap with a cross icon (the "x" shape) when autoedit changes a Cargo boolean field. Jonathan3 (talk) 14:47, 1 March 2021 (UTC)


 * P.S. Currently I'm using the  parameter but it would be good if the page reload were not required. Jonathan3 (talk) 14:48, 1 March 2021 (UTC)


 * Where is this icon located? Yaron Koren (talk) 17:48, 1 March 2021 (UTC)


 * It’s a Font Awesome icon (using an i tag). But I could use something else if it would work. Jonathan3 (talk) 18:03, 1 March 2021 (UTC)


 * No, I mean where is it located on the wiki. Could you describe in more detail what you're trying to do? Yaron Koren (talk) 20:41, 1 March 2021 (UTC)


 * I've got a "To do list" Cargo table and associated template, form etc. For each item, it displays a tick if "Done" is "Yes", or a cross if "Done is "No". If you click on a tick it autoedits Done to become "No"; if you click on a cross it autoedits Done to become "Yes". I'd like the new symbol (tick or cross, as the case may be) to replace the old symbol without needing the page to reload. Jonathan3 (talk) 22:19, 1 March 2021 (UTC)


 * Okay, I get it. That would be somewhat of a hack (since the icon would be changed even if the edit didn't work), though it is pretty clever. Unfortunately, I don't think it can be done - it would require a JavaScript hook to be called by the autoedit code, which could be done but is not being done at the moment. Yaron Koren (talk) 22:49, 1 March 2021 (UTC)


 * I've found a workable solution. I replaced MediaWiki:pf_autoedit_success with the Font Awesome "exchange" icon. When I click on a tick icon, that tick icon is replaced by the exchange icon. Similarly, when I click on a cross icon, that cross is replaced by the exchange icon. It looks quite neat. In fact it's better, as it's more intuitive to realise that the exchange icon (being different to all the clickable ticks and crosses on the page) is not clickable. Thanks for your help and the very flexible extension. Jonathan3 (talk) 11:01, 2 March 2021 (UTC)

Random names for pages (how it works it out)
If I were manually to create a page, e.g. called 12345, would PF know to avoid that in future when selecting a random number page name? I just wonder whether it saves its list of pages in a separate PF table/field, or whether it checks the existing page names on the wiki itself. Thanks. Jonathan3 (talk) 11:35, 1 March 2021 (UTC)


 * It checks existing page names. Yaron Koren (talk) 14:22, 1 March 2021 (UTC)


 * Thank you. Jonathan3 (talk) 14:45, 1 March 2021 (UTC)

Customise the autoedit "Modified ... using form ..." message
Is it possible to customise this? Thanks. Jonathan3 (talk) 11:36, 1 March 2021 (UTC)


 * Yes - edit the page "MediaWiki:pf_autoedit_success". Yaron Koren (talk) 14:22, 1 March 2021 (UTC)


 * Thanks yet again. Jonathan3 (talk) 14:45, 1 March 2021 (UTC)

Autocapitalize support to other input types
Hello Yaron,

Thank you for the autocapitalize support, it works fine on text input type.

Could you add it to the other input types like textarea ?

Kind regards. DSwissK (talk) 19:11, 1 March 2021 (UTC)

Page forms for template multi instance. Add button not showing as a button
Page forms for template multi instance. Add button not showing as a button, more like a link.

Legaulph (talk) 16:52, 2 March 2021 (UTC)


 * What versions of Page Forms and MediaWiki are you running? Yaron Koren (talk) 19:54, 2 March 2021 (UTC)

PHP	7.4.15 MediaWiki	1.35.1 Semantic MediaWiki	3.2.2 Page Forms	5.1 (2e079bc) Chameleon	3.1.0 Legaulph (talk) 18:27, 8 March 2021 (UTC)

Preventing returning to top of page after autoedit
After clicking on an autoedit link near the top of a page, it's fine - nothing appears to change apart from where you've clicked.

But nearer the bottom of a page (i.e. once you've scrolled down at all), after clicking the link the page returns to the top.

This isn't a big deal at all, but I just wondered if it would be possible for the page to stay where it was when the link is clicked. Thanks. Jonathan3 (talk) 17:13, 2 March 2021 (UTC)

pf_autoedit_anoneditwarning
This defaults to "Warning: You are not logged in. Your IP address will be recorded in this page's edit history."

When an anonymous user cannot edit the page at all, this is misleading, as the next thing is an error message "Modifying ... failed. You do not have permission to edit pages in the ... namespace".

I'll change the text on my site so it's not a big deal. I just thought I'd mention it here. Jonathan3 (talk) 22:32, 2 March 2021 (UTC)


 * Feel free to submit a patch, if you have code that works better. Yaron Koren (talk) 22:48, 2 March 2021 (UTC)


 * I just changed the MediaWiki:pf_autoedit_anoneditwarning page. But what effect do you want?
 * If the user is not logged in:
 * and can edit: "Warning: You are not logged in. Your IP address will be recorded in this page's edit history." (current error message)
 * and can't edit: "Warning: You are not logged in. You cannot make this edit."
 * If user is logged in and can't edit: "Warning: You cannot make this edit."
 * Unfortunately I don't know the equivalent to  for finding out whether the user can make the necessary edit. Jonathan3 (talk) 23:06, 2 March 2021 (UTC)

Auto-fixing pipe characters given as value to a template
So here's my situation. I want to create a form that allows users to add guitar tabs to songs. Guitar tablature, if you weren't aware, involves lots of pipe characters | to form the bars of music in plaintext. This is a problem because, due to an unfortunate bug, the tabs must be a value passed through a template, such that we can use TemplateStyles to style it.

Is it possible to have the plaintext input be for a template parameter, or somehow automatically convert the pipes to ! post-submit but pre-save? Or maybe even have the template put nowiki tags around the value (as with a #tag parser function), or even a  tag? The latter two tricks didn't seem to get around what appears to be Cargo-level messaging  "|" is not allowed, except within, ..., or special tags . I'm guessing what I need to do is simply not possible, and if that's the case, then I'll just have to accept that, heh. Thanks for any help, &mdash; MusikAnimal  talk  04:55, 3 March 2021 (UTC)


 * Hi - that's a problem, yes. Page Forms is pretty restrictive about pipes (and that error message comes from Page Forms). One potentially easy fix is to have the tablature be a section on the page, instead of a template field, by using the "section" tag - do you know about that option? Is it a possibility in this case? Yaron Koren (talk) 14:31, 3 March 2021 (UTC)
 * Sorry I meant to say PageForms, not Cargo :) Unfortunately due to T270845 I can't apply CSS to anything in MobileFrontend except through TemplateStyles. This is important here because by default all text will line wrap, essentially making tablature illegible on most mobile devices. I think I can still use TemplateStyles, just on the whole page. The "section" tag for the tabs section will still need a div tag around it to give it a CSS class name. I assume that's possible? &mdash; MusikAnimal  talk  15:35, 3 March 2021 (UTC)


 * No, I don't think you can automatically put a div tag around a section. I guess I would suggest using a responsive skin instead of MobileFrontend, given that it has this issue, though you've probably thought of that already... Yaron Koren (talk) 02:55, 4 March 2021 (UTC)
 * @Yaron Koren a new idea occurred to me... there's Extension:Pipe Escape which has a parser function I can wrap around the tabs parameter, such that it instructs the parser not to interpret pipes as argument delimiters. Frankly I could accomplish the same by wrapping the tabs parameter with, since tablature wouldn't contain wikitext. But in both cases, it seems Page Forms' checks for pipe characters prevent the user from saving. Could we perhaps have a configuration flag to turn off the pipe checks? &mdash;  MusikAnimal  talk  06:23, 19 March 2021 (UTC)

[OPEN] Field with 'uploadable' parameter leads to a white window and does not insert destination filename into respective field
I am trying to use the |uploadable parameter in one of my forms. When using the form and clicking the 'Upload file' button, the upload window pops up as expected. After choosing the file and the destination filename clicking 'upload file' does not close the window but leads to a completely white window that has to be closed with the x on the upper right. (The upload itself is successful.) However, the destination filename is not inserted in the respective field of the form.

It would be great if someone could point me towards a solution (preferably that does not include changing essential files as my wiki should be integrated into an existing one soon.) Thanks a lot in advance! MarenRtalk 11:53, 3 March 2021


 * I would look in the JavaScript console, if you know how to do that - I'm guessing that there's some JS error that is causing both problems. Yaron Koren (talk) 14:34, 3 March 2021 (UTC)


 * Exactly the same problem. Has anyone found a solution? --212.12.75.9 13:49, 15 March 2021 (UTC)


 * Same here. I even tried with a clean install of MW 1.35.1 (stable release) + PF 5.1-alpha without any other extensions and still the "white screen" with nothing on JavaScript console! Does it work for anyone? Molindho (talk) 11:33, 19 March 2021 (UTC)


 * This is the first confirmation I've seen that it's not a JS issue. If you're seeing a blank page, I would suggest following these steps - you may see a more helpful error message. Yaron Koren (talk) 16:33, 22 March 2021 (UTC)

Internal error: Status::getWikiText called for a good result, this is incorrect
Hello Yaron,

I'm trying to create a form to upload for a mediawiki 1.31 installation with Page Forms 4.7. Everytime I select a file in the upload dialog I get the error Internal error: Status::getWikiText called for a good result, this is incorrect.

I found someone having a similar issue in this topic: https://www.mediawiki.org/wiki/Extension_talk:Page_Forms/Archive_January_to_March_2020#Internal%20error%20with%20Page%20Forms%20upload

You said that you implemented a fix. However, I can not update my Mediawiki version due to other extensions not being compatible with MW versions higher than 1.31.

Do you have any advice or pointers on how to get this working?


 * Update your version of Page Forms; the latest Page Forms version still works with MW 1.31. Yaron Koren (talk) 18:36, 5 March 2021 (UTC)

Thank you very much! AID-PMBD (talk) 07:09, 8 March 2021 (UTC)

Field option "mapping template=" is ignored when used in conjunction with "property="
I was hoping to use a mapping template in a field that needs to use "property=" rather than "values from property=", but it seems to be ignored in that situation. The property in question has Allows Value's set and property= will list all of them even when they have not been #set in any page. I was hoping to integrate that in with a mapping template to show an image along with the entries in the form list (I am using radiobuttons or checkboxes in this situation, so it should be okay). The mapping template looks great when I use "values from property" but doesn't seem to be used at all with "property". --RinaCY (talk) 03:04, 6 March 2021 (UTC)

Issues with getWikiPageFactory?
I was in the process of trying to set up an MW 1.35.1 instance and got into trouble with Page Forms 5.1 installed. Attempting to save any page results in an error related to :

I had a similar error message before (something with  and  ).

Backtrace
 * 1) 0 [...]includes/HookContainer/HookContainer.php(321): PFFormUtils::purgeCache2
 * 2) 1 [...]includes/HookContainer/HookContainer.php(132): MediaWiki\HookContainer\HookContainer->callLegacyHook
 * 3) 2 [...]includes/HookContainer/HookRunner.php(2652): MediaWiki\HookContainer\HookContainer->run
 * 4) 3 [...]includes/Storage/PageUpdater.php(758): MediaWiki\HookContainer\HookRunner->onMultiContentSave
 * 5) 4 [...]includes/page/WikiPage.php(2015): MediaWiki\Storage\PageUpdater->saveRevision
 * 6) 5 [...]includes/EditPage.php(2457): WikiPage->doEditContent
 * 7) 6 [...]includes/EditPage.php(1724): EditPage->internalAttemptSave
 * 8) 7 [...]includes/EditPage.php(680): EditPage->attemptSave
 * 9) 8 [...]includes/actions/EditAction.php(71): EditPage->edit
 * 10) 9 [...]includes/actions/SubmitAction.php(38): EditAction->show
 * 11) 10 [...]includes/MediaWiki.php(527): SubmitAction->show
 * 12) 11 [...]includes/MediaWiki.php(313): MediaWiki->performAction
 * 13) 12 [...]includes/MediaWiki.php(940): MediaWiki->performRequest
 * 14) 13 [...]includes/MediaWiki.php(543): MediaWiki->main
 * 15) 14 [...]index.php(53): MediaWiki->run
 * 16) 15 [...]index.php(46): wfIndexMain
 * 17) 16 {main}

Cavila 19:09, 7 March 2021 (UTC)


 * Sorry about that! There was a not-very-good check in the code to see whether that getWikiPageFactory method should be called. I just modified this code, so hopefully it works better now. Yaron Koren (talk) 20:16, 8 March 2021 (UTC)


 * Great, it's working, and thanks again! Cavila 08:36, 9 March 2021 (UTC)

Using PageForms for File Uploads
Hello,

I'm currently trying to create a form that lets Users upload files and creates a wikipage with the file's name as pagename. I noticed that PageForms uses the Special:UploadWindow page as upload dialog and I'm wondering if it is possible to use the Wikieditor upload dialog instead, which seems more user friendly.

Thank you

Edit for clarity: I'm talking about this Upload Dialog.


 * No, but that sounds like it would be a good feature to have. Yaron Koren (talk) 18:08, 9 March 2021 (UTC)

Usability issues with tokens
Hi Yaron, I probably brought this up before in the middle of some other discussion, but promised to start a new post. There are two issues with tokens that affect usability and can no longer be worked around by returning to "text/textarea with autocomplete". I used the latest from master:


 * I often need select a string of text or place my cursor at the desired position, which I can do using regular inputs or comboboxes, but can't do using tokens. Especially with longer strings (40+ characters or so), this is especially unhelpful.
 * If you double-click a token to edit it and then cancel by clicking outside the input box, the token vanishes.

Fixing this would also bring tokens more into line with comboboxes. Cavila 20:24, 11 March 2021 (UTC)


 * The second one I know about already, and it's definitely a problem. I don't understand the first one. Yaron Koren (talk) 14:34, 12 March 2021 (UTC)


 * It means quite simply that after double-clicking you can't select text or position the mouse cursor. Cavila 22:04, 12 March 2021 (UTC)


 * Are you using the latest version of the Page Forms code? There was an improvement to tokens double-clicking last week. Yaron Koren (talk) 00:53, 15 March 2021 (UTC)


 * If you're referring to, that one only fixed the ability to edit by double-clicking. What I'm referring to is what happens after the user double-clicks. Try positioning the mouse cursor somewhere in the middle or selecting part of the text. (P.S. I had problems loading some of my forms with the then latest version of PF. Will look into it.) Cavila 09:58, 15 March 2021 (UTC)


 * That works fine for me. What browser are you using? Yaron Koren (talk) 14:46, 15 March 2021 (UTC)


 * Updated to the latest version. Now double-clicking may actually remove the entire token! I'm using Firefox and noticed that placing the mouse pointer does work in Chrome (but not in Firefox). Selecting text works in neither browser: instead it looks like the token is about to be moved. Cavila 18:09, 15 March 2021 (UTC)

Query form for Cargo list type
Let's say there's a Cargo field "Name", a List of String. I'd like to have a form so that if the user typed in both Smith and Jones, the Cargo query on the template related to the query form displays all the rows where the name field holds either Smith or Jones. I'm sure this should be easy but I can't get it to work. Could you show me an example? Thanks in advance. Jonathan3 (talk) 11:22, 17 March 2021 (UTC)


 * I've got a form to work with several List of String fields, but so far only by using . I think I might be able to get multiple values per field to work using  . Jonathan3 (talk) 00:07, 19 March 2021 (UTC)


 * Sorry, I don't understand - is the issue with creating the template that calls the query, or with creating the form that correctly calls the template? Yaron Koren (talk) 00:15, 19 March 2021 (UTC)


 * The template page containing the query. Jonathan3 (talk) 00:31, 19 March 2021 (UTC)


 * Okay - in that case, it sounds like a Cargo issue. Yaron Koren (talk) 01:04, 19 March 2021 (UTC)


 * Yes it's probably a Cargo problem with a Page Forms (#arraymap) solution :-) Jonathan3 (talk) 11:43, 19 March 2021 (UTC)


 * I got it to work with #arraymap! Thanks again for the extensions. Jonathan3 (talk) 17:18, 19 March 2021 (UTC)

Embed query form that displays results on Drilldown page
Is there any way of having a query form that sends the query to Cargo’s Special:Drilldown?

Maybe it would be possible with some other extension if not using Page Forms. Jonathan3 (talk) 17:20, 19 March 2021 (UTC) Edit: I meant "even if it is not possible using Page Forms". Jonathan3 (talk) 20:06, 19 March 2021 (UTC)


 * It seems strange to have a query interface that brings the user to a different query interface, so there may be a simpler way to do whatever you're trying to do. If not, though, then maybe you could embed " " directly in the template. If that doesn't work, then probably no. Yaron Koren (talk) 16:31, 22 March 2021 (UTC)


 * You're right about it being strange... I just wanted to see how it looked. The Drilldown page is great but a bit daunting to some, so I thought maybe a simpler way into it might help. I'll try what you suggest. Jonathan3 (talk) 16:43, 22 March 2021 (UTC)

Tab action on field with input type=tokens | existing values only
Normally in a tokens input type, if you press tab when a suggestion is there and highlighted, it creates a token for that value.

However, when it's "existing values only", pressing tab just deletes the text you've typed, without creating a token.

Ideally I think both should work the same, i.e. tab creates a token.

Incidentally, the enter/return key creates a token in both scenarios.

Thanks. Jonathan3 (talk) 20:04, 19 March 2021 (UTC)

Creating duplicate token deletes both
This is just a curiosity rather than a big problem, but you'd think when trying (by mistake) to create a second token the same as an existing one it would just refuse to create the second token. But it deletes the existing token at the same time as clearing the text you've just typed. Jonathan3 (talk) 20:08, 19 March 2021 (UTC)

Datepickers not working on multiple-instance templates
Is it just me, or are the datepicker and datetimepicker input formats broken on multiple-instance templates? They seem to work ok for existing templates, but for new template instances (created with add another) no value is saved. Molindho (talk) 22:38, 19 March 2021 (UTC)

"Show on select" linked to tokens field
I'd like to have part of a form initially hidden, and only display it when any text is entered into a tokens field. Then that part of the form should disappear again if the tokens field becomes empty again. Is this possible? Thanks. Jonathan3 (talk) 08:47, 20 March 2021 (UTC)


 * No - you would need some custom JavaScript for that. Yaron Koren (talk) 16:35, 22 March 2021 (UTC)

Tokens type to restrict input to the YEAR of existing Cargo field's dates
I've tried What can I try next? Thanks. Jonathan3 (talk) 09:19, 20 March 2021 (UTC)
 * "existing values only|cargo table=tablename|cargo field=Date" (which broke the page completely)
 * "values= " where "existing years" is a template with a Cargo query showing the years (and get a UNIQ error).
 * "values={ {existing years}} " where "existing years" is a template containing the text "2010,2011,2012" (the form just shows "{{cases existing years" as the only suggested input).


 * I'm surprised that that third one didn't work. (Not that it would be that helpful.) You could probably accomplish this "values from url", pointing to a Special:CargoExport URL (which you could generate via Special:CargoQuery). Yaron Koren (talk) 16:40, 22 March 2021 (UTC)

Special:MultiPageEdit edits more than only inside the template
Hello Yaron,

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. DSwissK (talk) 12:29, 20 March 2021 (UTC)

Form validation
I know that there is the per-field "mandatory" parameter, but is there a per-form equivalent which would require that at least one field be filled in, without specifying which? Thanks. Jonathan3 (talk) 09:36, 21 March 2021 (UTC)


 * No. Yaron Koren (talk) 16:43, 22 March 2021 (UTC)