Extension talk:Page Forms

Behavior of the field "text with autocomplete" with "values from property".
MW 1.35.1 / SMW 3.2.2 / PF 5.0.1

In a field "text with autocomplete" with the option "values from property", it is now impossible to update a previous value. You have to enter the whole string again. Too bad when it comes to editing a 135-character string. --Megajoule (talk) 20:31, 4 January 2021 (UTC)


 * Well, "text with autocomplete" no longer really exists - it's just an alias for either "combobox" or "tokens". Which one is it, in this case? Yaron Koren (talk) 00:29, 6 January 2021 (UTC)


 * Oh dear, I hope this is not permanent. Like I may have said before, tokens and combobox are not my kitchen knives for everything so I really miss "text/textara with autocomplete". The extra difficulty involved in editing a token and the impossibility of editing text in a combobox are only two reasons. A side-effect I noticed after upgrading and using a form is that I lost some data, apparently because combobox, previously text with autocomplete, couldn't handle the semi-colons. Cavila 13:14, 6 January 2021 (UTC)


 * @Yaron : In my case, it's a combobox. When I switch to "tokens", I can enter several values, which I don't want for this field. --Megajoule (talk) 18:00, 6 January 2021 (UTC)


 * Right, I never really realized before that "combobox" doesn't let you edit an existing value. That's a big problem, and I hope there can be a fix for it. Yaron Koren (talk) 18:21, 6 January 2021 (UTC)


 * There is a workaround. You can use  and add a maximum of one value,  . A little weird maybe, but that should work. Cavila 19:42, 6 January 2021 (UTC)


 * Okay, I just checked in what may be a fix for this - now, if you open the combobox dropdown, the current value shows up in the text entry field and can be edited. If anyone wants to get the latest code and try it out, I'd be curious what you think about the current interface. Yaron Koren (talk) 18:51, 7 January 2021 (UTC)


 * It looks very good to me! Thank you Yoren. --Megajoule (talk) 09:55, 9 January 2021 (UTC)


 * Thanks Yaron. I didn't work for me at first because of a javascript error. There's a spinning wheel that keeps on spinning probably because of  in the console. I couldn't edit text with autocomplete or token inputs and show on select wasn't working. Another form I tried though did not have this issue and the new, editable combobox is working rather nicely! Clicking outside a token after double-clicking still results in deleting it, by the way. Cavila 14:14, 9 January 2021 (UTC)


 * Great! If you're seeing other issues, please create separate sections for them (or Phabricator tasks). Yaron Koren (talk) 23:48, 10 January 2021 (UTC)

[OPEN] Autoedit parser function drops dates
MW 1.34, PF=5.0.1 (731d226, Dec. 28th)

Prior to 5.0 #autoedit parser function could update templates without issue. Since PF 5.0 (and including 5.0.1) the autoedit parser function is dropping dates from the template when used. The form input type in question is "datepicker".

Example:

turns page with wikitext:

into page with wikitext:

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

[INQUIRY] adding an "Are you sure? Y/N?" dialogue box to #autoedit button
Yaron, I'd like to add an "Are you sure? Y/N" pop-up dialoged box to the #autoedit button from Page Forms.

Do you have any advice on the easiest way to do this? Would it be easier to: A) modify the PF extension to provide this as an option in the #autoedit parser function call?, or B) make a #widget to intercept the #autoedit button click and provide the dialog box without changing PF at all.

