Extension talk:Page Forms

Save and Continue Bug?
I'm fixing a form for someone and the complaint is duplication of multiple-instance Template which I have tracked down to 'Save and Continue' when editing. If a user is editing and uses the 'Save and Continue' button for a change to a multiple-instance Template item, it creates a duplicate entry of the item. If a user just clicks the 'Save' button, no duplication occurs.

I don't know if this is related to this bug, Phabricator T208610 (Save-And-Continue not fully supported by Multi-Instance-Templates). The site is using the almost latest Pageforms, 4.7-Alpha, last commit from 19 Dec 2019. Has anyone tried this over a year old patch? Thanks --Hutchy68 (talk) 18:37, 8 January 2020 (UTC)


 * Little more information on bug. It seems to take the entire changed block of the multiple-instance template field and duplicate it. Example, if you add just one item to a blank field containing a multiple, you get the same field. Adding a link gives you this.

Link 1 Link 1
 * Adding two items to a multiple, you get this.

Link 1 Link 2 Link 1 Link 2
 * Adding additional items with items already held in multiple, Link 2 and Link 3 with Link 1 existing.

Link 1 Link 2 Link 3 Link 2 Link 3
 * The entire contents of the diff block to the content in a multiple-instance is duplicated in its entirety when 'Save and Continue' is used.


 * What kind of form is this - a regular form? A "partial form"? Yaron Koren (talk) 20:01, 8 January 2020 (UTC)
 * Regular form, embedded in a field. Right now I am going back to make sure they added something similar to this for all their multiple instances in the form. .Form is long and really complicated. Trying to clean it up. *edit* Yes, everything looks correct. As stated, works on a regular save without issue.


 * Any ideas Yaron? I noticed if you delete multiples, the Save and Continue button does NOT notice the changes, nor does it activate to apply the changes. Regular fields modified, the button activates. Seems as if 'Save and Continue' is broken for multiple instances. Should I file a bug report? Or add to the existing one? --Hutchy68 (talk) 16:16, 9 January 2020 (UTC)


 * I don't know... as far as I remember, the Page Forms code always re-generates all of the wikitext for the page, rather than adding to or modifying the existing wikitext, so I don't know how this could happen. If you put here, or pastebin, the form definition you are using, I can try to replicate the problem. I don't think it's related to that Phabricator bug, by the way. Yaron Koren (talk) 17:19, 9 January 2020 (UTC)


 * Sorry for the delay, I wanted to test this further with a vanilla install. I can still reproduce the same results on different versions of MW, 1.31 and 1.32. Also tested with custom skins and Vector. Same results. Pastebin link is Hutchy68's Pastebin. Form:Test, Template:Link and Template:Test. To reproduce:
 * Create a page with the form
 * Edit page with form and add a link, save and continue.
 * Leave page by clicking the Page or Read link, do not use the save button.
 * Note the duplication, Edit with form again.
 * Try to remove a multiple, note the save and continue never changes to yellow indicating a save is available even though the page is changed.


 * What I have noted, if you leave the page using the Page or Read Link or clicking on another link such as Recent Changes or any sidebar link, the doubling occurs. The only method of not doubling when using the save and continue is to leave the page with the save button. --Hutchy68 (talk) 16:15, 10 January 2020 (UTC)

listbox with mapping template
When using  input type in combination to   and selecting more than one value (with Ctrl key), the form does save correct values, however, when "Edit with form" is used, the form seems not reading the previous values and erases the content when we hit save again. See the exemple below.

Example:
 * Result: https://sandbox.semantic-mediawiki.org/wiki/Listbox_test
 * Form: https://sandbox.semantic-mediawiki.org/wiki/Form:Listbox_test
 * Template: https://sandbox.semantic-mediawiki.org/wiki/Template:Listbox_test
 * Mapping template: https://sandbox.semantic-mediawiki.org/wiki/Template:Listbox_test/codes1

Jaider msg 16:44, 14 January 2020 (UTC)

