Extension talk:Page Forms

Clicking form edit on page with 100s of template calls results in blank page timeout error
I have a page that uses a pageform to add multiple template calls (which people hold a certain role, in my case). This form worked for a while, but as the size of the wiki has increased, one page now calls over 300 templates. When I click "edit with form" on that page, I just get a blank page. The php log tells me [02-Jul-2020 10:17:26 America/Winnipeg] PHP Fatal error: Maximum execution time of 30 seconds exceeded in /home/.../extensions/PageForms/includes/PF_AutoeditAPI.php on line 1061 If I remove a bunch of the template calls from the page temporarily it works again, but still is very slow to load (>20s).

I realize that one answer to this would be to redesign the data structure how we store this, but that would require edits to hundreds of pages, so I would prefer not to go that route.

Is there a way to make this quicker? Short of that, is there a way to at least get an explicit error rather than a blank page? Or, if on most wikis pageforms breaks at a certain page size, push an error when that is reached and revert to a plain edit? My temporary work-around is to ask people use a plain edit for the page. I might be able to remove the form edit tab from just the big roles. In any case it introduces weird exceptions in the use of the wiki which is lowering acceptance. The whole reason I have them edit this directly is because I have not found a solution for an earlier problem, https://www.mediawiki.org/wiki/Extension_talk:Page_Forms/Archive_January_to_March_2020Tenbergen (talk) 21:57, 2 July 2020 (UTC)


 * This might help with the blank page thing. Beyond that, I don't know - there's always going to be a limit, no matter how fast the code is. Yaron Koren (talk) 01:26, 3 July 2020 (UTC)


 * I realize we are doing something strange there, but wanted to make sure it's just legitimate resource depletion and not some bug. I had a look at the link you gave, and an increase in the php execution time allows the page to load. It takes more than 30s, so clearly isn't really a solution, but it's much better than a blank page. Is there a way to block the edit with page explicitly on a single page that uses a template that otherwise has a designated form? Tenbergen (talk) 21:00, 9 July 2020 (UTC)


 * Sorry for the long delay. Yes, I think you can do that by adding  to the page. Yaron Koren (talk) 02:52, 27 July 2020 (UTC)

Using #autoedit from inside a form instead of inside a page
The following is copied from an archived version of this page since no edits should be made there. --- I have written an #autoedit tag to update a page. The tag works as expected when I call it from another page. However, I would like to use the tag from a Form page instead of a page in the regular namespace. When I try to use the link from the form page, I get the error Modifying failed. No form specified. Will try to find the default form for the target page.

No target page specified. The code for the autoedit tag is: Is it possible to use this tag from inside a form and I have the syntax wrong, or is it simply not possible to use this from inside a form?


 * That sounds like a bug. But why include #autoedit in a form? It seems strange to modify a page while in the middle of modifying a different page. Yaron Koren (talk) 03:48, 13 February 2020 (UTC)
 * Sorry, lost sight of this problem. I have a wiki with pages for people and pages for their roles. When I set it up, I pondered if the information about who holds a role should be on the role page or the person page, and decided to put it on the role page. When we first built it that made sense, but of course now, the process is such that a new person arriving will lead to them being in several roles, so each role page would need to be edited to add the person. To make that process a little more straightforward I wanted to add links in the person form to start editing the relevant roles in a different tab. The more elegant solution would be to redesign things to store role holding in the person pages, but that would mean changing hundreds of pages. So that's the use case, but I am open to a different solution to the problem. What I have done for now is provide a cargo driven table that generates a link to edit a given role page, but it doesn't actually generate the required template call to add the current person. The autoedit link I was trying to set can do that, but only from a main page not a form page. As a tangent, some of the role pages are getting big (one has 353 template calls now to add a person to that role) and the page form that opens it now times out. I have started a talk section about that separately, but mentioning it here because this is the reason I came back to the problem today: my work around of a link to a form edit of the page no longer works for some of the roles. Tenbergen (talk) 15:15, 2 July 2020 (UTC)


 * It does sound like storing this information in person pages would make much more sense. I guess I would recommend doing that... Even if it involves editing hundreds of pages, it might only take a few hours to do. Granted, it might not be a pleasant few hours.
 * Also, does this information need to be stored in multiple-instance templates? Can it be done with just a field holding a list of values instead? Or is there more than one column of data involved?
 * Anyway, if you're not going to change the data structure, what I would recommend is to put the #autoedit link into the person template, not the person form - that will work better, and seems less confusing to users also. Yaron Koren (talk) 03:19, 10 July 2020 (UTC)


 * I have proposed the edit-everything solution, but for now the consensus seems to be that that cure is worse than the condition of having to edit that single page without form. We are also discussing some alternatives that would not be mediawiki or even data structure related, so won't go into those.
 * It might not need to be a multi-instance template, but I can't even imagine what that would look like. Can you tell me of a sample form that does that? It is only the role name and the person name that are involved. I might need to tweak how I set them up, but that would only be template edits and not editing every page.
 * We use the form to drive our onboarding workflow, so putting the #autoedit in the page instead of the form would not work well with that. Putting the role holding on the person page rather than the role page would work with that. Maybe that's really what we are going to have to do.
 * I still don't understand why the #autoedit doesn't work from a form, though. I had thought of forms as just special kinds of pages. Does #autoedit only work for Main namespace pages, then? 104.246.134.43 19:23, 16 July 2020 (UTC)

