Extension talk:Page Forms

From mediawiki.org
Jump to navigation Jump to search

Behavior of the field "text with autocomplete" with "values from property".[edit]

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 input type=token and add a maximum of one value, max values=1. 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 Unknown dependency: ext.pageforms.jstree 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[edit]

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".


{{#autoedit:form=MyForm|query string=MyTemplate[MyProp1]=ABC| ... }}

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[edit]

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 libs/PF_autoedit.js 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[edit]

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 {{{for template}}} call, and while it works great, the label=XXX inside {{{field}}} 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[edit]

Is it possible to do this? I'd ideally like to use the namespace prefix chosen on Form:MyForm 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 Ixian Insignia SM.png 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 preload={{NAMESPACE}}:ABC {{#show:STEP:Main|?{{NAMESPACE}}CurrentRelease}} 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 ?[edit]

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[edit]

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﹠Evo)talk 11:13, 14 January 2021 (UTC)

Using #autoedit in the (SMW) property namespace[edit]

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.

{{#autoedit:form=Data item|target=Property:Customer|link type=button|link text=Reload Customer List|query string=Data item[Editdate]={{CURRENTDAY}} {{CURRENTMONTHNAME}} {{CURRENTYEAR}}|reload}}

It gives the error: Error: #autoedit cannot be called on pages in the "Property" namespace on this wiki.

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 [[Allows value:: used by SMW. Thanks --Felipe (talk) 09:37, 15 January 2021 (UTC)

My bad, it can be done with $wgPageFormsAutoeditNamespaces but I did find that the below syntax does not work.
Using $wgPageFormsAutoeditNamespaces[] = NS_PROPERTY; which gives Array( [0] => 0 [1] => NS_PROPERTY )
Using $wgPageFormsAutoeditNamespaces[] = 102; which gives Array( [0] => 0 [1] => 102 ) 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[edit]

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:

{{{field|file|input type=tokens|uploadable|max values=1|values from namespace=File}}}

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)

hacking link >>> Turning_forms_into_tabbed_sections ?[edit]


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

Issues with display=spreadsheet and form input with ampersands[edit]

I know that escaping ampersands into & is important for things to show up in javascript, but sadly, once it is saved to a template, the & 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[edit]

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!

-- 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?[edit]

#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 values from property= or values from concept= or property=, along with existing items only. 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 {{{field|}}} or {{{info|}}}) 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)