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)


 * That indeed is a bug. It doesn't happen for me, though. What version of Page Forms are you running? And is this a public wiki? Yaron Koren (talk) 00:02, 3 February 2021 (UTC)


 * Running PF 5.1-alpha on 1.35.1 ... not a public wiki at this point but in dev stages. happy to give you access if you want to have a look. Well, I guess you would only be able to read without creating an account though. ~z929669 Ixian_Insignia_SM.png Talk 03:21, 3 February 2021 (UTC)


 * That would be helpful, yes - no login is fine, as long as I can see that problem happening. You can send me the info at yaron57 at gmail.com. Yaron Koren (talk) 03:29, 3 February 2021 (UTC)


 * Sounds good. Email sent. ~z929669 Ixian_Insignia_SM.png Talk 04:04, 3 February 2021 (UTC)


 * We determined that it was an issue with Extension:DisplayTitle ... either a conflict or a side effect of using both together; although, I have been seeing other issues since enabling that extension so running without for a while to see if the oddities go away. ~z929669 Ixian_Insignia_SM.png Talk 04:46, 3 February 2021 (UTC)

Old Form Not Working
I imported this page from old version of mw, old version of page forms, into the latest version of both. Nothing loads except: Form:Retort New Retort Page Enter STATEMENT below. A new Draft will be created, with the STATEMENT as its title.

Did the syntax change? Or, do i need to run some maintenance script?

Here's the page content: -Johnywhy (talk) 06:11, 3 February 2021 (UTC)


 * Please check the JavaScript console, if you know how to do that - I'm guessing that there's some JS error that is preventing the form input from getting displayed. Yaron Koren (talk) 18:53, 3 February 2021 (UTC)

Leaflet input type and starting bounds
Hi, I can't find the way to use the starting bounds in the leaflet input. I'm using Mediawiki 1.35 and PF 5.1-alpha (ed9394b).

shows the full world map. Am I doing something wrong ?

Best, Ludovic.


 * Sorry about that. This was a bug in the documentation - "starting bounds" is only supported for "googlemaps". There's no good reason for that, but that's how it is at the moment. I just updated the documentation to reflect that. Yaron Koren (talk) 19:12, 5 February 2021 (UTC)
 * Ok, many thanks for your answer. Ludovic Strappazon (talk) 09:15, 8 February 2021 (UTC)

Determine where on a page the template is added
So I've got the form working fine, I just need to know how I can get it to display in a certain place on the page. I want my template to show up on this page, which is what I've managed to do, but I'd like it to appear below the part if possible. Is there any way I can achieve this? Hb1290 (talk) 02:38, 12 February 2021 (UTC)


 * Just add "/Intro" as another template in the form, this one at the top, with no fields, just a "for template" and "end template" tag. Yaron Koren (talk) 03:56, 12 February 2021 (UTC)
 * That worked, thank you! Hb1290 (talk) 05:48, 12 February 2021 (UTC)

Problem with multi-token field when using mapping (MW 1.35, PF 5.1)
Hi, I'm still having a problem when I use a field allowing multiple tokens, displayed with a mapping property. When I first edit the page, everything's fine, values are correctly mapped. But when I re-edit the page, values are no longer mapped. Steph. -> My guess is that the value cannot be mapped because it is taken as a single string, instead of a comma separated array.

HowTo Debug "Create or Edit" Process from PageForms
I have new fresh install media wiki with PageForms from git repository If I try to create a simple Form with "Special Pages" -> "Create a Form" I see a error: Some parts of the edit form did not reach the server; double-check that your edits are intact and try again.

But I can create and save a Form bei "Edit Source"

i.e.

Dies ist das Formular „FAQ“. Um eine Seite mit diesem Formular zu erstellen, gib den Seitennamen in das Eingabefeld unten ein. Sofern bereits eine Seite dieses Namens vorhanden ist, wirst du automatisch zum Bearbeitungsformular der Seite weitergeleitet.



Solution
Freitext:

If I try to create a new page with this PageForm, after giving a Name and clicking the "Create or Edit" button I see only a blank Page with loading.gif symbol that never finish

No Errorr messages at Web page at all and nothing special in the debug log File.

