Extension talk:Page Forms/Archive March to April 2021

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

Sorry for the delay - that's a good idea, and this feature was added in version 5.2.1. Yaron Koren (talk) 23:45, 2 May 2021 (UTC)

Thank you ! DSwissK (talk) 08:22, 4 May 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.

{{{for template|template|multiple|add button text=Add Connection|label=Add Connection}}}

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)

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.

In my case I upgraded from MediaWiki 1.33.1 to 1.35.2 and am now running:

PHP	7.4.19
MediaWiki	1.35.2
Page Forms	5.2.1
Chameleon	3.1.0

While I am here is there any way to format the button to have say rounded corners and/or a different color?

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.

Desired Button Style In Green

--GMShimokura (talk) 23:26, 19 May 2021 (UTC)

This is not totally related to your question, but maybe you should be using #autoedit instead of #formlink (which is what I think you're using)? Do you know about #autoedit? Yaron Koren (talk) 23:45, 19 May 2021 (UTC)

I'll look into #autoedit, not sure it will work for me because I am using #queryformlink to preload a form with specific values then executing a database query and displaying the results. I don't mind using CSS styling in Common.css to change the button to look like the previous button (or to my ideal). --GMShimokura (talk) 12:01, 20 May 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 mw.config.get( 'wgUserName' ) 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 <pre> 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, — 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 phab: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? — 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 <nowiki>, 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? — 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 parameter in one of my forms.

 {{{field|Image2|uploadable}}}

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! MarenR^talk 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)

I did try to get out any php errors too, but with no luck. The problem seems to be that Special:UploadWindow (even if opened directly without a form) doesn't return anything at a successfull upload ("this request has no response data available"). Any warning messages (duplicates etc.) are however returned normally. I guess it should return - as it does in an old version of PF I have in another setup - some javascript that updates the field and closes the fancybox. Molindho (talk) 11:25, 23 March 2021 (UTC)

Unless I'm mistaken, I haven't seen a bug reported for this blocking problem in Phabricator. Should I report it? --Megajoule (talk) 08:21, 16 April 2021 (UTC)

If it helps, I'm using MW1.34 and it all works fine for me. I recently upgraded PF to the latest version too. I think there are two ways of doing the upload (something to do with either using MediaWiki's or your computer's built-in pop up). I use MediaWiki's one which is a bit clunky but works all right for me. Jonathan3 (talk) 08:47, 16 April 2021 (UTC)

OK I take it back. I have noticed two problems recently. I can't tell whether it was from upgrading Page Forms or just from not noticing before... (1) When I select a file, the "Source filename" box contains the filename but the "Destination filename" box is empty (I just copy and paste from the system dialog into the "Destination filename" box to get round this). (2) When I selected a file with a single apostrophe in the filename tonight I get the error described above, i.e. blank modal/popup which I just had to close, but successful upload (I just copied and pasted the filename from Special:Newfiles into the PF form field). Jonathan3 (talk) 20:00, 16 April 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 getWikiPageFactory:

/index.php?title=Module:String&action=submit Error from line 602 of [...]/extensions/PageForms/includes/PF_FormUtils.php: Call to undefined method MediaWiki\MediaWikiServices::getWikiPageFactory()

I had a similar error message before (something with PFFormUtils::purgeCache2 and getWikiPageFactory).

Backtrace

#0 [...]includes/HookContainer/HookContainer.php(321): PFFormUtils::purgeCache2()
 #1 [...]includes/HookContainer/HookContainer.php(132): MediaWiki\HookContainer\HookContainer->callLegacyHook()
 #2 [...]includes/HookContainer/HookRunner.php(2652): MediaWiki\HookContainer\HookContainer->run()
 #3 [...]includes/Storage/PageUpdater.php(758): MediaWiki\HookContainer\HookRunner->onMultiContentSave()
 #4 [...]includes/page/WikiPage.php(2015): MediaWiki\Storage\PageUpdater->saveRevision()
 #5 [...]includes/EditPage.php(2457): WikiPage->doEditContent()
 #6 [...]includes/EditPage.php(1724): EditPage->internalAttemptSave()
 #7 [...]includes/EditPage.php(680): EditPage->attemptSave()
 #8 [...]includes/actions/EditAction.php(71): EditPage->edit()
 #9 [...]includes/actions/SubmitAction.php(38): EditAction->show()
 #10 [...]includes/MediaWiki.php(527): SubmitAction->show()
 #11 [...]includes/MediaWiki.php(313): MediaWiki->performAction()
 #12 [...]includes/MediaWiki.php(940): MediaWiki->performRequest()
 #13 [...]includes/MediaWiki.php(543): MediaWiki->main()
 #14 [...]index.php(53): MediaWiki->run()
 #15 [...]index.php(46): wfIndexMain()
 #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 [1], 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 |input type=tokens|max values=1. I think I might be able to get multiple values per field to work using #arraymap. 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 "{{Special:Drilldown}}" 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)

