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)


 * It works! Thanks! I'm glad I could help out with that other spreadsheet bug I did a patch on.  I have found a few more of a similar bug with the one I wrote the quick patch for last week, but I haven't had a chance to actually delve into it.  I'll try to when I run out of rush fixes! RinaCY 15 January 2021, at 09:08 (AKST)

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


 * Right, okay. None of what you're asking about is possible, I don't think. You might be better off creating different forms for the different namespaces. Yaron Koren (talk) 18:55, 18 January 2021 (UTC)


 * I assumed that might be the case, so I have already created the separate forms, and that works. Thanks! ~z929669 Ixian_Insignia_SM.png Talk 21:34, 18 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)

Uploadable tag doesn't add to token field
I have several file upload fields in my forms I'm building up, and finding that the current state of them is somewhat inconvenient for users. I had thought (maybe misremembered), that when you used the Upload button, it added the filename to the token field automatically. This doesn't seem to be the case anymore. The field in question is this: I am telling everyone to copy the name of the Destination Filename now to paste it into the field after they upload as a workaround.

I did also see one convenience thing with the upload modal that would help people out when using it.. Prepopulating the Destination Filename with the name of the uploaded file, so that if it already had the right name before uploading, they wouldn't have to do more copying and pasting as I'm having to have them do above too. This one I believe is an issue of the normal mediawiki Special:Upload page having it's javascript change and the modal version included with PF missing something? I'll try to look into it at some point too. --RinaCY (talk) 18:52, 15 January 2021 (UTC)


 * Yes, this is a bug. Unfortunately, I haven't been able to figure out yet how to get the code to add a value into "tokens" once the upload has happened - it's trickier than it seems. For the second issue, you may be asking about "default filename", but I'm not sure. Yaron Koren (talk) 18:58, 18 January 2021 (UTC)


 * The 2nd issue is that currently right now in the upload modal, if you browse for a file it doesn't default the name in the Destination Filename field to the name of the file you've selected. It makes you need to copy the name of the item before you upload it and put it into the destination field after the you've selected the item to upload. In the standard upload file page, it defaults to the filename of the selected file when you browse for it into the Destination Filename field, making it so that if the file is named good before upload you don't have to type it in again. --RinaCY (talk) 04:28, 26 January 2021 (UTC)

hacking link >>> Turning_forms_into_tabbed_sections ?
https://www.mediawiki.org/wiki/Extension:Page_Forms/Defining_forms#Turning_forms_into_tabbed_sections


 * Is this a question? Yaron Koren (talk) 18:59, 18 January 2021 (UTC)

Issues with display=spreadsheet and form input with ampersands
I know that escaping ampersands into &amp;amp; is important for things to show up in javascript, but sadly, once it is saved to a template, the &amp;amp; stays in the value when using display=spreadsheet. It's a bit sneaky in many ways as I didn't notice it was doing it, but it definitely breaks things if there is a Property Has Type::Page that uses an ampsersand in the name (since URL ampersands are % encoded rather than & and strings containing & encoded characters cannot be used in page names). I feel bad constantly finding bugs like this! --RinaCY (talk) 00:40, 19 January 2021 (UTC)

"default=current user" not working for multi-instance templates on pre-existing pages
MW 1.34.4 // SMW 3.2.2 // PF 5.0.1 (cbb0fe0)

