Extension talk:Page Forms/Archive January to February 2021

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

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:

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

turns page with wikitext:

{{MyTemplate|MyDate1=2020-01-05|MyProp1=XYZ}}

into page with wikitext:

{{MyTemplate|MyProp1=ABC}}

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

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

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

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

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)

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 & 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

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?

#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 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 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 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 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 for="input_12", while the input itself has id="input_4_12". 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 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 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 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:

<noinclude>
=New Retort Page=
Enter STATEMENT (not retort), below. A new Draft will be created, with the STATEMENT as its title.
{{#forminput:form=Retort|button text=Create Retort Page|query string=namespace=Draft|size=125|placeholder=Enter statement here}}
</noinclude>


<includeonly>
{{{info|page name=Draft}}}
{{{for template|Retort}}}
{{{end template}}}

__NOEDITSECTION__

==Short Retort==
{{{section|Short Retort|level=2|rows=2|cols=150|autogrow|editor=wikieditor}}}

==Claim Rationale==
{{{section|Claim Rationale|level=2|rows=2|cols=150|autogrow|editor=wikieditor}}}

==Retort Deep-Dive==
{{{section|Retort Deep-Dive|level=2|rows=2|cols=150|autogrow|editor=wikieditor}}}

{{{standard input|save}}}  {{{standard input|cancel}}}

</includeonly>

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

{{{field|coords|input type=leaflet|starting bounds=48,6;47,7}}}

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 {{/Intro}} 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.

{{{field|Author|values from category=Artist|mapping property=Has artist name|input type = tokens}}}

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.

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

{{#forminput:form=FAQ}}

</noinclude><includeonly>
<div id="wikiPreview" style="display: none; padding-bottom: 25px; margin-bottom: 25px; border-bottom: 1px solid #AAAAAA;"></div>
==Problem==
{{{section|Problem|level=2}}}

==Solution==
{{{section|Solution|level=2}}}

'''Freitext:'''

{{{standard input|free text|rows=10}}}


{{{standard input|summary}}}

{{{standard input|minor edit}}} {{{standard input|watch}}}

{{{standard input|save}}} {{{standard input|preview}}} {{{standard input|changes}}} {{{standard input|cancel}}}
</includeonly>

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 & # 38 ; (without internal spaces) or %26 ... not clear if you are using '&' and getting back '%26' or if you are using the encoded value. ~z929669 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 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 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 &action=delete 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.

{{#forminput:form=Event |size=40 |button text=Post Event |query string=namespace=Event&super_page={{CURRENTTIMESTAMP}} |autocomplete on namespace=Event |placeholder= Post an Event }} {{field|Text_Body|input type=textarea|rows=14|editor=visualeditor|placeholder=Enter the Main Text Body Here}}}

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 <unique number;random;4> and later on change it to <unique number;random;5> 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)