Bypass the datepicker control (disabled days) - how to prevent?
For filling the date fields I use the datepicker control. Thereby I deactivate the already booked days by cargo queries with which I set the parameters "first date", "last date", "highlight dates" and "disable dates". My problem: The disabled dates can be bypassed simply by entering a date in the field. How can the direct input into the field be blocked, forced to input via datepicker?

Ahaemmerli (talk) 14:00, 20 January 2020 (UTC)


 * There's no direct way to do that. It may be possible via some custom JavaScript that you put into MediaWiki:Common.js; I'm not sure. Yaron Koren (talk) 16:53, 21 January 2020 (UTC)

Multiple templates in tabs
Is it possible to obtain that sub-templates are written inside a tab (for instance using tabber)? I mean, suppose that I have a form "Main" like {| class="formtable" ! Name | 	|-       }

{| class="formtable" ! Position | 	|-       }

and a "Position" template Position Has position::

Following the form definition above, the "Position" templates will be added after the main template. How can I insert them into a tab, that is Main = |-| Positions =

Marco Falda (talk) 15:02, 21 January 2020 (UTC)


 * You can do that by making the "Position" template embedded - look for "embed in field" and "holds template" here. Yaron Koren (talk) 16:56, 21 January 2020 (UTC)

Create Form for Non-Technical Colleagues Using Subcategories as Values and Adding Appropriate Category Links?
Hi!

I'm hoping to create a form that will allow our non-technical users to enter new domains that we manage and their related information into our wiki. We have the Categories set up thusly:


 * Domains (top level category)
 * IP Addresses (subcategory of Domains)
 * Actual IP Addresses of the domains (ex: 255.255.255.255) (subcategory of IP Addresses)

or

We have them set up this way so we can see which domains have which IP (we host domains).
 * Domains (top level category)
 * Account Managers (subcategory of Domains)
 * Jane Doe (subcategory of Account Managers)

I've been trying to create a simple form that our sales people can use to enter new domain information into the wiki when they sign up a new client. They do not code at all. I've set up the wiki with inline category links. I can't upload screenshots because I get errors, so I'll try to describe here.

We have a page set up like this:

Domain Details

Wordpress

Yes

Wordpress Plugins

We have inline Category links (in red) that we use to organize our information and help the non-technical folks "search" for information they want. Is there a way to set up Page Forms to:
 * 301 Redirects 2.45
 * Advanced Custom Fields PRO 5.8.7
 * Classic Editor 1.3

1. Allow subcategories to be the "values from category" source when using a dropdown in Create a form? Right now it says it's only pages. We need subcategories. Example:


 * Field: IP Address


 * Input Type: dropdown


 * Other parameters: values from Category: (subcategories for IP Address here?)

2. Add the appropriate Category tags to the end of the page's code? (Example: we have inline links to subcategories "Jane Doe" and "John Doe" but they don't show up there without adding them as and  at the bottom of the page (as hidden categories to try and cut down on the eye-clutter). Is there a way to scrape the inline links and populate the correct categories without having to essentially double-type?

If Page Forms can't do this, can you suggest something that does? Our non-tech folks cannot be asked to code at all. Is there a better way to set up the Category Organizations?

Thanks in advance.


 * Let me preface by saying that I don't think it's a good idea to use categories for this kind of thing. The standard approach with Page Forms is to additionally use either the Cargo or Extension:Semantic MediaWiki extensions in order to query and display the data that is generated via forms. It might seem like a lot of overhead, but it's really worth it in the end. So, for example, instead of a "Category:Jane Doe", you would use Cargo or SMW to store the Account Manager, Project Manager information for each page - and then, on the page for every person (like "Jane Doe"), include a template that itself includes queries to show all the projects that this person is account manager for, project manager for, etc. It's a more accurate display of information, and it's a lot easier for users when they can see everything about a person (or whatever it is) on one page. And you can easily generate tables, etc. from all of that information.


 * That said, let me answer your questions: I believe the answer to the first question is no, unfortunately. For the second one, I would check out the #arraymap parser function - it sounds like you don't know about that one, and that may be what you are missing. Yaron Koren (talk) 19:20, 12 February 2020 (UTC)