I can't reproduce this problem; it's working fine for me. What versions of Page Forms and MediaWiki are you running? Yaron Koren (talk) 00:57, 24 March 2021 (UTC)

OK, now I got this to work! I had installed PF with composer, and just realized that "this is not a well-supported feature at the moment." When I fetched the same version with git, it just started to work. Sorry about the false alarm. Installing with git didn't, however, fix my other problem with the white screen in file upload...:( Molindho (talk) 07:11, 24 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

• "existing values only|cargo table=tablename|cargo field=Date" (which broke the page completely)
• "values={{existing years}}" 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).

What can I try next? Thanks. Jonathan3 (talk) 09:19, 20 March 2021 (UTC)

I'm surprised that that third one didn't work. (Not that it would be that helpful.) You could probably accomplish this with "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)

Your surprise in relation to the third point is warranted: I had missed out the }}... I'll try out your other suggestion. Thanks. Jonathan3 (talk) 01:25, 23 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)

[SOLVED] 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)

Thanks. I needed it for a query form so was able to get round it by an #if statement around the query in the template which displays "You forgot to fill in the form" wording if necessary. Jonathan3 (talk) 01:21, 23 March 2021 (UTC)

HTML tags like <span> are not interpreted in #formredlink

Configuration : MW 1.33 // PF 5.1
In the parameter existing page link text=, if I use HTML like that <span style="font-size:120%">XXX</span>, the <span> is not interpreted contrary to the parameter link text= where everything works fine. Has anyone encountered this problem ? Paul LEMPERIERE (talk) 20:36, 24 March 2021 (UTC)

You don't need it - what is possible (and less hacky anyway, I would say) is to just put the span tag around the entire #formredlink call. Yaron Koren (talk) 23:19, 24 March 2021 (UTC)

Thank you for the answer but it's not exactly what i need. The attributes of the span are differents if the link exist or not. I will work with #ifexist, it will be more simple Paul LEMPERIERE (talk) 18:59, 25 March 2021 (UTC)

Problem with "tokens" input type going blank

I've received the following comment: "When I type into the form and click 'run', the form clears!"

I know I could add a message to the form along the lines of: "After typing, press comma or tab, or select one of the suggestions."

But would it be possible to change the token input type so that it tokenises the existing text when the user moves to a different part of the form? Jonathan3 (talk) 09:55, 25 March 2021 (UTC)

Small bug (+fix) with multiple-instance "Add another" -button

When you have a lot of multiple instance templates, which are minimized, adding a new template with the "add another" button causes the new template to instantly minimize (PF 5.2-alpha). However, if you add a new template with one of the "add above" buttons, the new template remains unminimized. The latter seems the intended behavior. The problem is in PageForms.js, when dealing with the '#pfForm' clicks. The add another button should be ignored, but it's not catched with the "target.hasClass('multipleTemplateAdder')" condition on line 1641. The target is not that element, but instead one of its siblings. Changing the condition to "target.parents( '.multipleTemplateAdder' ).length" will solve the problem. Molindho (talk) 17:10, 25 March 2021 (UTC)

Thanks for this fix! I should have done more testing of the OOUI changes. I just added it to the code. Yaron Koren (talk) 20:00, 26 March 2021 (UTC)

#formlink and query string parameter to preload values for multiple-instance templates

Configuration : MW 1.33 // PF 5.1 It seems that multiple-instance template doesn't work in a #formlink. I'd just upgrade from PF 4.6 to PF 5.1. Is it a known bug ? Or the synthax has changed ? Paul LEMPERIERE (talk) 20:13, 29 March 2021 (UTC)

Actually, I thought it didn't work before and does work now. Maybe the syntax you were using no longer works, though. I believe the correct query string syntax is "TemplateName[InstanceNum][FieldName]=Value". Yaron Koren (talk) 20:23, 29 March 2021 (UTC)

Yes this is the synthax I use and my #formlink works fine when I roll back to 4.6... I will investigate and give you the answer if I find. Paul LEMPERIERE (talk) 04:05, 30 March 2021 (UTC)