The documentation here (https://www.mediawiki.org/wiki/Extension:Page_Forms/Defining_forms) mentions that "default" values only take effect when creating new pages. However, under previous versions of Page Forms, default values were still being inserted for newly added multi-instance templates on pre-existing pages and the username for the current user was correctly being inserted when "default=current user" was specified. Since I updated to the latest version, the string "current user" is being inserted in the form field instead of the actual username. Is this a bug? Should I avoid using default values for multi-instance templates?

Really appreciate all the work put into this extension, thanks a bunch!

--192.222.211.196 20:35, 20 January 2021 (UTC)


 * Sorry about that! That's definitely a bug. I just checked in what I think is a fix for it. Yaron Koren (talk) 18:04, 21 January 2021 (UTC)

#forminput: autocomplete on property or query result?

 * 1) forminput features the abilities to assist the user with autocompletion; however, this seems to be limited to either catagory or namespace. Ideally, I would like to autocomplete on a property, concept, or even better, a #ask query result. This would constrain input to valid text without allowing invalid creation of pages that would otherwise be excluded from downstream logic. Is any of this possible? ~z929669 Ixian_Insignia_SM.png Talk 19:47, 21 January 2021 (UTC)
 * There are ways! Use something like  or   or , along with  .  I use this constantly to prevent anyone from using options that aren't set by another page that has naming conventions set.  There are also things like using the input=regexp type. And if you want an #ask query, use Extension:Semantic_Forms_Select --RinaCY (talk) 19:55, 21 January 2021 (UTC)


 * But I think those methods are not available for #forminput specifically; although, I have not tried simply because these options are not listed for that function ... also, that function is not part of the form itself. I also use some of these methods within the Form itself (available for  or  ) but not in the form call, which seems more limited.~z929669 Ixian_Insignia_SM.png Talk 21:03, 21 January 2021 (UTC)


 * Right, for #forminput there's only "autocomplete on category" and "autocomplete on namespace". I haven't really looked into other possibilities, and actually I'm not sure if anyone has asked about it. The nice thing about the two current ones is that the user will only ever see page names that already exist on the wiki - so they can know right away whether a page is already there or needs to be created. (How important that is, I don't know.) Is there a particular use case for wanting to autocomplete on some SMW information? Yaron Koren (talk) 23:09, 21 January 2021 (UTC)


 * Yes, autocompleting on a Property or Concept helps users to see existing examples (e.g., if spaces are substituted by underscores or dashes) or form of existing values. It also helps to prevent unintended duplication of data entered if the string already exists (so uniqueness & format constraints would also be useful for these 'pre'-form fields). Allowing constraints to a given query is also very useful to focus the autocomplete on the relevant. In my use case, we have guides with many different versions and in several different classifications, and the versioning format is #.#.#, which isn't necessarily predictable. It is impractical and uninformative to use categories or namespaces to differentiate among the version strings. UPDATE: I just encountered a situation where I will need to add/alter categories in order to make use of "autocomplete on category" parameter. If "autocomplete on concept" was available, I could simply create a concept page associating the relevant properties and categories rather than touching hundreds of pages to modify the categories. I do adhere pretty strictly to attributing only a single category to a given page with few exceptions, so this exercise would still be necessary without the concept constraint, but I would personally always use concept or query if it were possible to constrain the autocomplete to either of those. ~z929669 Ixian_Insignia_SM.png Talk 21:41, 22 January 2021 (UTC)


 * Oh oops, sorry about that! I have actually put work into not having any form actually use #forminput and only #formlink.. I just have templates that build the name of a page based off the fields in the form when they hit save, for new pages. Thought it was easier just to take it out of the hands of everyone rather than hope they can get things to look right otherwise. --RinaCY (talk) 22:23, 22 January 2021 (UTC)


 * I'm still not convinced about the benefit of "autocomplete on property" or "autocomplete on concept" - maybe in part because a fair number of people who use Page Forms don't use Semantic MediaWiki, so this would only a partway solution. But I also still don't understand the use case. Are there cases where pages called, say, "London guide 1.0" and "London guide 2.0" use different forms? Or they use the same form, but you only want people to be able to edit one of those? Yaron Koren (talk) 16:11, 25 January 2021 (UTC)


 * If I was needing people to name things a specific way but didn't force it from the form itself using the 1 step method, I would likely just add in instructions on what names things should be for each form using the noinclude area. --RinaCY (talk) 04:31, 26 January 2021 (UTC)


 * Well ... people tend to overlook instructions, which is why #formlink is preferable in most cases; however, all of my approaches to use #formlink thus far have failed due to the downstream complexity of articulating with a fairly complicated form that uses 20 iterations of multiple-instance templates in order to build a page. Ahh well, I think I will give up on this one. Thanks anyway! ~z929669 Ixian_Insignia_SM.png Talk 04:37, 27 January 2021 (UTC)

Radiobutton labels not working
At first I had the impression that the radiobuttons stopped being clickable but the issue seems to be with the labels. I've only checked so far with "Show on select" in multiple-instance templates. Not sure if this is directly relevant but there seems to be a mismatch between the values used to link input and label. For instance, the label has, while the input itself has. Cavila 21:51, 28 January 2021 (UTC)


 * Fixed. Yaron Koren (talk) 17:57, 29 January 2021 (UTC)


 * 💪 Thanks! Cavila 19:54, 30 January 2021 (UTC)

Autocompletion Fails With Spaces
Autocompletion works well with continuous strings ... until you get to a space. Then the results become empty ... so typing "mammoth" correctly brings up any relevant results that update in real time as you type each char, so no issue here. But typing "mammoth tusks" fails with "no results" as soon as the space char is entered, even after tying "tusks". Similarly, any search using "a search term" give no result after the 'a', which is especially inconvenient (as is "the ..."). Im assuming this is a bug or unintended behavior rather than a limitation of autocomplete, because the standard Mediawiki search bar autocomplete does not exhibit this issue. I am specifically getting this with autocompletion via #forminput > autocomplete on category ~z929669 Talk 20:32, 2 February 2021 (UTC)