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.


 * 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)
 * 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 &eacute; (the html code is escaped). Raphoraph (talk) 14:00, 27 August 2020 (UTC)
 * I've edited my message above, and here's a precision : the error seems to be caused by an other exception throwed earlier. 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 : , in PF_tree.js:23. Kind regards, Raphoraph (talk) 13:55, 3 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.

default value when using "show on select" options
The goal is to ensure that a value is selected for property "TheOption" from 1 of 2 dropdown lists.
 * Mediawiki 1.34.1 (b1f6480)
 * Page Forms 4.9.4 (c4fb7d3)

I have a form with the following wikitext

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 | ," and the Form page shows ! 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 " " 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)

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.

results in a small form-input. I've added  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:

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:


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

"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)
 * Hi Yaron, I just updated to the master version (1343d6d). If I'm logged in  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:


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


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


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

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:

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)


 * 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 . 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:

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)

[SOLVED] Possible to "Preload" Multiple-instance templates?
I have a form page (Form:Foo) as follows:

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  to generate the new Foo page with the parameter   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)

Using autoedit on File namespace ($wgPageFormsAutoeditNamespaces global)
Hi,

''Our setup: MW 1.31.1 PageForms 4.6''

We are trying autoedit on the File namespace and have modified LocalSettings with "$wgPageFormsAutoeditNamespaces[] = NS_FILE;". How do we specify the namespace to target? Using "|target=File:file.png" does not work since the colon seems to cause a json format issue. We have tried putting into the query string "|query string=namespace=File&....." and that does not work. I assume there is no namespace parameter because this does not seem to work as part of the autoedit specification: "|namespace=". How do we use $wgPageFormsAutoeditNamespaces properly and how to define the autoedit link? We would like to autoedit outside the Main namespace.

Thanks,

Longphile (talk)