Extension talk:Page Forms

From MediaWiki.org
Jump to navigation Jump to search

Save and Continue Bug?[edit]

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.
{{{for template|wikipedia|multiple|label=Wikipedia articles|embed in field=Source[Wikipedia]}}}
.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[edit]

When using listbox input type in combination to mapping template 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:

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

Bypass the datepicker control (disabled days) - how to prevent?[edit]

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

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

        {{{for template|Main|label=Main}}}
	{| class="formtable"
	! Name
	| {{{field|Name|property=Has name|}}}
	|-
        {{end template}}}

	{{{for template|Position|label=Position|multiple}}}
	{| class="formtable"
	! Position
	| {{{field|Titolo|property=Has position|}}}
	|-
        {{end template}}}

and a "Position" template

<includeonly>
    '''Position''' [[Has position::{{{Position|}}}]]
</includeonly>

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

<includeonly>
    <tabber>
Main =
    {| class="wikitable"
	! Name
	| [[Has name::{{{Name|}}}]]
	|-
    |}
    |-|
Positions =
    <!-- HERE -->
</tabber>
</includeonly>


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

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

  • Domains (top level category)
    • Account Managers (subcategory of Domains)
      • Jane Doe (subcategory of Account Managers)


We have them set up this way so we can see which domains have which IP (we host domains).


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


IP Address DNS Hosting Status On Billing TLD Domain Owner Auto Renew Status Suspension Status Domain Status Website Status Creation Date
172.217.1.238 ns1.google.com, ns2.google.com, ns3.google.com, ns4.google.com Not in Hosting Yes .com Unknown Unknown Not Suspended Active Active Unknown


Account Manager Project Manager Notes
Jane Doe John Doe None


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:


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 [[Category:Jane Doe]] and [[Category:John Doe]] 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. — Preceding unsigned comment added by K894 (talkcontribs) 17:57, 12 February 2020‎ (UTC)

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

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:

{{#autoedit:
form=Role
|target=UMG employee role
|link text=UMG
|link type=link
|query string=RoleHeldBy[1000][RoleHolder]=Testperson
|tooltip=blah
|summary=added via button from form
}}

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

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:
| {{{field|frontimagefile|input type=text|uploadable|image preview|default filename=<page name>_frontpanel.jpg}}}
|-
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?[edit]

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. title=Special:MultiPageEdit&limit=500&offset=0 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.
'conds' => array( 'page_namespace' => NS_TEMPLATE , 'page_title IN ("' . implode( '", "', array_keys( $this->templateInForm ) ). '") ' )
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)

show on select not working[edit]

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)

Select columns to display in Special:MultiPageEdit[edit]

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)