Using #autoedit from inside a form instead of inside a page
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)

Internal error with Page Forms upload
When using Page Forms 1.34 on my mediawiki 1.34 installation, the standard form uploadable field popup gives the following error response on uploading:

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

I also notice that the Destination filename field does not auto populate after selecting a source file. I've used multiple computers to log in and have experienced the same issue.

The simple uploading works fine though.

--AgentIrons (talk) 21:58, 14 February 2020 (UTC)


 * Is there any more to the error message, or is that it? Yaron Koren (talk) 14:11, 17 February 2020 (UTC)


 * That's it. Chrome console doesn't give me any other info either. Screenshot AgentIrons (talk) 18:23, 17 February 2020 (UTC)


 * Alright. When you said you're using "Page Forms 1.34", I assume you meant you got the version of Page Forms that goes with MW 1.34 through ExtensionDistributor. That's not recommended - if you're getting code via ExtensionDistributor, you should just get the latest code. I would try that - maybe it'll fix this issue. Yaron Koren (talk) 21:52, 18 February 2020 (UTC)

Sorry, I misspoke - I was using the PageForms 4.7 .zip download from the Download and Install page. I switched to the latest .git clone, but no change in the error. I also added the various PHP debug options to LocalSettings.php but nothing gave me any more information to go on, especially as the debug info did not appear on the Special:UploadWindow frame. AgentIrons (talk) 00:03, 19 February 2020 (UTC)


 * What does the field tag for that uploadable field look like, in the form definition? Yaron Koren (talk) 00:34, 19 February 2020 (UTC)


 * The following:

! Front Panel Image:
 * AgentIrons (talk) 07:54, 19 February 2020 (UTC)


 * Okay, thanks. I finally tried this out myself - which I probably should have done right at the beginning, because I got that same error message right away. This turned out to be a bug I accidentally inserted into the code about a month ago. I just checked in a fix for this, so if you get the latest code the problem should hopefully go away. I should probably release a new version of Page Forms soon, because it could be that uploading in version 4.7 is broken completely... Yaron Koren (talk) 03:14, 20 February 2020 (UTC)


 * Confirmed working with latest code! Thanks Yaron. AgentIrons (talk) 23:55, 20 February 2020 (UTC)


 * Great. And sorry about the problem! Yaron Koren (talk) 00:04, 21 February 2020 (UTC)

Which tables does Special:MultiPageEdit work for? [RESOLVED]
This page only displays a minority of my tables. I wonder what I could do to get more added. The extension page states: "It currently supports text, text area, checkbox, date, combobox and tokens input types."

Looking at one of them, it has Wikitext (size=2000), String and Date input types. Would changing the first two to Text work?

Also is it relevant that the template has a #cargo_attach statement in it?

