Extension talk:Page Forms/Archive July to September 2020

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_2020#Using_#autoedit_from_inside_a_form_instead_of_inside_a_page ]]Tenbergen (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 {{#default_form:}} 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:

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

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 <url>?<other parameters>&template-name[template-parameter]=<name-of-wanted-item>. 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)

Sorry about that problem; I just checked in a fix for it. Yaron Koren (talk) 16:24, 30 October 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

• {{{field|User|input type=text|default=current user}}}
• {{{field|Date|input type=date|default=now}}}

In the template I have this:

• {{{Date|}}}
• {{{User|}}}

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:

• $wgPageFormsLinkAllRedLinksToForms = true;
  

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

Here are the issues :

• 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: {{{field|syn|property=Article|input type=tokens|placeholder=Séparer chaque entrée par une virgule (même la première!)}}}.
• 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:

  {{{field|cat|property=Catégories|input type=tree|height=300|list|depth=1|structure=

{{Dico:Catégories}} }}} - {{Dico:Catégories}} is a classic category tree, with a noinclude at the end.

Thanks by advance and sorry for eventual typos, Raphoraph (talk) 09:54, 19 August 2020 (UTC)

For the second one - the JS library used to display the "tree" input actually just changed last week, from FancyTree to jsTree. So if you get the latest Page Forms code, these specific problems may go away. Yaron Koren (talk) 22:09, 25 August 2020 (UTC)

@Yaron Koren: Sorry, I updated to the latest but it doesn't load with the error Uncaught TypeError: $(...).applyJSTree is not a function, at PageForms.js:1451. I tried to purge the cache but it didn't work. I found also another issue with the vesion I used when I posted the original message : it replaces all occurences of é, è and à by their HTML code, but it's problematic, as for example the category tree does not recognize anymore the category as checked and it shows in preview as é (the html code is escaped). Raphoraph (talk) 14:00, 27 August 2020 (UTC)

@Yaron Koren: I've edited my message above, and here's a precision : the error seems to be caused by an other exception throwed earlier.
Exception in module-execute in module ext.pageforms.jstree:
Error: Module "jquery" is not loaded.
This is strange as jquery seems to be loaded and to work.
Also, on my local wiki the jstree doesn't load too but here it is caused by this : Uncaught SyntaxError: JSON.parse: unterminated string at line 1 column 29 of JSON data, in PF_tree.js:23. Kind regards, Raphoraph (talk) 13:55, 3 October 2020 (UTC)

I'm also getting the first issue with token input type under Mediawiki 1.34.4 with PF 4.9.5. I can no longer drag-drop tokens in a form field. I'm also having a similiar issue with html escaped characters getting replaced into field values, but with the token input type. When I load forms for pages containing special characters (like "é", "ô", "&", etc) in token fields, the html code for those characters are substituted into the form fields and then get included in the template call upon publishing. This goes on recursively if I edit the same page again, re-expanding all special characters including the ones used for html codes (e.g. "&"). Any suggestions for solving this? Thanks!--192.222.211.196 19:44, 9 October 2020 (UTC)

My HTML encoding issue seems resolved in the master branch for Page Forms. Still can't move tokens. --192.222.211.196 14:37, 13 October 2020 (UTC)

Me neither. I also think the automatic alphabetical sorting is unhelpful. Cavila 11:27, 15 October 2020 (UTC)

Sorry, about these issues - they are due to the upgrade of the Select2 JavaScript library, which in turn is part of a bigger effort to improve the JavaScript code. I hope to get tokens sortable again in the next few weeks. The alphabetical sorting thing was already fixed about a month ago. Yaron Koren (talk) 16:25, 15 October 2020 (UTC)

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

Mapping template doesn't work when multiple values in tokens

In a form, I have a field of type "tokens", with a mapping template. When I first edit the field, everything is ok, mapping template does its job. But when I come back to edit, I see unmapped values in the field, and when I click to select values, the list shows both mapped values and unmapped set values. It only happend when the field is set with multiple values, when only one value, mapping works. The problem exists at least in version 4.5.1, 4.9.3 and 4.9.5. Steph.

Ref: https://phabricator.wikimedia.org/T266664

default value when using "show on select" options