Thanks! /Rich Revansx (talk) 14:06, 8 January 2021 (UTC)


 * That's interesting. I don't see how you could use a Widget for this (where would you put the #widget call), so it seems like there are two options: modify Page Forms, or add in some custom JavaScript, like within MediaWiki:Common.js. I don't know which of these is better; I guess it depends on how useful a feature this is. Yaron Koren (talk) 16:27, 8 January 2021 (UTC)


 * I'd really like to try my hand at adding this to Page Forms as a patch for you to consider. I think if you can point me to the file where the #autoedit button is rendered I can attempt to make this feature. Is it easy to say which PF file renders the button? Revansx (talk) 17:59, 8 January 2021 (UTC)


 * Maybe just confirm that what I'm looking to do might be appropriately added to  Revansx (talk) 19:20, 8 January 2021 (UTC)


 * That sounds right, yes. Yaron Koren (talk) 19:46, 8 January 2021 (UTC)


 * [UPDATE 2020-01-09] I've made a local edit to PageForms/libs/PF_autoedit.js that generate the confirm dialogue box. Here's a link to the commit in my git fork for you to see Is there a quick and dirty way of obtaining the autoedit button text as a variable in PF-autoedit.js so I can wrap the confirmation popup in an IF statement and test for key words? Revansx (talk) 21:10, 9 January 2021 (UTC)

Spreadsheet not showing form defined field labels
I had originally posted this as an anon earlier but ended up making an account so I could go onto Phabricator and issue bug reports as I have ran across another but while looking into this one, so rewording the question as a real user.

I am attempting to use the display=spreadsheet in a  call, and while it works great, the label=XXX inside   statements don't seem to show up at all and I only get the actual field template name. Been looking through the code to find what could be causing it.

Anyone else having problems like this? It didn't bother me when there was one spreadsheet in a form as I originally found this bug a few days ago, but the form I'm working on right now is a bit larger and has many multipleTemplate's and I am not wanting to change the name of the fields themselves to the more generic labels I want to use due to needing to push values into properties. - RinaCY 8 January 2021, at 20:56 (UTC)


 * Good point - I never tested labels with the new spreadsheet display code. I just checked in what I think is a fix for this. Yaron Koren (talk) 19:52, 11 January 2021 (UTC)

#forminput & #formlink - Using chosen "namespace selector=" value in "preload=" page name
Is it possible to do this? I'd ideally like to use the namespace prefix chosen on  as a string for my preload page name. It seems like this should be possible or would be a useful feature to add if not. ~z929669 Talk 06:00, 10 January 2021 (UTC)


 * I'm not sure I understand. Are you saying that, if "preload=ABC" is set, and the user selects the "Help:" namespace from the namespace selector, then the page that is preloaded should not be "ABC" but rather "Help:ABC"? Yaron Koren (talk) 23:47, 10 January 2021 (UTC)


 * Exactly what I mean. Additionally, I want to use "Help" anywhere else in the page-name definition like  The value selected for the namespace is needed within the page name definition, and there is no place to grab this at the time the page is created, since the propagation begins in the "Form:" namespace ... I just get "Form" as it stands, so it is not variable according to what is chosen from possible namespaces. ~z929669 Ixian_Insignia_SM.png Talk 16:31, 14 January 2021 (UTC)

Is it possible to target the edition of a specific subobject with #autoedit ?
Everything is in the title. Thks a lot ! Paul LEMPERIERE (talk) 22:29, 12 January 2021 (UTC)


 * Do you mean editing a specific instance of a multiple-instance template? If so, yes, I think it's possible, with something like "TemplateName[2][FieldName]=Value" in the query string. There are some bugs in the current handling, though. Yaron Koren (talk) 01:20, 13 January 2021 (UTC)


 * Yes I mean editing a specific instance of a multiple-instance template. The problem with "TemplateName[2][FieldName]=Value" is that I can only target the instance with its position [1], [2], etc... and this can change. I'd like to target an instance with a value of a field tobbe sure to target the good one. Is it possible to do something like that ? Paul LEMPERIERE (talk) 07:52, 13 January 2021 (UTC)


 * There's no way to do that directly in #autoedit - you would have to basically construct an #autoedit call, using parser functions or Scribunto, to run a query to get the right instance number. I suppose it could be useful to have something like a "where=" parameter within #autoedit. Yaron Koren (talk) 15:03, 13 January 2021 (UTC)


 * Thank you for the answer. I'll follow your advice. It could be very nice yo have a native parameter with #autoedit for that. Paul LEMPERIERE (talk) 19:46, 13 January 2021 (UTC)

Input_type examples
I'm attempting to use pageforms to build a form at this page. However, I've bneen struggling to get some of the input types to work and the manual on mediawiki is a bit sparse on examples. For example radiobuttons, it took me a while to find the section about values and mappings in a lower section. There's a link to an example for a few different input types in the last section, but examples section-by-section (even if collapsed) would be super useful. Indeed, links to an example form that uses one of each would be even better, especially for the more complex aspects like templates and conditional show-on-select. T.Shafee(Evo&#65120;Evo)talk 11:13, 14 January 2021 (UTC)

Using #autoedit in the (SMW) property namespace
The below code used to work but after upgrading Mediawiki and Page Forms it does not anymore. The below code is on a page in the User namespace.

It gives the error:

This is correct because in the Page Forms documentation it says:

"Only pages that are in any of so-called 'content namespaces' can be the target of an autoedit. This restriction does not apply to older versions of Page Forms."

Is there a reason why this was done and can I add a namespace manually?

We use this to reload data with Externaldata in  used by SMW. Thanks --Felipe (talk) 09:37, 15 January 2021 (UTC)


 * My bad, it can be done with  but I did find that the below syntax does not work.
 * Using  which gives
 * Using  which gives   actually works :-) --Felipe (talk) 11:36, 15 January 2021 (UTC)


 * Right, it should be SMW_NS_PROPERTY. Yaron Koren (talk) 15:39, 15 January 2021 (UTC)