Thanks Jonathan3 (talk) 22:51, 17 February 2020 (UTC)


 * This should probably be explained somewhere. Page Forms' selection actually has nothing to do with Cargo data, if I remember correctly. Rather, I believe it only picks form/template pairs where there is a direct, 1:1 connection between the form and the template. So if two or more forms include the same template (presumably as a multiple-instance template in both cases) then I believe Special:MultiPageEdit doesn't include either form. Could that be case on your wiki? If not, there may be some other rules too. Yaron Koren (talk) 21:50, 18 February 2020 (UTC)


 * I don't have any multiple-instance templates (that I am aware of!). I deleted a couple of test forms which made one extra form show up in Special:MultiPageEdit, so the 1:1 relationship must be part of it. I would be interested to hear the other rules. Jonathan3 (talk) 23:19, 20 February 2020 (UTC)


 * I think it's basically "any form that contains a template that's in more than one form is excluded". Yaron Koren (talk) 00:06, 21 February 2020 (UTC)


 * I'm not positive but I think I'm experiencing a related bug. My Special:MultiPage says "Showing below up to 6 results in range #1 to #6." but nothing is visible. The top/bottom view per page options are there but nothing in between them. I used the Special Pages 'Create Form' and 'Create Template' on a brand new pair just to test but no change. AgentIrons (talk) 03:11, 22 February 2020 (UTC)


 * I hadn't thought anything of it until your comment, but mine says "Showing below up to 50 results in range #1 to #50" then lists templates for four of my 13 forms. Jonathan3 (talk) 09:40, 22 February 2020 (UTC)


 * The code is correctly saving the the 1:1 template:form relationships in an array.


 * But when it comes to displaying the templates, it takes the limit (default 50) and runs through the first 50 templates in the wiki, which means that it misses any relevant templates beyond that. A workaround for now is to change the limit to a number which is higher than the number of templates in the wiki, e.g.  Jonathan3 (talk) 10:48, 22 February 2020 (UTC)


 * This seems to fix it. Change function getQueryInfo in PF_MultiPageEdit.php so that the 'conds' line also restricts results to those templates identified as being linked to by one form.




 * I have spent all morning working through the code, so really hope you haven't fixed this already :-) Jonathan3 (talk) 12:18, 22 February 2020 (UTC)


 * Thank you for that patch! I just checked it in - it does indeed seem to fix that problem. Yaron Koren (talk) 20:22, 24 February 2020 (UTC)


 * Yes it works fine - thank you. Jonathan3 (talk) 21:04, 25 February 2020 (UTC)

show on select not working
I tried following the example provided for a query form, but for some reason all fields are shown in the form regardless of selection. Is it possible that show on select doesn't work for form queries? I even tried using the actual code from the example (Source) but it isn't working either.

autocomplete isn't working as well in my fields, but I dont know if that's related. My version is MW 1.30.1, PHP 5.5.9, MySQL 5.7.25 .217.132.232.233 22:25, 21 February 2020 (UTC)


 * I'm guessing it's all related. If you look in your browser's JavaScript console, do you see any error messages there when viewing the form? Yaron Koren (talk) 23:13, 21 February 2020 (UTC)


 * just some error in PushServiceWebSocket.jsm calling _beginWSSetup in a state other than STATE_SHUT_DOWN. Doesn't sounds related to the form really. I can't post a link to my test wiki unfortunately. 217.132.232.233 06:57, 22 February 2020 (UTC)


 * One more update - I tried to narrow down to a simple field with autocomplete on regular values. Doesn't work either. The problem seems to be related to using Hebrew values. When using English values autocomplete works. I saw a post from 2016 mentioning this issue. Is this still a known an existing bug? 217.132.232.233 03:51, 24 February 2020 (UTC)


 * Does "show on select" work for you with English also? Or are these two separate issues? And what is the 2016 post? Yaron Koren (talk) 04:35, 24 February 2020 (UTC)


 * Nope. Alas, "show on select" doesnt work for english, nor Hebrew. So it's probably two separate issues. The post I saw mentioning issues with Hebrew is with the title 'Fix autocomplete filter function for no \w chars'. 217.132.232.233 09:16, 24 February 2020 (UTC)


 * I'm guessing you're talking about this, from 2019. I don't know if it was fixed. But it would be good to solve the "show on select" problem first - maybe it leads to the other one. Does this problem happen for you in browsers other than Firefox (which is what I assume you're using)? Yaron Koren (talk) 19:13, 24 February 2020 (UTC)


 * Besides Firefox I also tried Edge, doesn't work there either. 217.132.232.233 04:05, 25 February 2020 (UTC)


 * Is there a JavaScript error message there? Yaron Koren (talk) 16:27, 25 February 2020 (UTC)


 * Probably not related but, strangely, it shows "'mwCustomEditButtons' is not defined". 217.132.232.233 19:06, 25 February 2020 (UTC)

