Extension talk:Page Forms

#formredlink inside list created by #ask?
I have a SMW with PageForms to save some structured information about historical biographies. A person's residence is stored in subobjects and displayed with #ask as a bullet list:

How can red links for the homeLocation attribute automatically point to the right form (Form:Location)?


 * My current workaround is setting   and letting the wiki user choose the right form. Any better ideas?


 * Maybe use the "template" format, so you can embed #formredlink around each result. Yaron Koren (talk) 17:19, 20 October 2020 (UTC)

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)


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

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)

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:

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.

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)


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

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)


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

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)

Is it possible to change the delimiter by default?
Hi everyone,

I would like to use semicolons instead of commas  to separate values. Is there any variable o something else to configure this?

Thanks in advance!

Regards, Ivanhercaz (talk) 01:14, 8 October 2020 (UTC)


 * Yes - just add "|delimiter=;" or whatever it is to the relevant field tag(s) in the form definition. Yaron Koren (talk) 21:12, 9 October 2020 (UTC)

Links to a template using "queryformlink" from a cargo query
Hi, lets say i have Template:search that runs "queryformlink".

I have this simple cargo query:

When doing that, all of the Template:search values are: 'UNIQ--item-0--QINU', Why is that? Thank you!


 * Well, I wouldn't really call it a "simple" query - it's a call to a parser function (#cargo_query) that produces a template call that in turn is meant to call another parser function. What you're seeing is a bug, but I'm not totally surprised that it's failing, given the chain of parsing that has to take place. Maybe there's a simpler way to do whatever you're trying to accomplish? Yaron Koren (talk) 21:07, 13 October 2020 (UTC)
 * Im trying to add a link (to a query form with predefined params) for each row in the result, I can ofc write the unformatted link in the CONCAT but it seems to be bad practice IMO.Do you have any idea how to solve that? (Or a workaround) Thank you! 77.125.48.193 18:45, 14 October 2020 (UTC)

Bug report: namespace prefix getting removed
I use tokens with the "values from property" parameter, which gathers values from different namespaces. However, on autocomplete, I don't see the namespace prefix (which in my case denotes a particular language so that represents essential information) and when I select a value from the dropdown menu and save the page, values are saved without their namespace prefix. Same thing with "text on autocomplete". Cavila 10:25, 15 October 2020 (UTC)

Use Math Type Elements Inside Page Form
MW 1.35 Page Form 4.9.5 Cargo 2.7: Is it possible to create a Form which will do some simple math. I would like to have a handful of fields within a form which determine a real estate term Cap Rate. In essence, one field will be the Gross Income (GI). Next, we have several fields for Taxes (T), Maintenance (M), and Insurance(I). These 3 fields equal Net Income (T+M+I=NI). We have a field called Purchase Price (PP). The final field, Cap Rate is equal to NI/PP. Technically, this is a percentage and thus the decimal answer for Cap Rate would have to convert to a percentage. Any help would be greatly appreciated! -- Foreclosurepedia (talk) 19:22, 17 October 2020 (UTC)


 * I'm not sure I understand what you're asking, but Special:RunQuery may help with this. Yaron Koren (talk) 15:47, 19 October 2020 (UTC)

Upgrading from Semantic Forms to Page Forms
I am attempting to upgrade my MW instance from v 1.21 to v1.35. Most everything is working correctly, but Page Forms does not recognize any of my Semantic Forms data (or it wasn't converted properly via update.php or /SemanticMediaWiki/maintenance/rebuildData.php). Basically no /wiki/Form:blah pages exist, and my links to these are dead. I'm not exactly sure what sorts of log output is needed for troubleshooting, but I don't see any historic reference to these upgrade issues for this extension, which would seem to be a common problem. I have very limited PHP knowledge outside of basic config (php-fpm v 7.4 via nginx).

It looks like Templates are OK, but Property is being interpreted as 'Form' (i.e., clicking on 'Forms' link under [Page Forms] on Special Pages brings up a list of my Properties). I see no link to 'Properties' from Special Pages.

Please assist. Thanks in advance! ~z929669 Talk 17:57, 19 October 2020 (UTC)


 * I'm guessing that the problem has to do with namespace IDs in the database. Do you have access to your database? If so, I would call something like "SELECT page_namespace, COUNT(*) FROM page GROUP BY page_namespace" to try to get a sense of which IDs are being used. Yaron Koren (talk) 16:05, 19 October 2020 (UTC)


 * Thanks for the tip, Yaron. Yes, I can access the DB ... the query returns results (namespace IDs) corresponding to most of my namespaces, but 'Form' has never been defined in my LocalSettings.php. I'm not sure how to list all of my namespaces by name, because many of these don't need to be defined in LocalSettings.php:


 * ~z929669 Ixian_Insignia_SM.png Talk 17:57, 19 October 2020 (UTC)


 * Thanks, this is helpful. The relevant IDs here are 102 and 106, which are supposed to define SMW properties and PF forms, respectively. It looks like you've defined an enormous number of forms, but that's alright. I would run queries like "SELECT page_name FROM page WHERE page_namespace=102" and "SELECT page_name FROM page WHERE page_namespace=106" to make sure that these namespace IDs do in fact hold properties and forms, respectively. (No need to put the results here.) If those results seem fine, then somehow the namespace IDs are getting messed up in the code. Are you modifying them in any way in LocalSettings.php? Yaron Koren (talk) 17:48, 19 October 2020 (UTC)


 * I edited the info above to add names as defined by default and in my config:  and   as well as :   and
 * Note that I do define 102 but 106 is (and has always been) undefined. I will investigate per your advice and get back. ~z929669 Ixian_Insignia_SM.png Talk 17:57, 19 October 2020 (UTC)


 * UPDATE: So it looks like 116 is something new in upgrading (values like Group:Predefined_properties), my Concepts are under 112, my Forms are under 110, and my Properties under 106 in both my old wiki (1.21; Semantic Forms v2.6) and in my upgraded wiki (1.35; Page Forms [latest version]). I have no idea or indication that the default behavior was changed for Semantic Forms, so I'm guessing that 110 used to be used for Form namespace (or perhaps juxtaposed, since 102 is custom?)? Also, 102 does not line up really with 110 (or 106), because that is a many:1 relationship. I haven't figured out how to join 102 data with that of 110/106, but that would be useful. ~z929669 Ixian_Insignia_SM.png Talk 18:10, 19 October 2020 (UTC)


 * Ah... no wonder. Well, there may be a simple fix, then: in your LocalSettings.php, you probably have some setting of SF_NS_FORM and SF_NS_FORM_TALK. You just have to change those to PF_NS_FORM and PF_NS_FORM_TALK, respectively. Yaron Koren (talk) 18:25, 19 October 2020 (UTC)


 * Nope, no namespace defs for *FORM*, but I have customized 102 a long time ago (see my last [edited]). This may have thrown things off in the upgrade process that may not be revealed otherwise? I can easily define the namespaces in my old config and site and upgrade likewise. It would be good to have a clear idea beforehand though ... but I think you have nailed the general issue (whew!). Any ideas? ~z929669 Ixian_Insignia_SM.png Talk 18:30, 19 October 2020 (UTC)
 * UPDATE: I went ahead and added PF_NS_FORM* namespaces to my config, and that seems to have fixed the issue :) ... but I still can't see them under Speacial:SpecialPages - Page Forms section. It also looks like my Properties may be conflated with something OOtB in SMW, so perhaps I should explicitly define Page Forms namespaces? Please confirm syntax ... I assume PF_NS_PROPERTY? That appears to be 106/7. ~z929669 Ixian_Insignia_SM.png Talk 18:43, 19 October 2020 (UTC)
 * UPDATE2: I explicitly defined Property namespace in my config as SMW_NS PROPERTY* .... this had no impact, so running, and initial se output is promising with "find and rebuild Property pages ..." ~z929669 Ixian_Insignia_SM.png Talk 19:18, 19 October 2020 (UTC)
 * UPDATE3: Rebuilding the data followed by  has resolved all issues. Many thanks! ~z929669 Ixian_Insignia_SM.png Talk 19:52, 19 October 2020 (UTC)

Discourse DB examples not accessible
Hi, I'd like to be able to view the Discourse DB wiki that is frequently used to show examples (such as for Spreadsheet-style Editing) but to view such pages requires registering as a User of that wiki. When attempting to do so, there is a recaptcha that asks who the Secretary Of State of the US is, and no SOS from the last 20 years works. Or maybe the format of the name isn't right? Perhaps the question could be changed to something that shifts less often (especially with the current adminstrations high turnover) such "What is the Last Name of the SOS in the year 2013?"--GrapheneBob (talk) 22:05, 19 October 2020 (UTC)


 * Sorry about that - yes, the CAPTCHA answer is deliberately wrong, to prevent spammers, but it has caused a lot of frustration for real users. I just changed the permissions on Special:MultiPageEdit, i.e. the spreadsheet-style editing you're talking about, so that anyone can view the page. Hopefully I won't regret this. :) I should note that the version of this page on discoursedb.org uses different code from that in the main Page Forms code - this is a long-in-development change that may get checked in sometime this week. Yaron Koren (talk) 17:03, 20 October 2020 (UTC)