Default not working in PF 4.9.4
I think I stumbled on a new parsing issue. I have a form for adding multiple-instance templates. Users can add new instances by doing a search first (outside the form) and click the wanted item. What happens next is that the user is sent to the form with the wanted item listed in the url. The form reads the URL parameter and adds it as a default value of one of the form fields. If the user clicks "another instance" (or whatever label it is), that field is automatically filled with the item mentioned. Since the latest version (PF 4.9.4), however, this is no longer working: the field remains empty. Cavila 13:27, 12 July 2020 (UTC)


 * What's the structure you're using for the URL query string? Yaron Koren (talk) 02:15, 13 July 2020 (UTC)


 * It's always a variation of ? &template-name[template-parameter]=  . That PF-style format isn't strictly necessary for the final bit because I'm using the URLGetparameter extension to grab the URL string and the Variables extension to pass the values to the "default" in Page Forms. But the output of the variable has not been the problem. It's the fact that Page Forms doesn't pick it up any longer. Cavila 08:02, 13 July 2020 (UTC)


 * Thanks, the default is working again, as of 4.9.5! The difference I noticed is that comboboxes in multiple-instance templates now appear as unstyled dropdowns (something to do with "TypeError: data.unshift is not a function" I think), but that could be a new and unrelated issue. Cavila 09:18, 20 August 2020 (UTC)

Field missing from leaflet input type
The leaflet input type used to have two fields, one being a field for holding the coordinates, the other an input for searching places and showing the most probable match on the map. The latter appears to be removed in PF 4.9.4. Was this intentional? I thought it was pretty useful even if it ignored other possible matches for one's search. Cavila 13:38, 12 July 2020 (UTC)


 * Are you sure about this? I thought it was always only "googlemaps" that had this second input. Yaron Koren (talk) 02:16, 13 July 2020 (UTC)


 * I am. The leaflet input had it as well. Cavila 07:44, 13 July 2020 (UTC)


 * What version were you running in which the leaflet input had this field? I can't find any evidence that it ever did. Yaron Koren (talk) 19:08, 13 July 2020 (UTC)


 * PF 4.7 has the input with class="pfAddressInput" and placeholder="Enter address here", with a button-type input saying "Calculate coordinates using address". Cavila 08:13, 14 July 2020 (UTC)


 * Ah, yes! Thanks for pointing this out, and sorry for the problem. I just checked in a fix for this. Yaron Koren (talk) 03:00, 15 July 2020 (UTC)


 * Thanks! Cavila 20:49, 17 July 2020 (UTC)