When trying to edit a new page thanks to {{#formlink which has many query strings the form is time out. The form is trying to load many values with many "values from (Property|Category)"...

The bug may come from this commit and maybe this new statement (line 1095) :

$page_value = $tif->getValuesFromPage()[$field_name]; Nicolas NALLET Wiki-Valley.com (talk) 12:47, 31 March 2021 (UTC)

I have created a new phabricator task : https://phabricator.wikimedia.org/T278947 Nicolas NALLET Wiki-Valley.com (talk) 12:54, 31 March 2021 (UTC)

Tokens split in Edit With Form when mapping property has commas

MW 1.34.4 + PF 5.1 (9eeed94) 14:43, 10 February 2021

{{{field|Has Users
   |input type=tokens
   |values from category=User
   |mapping property=Has Users Full Name
}}}

Example: Page "User:Revansx" in "Category:User" has property [[Has Users Full Name::Evans, Richard

The initial selection of token saves fine as: |Has Users=User:Revansx

When editing the page with the "edit with form" link, the existing token has been split on the comma of the mapping property (Evans, Richard) and shows as 2 token: "Evans" and "Richard"

Is there a work around for this?

Revansx (talk) 23:03, 7 April 2021 (UTC)

Ref: https://phabricator.wikimedia.org/T266664

I thought I came across the same problem today. I have a Cargo field "Author" which for non-institutional authors is in the format "Surname, Christian name". When I used a Page Forms query form using values from the Author field, the autocompletion worked correctly. But when the form was displayed again, below the query results, with the search terms pre-populated, the Author field had changed to two separate tokens, e.g. "Bloggs", "Joe" (instead of "Bloggs, Joe"). Anyway, my Cargo field is a List (;) of String so the answer was to add delimiter=; to to the PF form. The default delimiter is comma. So I guess you just need to do the same. If you're not using a list of authors then it maybe doesn't matter which non-comma delimiter you use. Jonathan3 (talk) 14:17, 8 April 2021 (UTC)

How to get radio button options to stack vertically

By default, radio button options display left to right in a series.

How does one get them to display as a left justified stack? Is there some clever CSS to do this?

Revansx (talk) 00:25, 8 April 2021 (UTC)

This is just a quick reply to give you hope! I used to do this so it was (and likely is) possible. The answer is probably in the archives here. Jonathan3 (talk) 09:31, 8 April 2021 (UTC)

Found it (commented out) on my site... you can put this into MediaWiki:Common.js:

$( "label.radioButtonItem" ).after( "<br/>" );

Good luck. Jonathan3 (talk) 10:47, 8 April 2021 (UTC)

Oh, wow.. JS.. I was thinking it was going to be a CSS trick.. Thank you!

That said, this seems like it might be an easy feature to add to PF as an input type option for radiobuttons.

/Revansx (talk) 11:53, 8 April 2021 (UTC)

It's likely possible with CSS too. I just stopped looking when I found something that worked. I think Yaron is reluctant to add options unless really necessary. I guess there could be a page in the manual with tips like this though. Jonathan3 (talk) 14:18, 8 April 2021 (UTC)

[SOLVED] Page Forms breaks Special:CargoTables

I upgraded both Page Forms and Cargo to the latest version today. When I go to Special:CargoTables, it says:

Fatal exception of type "Error" 

... 

[exception] [aa0801e543fbd9a68a957b1a] /Special:CargoTables Error from line 297 of /var/www/example.com/html/extensions/PageForms/includes/PF_Hooks.php: Class 'MediaWikiServices' not found

When I disable Page Forms (in LocalSettings.php) the error goes away.

What should I try? Jonathan3 (talk) 22:39, 8 April 2021 (UTC)

PS. When I git checkout REL1_33 the error goes away too. Jonathan3 (talk) 22:42, 8 April 2021 (UTC)

PS. Could it be linked to Replace:: Linker::linkKnown with linkRenderer on Phabricator? It was a change made today. I'm still on MW 1.34 if it helps, so maybe the MediaWikiServices thing only works for 1.35+ ? Or maybe use MediaWiki\MediaWikiServices; is missing? Jonathan3 (talk) 22:48, 8 April 2021 (UTC)

Sorry about that! And thanks for letting me know. I just checked in a fix. Yaron Koren (talk) 01:06, 9 April 2021 (UTC)

Thanks for the quick response. It all works again now. Jonathan3 (talk) 08:49, 9 April 2021 (UTC)

[SOLVED] Section tag blanking code

Hi, so I’ve been trying to use the section tag for a while now and cannot for the life of me understand why it’s doing this.

I’m trying to make a page with multiples of the same template, with some under different sections (basically, a recipes page with multiple categories, with one section being Salad, and another being Soup, and so on and so forth). So I thought that a good way to do that would be to use both partial forms and the section tag. Essentially, when I use a section tag, the code that already exists on that page before the template completely disappears, leaving the page with just the templates made from the form — no headers or anything. Any code after the template is fine, however.

Is this because of the partial forms, or am I simply just not using the section tags correctly? Thanks in advance. --Kiwibasket (talk) 19:28, 10 April 2021 (UTC)

It's probably because of the partial forms - they're an unsupported feature that probably should have been removed a long time ago. Hopefully you can accomplish what you're trying to do without them. Yaron Koren (talk) 01:30, 12 April 2021 (UTC)

Ohhhh. Yeah, I ended up removing the partial form tag, and it worked perfectly fine. I didn't realize that I didn't need partial forms for multiple-instance templates. Whoops! --Kiwibasket (talk) 12:19, 14 April 2021 (UTC)

Is it possible to use format=template with a query form?

I created a template that worked fine with a normal cargo query (it's a responsive table using CSS) but it didn't work when used with a query form. I can provide more details if it's supposed to work - but is it maybe something that's known not to work? Thanks. Jonathan3 (talk) 20:30, 11 April 2021 (UTC)

They should work. Yaron Koren (talk) 01:30, 12 April 2021 (UTC)

I also have a problem with the use of format=template in a query form or the corresponding template.

As soon as I try to create a link to the page of a result with the schema [[{{{page name}}}|{{{page title}}}]] via the output template, this link is simply not displayed. The column in the result list is simply empty.

External links do not work either. Here I get the following displayed in the output column:

<a target="_blank" rel="nofollow noreferrer noopener" class="external text" href="https://www.link.com">a link</a>

Maybe a config/parameter issue I am not aware of? --Shuitavsshente (talk) 10:44, 12 April 2021 (UTC)

I've narrowed it down. When one of the fields is _fileData._fullText (and I guess the same might apply for _pageData._fullText) it stops working and just shows the following text:

[[:#cargo_query:

tables=_fileData]]

When I replace that field with another field like _pageName it works fine. I haven't tried to create links yet. Jonathan3 (talk) 20:54, 12 April 2021 (UTC)

P.S. I've just tried creating a link using [[{{{1|}}}|{{{1|}}}]] in the template and it worked fine for me. (I can't remember why I didn't try just [[{{{1|}}}]] but I'm sure that would work too.) Jonathan3 (talk) 21:05, 12 April 2021 (UTC)

Does that same "format=template" query work when called outside of a query form? Yaron Koren (talk) 21:56, 12 April 2021 (UTC)

Yes, it works fine. (I was testing it with a normal wiki-page query, and it worked fine, but it broke when used within a query form's template.) Jonathan3 (talk) 22:03, 12 April 2021 (UTC)

That's strange - I know Special:RunQuery can have different behavior from just calling the template (because the parser runs differently on the two), but I don't know why you would see that particular output. Yaron Koren (talk) 01:34, 13 April 2021 (UTC)

I've been putting off upgrading from MW 1.34 as nothing seemed to work with 1.35. Do you think maybe that's relevant? Maybe it'll just start working with 1.35? Jonathan3 (talk) 09:25, 13 April 2021 (UTC)

I doubt that will help, although it's always good to use the latest version. Yaron Koren (talk) 02:01, 15 April 2021 (UTC)

Getting alpha version when using git...

I downloaded the newest version of PageForms on Apr 8 and again today, using the git string provided in the instructions, git clone https://gerrit.wikimedia.org/r/mediawiki/extensions/PageForms.git . When I use this version, one of my forms that services more than one template no longer works on the second template. When I looked at versions to find out to report this, it shows an alpha version (5.2-alpha (df6f061) 2021-04-08T08:55:00). Should the git pull be getting me an alpha version? How do I get the stable version? And, for a bonus, has anything changed that would be breaking my multi-template form? Thanks! Tenbergen (talk) 20:57, 14 April 2021 (UTC)

Well, to get the stable version, you need to do a checkout on the latest tag. Although the current code, though it's labelled as "alpha", is pretty stable, I think - I'm planning to release version 5.2 pretty soon. I'm very surprised that some form is no longer working. Could you link to that form, or pastebin it, or something? Yaron Koren (talk) 02:01, 15 April 2021 (UTC)

When you say I need to "do a checkout on the latest tag", is there generic code to do that? Should that be what is listed at Extension:Page Forms/Download and installation? The form is here. The "investigator" section doesn't show up any longer. Thanks Yaron!

Okay - I'm pretty sure you're still using the version from April 8, because that looks a lot like a bug that was fixed (coincidentally) on April 9. If you use the latest code, hopefully everything will work fine again. As for getting a tagged version - all the tags for Page Forms (and my other extensions) are just the version number, so if you call something like "git checkout 5.1", I think that will work. Yaron Koren (talk) 13:25, 15 April 2021 (UTC)

I only use git to pull to install these components, so I may not be doing this right. I did a git pull on one wiki and it got me 5.2-alpha (fa54bf4) 2021-04-14T01:38:50; then I did a git pull on another wiki after and got 5.2-alpha (df6f061) 2021-04-08T08:55:00. Then I tried the command Yaron suggested and it got me 5.1 (df6f061) 2021-04-08T08:55:00; that last version fixed my form and things work for now, so thank you for the info Yaron! But it raises the question: what is the appropriate way to install this extension? To do my regular updates I currently run the git pull as suggested on the install page - is that still the right way to get a stable version of this extension? Tenbergen (talk) 14:43, 15 April 2021 (UTC)

If you're doing a git pull and getting code from April 8, then something is wrong - I don't know what, though. And running git pull by itself (i.e., something like "git pull origin master") was never the right way to get a stable version - it just gets the latest code. (Well, it's supposed to, anyway.) To get a stable version via Git, you should call something like "git checkout 5.2". Yaron Koren (talk) 15:40, 15 April 2021 (UTC)

I only know enough about git to download MediaWiki extensions, but my notes are that git tag -l or just git tag lists all tags (e.g. 5.0, 5.0.1, 5.1) and git branch -r lists all the branches (e.g. origin/REL1_35, origin/REL1_36). You can get what you want by git checkout [tag name] or git checkout [branch name] or the latest by git checkout master. After that, git pull gets you the latest code (of the tag/branch or master) if anything has changed. With MediaWiki extensions, I always just use the very latest code, unless there's some reason not to, as there seems to be a greater chance that a bug has been fixed since the relevant branch (or tag) than risk that one has been introduced. Though I tend not to git pull an extension until upgrading MediaWiki itself, with the exception of Yaron's extensions. Jonathan3 (talk) 10:59, 16 April 2021 (UTC)

Same here, I only use git to install web apps or extensions. And I think that's what an audience of Extension:Page Forms/Download and installation is looking for as well: minimum info to install. Ideally the instruction there should not require an update every time there is a minor version change, unless someone owns the job of keeping it up to date. I just tried git checkout master https://gerrit.wikimedia.org/r/mediawiki/extensions/PageForms.git in the extensions directory after renaming PageForms, and I get a "fatal:not a git repository (or any of the parent directories)", so that's not it.

I'm far from a Git expert, but I think just "git checkout master" is what should be called. And I don't think renaming the local directory will have any effect. Yaron Koren (talk) 15:10, 19 April 2021 (UTC)

For an initial install of the extension it would also need the address. If I try git checkout master https://gerrit.wikimedia.org/r/mediawiki/extensions/PageForms.git I get an error, "fatal:not a git repository (or any of the parent directories)", so what is the full line of code that needs to go on the documentation page? And, I am re-naming the PageForms directory to get a new pull as if I had never installed it. Is that not how I would need to do that to test the process, ie. does git leave a trail in the parent directory that causes it to install different versions? That would certainly explain why I am not getting the same version when I test on different wikis... Tenbergen (talk) 15:25, 19 April 2021 (UTC)

I guess this might also mean that there need to be different instructions for install and for update. Tenbergen (talk) 15:26, 19 April 2021 (UTC)

I partly agree. I think the instructions for installation are adequate, though it might be helpful to add instructions for upgrading. To install, you just need to go to the extensions directory and type git clone https://gerrit.wikimedia.org/r/mediawiki/extensions/PageForms.git.

If you're always going to stick with the latest (master) code, as Yaron generally recommends, then you never need to type git checkout 5.1 or whatever. If you did then you could go back to the master branch by git checkout master.

When you are on master, git pull will download the very latest code. I think it's possible to change the code for old tags (e.g. to fix a bug) so git pull might have an effect there too.

It's not correct to type git checkout master http://... (as it's only git clone that takes a URL).

There's never any need to rename the directory (though I think git would work just the same if you were to rename it). The only time you need to worry about the directory name is if the git clone command creates a directory like mediawiki-extension-ExtensionName (which doesn't happen with this extension).

So in summary, all you ever need is the initial git clone [URL] and subsequent git pull whenever you want to get the latest code.

Standing by to be corrected in relation to any of this :-) Jonathan3 (talk) 16:49, 19 April 2021 (UTC)

So that's where we started... I had used git pull and got an alpha version. When I use git pull now, I get a non-alpha that no longer causes the problem that got me to pull a new version in the first place. So, maybe I don't need to know why I got an alpha version as long as I was using the right way to set up. I was going to add the git pull will download the very latest code to the install page, but got some warnings about translations so will leave that to someone who is familiar with it. Thanks for the answers and clarifications! Tenbergen (talk) 14:46, 20 April 2021 (UTC)

┌───────────────────────────────────────┘
I guess the latest code earlier on was designated as 5.2-alpha but now that 5.2 has been released it's just 5.2. Jonathan3 (talk) 15:07, 20 April 2021 (UTC)

#template_params and #template_display

I see that these are new additions and are mentioned on Extension:Page_Forms/Page_Forms_and_templates. Could you share any examples of these being used? For existing forms/templates would there be any benefit in adding #template_params and #template_display? Will Special:CreateTemplate now use these new parser functions? Thanks. Jonathan3 (talk) 10:47, 16 April 2021 (UTC)

Yes, here; yes, it makes it easier to modify the template; yes. Yaron Koren (talk) 13:14, 16 April 2021 (UTC)

template_display seems to replace the #cargo_query. Is that right? So if I'm using format=template then I guess it's not possible to replicate that with #template_display. Jonathan3 (talk) 14:06, 16 April 2021 (UTC)

No, there's no connection between the two. Yaron Koren (talk) 14:23, 16 April 2021 (UTC)

Oops. I'll sit down and look at it properly later. Jonathan3 (talk) 15:39, 16 April 2021 (UTC)

In your Musician example it just has {{#cargo_store:}} where ordinarily it would have {{#cargo_store:_table=Musicians|Instrument={{{Instrument|}}} | ... }}. I guess #cargo_store takes the information from #template_params. Is that right? Jonathan3 (talk) 18:33, 16 April 2021 (UTC)

I'm trying to convert one of my templates to help me understand this. I've added #template_params. It shows the "This is the ... template. It should be called in the following format ... Edit the page to see the template text." text so I was able to get rid of the literal text to that effect. The template also has (in the noinclude part) #cargo_declare and #cargo_attach, and (in the includeonly part) #cargo_store for the main table and #cargo_store for the attached table (each #cargo_store stores different fields). How would I replace this all with the new system? If the template declaring the attached table had its own #template_params would I be able to get rid of its parameters from the main template and just have {{#cargo_store:}} there? Cheers.

I've seen what #template_display does. It could replace all my wikitext containing {{{Parameter1|}}}, {{{Parameter2|}}} etc. That could be useful if I were still using the default displays, but since I've customised how the fields are displayed (e.g. some in an infobox, some elsewhere) I guess there is no benefit to me of #template_display. Jonathan3 (talk) 18:48, 16 April 2021 (UTC)

No, #cargo_store gets all its information from #cargo_declare. This is a new feature in Cargo that just happened to be released around the same time as #template_params and #template_display. Right, #template_display is not useful for all purposes. Yaron Koren (talk) 19:36, 16 April 2021 (UTC)

That's quite a nice feature for Cargo as it will avoid some duplication of effort when creating/editing template pages. As far as #template_params is concerned, of the three benefits listed, I can see how it lists the parameters nicely, and how it works with #template_display (though I will not use #template_display). Could you explain the third benefit? ("Some of this information is also used by forms, enabling the form definition to be simpler.") Jonathan3 (talk) 14:03, 19 April 2021 (UTC)

If you specify a "label" in #template_params, that label can be (and I think already is) used within the corresponding form, so you don't need to specify it in the form definition, assuming you want the same label in both. The same could be done for "holds template", removing the need for a rather complex part of form definition syntax, although I think that's not being done yet. Yaron Koren (talk) 12:31, 26 April 2021 (UTC)

Bug in FormInput Parserfuntion?

The forminput Parserfunction with multipe forms is working fine in Page Forms 4.5.1, in the current version the following error is thrown.

{{#forminput:form=From1,Form2}}

615d1ce455fcee93e5837ab1] /index.php?title=Page&action=submit MWException from line 545 of /opt/bitnami/mediawiki/includes/Html.php: HTML attribute data-possible-forms can not contain a list of values
Backtrace:
#0 /opt/bitnami/mediawiki/includes/Html.php(305): Html::expandAttributes(array)
#1 /opt/bitnami/mediawiki/includes/Html.php(210): Html::openElement(string, array)
#2 /opt/bitnami/mediawiki/includes/Html.php(235): Html::rawElement(string, array, string)
#3 /bitnami/mediawiki/extensions/PageForms/includes/PF_ParserFunctions.php(401): Html::element(string, array, NULL)
#4 /opt/bitnami/mediawiki/includes/parser/Parser.php(3340): PFParserFunctions::renderFormInput(Parser, string)
#5 /opt/bitnami/mediawiki/includes/parser/Parser.php(3047): Parser->callParserFunction(PPFrame_Hash, string, array)
#6 /opt/bitnami/mediawiki/includes/parser/PPFrame_Hash.php(253): Parser->braceSubstitution(array, PPFrame_Hash)
#7 /opt/bitnami/mediawiki/includes/parser/Parser.php(2887): PPFrame_Hash->expand(PPNode_Hash_Tree, integer)
#8 /opt/bitnami/mediawiki/includes/parser/Parser.php(1556): Parser->replaceVariables(string)
#9 /opt/bitnami/mediawiki/includes/parser/Parser.php(651): Parser->internalParse(string)
#10 /opt/bitnami/mediawiki/includes/content/WikitextContent.php(374): Parser->parse(string, Title, ParserOptions, boolean, boolean, NULL)
#11 /opt/bitnami/mediawiki/includes/content/AbstractContent.php(590): WikitextContent->fillParserOutput(Title, NULL, ParserOptions, boolean, ParserOutput)
#12 /opt/bitnami/mediawiki/includes/EditPage.php(4282): AbstractContent->getParserOutput(Title, NULL, ParserOptions)
#13 /opt/bitnami/mediawiki/includes/EditPage.php(4187): EditPage->doPreviewParse(WikitextContent)
#14 /opt/bitnami/mediawiki/includes/EditPage.php(2965): EditPage->getPreviewText()
#15 /opt/bitnami/mediawiki/includes/EditPage.php(701): EditPage->showEditForm()
#16 /opt/bitnami/mediawiki/includes/actions/EditAction.php(71): EditPage->edit()
#17 /opt/bitnami/mediawiki/includes/actions/SubmitAction.php(38): EditAction->show()
#18 /opt/bitnami/mediawiki/includes/MediaWiki.php(527): SubmitAction->show()
#19 /opt/bitnami/mediawiki/includes/MediaWiki.php(313): MediaWiki->performAction(Article, Title)
#20 /opt/bitnami/mediawiki/includes/MediaWiki.php(940): MediaWiki->performRequest()
#21 /opt/bitnami/mediawiki/includes/MediaWiki.php(543): MediaWiki->main()
#22 /opt/bitnami/mediawiki/index.php(53): MediaWiki->run()
#23 /opt/bitnami/mediawiki/index.php(46): wfIndexMain()
#24 {main}

Not Working: MediaWiki 1.35.1 PHP 7.3.27 (apache2handler) Page Forms 5.1

Working fine: MediaWiki 1.31.3 PHP 7.2.33 (apache2handler) Page Forms 4.5.1

--Tsch42 (talk) 13:49, 16 April 2021 (UTC)

Please upgrade to the latest version, 5.2. Yaron Koren (talk) 13:59, 16 April 2021 (UTC)

Thank you. Version 5.2 fixed the Bug. --Tsch42 (talk) 15:20, 16 April 2021 (UTC)

Browser side autocompletion overlaps datepicker popup

As you can see on this picture, on Chrome https://ibb.co/HPHdLzB

(On Firefox it is less annoying, because the autocompletion suggestion appears only if you click a second time in the input. On Chrome it appears as soon as the input gets focus)

Two questions :

• Which immediate workaround ? I tried to add autocomplete="off" with a JS in Common.js, but it doesn't work, I think because the datepicker is not loaded yet when the script is run.
• To prevent this, shouldn't the datepicker type be coded to have the attribute autocomplete="off" ?

Thanks --Varlin (talk) 14:28, 21 April 2021 (UTC)

What version of Page Forms are you running? Yaron Koren (talk) 18:09, 21 April 2021 (UTC)

Forms v 4.9.3 with MW 1.34.0 --Varlin (talk) 11:32, 22 April 2021 (UTC)

Okay, that's what I thought. In version 5.0 of Page Forms, the datepicker input was changed to use a different JS library, so this problem has probably gone away. I would suggest upgrading to the latest version of PF. Yaron Koren (talk) 13:16, 22 April 2021 (UTC)

Thanks for your answer, I'll do that. --Varlin (talk) 22:22, 22 April 2021 (UTC)

PAGENAMEE rather than PAGENAME for formlink target?

On my wiki I have lots of pages with special characters in their names, and had to switch from PAGENAME to PAGENAMEE (URL encoded name rather than plain pagename) when using formlink, I think this should be the standard recommendation? I'm happy to make the changes to e.g. Extension:Page_Forms/Linking_to_forms, but wanted to check whether there are any objections first. --Plexish (talk) 19:56, 21 April 2021 (UTC)

PAGENAME works fine for me, even with special characters. What's an example of a special character that doesn't work for you with PAGENAME? And what versions of Page Forms and MediaWiki are you running? Yaron Koren (talk) 02:09, 22 April 2021 (UTC)

I think that problem occurs with page names containing apostrophes, although I haven't checked the latest version of PF to see if that's still the case. Cavila 12:08, 22 April 2021 (UTC)

Oh, I see - yes, there's still a problem with the handling of apostrophes. That's a bug that needs to be fixed, but until then, yes, it probably makes sense to change PAGENAME to PAGENAMEE in the documentation. Yaron Koren (talk) 13:18, 22 April 2021 (UTC)

Graphical bug with datetimepicker

I'm having this issue with the datetimepicker: (guess what goes here, it would not let me upload to MW or post the link)imgur.com/a/J6kYj0H (looks glitchy) any suggestions on resolving it? More information you may need? --Plexish (talk) 20:56, 25 April 2021 (UTC)

We fixed it by adding

$("input[name='Answer[date]']").attr('type', 'datetime-local');

$("input[name='Answer[date]']").attr('class', '');

to Common.js, to use the browser default date picker, if anyone else runs into this. --Plexish (talk) 18:01, 26 April 2021 (UTC)

What versions of MediaWiki and Page Forms are you running? Yaron Koren (talk) 20:57, 26 April 2021 (UTC)

Version - Page Forms 5.1 and MW 1.35.1. --Plexish (talk) 13:01, 27 April 2021 (UTC)

Images are no longer displayed in post buttons

With the latest updates (2.5 and 2.5.1), the link text field of a formlink form call in post button format no longer accepts an image.

Example: {{#formlink:form=myForm|link text=[[File:duplicate.png|32px|Duplicate|link=]] Duplicate|link type=post button|query string=myTemplate[field1]=value1&myTemplate[field2]=value2&...}}

What is displayed : <img alt="Duplicate" src="/myWiki/images/666/666/Duplicate.png" decoding="async" title="Duplicate" width="32" height="32" data-file-width="64" data-file-height="64" /> Duplicate in full text in a nice but not wanted blue button with an right-arrow picture.

--Megajoule (talk) 15:25, 29 April 2021 (UTC)

Yes, that's true. It's due to a gradual move-over of all of Page Forms' functionality to use OOUI, MediaWiki's own UI JS library. One of the side effects of that is that there is less flexibility to the display than when a lot of this functionality was just simple HTML tags. I think in general that's good, because it ensures more consistency with the rest of the MediaWiki interface, but of course there are drawbacks as well. What was the specific image you had, by the way? Is there anything comparable to it in this list of OOUI icons? Yaron Koren (talk) 18:31, 29 April 2021 (UTC)

My picture looks like this one. Between us, the recent changes of JS libraries in Page Forms seem to me more like regressions than progress... We should be able to choose between the old version and the new one. That said with all due respect to the work of the developers. --Megajoule (talk) 07:54, 1 May 2021 (UTC)

That looks like a "copy" icon, and unfortunately I think OOUI lacks such a thing (although this maybe comes close). This might be a different conversation if OOUI had a copy icon. We can talk about some options to get your old icon back in, but now I'm curious: besides this, what are the other flaws you see with the current JS? Yaron Koren (talk) 23:41, 2 May 2021 (UTC)

Even if there was an icon corresponding to the copy function, I think it's a shame to remove the possibility to customize the interface. In this logic, why not impose CSS styles for any instance of MediaWiki and remove Mediawiki:Common.css? 😱

Regarding the JS flaws, some new entry types seem to me less ergonomic than the previous ones:

• Combobox : when you enter a combobox field, the box used to update the value is displayed below the initial field. When you have another field below the combobox field, it seems you're updating this second field. The previous presentation was less confusing : the link to the initial (top) box of the whole drop-down list was more obvious.
• Datetimepicker: impossible now to type directly a date (dd/mm/yyyy) and a time (hh:mm) + the first day is necessarily Sunday (even if MediaWiki:Pf-datepicker-firstdayofweek is set to 1).

--Megajoule (talk) 15:37, 4 May 2021 (UTC)

Thank you for this feedback. I'm guessing that, if you put some "span" tag around the #formlink call, and give it its own class, you could probably fully customize the display of the button if your CSS was detailed enough. It would definitely take more work, though. For the combobox - there's work going on now to change the combobox display (from Select2 to OOUI), which I think will make the interface better. For dateimepicker - right, the "firstdayofweek" setting no longer has any effect. You can change the first day of the week from Sunday to Monday if you change your wiki's language from "en" to "en-gb", but that's kind of a hack, and of course it only works if your wiki is in English. Yaron Koren (talk) 17:07, 12 May 2021 (UTC)

How to get user list with the form autocompletion (from the namespace User:)

In a form, when using autocompletion, i'm not able to get the list of actual users who have an account ou the mediawiki. the "values from namespace" is not giving any result Is there any raison for that or any specific configuration to get the list of users ?

-> The solution si that the user page must be created to get it in the list. One way to do it automatically is to use this extension : 'CreateUserPage'.