Extension talk:Page Forms/Archive July to August 2019

autoedit issue when page has subobjects

Product	Version
MediaWiki	1.31.1
PHP	7.1.8 (apache2handler)
MySQL	5.6.10
Semantic MediaWiki	2.5.8
Page Forms	4.3.1 (624f2a9) 18:20, 16 January 2018

I'm using auto edit to set a property to a new value on a page. When the page has subobjects and I select the button to change the property 1 of the subobjects disappears.

I upgraded page forms to 4.5.1 and that seems to have fixed the issue Legaulph (talk) 11:23, 2 July 2019 (UTC)

No default values for embedded multiple-instance templates

(MediaWiki 1.32.2, Page Forms 4.5.1) I made a query form with a main template and a secondary "embed in field" multiple instance template.

{{{for template| X | multiple | embed in field= Y[Z] }}}

It works fine but the fields default values are not set for the secondary template. Tested without "embed in field": defaults are ok.

By the way, "Select all" and "Select none" for checkboxes are not shown in multiple instance layout, I don't know if its made on purpose, still it would be nice to have it also in this context.

I switched skin and browser user-agent, don't know what happens but now defaults are correctly set.

Steph.

Select2 don't work.

When I create a form, I create 'field' tag, which have input type: 'text with autocomplete', 'textarea with autocomplete', 'tokens' or 'combobox', and have 'list' parameter for many values. This field are associated with template field which have SMW-property "Page" and have several allow values ([[AllowValues:: ]]. When I try to use this form, I type characters but nothing happens. I don't see autocomplete. At the same time, on my monitor screen, I see spinning boot icon (from the file extension\PageForms\skins\loading.gif).
When I change input type on 'checkboxes' or 'listbox', I can select required values in the form without problem. But it is uncomfortable.
I think, it is problem into Select2-library. What must I do?

MediaWiki 1.32.1
PHP 7.3.5 (apache2handler)
MariaDB 10.1.40-MariaDB
Windows 10 64 bit
FireFox 68.0
Language Russian

Extension:
Semantic Drilldown 2.1
Semantic MediaWiki 2.3.1
Page Forms 4.5.1
DataValues 1.0
DataValues Common 0.2.3
DataValues Interfaces 0.1.5
DataValues Validators 0.1.2
ParserHooks 1.4.0
Validator 2.0.4

Settings in LocalSetting.php:
$wgPageFormsAutocompleteOnAllChars = true;
$smwgEnableUpdateJobs = false;

Could you look in the console on your browser, and see if there are any JavaScript errors? Yaron Koren (talk) 22:54, 18 July 2019 (UTC)

Browser console:

[ac0a9dbb1002909f24b58b84] /wiki/mediawiki-1.32.1/load.php?debug=false&lang=ru&modules=startup&only=scripts&skin=vector BadMethodCallException from line 848 of C:\xampp\htdocs\wiki\mediawiki-1.32.1\includes\session\SessionManager.php: Sessions are disabled for this entry point
Backtrace:
#0 C:\xampp\htdocs\wiki\mediawiki-1.32.1\includes\session\SessionManager.php(310): MediaWiki\Session\SessionManager->getSessionFromInfo(MediaWiki\Session\SessionInfo, WebRequest)
#1 C:\xampp\htdocs\wiki\mediawiki-1.32.1\includes\session\SessionManager.php(244): MediaWiki\Session\SessionManager->getEmptySessionInternal(WebRequest)
#2 C:\xampp\htdocs\wiki\mediawiki-1.32.1\includes\session\SessionManager.php(194): MediaWiki\Session\SessionManager->getEmptySession(WebRequest)
#3 C:\xampp\htdocs\wiki\mediawiki-1.32.1\includes\WebRequest.php(750): MediaWiki\Session\SessionManager->getSessionForRequest(WebRequest)
#4 C:\xampp\htdocs\wiki\mediawiki-1.32.1\includes\user\User.php(1377): WebRequest->getSession()
#5 C:\xampp\htdocs\wiki\mediawiki-1.32.1\includes\user\User.php(447): User->loadFromSession()
#6 C:\xampp\htdocs\wiki\mediawiki-1.32.1\includes\user\User.php(5487): User->load()
#7 C:\xampp\htdocs\wiki\mediawiki-1.32.1\includes\user\User.php(3174): User->loadOptions()
#8 C:\xampp\htdocs\wiki\mediawiki-1.32.1\includes\context\RequestContext.php(336): User->getOption(string)
#9 C:\xampp\htdocs\wiki\mediawiki-1.32.1\includes\Message.php(713): RequestContext->getLanguage()
#10 C:\xampp\htdocs\wiki\mediawiki-1.32.1\includes\context\RequestContext.php(426): Message->setContext(RequestContext)
#11 C:\xampp\htdocs\wiki\mediawiki-1.32.1\includes\context\ContextSource.php(171): RequestContext->msg(string)
#12 C:\xampp\htdocs\wiki\mediawiki-1.32.1\extensions\SemanticMediaWiki\includes\queryprinters\TableResultPrinter.php(35): ContextSource->msg(string)
#13 C:\xampp\htdocs\wiki\mediawiki-1.32.1\extensions\SemanticMediaWiki\src\MediaWiki\Hooks\ResourceLoaderGetConfigVars.php(62): SMW\TableResultPrinter->getName()
#14 C:\xampp\htdocs\wiki\mediawiki-1.32.1\extensions\SemanticMediaWiki\src\MediaWiki\Hooks\HookRegistry.php(341): SMW\MediaWiki\Hooks\ResourceLoaderGetConfigVars->process()
#15 C:\xampp\htdocs\wiki\mediawiki-1.32.1\includes\Hooks.php(174): SMW\MediaWiki\Hooks\HookRegistry->SMW\MediaWiki\Hooks\{closure}(array)
#16 C:\xampp\htdocs\wiki\mediawiki-1.32.1\includes\Hooks.php(202): Hooks::callHook(string, array, array, NULL)
#17 C:\xampp\htdocs\wiki\mediawiki-1.32.1\includes\resourceloader\ResourceLoaderStartUpModule.php(129): Hooks::run(string, array)
#18 C:\xampp\htdocs\wiki\mediawiki-1.32.1\includes\resourceloader\ResourceLoaderStartUpModule.php(432): ResourceLoaderStartUpModule->getConfigSettings(ResourceLoaderContext)
#19 C:\xampp\htdocs\wiki\mediawiki-1.32.1\includes\resourceloader\ResourceLoaderModule.php(708): ResourceLoaderStartUpModule->getScript(ResourceLoaderContext)
#20 C:\xampp\htdocs\wiki\mediawiki-1.32.1\includes\resourceloader\ResourceLoaderModule.php(675): ResourceLoaderModule->buildContent(ResourceLoaderContext)
#21 C:\xampp\htdocs\wiki\mediawiki-1.32.1\includes\resourceloader\ResourceLoaderModule.php(812): ResourceLoaderModule->getModuleContent(ResourceLoaderContext)
#22 C:\xampp\htdocs\wiki\mediawiki-1.32.1\includes\resourceloader\ResourceLoader.php(660): ResourceLoaderModule->getVersionHash(ResourceLoaderContext)
#23 [internal function]: ResourceLoader->{closure}(string)
#24 C:\xampp\htdocs\wiki\mediawiki-1.32.1\includes\resourceloader\ResourceLoader.php(672): array_map(Closure, array)
#25 C:\xampp\htdocs\wiki\mediawiki-1.32.1\includes\resourceloader\ResourceLoader.php(753): ResourceLoader->getCombinedVersion(ResourceLoaderContext, array)
#26 C:\xampp\htdocs\wiki\mediawiki-1.32.1\load.php(51): ResourceLoader->respond(ResourceLoaderContext)
#27 {main} load.php:33:47

Exception in resolve: load.php:35:625
Error: "Unknown dependency: ext.pageforms.main"
    sortDependencies http://localhost/wiki/mediawiki-1.32.1/load.php?debug=false&lang=ru&modules=startup&only=scripts&skin=vector:41
    resolveStubbornly http://localhost/wiki/mediawiki-1.32.1/load.php?debug=false&lang=ru&modules=startup&only=scripts&skin=vector:42
    load http://localhost/wiki/mediawiki-1.32.1/load.php?debug=false&lang=ru&modules=startup&only=scripts&skin=vector:53
    <anonymous> http://localhost/wiki/mediawiki-1.32.1/index.php/Служебная:FormEdit/Создание_нового_документа/13:9
    push http://localhost/wiki/mediawiki-1.32.1/load.php?debug=false&lang=ru&modules=startup&only=scripts&skin=vector:76
    <anonymous> http://localhost/wiki/mediawiki-1.32.1/load.php?debug=false&lang=ru&modules=startup&only=scripts&skin=vector:76
    <anonymous> http://localhost/wiki/mediawiki-1.32.1/load.php?debug=false&lang=ru&modules=startup&only=scripts&skin=vector:76
load.php:35:662

And other analogical errors:

Exception in resolve: load.php:35:625
Error: "Unknown dependency: ext.pageforms.submit"
load.php:35:662

Exception in resolve: load.php:35:625
Error: "Unknown dependency: ext.pageforms.fancytree"
load.php:35:662

Exception in resolve: load.php:35:625
Error: "Unknown dependency: ext.pageforms.imagepreview"
load.php:35:662

Exception in resolve: load.php:35:625
Error: "Unknown dependency: ext.pageforms.autogrow"
load.php:35:662

Exception in resolve: load.php:35:625
Error: "Unknown dependency: ext.pageforms.checkboxes"
load.php:35:662

Exception in resolve: load.php:35:625
Error: "Unknown dependency: ext.pageforms.select2"
load.php:35:662

Exception in resolve: load.php:35:625
Error: "Unknown dependency: ext.pageforms.rating"
load.php:35:662

Exception in resolve: load.php:35:625
Error: "Unknown dependency: ext.pageforms.fancybox.jquery3"
load.php:35:662

I have solved this problem by change the skin in my Wiki from 'Vektor' to 'Monobook'. But it isn't good, because 'Vektor' more beautiful then 'Monobook'. I hope this bug will be eliminate in future. Thank you for support. Thiazole

Interesting. Is "Vektor" the same as "Vector"? (I assume so.) And do these JS errors show up in every one of your forms, if you have more than one? Yaron Koren (talk) 13:24, 19 July 2019 (UTC)

Yes, "Vektor" = "Vector", it is a misprint. I'm sorry. I have several forms, and all of this forms have errors. Thiazole

It sounds like there are one or more JavaScript bugs there, which may be unrelated to Select2. Possibly they're coming from Semantic MediaWiki, judging by that console printout. Could you try temporarily disabling SMW and seeing if the JS errors are still there in the forms? Yaron Koren (talk) 01:57, 25 July 2019 (UTC)

Input type "checkboxes": Missing CSS class in span tag?

I am going to use Page Forms in this wiki here in order to create file descriptions for uploaded files by using a page form. I fiddled around with radio buttons and I am now finally able to format and position them with the help of a CSS grid. Therefore I created a CSS class for a special group of radio buttons in Common.css. This works fine. Then I tried the same on checkboxes. Of course with a different CSS class for a special group of checkboxes. That failed at first. I took a look at the HTML source code of such a page form. Every group of radio buttons and every group of chackboxes with their label and input tags is wrapped in a span tag. The span tag of the radio button group includes the CSS class, witch I added to the field tag in the form. The span tag of the group of checkboxes shows no sign of the CSS class as provided by the field tag in the form. Only the label tags of every item in that span tag are carrying this class.

This here is line 107 to 113 from the original PF_RadioButtonInput.php file:

$spanClass = 'radioButtonSpan';
if ( array_key_exists( 'class', $other_args ) ) {
	$spanClass .= ' ' . $other_args['class'];
}
if ( $is_mandatory ) {
	$spanClass .= ' mandatoryFieldSpan';
}

This is line 94 to 97 from the original PF_CheckboxesInput.php

$outerSpanClass = 'checkboxesSpan';
if ( $is_mandatory ) {
	$outerSpanClass .= ' mandatoryFieldSpan';
}

I changed that part in "my" PF_CheckboxesInput.php to:

$outerSpanClass = 'checkboxesSpan';
if ( array_key_exists( 'class', $other_args ) ) {
	$outerSpanClass .= ' ' . $other_args['class'];
}
if ( $is_mandatory ) {
	$outerSpanClass .= ' mandatoryFieldSpan';
}

Now the span tag of the group of checkboxes includes the CSS class, witch I added to the field tag in the form. And the CSS grid gets effectiv.

Is this a bug? --Wgkderdicke (talk) 14:13, 20 July 2019 (UTC)

Questions about the input types "radiobutton" and "checkboxes"

While fiddeling around with the above-named input types, I discovered this:

For every value from the values parameter one input element is created. If there is no mapping, the order of the input elements is determined by the order of the values as specified at the values parameter. If the label of the input elements is changed by a mapping template, the order changes. Now the input elements are sorted in ascending alphabetic order on the basis of the values given by the mapping template. And if the mapping template creates dynamic labels, the input elements are going to appear here and there. I think, it is better, if the order is fix and determined by the order of the values as specified at the values parameter. Or there is an extra parameter which provides sorting options.

The default parameter has to be set with one specific value out of the comma separated list from the values parameter. The show on select parameter needs the values given by the mapping template. To retrieve the values from different sources seems odd to me.

It seems that the semicolon separated values of the show on select parameter, the allocation from IDs to values, can not be generated by a template (or maybe all my attempts went wrong because of faulty syntax). Lets presume that the input field holds 90 radio buttons. And every single radio button wants to get an ID to show further information on select of this button. And the pretty long show on select part in the field tag clutters everything in the wiki code of this form... --Wgkderdicke (talk) 21:13, 24 July 2019 (UTC)

For the first issue, I didn't understand this part: "if the mapping template creates dynamic labels, the input elements are going to appear here and there". What are dynamic labels? For the second one, I'm guessing that the "show on select" value isn't parsed - not all values are parsed. That seems like a problem in this case, though it doesn't sound like a major one. Yaron Koren (talk) 02:43, 25 July 2019 (UTC)

Wrong word. Here in Germany one says: dynamische Beschriftung. This means: variable label. I "translated" this to dynamic label. Seems to be a false friend thing. Actually, I mean: if the mapping template creates variable labels, the input elements are going to appear here and there.--Wgkderdicke (talk) 08:01, 25 July 2019 (UTC)

I still don't understand what this means. Does the mapping template sometimes create "variable labels" and sometimes not? Yaron Koren (talk) 20:12, 25 July 2019 (UTC)

OK, let's presume one wants to categorize crimes. To choose one of them the form provides this field tag:

{{{field|Crime|input type=radiobutton|values=A,B,C}}}

You get three radiobuttons in this order: A,B,C. Furthermore, let's presume that the page created by this form needs exactly the A,B,C values at the Crime parameter. So it is unfeasible to change the values parameter.

Now the mapping template named Template:StaticCrimeLabel comes into play with this code:

{{#switch: {{{1|}}}
| A = Robbery (A)
| B = Assault and battery (B)
| C = Murder (C)
}}

The field tag gets the mapping template=StaticCrimeLabel option and now the order of the radiobuttons changes to:

Assault and battery (B),Murder (C),Robbery (A)

.

Now another mapping template called VariableCrimeLabel is used. This template calls yet another template named GetLastMonthCrimePercentage, which retrieves the percentage of a specific crime from the last month. The code of the new mapping template:

{{#switch: {{{1|}}}
| A = ({{GetLastMonthCrimePercentage | {{{1|}}} }}%) Robbery (A)
| B = ({{GetLastMonthCrimePercentage | {{{1|}}} }}%) Assault and battery (B)
| C = ({{GetLastMonthCrimePercentage | {{{1|}}} }}%) Murder (C)
}}

The field tag contains ths: mapping template=VariableCrimeLabel. At the moment the radiobuttons will show us this, for example, and again in a different order:

(27%) Murder (C),(30%) Robbery (A),(43%) Assault and battery (B)

.

The percentages of the crimes have changed to 22% for Murder, 33% for Assault and battery and 45% for Robbery. Time passes, it is the next month now, the last month is the former current month, the form now shows this and yet again in a different order:

(22%) Murder (C),(33%) Assault and battery (B),(45%) Robbery (A)

.

Depending on a variable value a specific radiobuttion will appear sometimes as first radio button, some other time as second radiobutton and another time as third radiobutton. The button apears here and there.

But perhaps one wants to keep a static order or respectively stick to that order, which is given by the comma separated list at the values parameter. And wants to use the mapping feature. --Wgkderdicke (talk) 21:44, 25 July 2019 (UTC)

Aha! Now I understand; thanks for that full explanation. This does seem like a bug - if "values=" is specified, the values should be kept in that order, even if they are mapped. Yaron Koren (talk) 18:27, 26 July 2019 (UTC)

Living example, check this: Form, Page, Mappig template. --Wgkderdicke (talk) 21:10, 26 July 2019 (UTC)

Same with checkboxes. I just added them to the above-posted example. --Wgkderdicke (talk) 11:58, 27 July 2019 (UTC)

Since "my" wiki runs with German language, you may view the source code of the page and the mapping template by klicking the tab named "Quelltext anzeigen" and on the page you may view the form by klicking the tab named "Formular anzeigen". --Wgkderdicke (talk) 10:01, 29 July 2019 (UTC)

And this here is an example of a so called cluttered field tag. There are 161 Buttons generated by the field tag. They are positioned in a specific order using a CSS grid. And every button triggers a select on case ID. This works! Actually it works fine. And I am going to use this. But look for yourself, if you will edit the form, what you get in the wiki editor because of the not parsed show on select value. For this following example I only added some line feed here, so that it looks a little bit like the wiki text one gets to see in the edit window. The syntaxhighlight tag here would give me only two lines and one has to scroll at least five miles to the right to watch the end of the line. I would gladly appreciate a parsed show on select value.

{{{field|Nenngroesse|input type=radiobutton|class=pfRadioButtonNenngroesse|mandatory|delimiter=\|values={{Form-File-Scale-List}}|default=-|
show on select=-=>scaleNoScale;II=>scaleII;IIm (Spur G)=>scaleIIm;IIe=>scaleIIe;IIi=>scaleIIi;IIp=>scaleIIp;I=>scaleI;Im=>scaleIm;Ie=>scaleIe;Ii=>scaleIi;
Ip=>scaleIp;0=>scale0;0m=>scale0m;0e=>scale0e;0i=>scale0i;0p=>scale0p;S=>scaleS;Sm=>scaleSm;Se=>scaleSe;Si=>scaleSi;Sp=>scaleSp;H0=>scaleH0;H0m=>scaleH0m;
H0e=>scaleH0e;H0i=>scaleH0i;H0f=>scaleH0f;H0p=>scaleH0p;H03L=>scaleH03L;H0m3L=>scaleH0m3L;H0e3L=>scaleH0e3L;H0i3L=>scaleH0i3L;H0f3L=>scaleH0f3L;
H0p3L=>scaleH0p3L;TT=>scaleTT;TTm=>scaleTTm;TTe=>scaleTTe;TTi=>scaleTTi;N=>scaleN;Nm=>scaleNm;Ne=>scaleNe;N180=>scaleN180;N3L=>scaleN3L;Z=>scaleZ;Zm=>scaleZm;
T=>scaleT;X=>scaleX;Xm=>scaleXm;Xe=>scaleXe;Xi=>scaleXi;Xp=>scaleXp;VII=>scaleVII;VIIm=>scaleVIIm;VIIe=>scaleVIIe;VIIi=>scaleVIIi;VIIp=>scaleVIIp;V=>scaleV;
Vm=>scaleVm;Ve=>scaleVe;Vi=>scaleVi;Vp=>scaleVp;III=>scaleIII;IIIm=>scaleIIIm;IIIe=>scaleIIIe;IIIi=>scaleIIIi;IIIp=>scaleIIIp;A=>scaleA;REA=>scaleREA;
An3,5=>scaleAn3k5;An2,5=>scaleAn2k5;An2=>scaleAn2;F=>scaleF;Fm=>scaleFm;Fn3=>scaleFn3;H=>scaleH;P4=>scaleP4;EEM=>scaleEEM;EM=>scaleEM;Z0=>scaleZ0;00=>scale00;
00-12=>scale00-12;00-9=>scale00-9;TT3=>scaleTT3;ZZ=>scaleZZ;TY=>scaleTY;LEGO=>scaleLEGO;1:5=>scale1d5;1:5,5=>scale1d5k5;1:6=>scale1d6;1:7=>scale1d7;1:8=>scale1d8;
1:9=>scale1d9;1:10=>scale1d10;1:11=>scale1d11;1:12=>scale1d12;1:14=>scale1d14;1:15=>scale1d15;1:16=>scale1d16;1:18=>scale1d18;1:19=>scale1d19;1:20=>scale1d20;
1:20,32=>scale1d20k32;1:22,5=>scale1d22k5;1:24=>scale1d24;1:25=>scale1d25;1:28=>scale1d28;1:29=>scale1d29;1:30=>scale1d30;1:32=>scale1d32;1:33=>scale1d33;
1:34=>scale1d34;1:35=>scale1d35;1:36=>scale1d36;1:38=>scale1d38;1:43=>scale1d43;1:43,5=>scale1d43k5;1:45=>scale1d45;1:48=>scale1d48;1:50=>scale1d50;
1:55=>scale1d55;1:60=>scale1d60;1:64=>scale1d64;1:65=>scale1d65;1:66=>scale1d66;1:72=>scale1d72;1:75=>scale1d75;1:76=>scale1d76;1:76,2=>scale1d76k2;
1:80=>scale1d80;1:82=>scale1d82;1:87=>scale1d87;1:96=>scale1d96;1:100=>scale1d100;1:101,6=>scale1d101k6;1:108=>scale1d108;1:110=>scale1d110;1:120=>scale1d120;
1:128=>scale1d128;1:144=>scale1d144;1:148=>scale1d148;1:150=>scale1d150;1:152=>scale1d152;1:160=>scale1d160;1:180=>scale1d180;1:200=>scale1d200;1:220=>scale1d220;
1:239=>scale1d239;1:250=>scale1d250;1:288=>scale1d288;1:350=>scale1d350;1:400=>scale1d400;1:450=>scale1d450;1:480=>scale1d480;1:500=>scale1d500;1:570=>scale1d570;
1:600=>scale1d600;1:700=>scale1d700;1:720=>scale1d720;1:800=>scale1d800;1:900=>scale1d900;1:1000=>scale1d1000;1:X=>scale1dX}}}

--Wgkderdicke (talk) 19:54, 4 August 2019 (UTC)

I think that I found the line where the order of the radiobuttons is changed. It's the disambiguateLabels function in the PF_ValuesUtils.php file. The first line (asort( $labels );) changes the order. To test it, I commented this line out. And the radiobuttons are displayed in the order like specified by the values parameter but shows the label text and not the value. --Wgkderdicke (talk) 23:42, 13 August 2019 (UTC)

PF namespaces 106 & 107

To begin with, in principle the PF extension seems to run without any problems here in this wiki. In the LocalSettings.php file of this wiki near the top there are four custom namespaces defined (100-103). In the middle of that file the installation of PF happens. After that, near the end of that file, the access to several namespaces is restricted via $wgNamespaceProtection and the Lockdown extension. Now I additionally want to restrict the access to the form namespace PF_NS_FORM. Therefore I added this line beneath the other restriction:

$wgNamespaceProtection[PF_NS_FORM] = 'editinterface';

I immediately got this warning: Use of undefined constant PF_NS_FORM.

Then I added near the top and beneath the other definitions for "my" custom namespaces but before the PF installation line this here:

define("PF_NS_FORM", 106);
define("PF_NS_FORM_TALK", 107);

Now the warning has disappeared. And the restriction seams to get effectiv.

Is this a bug? --Wgkderdicke (talk) 20:42, 25 July 2019 (UTC)

How are you loading Page Forms - with PageForms.php, or with wfLoadExtension()? Yaron Koren (talk) 18:28, 26 July 2019 (UTC)

It's the wfLoadExtension() method. --Wgkderdicke (talk) 21:06, 26 July 2019 (UTC)

Section tag & VEForAll prevents placeholder from showing

Using a 'section' tag with VEForAll prevents the display of any placeholder text (although it flashes when the form is loaded, then disappears). If you switch to the wikitext editor, the placeholder text returns. --Bryandamon (talk) 08:09, 7 August 2019 (UTC)

Parsing multiple-instance templates

What is the best way to parse data stored in multiple-instance templates? I'm not sure I'm doing everything correctly to start with, but I have a Main Form that contains something like this:

{{{for template|Time}}}

{| class="formtable"
! Project: 
| {{{field|Project}}}
|}

'''Worker Hours:'''
::: {{{field|WorkerHours|holds template}}}

{| class="formtable"
! Date: 
| {{{field|Date}}}
|}
{{{end template}}}

{{{for template|WorkerHours|multiple|embed in field=Time[WorkerHours]}}}
'''Worker:''' {{{field|1}}}
'''Hours:''' {{{field|2}}}
{{{end template}}}

Which calls (I think) this template called WorkerHours:

<noinclude>{{#cargo_declare:_table=WorkerHours|_parentTables=Time|Worker=Page|Hours=Float}}
</noinclude><includeonly>{{#cargo_store:_table=WorkerHours|Worker={{{1|}}}|Hours={{{2|}}} }}
'''Worker:''' {{#if:{{{1|}}}|[[{{{1|}}}]]}}
'''Hours:''' {{{2|}}}
</includeonly>

A page created by the form gives me the following after creating multiple instances of the WorkerHours template in the Time Form

{{Time
|Project=Test
|WorkerHours={{WorkerHours|Adam|1.5}}{{WorkerHours|Becky|3}}{{WorkerHours|Cliff|0.2}}
|Date=2019/08/08
}}

I would like to list all the Worker/Hour values in a side infobox and format it. If possible, I'd like to total the hours from all the workers. The results are reliably placed on the page instances, however the values don't seem to exist in any Cargo tables I have (Time or WorkerHours) and I'm not sure how I can use them. --Bryandamon (talk) 10:21, 8 August 2019 (UTC)

If the template is "WorkerHours", why is the template being called in the page named "Hours"? Yaron Koren (talk) 16:19, 8 August 2019 (UTC)

Sorry, I changed the name of the templates to paste here, but didn't do a good job being consistent. I updated the code above to better capture a simplified version of what I'm doing (the Cargo changed from "Hours" to "WorkerHours" and similar with the instances in the created page). I do have a new field (WorkerHours) in any instance created from my Time Form/Template (it's created in the order the Form calls). The values are correct for the information saved, but I'm not sure how I can "use" them; i.e. place them where I chose in the template, format and arrange the values, or sum the hours. --Bryandamon (talk) 20:58, 8 August 2019 (UTC)

I think I figured out the storage part. What worked was removing my version of an embedded multiple-instance template for a regular one. Now to see if I can understand how to use/display this new data structure. Thanks Yaron! --Bryandamon (talk) 22:54, 8 August 2019 (UTC)

Alright. You should be able to get this working with an embedded multiple-instance template as well - my guess is that what was missing was a call to the "{{{WorkerHours|}}}" field from within the "Time" template, although maybe it was something else. Yaron Koren (talk) 23:16, 8 August 2019 (UTC)

I think I understand what you mean, I actually tried this on a completely different project and it seemed to work. I added the equivalent of the following to the "Time" template:

• WorkerHours=String to #cargo_declare
• WorkerHours={{{WorkerHours|}}} to #cargo_store

Is that what you meant? It adds an empty field to the Time table and properly completes the WorkerHours table, but I'm not sure why that worked? Also, am I right in assuming that, "_parentTables=Time" isn't necessary for what I'm doing, only for Drilldown? --Bryandamon (talk) 07:18, 16 August 2019 (UTC)

Save and Continue doesn' work in forms with mandatory fields

Hi Yaron,

is there a way to solve this issue? Using MW 1.31 and PageForms 4.5

Thanks, Klaus

I don't think I knew about this problem before. Does it fail even when the mandatory field(s) are filled in? Yaron Koren (talk) 23:17, 8 August 2019 (UTC)

No, only when one or more are not filled. --DDSnowl (talk) 10:53, 13 August 2019 (UTC)

Radiobuttons: "Show on select" and default values

Hi Yaron

I created this field here:

<div id="licence">

{{{field|Lizenz_1|input type=radiobutton|class=pfRadioButtonLizenz|mandatory|values={{Form-File-Licence-List}}|default=CC|show on select=Keine Angabe=>nolicence1;Keine Angabe=>nonextlicence2;CC=>cclicence1;CC=>nextlicence2;CC=>ccart;PD=>pdlicence1;PD=>nextlicence2;CR=>crlicence1;CR=>nextlicence2;
GPL=>gpllicence1;GPL=>nextlicence2;LGPL=>lgpllicence1;LGPL=>nextlicence2;GFDL=>gfdllicence1;GFDL=>nextlicence2;CL=>cllicence1;CL=>nextlicence2;
OCAL=>ocallicence1;OCAL=>nextlicence2;CRM=>crmlicence1;CRM=>nextlicence2}}}

{{Form-File-Licence-Info|1}}

<div id="ccart">
...
</div>
</div>

There is a div tag with the id licence and is triggered by a show on select parameter ahead of this code. If a specific value is choosen ahead, this div tag is shown.

The field tag here gives me 10 radiobuttons. The default value is set to CC. Each values is provided with two or three IDs. Some div tags and the content inbetween are provided by the Form-File-Licence-Info template. The div tag with the id ccart is not wrapped in a template.

If the licence div tag pops up with its default value for the first time, the ccart div tag is not shown. If another radio button is choosen and then the CC radiobutton is choosen again, finally the ccart div tag pops up.

Is that a bug? By the way, did you noticed the span tag issue? --Wgkderdicke (talk) 20:26, 10 August 2019 (UTC)

In addition to the above, you can take a look at the full wikitext of the form here: Formular:DateiFlex.

And this is the odd part. The CC value is provided with three IDs: ;CC=>cclicence1;CC=>nextlicence2;CC=>ccart;. If the licence div tag pops up with its default value for the first time, the ccart div tag is not shown, as said before. But the cclicence1 tag and the nextlicence2 is shown. A change of order for this three IDs at the show on select parameter doesn't pay.--Wgkderdicke (talk) 09:55, 11 August 2019 (UTC)

It comes better. I renamed the ccart tag to wgkart. And, of course, the corresponding part in the show on select value. This does the trick. The now called wgkart div tag is also shown, if the licence div tag pops up with its default value for the first time. Does one have to be careful that the first two letters of an ID are not identical? --Wgkderdicke (talk) 18:25, 11 August 2019 (UTC)

Radiobutton: First default value 'none'

Hi, Yaron.

The description regarding the radiobutton input type says:

By default, the first radiobutton value is "None", which lets the user choose a blank value. To prevent "None" from showing up, you must make the field "mandatory", as well as making one of the allowed values the field's "default=" value.

Let's presume this:

{{{for template|Radiobuttons}}}

{{{field|Radiobutton1|mandatory|values=A,B,C|default=A|show on select=A=>everythingsgreat;B=>dosomething;C=>dosomething}}}

<div id="everythingsgreat">
'''Everything is great!'''
</div>

<div id="dosomething>
'''<big>Precisely nothing is great! Do something! Now!!!<big>'''

{{{field|Radiobutton2|mandatory|values=X,Y,Z|default=X}}}
</div>

If I create a page using this form and the radiobutton 1 stays on its default value A, I will get a page with the following template call:

{{Radiobuttons
|Radiobutton1=A
}}

The parameter for the first field Radiobutton1 is available. The parameter for the second field Radiobutton2 does not show up.

If I edit this page using the form and change the value of radiobutton 1 to, for example, B, the second radiobutton input appears. And, so I presume, because of the missing Radiobutton2 parameter, and besides the defined three values, the second radiobutton input is provided also with an extra default value "none" notwithstanding the "mandatory" setting, which should suppress the default value "none".

Imho every mandatory field with a default value should get its parameter in the saved page's template call, no matter if this mandatory field is visible or not. Or every mandatory field which lacks a parameter in a saved page's template call should not be extended by a possibly unwanted extra "none" value (which leads to an extra radiobutton or checkbox, for example) but stick to the defined values and set to the default value. --Wgkderdicke (talk) 21:45, 11 August 2019 (UTC)

I did some research in the PF_RadioButtonInput.php file. This here is line 41 to 37 from this file:

// Add a "None" value at the beginning, unless this is a
// mandatory field and there's a current value in place (either
// through a default value or because we're editing an existing
// page).
if ( !$is_mandatory || $cur_value === '' ) {
	array_unshift( $possible_values, '' );
}

I changed that part in "my" PF_RadioButtonInput.php file to:

// Add a "None" value at the beginning, unless this is a
// mandatory field and there's a current value in place (either
// through a default value or because we're editing an existing
// page).
if ( !$is_mandatory || ( $cur_value === '' && $other_args['default'] === '' ) ) {
	array_unshift( $possible_values, '' );
}

Now no extra "None" value is added, if the field is mandatory and a default value is available.

But another "feature" crops up. In case of a missing parameter in the saved page's template call the $cur_value variable comes with an empty string. If the labels of the field's radiobuttons are not changed by a mapping template, the default value of this field gets effective. But if the labels of the field's radiobuttons are changed by a mapping template, the first value of the $possible_values array gets effective, not the declared default value. Furthermore, it seems that, if the labels of the field's radiobuttons are changed by a mapping template, the $possible_values array holds the mapped labels and not the declared values of the field. After that above-mentioned change I added this to "my" PF_RadioButtonInput.php file:

• This doesn't pay, the field wasn't set to the default value.

$cur_value = $other_args['default'];

• One of the fields values is "-". This is the defaukt value, But this doesn't pay either, the field wasn't set to the default value.

$cur_value = '-';

• The field value "-" is mapped to "Keine Angabe" (german for "not specified"), so that the label shows "Keine Angabe" but the "-" is used in the saved page's template call. Well, this pays! Now the field shows the default value!

$cur_value = 'Keine Angabe';

--Wgkderdicke (talk) 20:54, 12 August 2019 (UTC)

Multiple }} in default value

In relation to the default value - "You can also include templates, parser functions, and magic words within the "default=" value." - I just noticed that if you have multiple }}'s, you need to put spaces between each, otherwise PF thinks the first }}} closes the initial {{{. Jonathan3 (talk) 00:31, 12 August 2019 (UTC)

Using Templates in Form Default values

Hi,

The various help pages seem to indicate that this should be possible but I must be missing something. I have a form field that allows user to select people based on there real name (or Foaf:name), which is a semantic property on their "user page":

{{{field|user|input type=combobox|values from property=Foaf:name|size=18|default=Joe Blogs}}}

This work fine, but I would like to set the default value for this field to the real name of the current user. I can get this value in a few different ways such as:

{{#ask:[[User:{{REVISIONUSER}}]]|?Foaf:name=|mainlabel=-|link=none}}

I have tried to place this inline query directly in the code and also tried to put it in a separate template but neither works:

{{{field|user|input type=combobox|values from property=Foaf:name|size=18|default={{#ask:[[User:{{REVISIONUSER}}]]|?Foaf:name=|mainlabel=-|link=none}} }}}

{{{field|user|input type=combobox|values from property=Foaf:name|size=18|default={{MyName}} }}}

Where {{MyName}} correct outputs the text value of "Foaf:name". Both options correctly creates the dropdown field but have the following warming message as the default value:

<span class="smw-highlighter" data-type="4" data-state="inline" data-title="Warning" title="The page type input value "User:" contains invalid characters or is incomplete and therefore can cause unexpected results during a query or annotation process."><span class="smwtticon warning"></span><span class="smwttcontent">The page type input value "User:" contains invalid characters or is incomplete and therefore can cause unexpected results during a query or annotation process.</span></span>

Should this actually work and if so can anyone say what I have missed? If this should not work can anyone suggest an alternative way to get this type of default value in a field?

Thanks

--Jpadfield (talk) 10:31, 12 August 2019 (UTC)

MediaWiki 1.33.0 Semantic MediaWiki 3.0.2 Page Forms 4.5.1

I wonder if subst: would help - it’s mentioned here: https://stackoverflow.com/questions/12926969/variable-in-mediawiki-for-the-current-user Jonathan3 (talk) 13:41, 12 August 2019 (UTC)

Or maybe REVISIONUSER has no value or a problematic value when displaying a form for a new page (and default= only works on new pages, I think). Just more guesswork as I’ve not used it. Have you tried displaying it within the form? Jonathan3 (talk) 13:51, 12 August 2019 (UTC)

The name is displayed correctly when the inline query or the template is used outside of the form. It was trying to display it in the form that gave me the big "span" error - all as un-parsed text in the combobox on the form. It seemed that the REVISIONUSER value, or template, etc . was being parsed or interpreted differently wen included in the form. I will have look at your other suggestion, thanks --Jpadfield (talk) 15:43, 12 August 2019 (UTC)

Ah it seems that the value for REVISIONUSER is not processed correctly, and in fact it is not really the one I needed. I have solved the problem by using Extension:MyVariables and the new variable {{CURRENTLOGGEDUSER}} and everything seems fine. Thanks --Jpadfield (talk) 16:13, 12 August 2019 (UTC)

Simple upload not working on MW 1.33.0 and PageForms 4.5.1

I'm noticing that simpleupload option is not working on the current builds of PageForms and MediaWiki. I looked through the archives and noticed this had been brought up before but it seemed that no one had reported using the master branch with the latest version of MediaWiki. So just wanted to report that it still doesn't seem to work. Thanks, really appreciate this extension and all the work you've put into it! Mwyman (talk) 15:09, 12 August 2019 (UTC)

did you resolve this? Squeak24 (talk) 16:59, 18 August 2019 (UTC)

I haven't yet. Any suggestions on things to try? Not really sure where to start to try to resolve it. Mwyman (talk) 19 August 2019 (UTC)

Reuse template in page forms without the multiple instance buttons?

Versions: Mediawiki: 1.33.0, SMW: 3.0.2, Page forms: 4.5.1, Header tabs 1.2.

Is it possible to call a template with page-forms multiple times without using the multiple parameter? If I add a form by the «Create Form» special page, and I add a template twice, then fill out the data and submit, only the first template adds the annotations, and the values saved are the last ones. The second template is written with no output.

For instance a dummy form with two sections using the same template: English section: (label=test,altLabel=trial,iso_lang=en) German section: (label=prüfung, iso_lang=de, altLabel=)

Results in

{{MinLangTerm
|label=prüfung
|iso_lang=de
|label=prüfung
|iso_lang=de
}}
{{MinLangTerm}}

Best regards, Øyvind

I don't think so. Yaron Koren (talk) 13:32, 13 August 2019 (UTC)

Checkboxes vs. mapping templates and 'edit with form' mode

Hi.

It's about the checkboxes field. I discovered, that, if more than one value is chosen, the values are saved after the equal sign in the page's template call not only separated by the delimiter character. After every delimiter character there follows a white space character. Happens this by purpose? A tokens field generates no white space after the delimiter, if his value is composed of several individual values. Only the delimiter separates the individual values without any white space characters.

In addition to that, if the checkboxes' lables get their text by a mapping table and if an existing page is edited with the form, the checkboxes in the form are not set to the value which is saved in the page's template call.--Wgkderdicke (talk) 23:14, 14 August 2019 (UTC)

Yes, the spaces are there on purpose. If "tokens" does not add spaces after the commas, that sounds like a bug. And that second one definitely sounds like a bug. Yaron Koren (talk) 15:38, 15 August 2019 (UTC)

autocomplete list by cargo table contains decoded html entities in autocomplete

The reason is this line in includes/CargoSQLQuery.php

$resultsRow[$alias] = htmlspecialchars( $curValue );

While it's necessary to filter user input, I'm not sure that's the best place to do this filtering. This preventing the use of the source data needed in some cases.

Do you have HTML in your autocomplete values? If so, that's not good - Cargo (and Page Forms) are doing the right thing by escaping it, because otherwise it's a security risk. Yaron Koren (talk) 15:40, 15 August 2019 (UTC)

That's decoding also double quetes which I have in page titles. If this will be fixed, it would solve current issue. As side note, well aware of security risks, there are still cases you need to grab none-sanitized content.--Anysite (talk) 10:27, 16 August 2019 (UTC)

Database error when using Edit with Form

I think I bungled a MW/SMW upgrade somewhere and now I'm getting 500 Internal errors when I click Edit with Form. SMW queries etc are behaving normally. This happens with a clean MW and extensions install and a default LocalSettings.php. I suspect I have a mismatch between the Postgres database schema and the SMW/PF version. So this may be an SMW rather than PF question.

MediaWiki 1.33.0, SemanticMediaWiki 3.0.2, Page Forms 4.5.1

Nginx 1.12.2, PHP 7.2.19, Postgresql 9.5.15

This happened a couple of upgrades ago and I've been living in denial and hoping Something Magic would happen when I upgraded and ran the maintenance scripts. So I can't describe exactly which actions have been taken.

Is there any way I can tell from the database schema or contents, which version of SMW/PF it conforms to? That is, could I install a previous version and run the upgrade scripts from there to bring my database up to date?

Thanks, Andrew

[70eda6171c99d8e2ac8b55fc] [no req] Wikimedia\Rdbms\DBTransactionStateError from line 1423 of /var/www/foo.com/mediawiki-1.33.0/includes/libs/rdbms/database/Database.php: Cannot execute query from LCStoreDB::get while transaction status is ERROR.

Backtrace:

#0 /var/www/foo.com/mediawiki-1.33.0/includes/libs/rdbms/database/Database.php(1192): Wikimedia\Rdbms\Database->assertTransactionStatus(string, string)
#1 /var/www/foo.com/mediawiki-1.33.0/includes/libs/rdbms/database/Database.php(1784): Wikimedia\Rdbms\Database->query(string, string)
#2 /var/www/foo.com/mediawiki-1.33.0/includes/libs/rdbms/database/Database.php(1609): Wikimedia\Rdbms\Database->select(string, string, array, string, array, array)
#3 /var/www/foo.com/mediawiki-1.33.0/includes/cache/localisation/LCStoreDB.php(61): Wikimedia\Rdbms\Database->selectField(string, string, array, string)
#4 /var/www/foo.com/mediawiki-1.33.0/includes/cache/localisation/LocalisationCache.php(391): LCStoreDB->get(string, string)
#5 /var/www/foo.com/mediawiki-1.33.0/includes/cache/localisation/LocalisationCache.php(294): LocalisationCache->loadSubitem(string, string, string)
#6 /var/www/foo.com/mediawiki-1.33.0/languages/Language.php(2645): LocalisationCache->getSubitem(string, string, string)
#7 /var/www/foo.com/mediawiki-1.33.0/includes/cache/MessageCache.php(990): Language->getMessage(string)
#8 /var/www/foo.com/mediawiki-1.33.0/includes/cache/MessageCache.php(948): MessageCache->getMessageForLang(Language, string, boolean, array)
#9 /var/www/foo.com/mediawiki-1.33.0/includes/cache/MessageCache.php(890): MessageCache->getMessageFromFallbackChain(Language, string, boolean)
#10 /var/www/foo.com/mediawiki-1.33.0/includes/Message.php(1308): MessageCache->get(string, boolean, Language)
#11 /var/www/foo.com/mediawiki-1.33.0/includes/Message.php(863): Message->fetchMessage()
#12 /var/www/foo.com/mediawiki-1.33.0/includes/Message.php(955): Message->toString(string)
#13 /var/www/foo.com/mediawiki-1.33.0/extensions/PageForms/specials/PF_FormEdit.php(144): Message->text()
#14 /var/www/foo.com/mediawiki-1.33.0/extensions/PageForms/includes/PF_FormEditAction.php(299): PFFormEdit->printForm(string, string)
#15 /var/www/foo.com/mediawiki-1.33.0/extensions/PageForms/includes/PF_FormEditAction.php(32): PFFormEditAction::displayForm(PFFormEditAction, Article)
#16 /var/www/foo.com/mediawiki-1.33.0/includes/MediaWiki.php(499): PFFormEditAction->show()
#17 /var/www/foo.com/mediawiki-1.33.0/includes/MediaWiki.php(294): MediaWiki->performAction(Article, Title)
#18 /var/www/foo.com/mediawiki-1.33.0/includes/MediaWiki.php(865): MediaWiki->performRequest()
#19 /var/www/foo.com/mediawiki-1.33.0/includes/MediaWiki.php(515): MediaWiki->main()
#20 /var/www/foo.com/mediawiki-1.33.0/index.php(42): MediaWiki->run()
#21 {main}

Very strange... it looks like the problem comes when the code tries to get the value of the message 'pf_formedit_edittitle' from the "l10n_cache" table. Does that table look alright in your database? I would try truncating it - calling something like "DELETE * FROM l10n_cache". It shouldn't break anything - that table exists just to improve performance. But don't mess with any of the other tables. :) Yaron Koren (talk) 19:59, 15 August 2019 (UTC)

That table held exactly 15,228 entries. Deleting them resulted in an empty table, but after the next page load there were the exact same number of entries in the table. And 'Edit with Form' gives the same error message as before. --Acrabb (talk) 20:52, 15 August 2019 (UTC)

I don't know then - I've never heard of this kind of problem happening. I would try disabling every extension other than Page Forms, to see if the problem persists - if not, then it's a matter of isolating the extension causing the problems. Yaron Koren (talk) 21:01, 15 August 2019 (UTC)

OK, thanks! I had already tried reinstalling MW with just SMW and PageForms enabled. Anything else I might try, even if it takes some work? I have a fair investment in this database, 100-odd properties and a few thousand property values over the last five years or so. I do recall it started when I did an upgrade, perhaps I skipped a version or didn't run the maintenance script. Acrabb (talk) 21:19, 15 August 2019 (UTC)

What about disabling SMW? Do you know how to temporarily disable an extension? Yaron Koren (talk) 00:28, 16 August 2019 (UTC)

Hadn't thought of that - in my mind Page Forms was inextricably linked with SMW. But disabling SMW (verified, no queries work) has no effect, I get the same error message. The only extension loaded is PF. I also cleared the l10n_cache, same thing. Acrabb (talk) 15:26, 16 August 2019 (UTC)

Adding visual editor references/citations

Hello! I'd like to be able for users to add references/citations using the visual editor interface within Page Forms (via VEForAll). I think this functionality is part of the default mediawiki visual editor interface. Please let me know if this is possible. On second thought, I'm guessing this is a VEForAll issue, so I will ask at that forum as well.

Thanks, Patrick

Special:FormStart + preload

I want to create the link for start the form (FORM_NAME) to create the page PAGE_NAME. This form must content preload data from the page PRELOAD_PAGE. I have done following code: [[Special:FormStart/FORM_NAME/PAGE_NAME?preload=PRELOAD_PAGE]], but it's not work. Reason, it's the sistem transform characters '?' and '=' in URL-characters '%3f' and '%3d'. If I use parser function {{#forminput:form=FORM_NAME|preload=PRELOAD_PAGE}}, all work fine. But I want use the link.

What must I do? Thiazole

I think you would have to do a URL link instead of a wiki link. So, for example: [http://mywiki.org/wiki/Special:FormStart/FORM_NAME/PAGE_NAME?preload=PRELOAD_PAGE Create new]

Metalliqaz (talk) 16:19, 21 August 2019 (UTC)

It's work fine. Thank you. But this trick have one problem. If I will write following code:{{#formlink:form=FORM_NAME_2|...|returnto=[http://mywiki.org/wiki/Special:FormStart/FORM_NAME/PAGE_NAME?preload=PRELOAD_PAGE Create new]}}, the form 'FORM_NAME' will not opened after close the form 'FORM_NAME_2'. The code:{{#formlink:form=FORM_NAME_2|...|returnto=[[Special:FormStart/FORM_NAME/PAGE_NAME?preload=PRELOAD_PAGE Create new]]}} aslo don't work.
How can I solve this problem? Thiazole

How about using the URL link without the square brackets? Or using a redirect page (to avoid having to use the URL, in case returnsto= requires a wiki page name)? Jonathan3 (talk) 01:52, 28 August 2019 (UTC)

Change formlink button color?

Is it possible to change the background color of a formlink button? --Bryandamon (talk) 18:00, 22 August 2019 (UTC)

Sure - one option is wrap in a span with a class name, and then use that class name to change the CSS for it, in MediaWiki:Common.css. Yaron Koren (talk) 18:03, 22 August 2019 (UTC)

That was the plan, but I was playing with it first using span and then a style <span style="background:red;">{{#formlink:...}}</span>, but it didn't seem to work. I'll try using a class name and then Common.css, but I thought that I could use the above method to test? --Bryandamon (talk) 18:14, 22 August 2019 (UTC)

autoedit does not change or remove date from date field

Product	Version
MediaWiki	1.31.1
PHP	7.1.8 (apache2handler)
MySQL	5.6.10
Semantic MediaWiki	2.5.8
Page Forms	4.5.1 (624f2a9) 18:20, 16 January 2018

I have

|query string=InterOp_Lab[End date]=12/19/2024 |reload}}

if the date has been previously set it will not change i tried clearing it first as well.

|query string=InterOp_Lab[End date]=&InterOp_Lab[End date]=12/19/2024 |reload}}

This works for any other field and it works if the date field is empty.

Somehow it now seems to be working as expected, not sure what I did.

Legaulph (talk) 11:39, 28 August 2019 (UTC)

Oh great! That's good, because I had no idea what was causing the problem. Yaron Koren (talk) 00:55, 29 August 2019 (UTC)

OOPS I actually use it for 2 different forms. 1 in the main namespace and one in custom namespace, The autoedit works correctly in the main namespace, in the custom namespace it does not work properly, only if the field is empty does it work. Legaulph (talk) 13:42, 4 September 2019 (UTC)

See the last part of this section. Could that be the issue? I'm surprised the other #autoedit was working at all... Yaron Koren (talk) 19:37, 4 September 2019 (UTC)

No I have that in LocalSettings already. I have a few autoedit fields in the template, and the only thing I have an issue with is if a date is already in the date field it wont change it, it will add it if the field is empty only. Legaulph (talk) 10:13, 5 September 2019 (UTC)

How to auto-categorize the output of a form?

Hi,

I have, for example, a form where there is a user selection: user1, user2, user3... and so on.

I would like to, somehow, that, when the page based on that form is created, a category tag to be attached to that form with the specific user.

The main purpose is to have an accountability of, for example, how many pages a user owns.

Can you help me with this, please?

Thank you very much and regards,

Joan.

You would do this by editing the Template associated with the Form. If the field with user1, user2, etc was called UserName, then at the end of the <includeonly> section, you would add a [[Category:Assigned_to_{{{UserName}}}]] or whatever you call your categories. Metalliqaz (talk) 01:17, 27 August 2019 (UTC)