• Mediawiki 1.34.1 (b1f6480)
• Page Forms 4.9.4 (c4fb7d3)

The goal is to ensure that a value is selected for property "TheOption" from 1 of 2 dropdown lists.

I have a form with the following wikitext

{{{field|TheOption
  |input type=dropdown|values=A,B|default=A
  |show on select=A=>OptionA;B=>OptionB
  |mandatory
}}}

<div id=OptionA>
   {{{field|TheOption|input type=dropdown|values from category=Option Set A|default=ABC|mandatory}}}
</div>

<div id=OptionB>
   {{{field|TheOption|input type=dropdown|values from category=Option Set B|default=ABC|mandatory}}}
</div>

The goal is that "TheOption" is mandatory and defaults to "ABC" in both cases.

When creating a new page from the form the tool works fine, however, the code fails when editing an existing page.

When you edit an existing page the alternate option always provides the blank option in the pull-down and does not behave as it did as mandatory when the page was being created.

How to get to both dropdowns to load with the property value "TheOption" regardless of what was selected previously?

Thanks! Revansx (talk)

You can't have the same field twice in a form definition, unfortunately - even if only one of it will be shown at any given time. Yaron Koren (talk) 23:35, 26 August 2020 (UTC)

How Do I Create A Drop Down List

MW 1.34.2 with Cargo. I built a Template and then Form. Neither really worked until I did the Special:CreateClass. Now they seem to work to a point. A am trying to create a form that will allow a dropdown list as a field wherein I can select an option. Basically, it is Type of House and options would be Brick,Siding,etc. I have tried boolean, string, and text and all I get are the words in a row with a checkbox (and all can be checked). The Template page shows for pertinent value: At the top "|House_Type=List (,) of Text (allowed values=Tall,Short,Wide)" and "! House Type | {{#arraymap:|,|x|x}}," and the Form page shows ! House Type: | House Type. To that point, I also have been unable to figure out how to edit the any of these unless I continue to rebuild from the Special:CreateClass page. Is there an easy way to go back and edit so I can add and change fields in the form setting like on Special:CreateClass or do I have to rebuild these each and every time manually. Thanks for any help and form is here: https://digitalmatrixgroup.com/index.php/Form:Investor_Asset if you need to look around. Form is Investor Asset. --Foreclosurepedia (talk) 04:52, 30 August 2020 (UTC)

• Fixed the dropdown issue by copy and pasting from elsewhere. Changed List to String and entered values. Appears to be easier to manually build out all of this after the initial Template and Form are built. Is there somewhere I can go read a layman's view on how the Extension works? Thanks and have a great day! --Foreclosurepedia (talk) 17:17, 30 August 2020 (UTC)

Problem With Header Tabs On Page Forms

Posted on Header Tabs Talk as well: MW 1.34.2, Header Tabs 1.2, Page Forms 4.9.5. Have a form with a template built out with Page Forms and Cargo. Installed Header Tabs. Tabs pop up but only the last tab shows the Form. It is a single Template and a single Form. I would like to split the Form into tabs. So, link here: https://digitalmatrixgroup.com/index.php/Form:Investor_Asset and here https://digitalmatrixgroup.com/index.php/Template:Investor_Asset. The example link listed in your Extension page does not allow viewing any code and looks like a regular web page. I put links to the photo examples here which document where I put the '=Tab=' info into the Form and I added the end "<headertabs/>" before the Standard sections: https://pasteboard.co/JoXbcZI.png ... https://pasteboard.co/JoXbV6F.png ... https://pasteboard.co/JoXc6C8.png ... I asked over on the IRC but no one really had a response. Thanks for your time! --Foreclosurepedia (talk) 20:02, 31 August 2020 (UTC)

• This was solved by Yaron Koren over on the Header Tabs Page Talk. Thanks to him! I have to enter the tabs by creating separate tables for each tab. --Foreclosurepedia (talk) 14:42, 7 September 2020 (UTC)

Problem With Header Tabs On Page Forms

MW 1.34.2. Using Cargo, Tabs and ParserFunctions. I can't seem to get multiple "rating"-type fields to work. Whenever I add more than one of them to a form, they display buggy behaviour when trying to edit a page that already exists. Instead of displaying the value of the field that had been saved, all rating fields will display a number of stars equal to the number of stars in the first rating field for that page. Any idea what could be causing this? Here's an image displaying the issue: imgur.com/a/Lgw1aWw