Autocapitalize off for mobile
Hi Yaron,

Could you add an "autocapitalize" parameter (keywords being "off", "characters", "words" and "sentences") to the "field" tag to be able to turn autocapitalize off for mobile ? The fix seems to be adding autocapitalize="off" to the search element.

More info : https://developers.google.com/web/updates/2015/04/autocapitalize

Thank you. Best regards.

DSwissK (talk) 09:04, 20 October 2020 (UTC)


 * Hi! Sorry, I don't understand this. What is autocapitalize - is it the fact that, on mobile devices, the keyboard switches to capital letters before you type the first letter? Or is it something that happens to words after you have already typed them? And do you ever want it enabled, or always disabled? Yaron Koren (talk) 17:17, 20 October 2020 (UTC)


 * Hi, sorry for not being clear enough. Autocapitalize is usually very useful when using mobile devices (for entering cities, names or states in a form, for example). As you said, the keyboard automatically switches to capital letters before I type de first letter. You can see it live here : https://dicoado.org/dico/Formulaire:Ajouter_un_mot
 * In the Dico des Ados (since it's a dictionary) it's something I'd like to disable when adding up a word with the form, since only proper nouns start with a capital letter in French. Since way more people add common nouns than proper ones, it'd be better to be disabled by default (which doesn't hinder the person to press shift on his virtual keyboard to start with a captal letter).
 * I hope this makes more sense now. :)
 * Best regards. DSwissK (talk) 07:12, 21 October 2020 (UTC)


 * Okay, now I understand. And that is annoying! But what you are specifically asking for here is a change to the #forminput syntax, which is different from form definitions. Do you need an "autocapitalize" parameter in both? Yaron Koren (talk) 19:37, 21 October 2020 (UTC)


 * Yes, we do need both. Since we also use parameters that should start with lower-case characters (like synonyms, definition...). DSwissK (talk) 10:53, 24 October 2020 (UTC)

Values from Category and Subcategories
Is it possible to get Values from Category to display subcategories as possible values as well? For my use, I have a database of Books that have a Genre and each book is in a genre category. All of those genre categories roll up to the Genre Category. So a tree is like this:
 * Category:Genres
 * Category:Sci-Fi
 * Star Trek
 * Star Wars
 * Category:Fantasy
 * Sword of Shannara
 * Lord of the Rings

My form is for creating new Book pages, and would like to add one or multiple genres to each using tokens. Ideally values come from the subcategories. And if a user enters a genre that doesn't exist yet as a category, it would create a new category page (rather than article)....this part I'm not 100% sure on yet, as it's likely we'll just limit to existing values only. Thanks --GrapheneBob (talk) 15:46, 22 October 2020 (UTC)


 * If you're fine with limiting it to to just existing values, your best option might be to use the "tree" input type, with the "top category" parameter. Yaron Koren (talk) 15:54, 22 October 2020 (UTC)


 * Is it possible to store the actual Category page as the value in the cargo field? I see the documentation notes that it strips "Category:" prefix off, and the work around is to set the #arraymap up to add back in "Category:" when it is displayed in the template...But if I have a query that displays this field it will only display the non-category value in the results.  Is it A) possible to add "Category:" to the stored value when it is getting stored initially, or B) possible to use #arraymap/similar method on query results to append "Category:" prefix to every value?   On the latter, i have tried just using the query as the "string" parameter, but that only appends "Category:" to the sets of values in each record, rather than to each value themselves.


 * Thank you


 * Yes, it's possible - just put an #arraymap call within #cargo_store itself, so that it prepends "Category:" onto every name. Yaron Koren (talk) 13:19, 26 October 2020 (UTC)

Populating input with content from a different template
Hello,

Is there any way to populate the default field of input box with a different template content (After it was parsed)?

For example,

Will show the   content to the user.

Thanks in advance. --Tufloc (talk) 16:22, 26 October 2020 (UTC)


 * No, and I don't know why you would want that - won't that lead to redundant content? Yaron Koren (talk) 20:15, 26 October 2020 (UTC)

Tokens only working as dropdown, no text entry
Hi, I am having an issue with token fields only functioning as dropdown menus and not allowing any text entry, rearranging of tokens, or removal of tokens once entered. I reported this as a comment on a similar topic but was advised to create a new topic for it ("Fields of type 'Page' showing as dropdown only instead of text with autocomplete")

PF v4.9.5, MW 1.34.4, Cargo 2.7, and the skin is Citizen 0.9.4. Hosted on Miraheze.

This page form is for entry into a Cargo field that holds a list of Pages. The form itself has values from namespace, and the values in the dropdown are correct. I have a few similar forms all with the same issue. Since I last posted I tried to see if I would have the same issue on another miraheze wiki and I didn't; it works fine. I also switched the Skin I am using which did not fix it. I have removed a bunch of extensions I had, to the point where I matched what that other wiki has, but no luck there either. In the previous topic it was suggested maybe an extension "importArticle" was the culprit or somehow related, but I do not have such an extension.

I looked at "common issues with Select2" that seemed related and it seems this is not an "uncommon" issue, as discussed here, here, and here. I have no idea why it would work on one wiki and not another, though... --GrapheneBob (talk) 16:18, 27 October 2020 (UTC)


 * It would help if you added "&debug=true" (or maybe "?debug=true"), then looked at the form page again with the JS console - you'll probably get a more helpful error message. It would be good to know which specific JS file the error is coming from. Yaron Koren (talk) 16:27, 30 October 2020 (UTC)