Tokens getting removed after an aborted edit (PF 4.9.4)
I hope I'm not getting you all worked up but there's one more, slight thing. Something seems not to be working correctly with tokens in PF 4.9.4 (a newer Select2 library I guess). If you double-click to edit a token and then having second thoughts, you click outside the field, the token disappears. Sometimes hitting enter after editing the text of a token also results in its removal. Cavila 13:52, 12 July 2020 (UTC)


 * Sorry about that - there are indeed some problems remaining from the Select2 upgrade. I believe this particular problem was just fixed. Yaron Koren (talk) 02:03, 27 July 2020 (UTC)


 * It was, thanks. Some other strange things are happening. Sometimes there's an empty token, or entering one value yields two identical tokens, but it's better already. Cavila 14:06, 20 August 2020 (UTC)

Severals fields in form using rating input type
Hello ! I am trying to use the "rating" input type for severals fields in a form.

I use MW 1.33.0 and Page Forms 4.6.

When I save a page and reload the form to edit this page again, all the fields are displayed with the same rate. It seems to be just a displaying aberration. has anyone ever encountered this problem ?

Thanks ! Paul LEMPERIERE (talk) 10:15, 25 July 2020 (UTC)


 * Sorry for the long delay. Is this still a problem in the latest version of Page Forms? Yaron Koren (talk) 18:31, 4 August 2020 (UTC)

Issue with #autoedit and current user
I use #autoedit and would like to add the current user and the current date to the page to be created. In the form I have the two fields In the template I have this: Date works perfect and gets filled however User does not. Not sure why. --91.64.58.72 22:15, 13 August 2020 (UTC)
 * Updating from 4.8 to 4.9.5 does not help either. Probably a bug. --91.64.58.72 10:34, 14 August 2020 (UTC)
 * I solved the issue differently. I used the query string to pass over the current user. --91.64.58.72 20:45, 14 August 2020 (UTC)

"tokens" input type can't be rearranged anymore and other issues
Hi,

I'm one of the admins of Le Dico des Ados, a french wiktionnary but adapted for children and teens. I've updated from 4.4.2 to 4.9.5, but I have several issues with the new version.

First here's my configuration of PageForms and some maybe useful informations: Here are the issues : Thanks by advance and sorry for eventual typos, Raphoraph (talk) 09:54, 19 August 2020 (UTC)
 * We also use Extension:HeaderTabs 1.3, Extension:Echo, SMW 3.1.6 and Extension:Cargo 2.6. HeaderTabs and Echo are supposed to interfere, but apparently disabling one or both don't change anything.
 * You may test the form we use and the issues here (in french).
 * You may test the form we use and the issues here (in french).
 * The "tokens" input type (in the test link it is used for the field "Synonyme(s)") is supposed to create tokens that can be rearranged, which is not possible in the new version (or I did not find how to). I tried to drag/drop these tokens but they stayed still. Also, when you click on the field a message in english show up. I can translate this message in the js code directly but it would be good for a future update to have a french version. The code we use for the field:.
 * The "tree" input type (field "Catégorie(s)") does not offer anymore the option to unexpand parent-categories, there is an icon inviting to click to unexpand but it doesn't do anything. The code:  -   is a classic category tree, with a noinclude at the end.

[RESOLVED] What Skins does Page Forms work with?
I'm running MW 1.34 and Page Forms 4.9.4 (c4fb7d3)

I'm looking for an alternative to the default Vector Skin and I'm running into problems with Pop-Ups and VEForAll on the different skins I've tried. Does anyone have any recommendations on a skin that works well with all of Page forms features including VEForAll? Thanks! Revansx (talk) 13:22, 19 August 2020 (UTC)


 * We think we're settling on Skin:Chameleon.. it seems to be the most supported skin with respect to: SMW, SRF, Page Form pop-ups, and VEforAll.. with a few minor CSS tweaks it seems the best off-the-shelf choice out there for an enterprise wiki. Revansx (talk) 19:46, 25 August 2020 (UTC)

Thanks for this
While admittedly, I was sceptical at first, I've really grown to appreciate the automatic collapsing/expanding of multiple-instance templates. It helps me keep sight of what I'm doing. In fact, because I often work with a lot of different information, I don't know how I can live without them these days. Cavila 14:09, 20 August 2020 (UTC)


 * Cool, that's good to hear! I haven't gotten that much feedback about the automatic collapsing feature, either way. Yaron Koren (talk) 17:58, 20 August 2020 (UTC)