It might be related. Maybe this error comes from some custom code, in MediaWiki:Common.css or elsewhere, that needs to be updated? And by the way, what version of Page Forms are you running? Yaron Koren (talk) 19:40, 25 February 2020 (UTC)


 * Deleted everything from Mediawiki:Common.css, cleared cached, reloaded. Same problem. PF version is 4.1.2. 217.132.232.233 20:06, 25 February 2020 (UTC)


 * Alright. I would definitely try upgrading Page Forms - that's a very old version, so maybe this is a problem that has been fixed already. Yaron Koren (talk) 20:54, 25 February 2020 (UTC)


 * That's the version for MW 1.30 (downloaded from github), it's three years old, not THAT old... anyway upgraded to 4.5. Problem persists 217.132.232.233 04:57, 26 February 2020 (UTC)


 * Okay, maybe three years is not very old. :) Could you try it with the actual latest version, 4.7, though? There's no reason not to use the latest version. Yaron Koren (talk) 14:24, 26 February 2020 (UTC)


 * Same problem :/ 217.132.232.233 18:45, 26 February 2020 (UTC)

Select columns to display in Special:MultiPageEdit
Is it possible to do this? It would help for tables with many fields.

Thanks. Jonathan3 (talk) 19:02, 23 February 2020 (UTC)


 * No, but you can "X" out the columns you don't want, if there are a lot of them. Yaron Koren (talk) 04:36, 24 February 2020 (UTC)


 * I hadn't noticed those! Thanks. Jonathan3 (talk) 21:06, 25 February 2020 (UTC)

Computed value in values from namespace=?
Hi Yaron,

I have a form editing pages in different namespaces, and would like to autocomplete from a current namespace. For instance NS1:page1 should autocomplete from NS1. I have a variable containing the current namespace using the variable module. However when use the example code block

it returns

I can see from debugging and other usage that the variable works. Is there another way to retrieve values on a 'current' namespace? Thank you! Øyvind


 * I can't think of a way to always get that to work, no. Let me note that a form that applies to pages in multiple namespaces is rare, and may indicate an overuse of namespaces - although I don't know your data structure, so maybe it's fine. Yaron Koren (talk) 16:33, 25 February 2020 (UTC)


 * Thanks. Is this something I could try to implement? I'm thinking of adding a case looking for `current` or maybe `page`, but some thought should probably go into thinking about reserving a keyword. Øyvind.


 * Adding handling just for this particular use case seems like a bad idea, because it's a very rare use case. There are a few potential other solutions, though:
 * Add parsing for "values from namespace=". This will work for you when editing existing pages. However, I think it will fail when the page name of the form starts with "Special:FormEdit", i.e. when creating a new page.
 * Change your data structure so that the same form does not handle multiple namespaces. I don't know what your data structure is, but I'm guessing that it can be "improved"/simplified in some way.
 * Add a hook to Page Forms to allow for admins to create custom PHP code to set the values for an input. This is the most general solution, and it could help solve a number of different issues.
 * Maybe #3 is the best solution; I'm curious what you think about #2, though. Yaron Koren (talk) 14:32, 26 February 2020 (UTC)

Format of Special:MultiPageEdit
Here are some suggestions: Other than these suggestions, it's a great idea and seems to work well :-) Jonathan3 (talk) 21:16, 25 February 2020 (UTC)
 * 1) It would be good if the space to edit the text were bigger. I have some long-ish String fields (e.g. lists of authors) and there isn't room to view all the text in the narrow one-row text field.
 * 2) Maybe, linked with this, it would be good if it were possible to 'X' out columns even after the screen space limit has been reached (i.e. even if the screen can hold 6 columns, it should be possible to reduce it to fewer than 6).
 * 3) Instead of having an extra frame with its own toolbar would it be possible to just display the spreadsheet in the normal (larger) page?
 * 4) On an empty field of type Page, the dropdown autocomplete suggestions aren't wide enough to display even one letter.
 * 5) On my laptop screen the light/dark/light row colouring is invisible unless I push the screen right back and lift up the keyboard. The lack of a row border makes it difficult, especially as the rows change size when you go to edit them.