Thanks for your time! SonGuhun (talk) 02:14, 3 September 2020 (UTC)

Sorry about that! It looks like that was a bug that was in place for about two years. I just checked in a fix for it. (By the way, the header for this section seems incorrect.) Yaron Koren (talk) 19:26, 4 September 2020 (UTC)

Deprecated: array_key_exists() on PF_TreeInput.php

I'm using php 7.4 and I get plenty of warnings:

Deprecated: array_key_exists(): Using array_key_exists() on objects is deprecated. Use isset() or property_exists() instead in (...)/wiki/extensions/PageForms/includes/forminputs/PF_TreeInput.php on line 219

Solved by tweaking line 219 of PF_TreeInput.php from:

if ( array_key_exists( 'children', $node ) ) {

to:

if (property_exists($node,'children')) {

--Choralia (talk) 06:15, 10 September 2020 (UTC)

This bug may have been (inadvertently) fixed already, when handling of the "tree" input type was overhauled a few weeks ago. Yaron Koren (talk) 14:42, 10 September 2020 (UTC)

Where can I get the overhauled version? I'm still struggling with the tree displaying that is not collapsible (see "Tree display not collapsing" here), so I'm hoping that this is problem is also solved by it. --Choralia (talk) 11:12, 12 September 2020 (UTC)

You would need to get the latest code through Git. If you only want to use officially-released versions, the next version of Page Forms (which will have the new version of "tree", and a lot of other changes) will hopefully come out in the next few weeks. Yaron Koren (talk) 13:17, 15 September 2020 (UTC)

I got the new version of "tree" through Git, and it looks good (maybe the arrows showing items that can be expanded should be more prominent). However, when the form includes multiple trees, the page hangs indefinitely. The browser's console reads:

This page is using the deprecated ResourceLoader module "jquery.ui".
Please use OOUI instead.

JQMIGRATE: jQuery.fn.delegate() is deprecated

Uncaught SyntaxError: Unexpected end of JSON input
at JSON.parse (<anonymous>)
at pf.TreeInput.TreeInput_proto.setOptions (load.php?lang=en&modules=ext.pageforms.fullcalendar.jquery3|ext.pageforms.jstree%2Cselect2|jquery|jquery.ui&skin=vector&version=15yoe:540)
at jQuery.fn.init.applyJSTree (load.php?lang=en&modules=ext.pageforms.fullcalendar.jquery3|ext.pageforms.jstree%2Cselect2|jquery|jquery.ui&skin=vector&version=15yoe:542)
at HTMLDivElement.<anonymous> (<anonymous>:240:349)
at Function.each (load.php?lang=en&modules=ext.pageforms.fullcalendar.jquery3|ext.pageforms.jstree%2Cselect2|jquery|jquery.ui&skin=vector&version=15yoe:690)
at jQuery.fn.init.each (load.php?lang=en&modules=ext.pageforms.fullcalendar.jquery3|ext.pageforms.jstree%2Cselect2|jquery|jquery.ui&skin=vector&version=15yoe:688)
at jQuery.fn.init.$.fn.initializeJSElements (<anonymous>:240:325)
at <anonymous>:242:655

I hope this helps. --Choralia (talk) 17:15, 4 October 2020 (UTC)

Select2 autocomplete - forminput has very little width

Hi Yaron

I've updated my extension to master to use the fix in https://phabricator.wikimedia.org/T261943 and noticed something I think is a bug or WIP on the switch to using select2 from jquery-ui for autocomplete.

{{#forminput:button text=Legg til/rediger termpost|form=Begrep|link type=button|query string=Begrep[medlem]=Page_Forms/Archive_July_to_September_2020&Begrep[namespace]= results in a small form-input. I've added .select2-container {min-width: 125px;} in the common.css but thought it was worth reporting.

Also I'm a bit unsure on how I should use phabricator on PageForms. Should I close issues when solved, or leave open for author to close?

Kind regards, Øyvind

Wow! That was a really untested change to the code. I just checked in a fix, so hopefully autocompletion in #forminput now works correctly. (By the way, there's no "link type" parameter for #forminput.) As for Phabricator - sure, feel free to close issues that you think are resolved. They can also be re-opened if necessary. Yaron Koren (talk) 21:11, 10 September 2020 (UTC)

Thank you for the quick fix and the heads up on "link type". I updated to latest and a minor nitpick is that the input box now expands a short time vertically before expanding to the expected size. See https://test.wiki.terminologi.no/index.php?title=MRT:MRT.

Yes, I'm aware of that momentary FOUC (flash of unstyled content). It's on my list of things to fix. Yaron Koren (talk) 13:19, 11 September 2020 (UTC)

Version 4.9.5 and default=current user error

I get the following error when I use the following field with version 4.9.5:

{{{field|Username|hidden|default=current user}}}

Doesn't happen with version 4.8.

[6cdf5a310b4457d536c66eb6] [no req] Error from line 1248 of D:\inetpub\wwwroot\ProjectBook\extensions\PageForms\includes\PF_FormPrinter.php: Call to undefined method User::isRegistered()

Backtrace:

1. 0 D:\inetpub\wwwroot\ProjectBook\includes\StubObject.php(112): PFFormPrinter->formHTML(string, boolean, boolean, integer, string, string, string)
2. 1 D:\inetpub\wwwroot\ProjectBook\includes\StubObject.php(138): StubObject->_call(string, array)
3. 2 D:\inetpub\wwwroot\ProjectBook\extensions\PageForms\includes\PF_AutoeditAPI.php(948): StubObject->__call(string, array)
4. 3 D:\inetpub\wwwroot\ProjectBook\extensions\PageForms\includes\PF_AutoeditAPI.php(115): PFAutoeditAPI->doAction()
5. 4 D:\inetpub\wwwroot\ProjectBook\extensions\PageForms\specials\PF_FormEdit.php(104): PFAutoeditAPI->execute()
6. 5 D:\inetpub\wwwroot\ProjectBook\extensions\PageForms\specials\PF_FormEdit.php(40): PFFormEdit->printForm(string, string, NULL)
7. 6 D:\inetpub\wwwroot\ProjectBook\includes\specialpage\SpecialPage.php(569): PFFormEdit->execute(string)
8. 7 D:\inetpub\wwwroot\ProjectBook\includes\specialpage\SpecialPageFactory.php(568): SpecialPage->run(string)
9. 8 D:\inetpub\wwwroot\ProjectBook\includes\MediaWiki.php(288): MediaWiki\Special\SpecialPageFactory->executePath(Title, RequestContext)
10. 9 D:\inetpub\wwwroot\ProjectBook\includes\MediaWiki.php(860): MediaWiki->performRequest()
11. 10 D:\inetpub\wwwroot\ProjectBook\includes\MediaWiki.php(517): MediaWiki->main()
12. 11 D:\inetpub\wwwroot\ProjectBook\index.php(42): MediaWiki->run()
13. 12 {main}

Thanks, Margaret

Sorry! And thanks for the bug report. I just checked in what I think is a fix for this. Yaron Koren (talk) 15:28, 10 September 2020 (UTC)

THANK YOU! Issiegainsley (talk)

Hi Yaron, I just updated to the master version (1343d6d). If I'm logged in default=current user seems to work fine (it also did before in my case). But it still doesn't work if an anon edits. This is the warning message I get from SMW after saving as an anon:
"Property "User" (as page type) with input value "Benutzer:" contains invalid characters or is incomplete and therefore can cause unexpected results during a query or annotation process."
Thanks! --Stefahn (talk) 08:14, 11 September 2020 (UTC)

It sounds like you just need to add an #if call or something to the template... Yaron Koren (talk) 13:18, 11 September 2020 (UTC)

Add a condition when using 'cargo table & cargo field'

Hi, Im using a form to allow search information from cargo tables.

1) I have table in this form:

--/ first / second
1/ a / 1
2/ a / 2
3/ b / 10
4/ b / 20


My form contains two dropdown lists, one for 'first' and the other for 'second'.
I want that when the user select 'a' on 'first' dropdown, he will get only relevant values (without 10 and 20).


That possible somehow?
If not, I think that this is a good feature request :)

2) I would allow to use the condition on predefined dropdownlists as well, like i would have this situation (and i do, I'm simplifying it):

--/ first / second / am_i_visible
1/ a / 1 / True
2/ a / 2 / False
3/ b / 10 / True
4/ b / 20 / False

< .... cargo_table="my_table" cargo_field="first" cargo_condition="am_i_visible=True">

This could be very helpful :)

77.124.40.95 17:03, 13 September 2020 (UTC)

For the first one, the closest feature to that is "values dependent on" - which requires comboboxes instead of dropdowns, but you may be able to get the functionality you are looking for. I didn't understand the 2nd feature requested there, but it doesn't sound like Page Forms supports it. Yaron Koren (talk) 13:15, 15 September 2020 (UTC)

Internal Error for Special:CreateClass

Hi. I'm getting an error when trying to access Special:CreateClass. I've just started setting up semantic mediawiki on my wiki (https://wikimsk.org). Any ideas?

[d053a01e2ad44a967d833c60] /wiki/Special:CreateClass Error from line 219 of /container/application/public/w/extensions/PageForms/specials/PF_CreateClass.php: Call to a member function getDatatypeLabels() on null

Backtrace:

#0 /container/application/public/w/includes/specialpage/SpecialPage.php(575): PFCreateClass->execute(NULL)
#1 /container/application/public/w/includes/specialpage/SpecialPageFactory.php(611): SpecialPage->run(NULL)
#2 /container/application/public/w/includes/MediaWiki.php(296): MediaWiki\Special\SpecialPageFactory->executePath(Title, RequestContext)
#3 /container/application/public/w/includes/MediaWiki.php(900): MediaWiki->performRequest()
#4 /container/application/public/w/includes/MediaWiki.php(527): MediaWiki->main()
#5 /container/application/public/w/index.php(44): MediaWiki->run()
#6 {main}

Also have the following error with Special:CreateProperty

[49e777dba95755b3845f78db] /wiki/Special:CreateProperty Error from line 99 of /container/application/public/w/extensions/PageForms/specials/PF_CreateProperty.php: Call to a member function getDatatypeLabels() on null

Backtrace:

#0 /container/application/public/w/extensions/PageForms/specials/PF_CreateProperty.php(22): PFCreateProperty->printCreatePropertyForm(NULL)
#1 /container/application/public/w/includes/specialpage/SpecialPage.php(575): PFCreateProperty->execute(NULL)
#2 /container/application/public/w/includes/specialpage/SpecialPageFactory.php(611): SpecialPage->run(NULL)
#3 /container/application/public/w/includes/MediaWiki.php(296): MediaWiki\Special\SpecialPageFactory->executePath(Title, RequestContext)
#4 /container/application/public/w/includes/MediaWiki.php(900): MediaWiki->performRequest()
#5 /container/application/public/w/includes/MediaWiki.php(527): MediaWiki->main()
#6 /container/application/public/w/index.php(44): MediaWiki->run()
#7 {main}

InnerCitadel (talk) 07:24, 16 September 2020 (UTC)

Sorry about that - this is a known problem with SMW 3.2 and later; see here. I'm someone can fix the problem. Yaron Koren (talk) 12:19, 16 September 2020 (UTC)

There was a change in the code of Semantic Mediawiki in april 2020 (see https://phabricator.wikimedia.org/T246579). It seems, that there is no fix in the master branch of PageForms yet. You may fix the bug by editing the effected files that are named in the error msg (e.g. [...]/extensions/PageForms/specials/PF_CreateClass.php)

At the line, stated in the error message there should be a code like this:

$possibleTypes = $smwgContLang->getDatatypeLabels();

the variable $smwgContLang is no longer available (thats why the error msg tells that the function "getDatatypeLabels" is called on null). change the code as following:

$possibleTypes = smwfContLang()->getDatatypeLabels();

This should get PageForms special pages back to work.

KBailly (talk) 14:35, 16 September 2020 (UTC)

Thanks, KBailly - I checked in a change based on this suggestion. Hopefully anyone using the very latest Page Forms code and any version of SMW will have these special pages working. Yaron Koren (talk) 02:37, 17 September 2020 (UTC)

@Yaron Koren: Hi! Thank you very much for this awesome extension. I am having the same issue, but I already see there is a patch for this error. I installed Page Forms using Composer, but the latest upgrade was on 2020-08-04, have you planned to release this patch soon? I do not mean to hurry you, I just want to know if I should reinstall it from the git repository. Regards, Ivanhercaz (talk) 21:27, 30 September 2020 (UTC)

P.S. I already solved thanks to Jeroen in the Semantic MediaWiki's Telegram group. I just change the version to dev-master. Excuse me the inconveniences! Regards, Ivanhercaz (talk) 21:41, 30 September 2020 (UTC)

Cannot expand tree elements [SOLVED]

In the old version, depth= was ignored and everything was displayed.

In the latest version, depth= works, but there is no ability to expand a node. This is my code currently:

{{{field|Subject|input type=tree|list|top category=xyz|height=300|width=600|depth=2|hideroot}}}

Please let me know if you need further information.

There is a chance that some Common.css fix from before is messing things up now. I will check, and can send you a link to my site privately if you need it. Jonathan3 (talk) 23:03, 18 September 2020 (UTC)

You've found a bug in the handling of "depth" in the new tree code. I would avoid the use of "depth" until this is fixed... Yaron Koren (talk) 20:38, 25 September 2020 (UTC)

Fixed now, I think. Sorry about that. Yaron Koren (talk) 21:55, 25 September 2020 (UTC)

This works now. Thanks. The little arrows aren't very prominent though, if you're still looking to make small improvements. Jonathan3 (talk) 22:27, 26 September 2020 (UTC)

MultiPageEdit stops the parsing when a pipe is used

Hi Yaron,

Another bug we discovered using MultiPageEdit :

When a template is used with a pipe, it doesn't get through MultiPageEdit and stops parsing the remaining properties.

For exemple, for the word suffixe : https://dicoado.org/dico/suffixe (correct properties shown https://dicoado.org/wiki/index.php?title=suffixe&action=pagevalues)

On Special:MultiPageEdit we get :

Page : suffixe

Def : affixe derrière le radical d’un mot

Classe : nom masculin

Ex : Le mot {{"

and it stops right here, where the pipe should be. No "Contr", "Voir", "Image", "Légende", "Cat" nor "Attention".

Thank you for your time.

DSwissK (talk) 07:47, 19 September 2020 (UTC)

(copied from https://www.mediawiki.org/wiki/Extension_talk:Page_Forms/Special_pages since the right place is here)

Yes, sorry about that problem. I just checked in a fix for this! Page parsing should now work a lot better. Yaron Koren (talk) 20:38, 25 September 2020 (UTC)

MultiPageEdit doesn't show everything it should

Hi again Yaron,

I'm using MultiPageEdit on my wiki https://dicoado.org/wiki/index.php?title=Sp%C3%A9cial:MultiPageEdit&template=Article&form=Ajouter+un+mot (you will be able to see it, since you have the rights.)

Problem : There should be more than 9'000 rows but I can only see 500 entries. Is it somewhere limited (if so, is there a parameter to set a higher limit and/or a way to work around it)? It seems to me that the 500 shown ones are the 500 first created articles.

Thanks for your time.

DSwissK (talk) 07:51, 19 September 2020 (UTC)

(also copied from https://www.mediawiki.org/wiki/Extension_talk:Page_Forms/Special_pages to have all bugs at the same place)

Yes, I think the current spreadsheet handling only shows the first 500 rows/pages. This problem will go away once the spreadsheet handling changes to use a different JS library (jExcel instead of jsGrid). Yaron Koren (talk) 20:40, 25 September 2020 (UTC)

Width of tokens etc (select2) input types

This is similar to "Select2 autocomplete - forminput has very little width" above.

After upgrading to the latest Page Forms, some of the input fields were tiny. This turned out to be because of a Common.css fix I had used with earlier PF versions to make PF work with the Foundation skin (to prevent the tokens field from being too wide):

.pf-select2-container {min-width:0px !important}

After the upgrade this made the width 0px, so I've changed it to 200px to make it acceptable for now. But it's not 100% of the width the way it used to be.

Also, when I type into it, it expands and gets too wide. What I want, ideally, is for it to start at 100% of the div it's in, and stay there.

I will check whether there are some Common.css things that are causing this... but what do you think?

Thanks Jonathan3 (talk) 09:21, 19 September 2020 (UTC)

Sorry for the delay. I don't know, but hopefully there's a solution for it! Yaron Koren (talk) 13:07, 5 October 2020 (UTC)

[SOLVED] Possible to "Preload" Multiple-instance templates?

I have a form page (Form:Foo) as follows:

<noinclude>
{{#forminput:form=Foo|link type=button|link text=CREATE NEW FOO}}
</noinclude>

<includeonly>
{{{for template|Foo}}}
{{{field|Bar|holds template}}}
{{{end template}}}

{{{for template|Bar|label=User defined Foo Bar sections|multiple|embed in field=Foo[Bar]}}}
{{{field|Zaz}}}
{{{end template}}}
</includeonly>

It works fine, however, on a new page created with this form I'd like to "pre-populate" a few standard Zaz'es in the Bar sections that I know that 'most' users will want, but not all.

Is this possible?

Thanks!

/Rich Revansx (talk) 12:27, 23 September 2020 (UTC)

turns out I can do this by using #formlink to generate the new Foo page with the parameter |preload=somepagewithdefaultwikitext pointing to somepagewithdefaultwikitext ... yippie! - Revansx (talk) 16:48, 25 September 2020 (UTC)

Great! I think you can also do it using individual values in the query string, but having a preloaded page is the easiest solution. Yaron Koren (talk) 20:41, 25 September 2020 (UTC)

Fields of type 'Page' showing as dropdown only instead of text with autocomplete

Using PageForms 4.9.5, Cargo 2.7, and MW 1.34.0. I must have caused this but not sure how - on my form there are several fields using the cargo 'Page' type, and where before I could type text into them and choose from an autocomplete list, now they only appear as dropdown menus with existing pages and no way to type in anything. I was using Cargo 2.4 and upgraded to see if that fixed it, but no luck.

--AgentIrons (talk) 18:26, 26 September 2020 (UTC)

Sorry for the delay. I'm guessing that this is due to a JavaScript error. If you know how to do it, could you look in the browser console and see if any JS errors appear on that page? Yaron Koren (talk) 13:08, 5 October 2020 (UTC)

Not the original poster, but I have what seems to be a similar problem? PF v4.9.5, MW 1.34.4, Cargo 2.7, and the skin is Citizen 0.9.4. Hosted on Miraheze.

Token fields are not allowing text to be typed, but allows choosing a dropdown option. Also, the tree input type doesn't seem to function as I would expect- I have nested categories 3 or 4 levels deep, but it only displays the top 2 levels and clicking on the radio buttons does nothing. I do not have a depth parameter set.

Not sure if this is a skin issue, or JS, or both?

Here are some errors from the console when loading the Form:

Uncaught ReferenceError: importArticles is not defined
    <anonymous> https://khouba.miraheze.org/wiki/Form:Shop line 12 > injectedScript:1
    jQuery 2
Form:Shop line 12 > injectedScript:1:14
Uncaught ReferenceError: importArticles is not defined
    <anonymous> https://khouba.miraheze.org/w/load.php?debug=true&lang=en&modules=site&only=scripts&skin=citizen&version=ig8x3:6
    jQuery 2
load.php:6:2

--GrapheneBob (talk) 14:06, 20 October 2020 (UTC)

These sound unrelated - I would create separate sections for them. And I think those JS errors are from something other than Page Forms (maybe the ImportArticles extension). Yaron Koren (talk) 16:36, 20 October 2020 (UTC)

Sorry for my own delay! In the console there are a handful of warnings that various jquery modules have been deprecated (jquery.tabIndex, jquery.ui, jquery.position, etc.) and then four of these:

TypeError: data.unshift is not a function

--AgentIrons (talk) 22:43, 20 October 2020 (UTC)

Sorry about that problem; I just checked in a fix for it. Yaron Koren (talk) 16:25, 30 October 2020 (UTC)

Thanks! That fixed the first issue, but now I've got the opposite problem - fields of type 'Page' will let me type in a value, but their dropdown shows 'No results found' and nothing comes up for autocompletion. Fields of 'String' or 'List (,) of Page' still work as expected.

--AgentIrons (talk) 13:53, 1 November 2020 (UTC)