What goes wrong here and how can I enable some Debugging for PageForms at creating process?


 * This is a problem that sometimes happens, not just in Page Forms but in MediaWiki in general. (That specific error message comes from MediaWiki.) If you try using the "Create form" form again, it may work this time. Yaron Koren (talk) 17:20, 18 February 2021 (UTC)
 * Yes, that is annoying but can be avoided by creating the forms via "Edit source". The second problem is a bigger one, and make the whole Forms useless at the moment because all tries to create a Page from a Form end with loading page:-(
 * I could reproduce this with MediaWiki 1.35, SMW 3.2 and PageForms 5. The issue seems to be, that PageForms does not send the "wpUltimateParam" parameter, which is checked by "EditPage". See https://gerrit.wikimedia.org/r/c/mediawiki/core/+/443867/2/includes/EditPage.php Osnard (talk) 14:09, 26 February 2021 (UTC)
 * I have created a patch that solves this issue: https://gerrit.wikimedia.org/r/c/mediawiki/extensions/PageForms/+/667168 Osnard (talk) 14:21, 26 February 2021 (UTC)
 * With the Patch the first Problem is solved for me. Big Thanks for this! The second Problem ist still here, every try to create a new Page from a Form ends in a white Screen with loading.gif animation in the middle of the screen. I have uploaded a short gif video (https:)//imgur.com/OiA1RKi It looks like mentioned T267724 on phabricator, so I double checked all file permissions on my installation. How can I debug this to see what here really happens?
 * filled a bug report on phabricator T276663

Ampersand handling is so frustrating
I am struggling with ampersand so much right now.

If I am using query string= in a formredlink to create a page, and the query string happens to have an ampersand in it, the ampersand gets html escaped into the class="select2-match-entire" span for the field I'm sending information into. The form itself doesn't un-escape this when the form is submitted, and my pages now have a bunch of html escaped ampersands in their template definitions. This causes conflicts between pages generated by query string and manually input pages using non escaped versions of the same string with SMW. --RinaCY (talk) 23:51, 22 February 2021 (UTC)


 * Curious if you have tried subbing the amper in the form call with the encoded value like  (without internal spaces) or   ... not clear if you are using '&' and getting back '%26' or if you are using the encoded value. ~z929669 Ixian_Insignia_SM.png Talk 19:52, 24 February 2021 (UTC)


 * I just checked in what I think is a fix for this. Yaron Koren (talk) 22:02, 24 February 2021 (UTC)

#forminput 'popup' option breaks dropdown behavior
The popup option works great otherwise. I can still get dropdown to work, but I need to keep the mouse click depressed and unclick on selection. I'm not sure if this is caused by the change to the window borders or if it's impacted by CSS. You can test here: https://stepmodifications.org/wikidev/Form:Mod ~z929669 ... this is a DEV environment, so create pages without concern or cleanup. Talk 19:38, 24 February 2021 (UTC)


 * What am I supposed to do there? Yaron Koren (talk) 22:06, 24 February 2021 (UTC)


 * Verify the issue if it's not clear from my description: Dropdown fields don't stay "dropped down" in popups. Just add any text into the field, click create/edit, and try to select a value from one of the dropdown fields. Then you should see the issue. I need to understand if it is reproducible on your side or if I have some specific incompatibility. ~z929669 Ixian_Insignia_SM.png Talk 14:47, 25 February 2021 (UTC)


 * I can't reproduce this problem locally, no. And unfortunately I can't see the error on your site, because I don't have a user account. Yaron Koren (talk) 19:51, 25 February 2021 (UTC)


 * I figured it could be CSS or skin related, so if you cannot reproduce, it must be related to the skin affecting the dropdown widget. I'm using Chameleon 3.x. any chance you tried to reproduce under that skin, or are you aware of this sort of play between skin and PF? ~z929669 Ixian_Insignia_SM.png Talk 19:04, 26 February 2021 (UTC)


 * I haven't tried it with Chameleon or any other responsive skin; maybe that's the issue. Yaron Koren (talk) 19:42, 26 February 2021 (UTC)

Create an on-wiki to do list
I'd quite like to have a to do list on my wiki and have buttons/links beside each item:
 * Edit the item (simple enough - link to the PF form).
 * Mark the item as done.
 * Delete the item entirely. This could link to the  page but could it be done without that intermediate step?

Would this be possible? Thanks.

Maybe the answer instead is just to display the items as a normal list (from a to do list Cargo table) on the page, and to use Special:MultiPageEdit for marking as done or deleting. Jonathan3 (talk) 10:47, 26 February 2021 (UTC)


 * Hi - I think the 2nd one could be done using #autoedit. The 3rd one, I don't know - it may require a new extension. (Although one-click delete is risky, of course.) For the 1st one, #formlink with the "popup" parameter may be helpful. Yaron Koren (talk) 14:48, 26 February 2021 (UTC)


 * Thanks again Yaron. The popup is great for editing, and autoedit works well for swapping between "Yes" and "No" in the Cargo "Done" boolean field. I ended up putting a "Delete page" link in the popup form as I agree with you about one-click deletion (and also I put an "Edit page" link there too). Jonathan3 (talk) 09:55, 1 March 2021 (UTC)

Can not save a form containing a visual editor textarea input field using a super_page query string in the #forminput
MW 1.35.0/PF 5.1

My form adds the date to the page title using super_page in the query string.

All worked well until visualeditor integration.

I am unable to save or preview a form that contains a visual editor textarea and #forminput query string=super_page.

No action occurs when clicking either the Save or Preview buttons.

Save/Preview works fine if I switch to wikitext editor when using the form. Save/Preview also works if I remove super_page from #forminput, and manually add the subpage to the page title in the form start field.

Any solutions or work arounds that would add the date to the page title at form start would be appreciated.

Thank you for all of your wonderful contributions to Mediawiki. I am currently using your Page Forms, Cargo, and External Data extensions with excellent results.


 * That's great! There are some problems with the handling of VisualEditor/VEForAll in Page Forms with the latest versions of MediaWiki - I hope to get this fixed soon-ish. Yaron Koren (talk) 14:21, 1 March 2021 (UTC)

Thank you for the prompt response! And your MW contributions!

Random names for pages (leading zeroes)
If I were to create a form with  and later on change it to   could it end up with "duplicate" numbers (one with a leading 0 and one without)?

E.g. 8474 created now but 08474 created later.

Thanks Jonathan3 (talk) 19:00, 28 February 2021 (UTC)


 * Yes. Yaron Koren (talk) 14:21, 1 March 2021 (UTC)


 * Thanks for clarifying this. Jonathan3 (talk) 14:44, 1 March 2021 (UTC)

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

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


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


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


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


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


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


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


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


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


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

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


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


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

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


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


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

Autocapitalize support to other input types
Hello Yaron,

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

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

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

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

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


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

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

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

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

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

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

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

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


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


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

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

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


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


 * No, I don't think you can automatically put a div tag around a section. I guess I would suggest using a responsive skin instead of MobileFrontend, given that it has this issue, though you've probably thought of that already... Yaron Koren (talk) 02:55, 4 March 2021 (UTC)

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

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


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


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

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

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

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

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

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


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

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

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

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

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

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

Cavila 19:09, 7 March 2021 (UTC)


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


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

Using PageForms for File Uploads
Hello,

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

Thank you

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


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

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


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

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


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


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


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


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