Extension talk:Page Forms/Archive August to September 2018

#autoedit erases other template values...

Hi there,

Is the #autoedit function supposed to erase all other values in a template if they are not included in the "query string" part of the function? I'm experiencing that on:
MW 1.26.3
SMW 2.5.6 (33df15e) 13:09, 14 February 2018
PF 4.3.1

To be clear: I have the following code:

{{#autoedit:form=Application
	|target={{FULLPAGENAME}}
	|link text=<i class="fas fa-plus fa-fw" style="color: red;"></i>
	|link type=link
	|summary=Added existing file to form.
	|tooltip=Add existing file to form field
	|query string=Application[{{{2}}}]={{urlencode:{{PAGENAME:{{{1}}}}} }}
	|query string=Application[{{{3}}}]=Yes
	|reload
}}

And while those two fields get filled out... the other 156 parameters in that template get wiped. I've tried dealing with it in multiple ways without figuring it out.

Thanks for any info!

There should only be one "query string" parameter - if there are multiple values, they should be separated by "&". That may or may not solve this problem - I'm guessing no. If not, the problem might be somehow due to the very large number of parameters and form fields involved. Do you have any smaller forms that you could try #autoedit on? If so, I would try using one of those. Yaron Koren (talk) 16:56, 5 August 2018 (UTC)

Easy way to populate a values list via Cargo?

I used to use |property= with a property with allowed values, but migrating away from SMW that's not possible anymore. So mostly I just make templates that have lists of values and transclude them to the form for |values=. But today I tried

{{#cargo_query:table=InfoboxChampion
|fields=Name
|delimiter=,
|limit=999
|order by=Name
}}

And transcluding this page as my |values=, which ended up throwing an error instead of working. Did I do something wrong with this query? It output the right result to the page, so I just copy-pasted that & it works now, but still, it would be nice to remove this manual data step. --RheingoldRiver (talk) 05:10, 15 August 2018 (UTC)

I don't know what exactly is causing that error, but it's definitely possible to still have allowed values using Cargo - you just need to set the tag parameters "cargo table=" and "cargo field=", where you would have used "property=" before, to "attach" a form field to a specific Cargo field. Yaron Koren (talk) 15:33, 15 August 2018 (UTC)

Ah, yeah that works, however it's displaying an & as &. Any way to fix? --RheingoldRiver (talk) 04:05, 16 August 2018 (UTC)

I can't replicate that issue. Is this '&' within "allowed values"? What's the input type - a dropdown? And where does the & appear - on the screen, in the wiki page, or both? Yaron Koren (talk) 19:22, 16 August 2018 (UTC)

Here is the form. For the Favorite Champions first dropdown, the entry Nunu & Willump has the wrong & (the remaining fields I am still using a template as the input source instead of the Cargo table, so that's why those aren't also broken). Here is the page that generates the data (table is InfoboxChampion). And it saves it into the page with the amp as well as displaying it. --RheingoldRiver (talk) 10:15, 17 August 2018 (UTC)

I see the problem, but I still can't replicate it. My guess/hope is that it's due to differences in the Cargo and/or Page Forms versions, and that upgrading to the latest version for both will fix the problem, though I don't know of any specific recent changes that would be relevant to this. Yaron Koren (talk) 14:41, 17 August 2018 (UTC)

Ok. For now I'm going to go back to using just "Nunu" instead of "Nunu & Willump" because SMW can't deal with the & either, so hopefully by the time we've resolved the Cargo dupe issue we somehow resolve this too. --RheingoldRiver (talk) 06:59, 18 August 2018 (UTC)

Ah, one other issue actually. This dropdown needs to have 140+ possible options, but it seems it's capping at 100. I don't see any documentation about increasing the number of entries allowed, is that possible? --RheingoldRiver (talk) 07:04, 18 August 2018 (UTC)

That also sounds like a bug. Though, with that many values, "combobox" seems like the better input type to use, since it allows for autocompletion. You can add the parameter "|existing values only" to ensure that users don't type in other values. There's a chance that ampersands will work better with this input type too... Yaron Koren (talk) 02:31, 19 August 2018 (UTC)

Sorry, was just out of town for a couple days. I'd guess it's just using the default limit in queries right now to generate the list, but yeah switching to combobox seems like it might be a good idea for this either way. --RheingoldRiver (talk) 21:06, 23 August 2018 (UTC)

On a random thought decided to try the above query in Lua and invoke that on the populating page, and this solved the problem, in case anyone else is trying to do the same. --RheingoldRiver (talk) 19:20, 9 October 2018 (UTC)

Text input with pipe | and square bracket [ ] symbols

I'm trying to store multiline strings with |, [ and ] symbols (among others) in semantic media-wiki in combination with PageForms.

Note only does PageForms decline to save the page when these strings are in the template, but these multiline strings also mess up template calls and the inline version of semantic media-wiki property value setting with "[[" and "]]". The pipe symbols get in the way of the {{#set: too, unfortunately.

I have been able to add <pre></pre> at the start and end of the string value in the template, but these tags then appear in the Form values (and ideally shouldn't be stored in the property value.

Can anyone help me figure out how to proceed?

Thanks,

- n

Something like #set, at least, should work - I think parser functions (including pipes) within template fields should work fine in both forms and the resulting pages. If it's not working for you, what versions of MediaWiki and Page Forms are you running? Yaron Koren (talk) 19:23, 16 August 2018 (UTC)

I can't create form, with extension Form or with extension PageForm

I tried many ways.

1) Using Extension Form I followed the instructions of examples in https://www.mediawiki.org/wiki/Help:Extension:Form, creating MediaWiki:Test-form and Template:Test. When I go to Special:Form/Test I get bad name error. I tried to create, then, the page Test-form, but it did not work.

2) Second way, using Special:CreateClass

I created a class with name "Event". When I go to page Form:Event, there is a text box and a "Create/Edit" bottom. But when I click on it I get a blank page on Firefox and an error 500 on Google Chrome.

3) Third way, using Special:CreateTemplate and then Special:CreateForm After creating a template, I went to page Special:CreateForm, chose the template and clicked Add and then I got a blank page on Firefox and an error 500 on Google Chrome.

I can't help with the "Form" extension - that's a different extension. But for the blank page and 500 errors, see here for how to display the actual error message on the screen. Yaron Koren (talk) 21:50, 16 August 2018 (UTC)

Account for values specified with special property "Allows value"

My setup:

• MediaWiki 1.27.4 (f68f9cf)
• Semantic MediaWiki 2.5.6 (33df15e)
• Page Forms 4.2 (198bcda)

If I have a property e.g. "Has gender" with the the three values "female", "male", "other" and point to it via a form like e.g. {{{field|Gender|input type=dropdown|values from property=Has gender}}} one is unable to select either of the allowed values. Only after storing the respecitve values to a helper page these selections are offered to the editor, i.e. it behaves like specifing "existing values only". I am pretty sure this worked before and it will be nice if PF would account for "Allows value". If not this would be a feature request. Cheers --[[kgh]] (talk) 14:31, 17 August 2018 (UTC)

That does sound like a bug - Page Forms should be using the set of "allowed values", if those are specified. Do you know if this is still a problem in the latest version? Yaron Koren (talk) 14:46, 17 August 2018 (UTC)

Thanks for the info. Affirmative, this is still an issue (4.3.1 (a3c23fe)): See this form where only "male" is presented since this is the only values stored for this property so far. Cheers --[[kgh]] (talk) 14:53, 17 August 2018 (UTC)

Input type "datepicker" is not working

My setup:

• MediaWiki 1.27.4 (f68f9cf)
• Semantic MediaWiki 2.5.6 (33df15e)
• Page Forms 4.2 (198bcda)

The browser console (Firefox) emits:

TypeError: initFunction is not a function TypeError: "initFunction is not a function"

PageForms_registerInputInit	https://www.example.com/w/load.php?debug=false&lang=de-formal&modules=ext.JSBreadCrumbs%2Cheadertabs%2Cpageforms%7Cext.headertabs.large%7Cext.pageforms.autogrow%2Cbrowser%2Ccheckboxes%2Cdatepicker%2Cdynatree%2Cfancybox%2Cimagepreview%2Cmain%2Crating%2Cselect2%2Csimpleupload%2Csubmit%2Cwikieditor%7Cjquery.checkboxShiftClick%2Ccookie%2CgetAttrs%2ChighlightText%2CmakeCollapsible%2Cmw-jump%2Cplaceholder%2Csuggestions%7Cmediawiki.api%2Ccldr%2Ccookie%2CjqueryMsg%2Clanguage%2CsearchSuggest%2Cuser%7Cmediawiki.api.user%7Cmediawiki.language.data%2Cinit%7Cmediawiki.libs.pluralruleparser%7Cmediawiki.page.ready%7Csite%7Cuser.defaults&skin=vector&version=dea226de3d81:159:20

fire		https://www.example.com/w/load.php?debug=false&lang=de-formal&modules=jquery%2Cmediawiki&only=scripts&skin=vector&version=ItpUfkfi:45:104addhttps://www.example.com/w/load.php?debug=false&lang=de-formal&modules=jquery%2Cmediawiki&only=scripts&skin=vector&version=ItpUfkfi:45:656

ready		https://www.example.com/w/load.php?debug=false&lang=de-formal&modules=jquery%2Cmediawiki&only=scripts&skin=vector&version=ItpUfkfi:49:40

<anonymous>	https://www.example.com/w/load.php?debug=false&lang=de-formal&modules=ext.JSBreadCrumbs%2Cheadertabs%2Cpageforms%7Cext.headertabs.large%7Cext.pageforms.autogrow%2Cbrowser%2Ccheckboxes%2Cdatepicker%2Cdynatree%2Cfancybox%2Cimagepreview%2Cmain%2Crating%2Cselect2%2Csimpleupload%2Csubmit%2Cwikieditor%7Cjquery.checkboxShiftClick%2Ccookie%2CgetAttrs%2ChighlightText%2CmakeCollapsible%2Cmw-jump%2Cplaceholder%2Csuggestions%7Cmediawiki.api%2Ccldr%2Ccookie%2CjqueryMsg%2Clanguage%2CsearchSuggest%2Cuser%7Cmediawiki.api.user%7Cmediawiki.language.data%2Cinit%7Cmediawiki.libs.pluralruleparser%7Cmediawiki.page.ready%7Csite%7Cuser.defaults&skin=vector&version=dea226de3d81:182:296

<anonymous>	https://www.example.com/w/load.php?debug=false&lang=de-formal&modules=ext.JSBreadCrumbs%2Cheadertabs%2Cpageforms%7Cext.headertabs.large%7Cext.pageforms.autogrow%2Cbrowser%2Ccheckboxes%2Cdatepicker%2Cdynatree%2Cfancybox%2Cimagepreview%2Cmain%2Crating%2Cselect2%2Csimpleupload%2Csubmit%2Cwikieditor%7Cjquery.checkboxShiftClick%2Ccookie%2CgetAttrs%2ChighlightText%2CmakeCollapsible%2Cmw-jump%2Cplaceholder%2Csuggestions%7Cmediawiki.api%2Ccldr%2Ccookie%2CjqueryMsg%2Clanguage%2CsearchSuggest%2Cuser%7Cmediawiki.api.user%7Cmediawiki.language.data%2Cinit%7Cmediawiki.libs.pluralruleparser%7Cmediawiki.page.ready%7Csite%7Cuser.defaults&skin=vector&version=dea226de3d81:154:104

runScript	https://www.example.com/w/load.php?debug=false&lang=de-formal&modules=jquery%2Cmediawiki&only=scripts&skin=vector&version=ItpUfkfi:163:74firehttps://www.example.com/w/load.php?debug=false&lang=de-formal&modules=jquery%2Cmediawiki&only=scripts&skin=vector&version=ItpUfkfi:45:104addhttps://www.example.com/w/load.php?debug=false&lang=de-formal&modules=jquery%2Cmediawiki&only=scripts&skin=vector&version=ItpUfkfi:45:656

always		https://www.example.com/w/load.php?debug=false&lang=de-formal&modules=jquery%2Cmediawiki&only=scripts&skin=vector&version=ItpUfkfi:46:865

runScript	https://www.example.com/w/load.php?debug=false&lang=de-formal&modules=jquery%2Cmediawiki&only=scripts&skin=vector&version=ItpUfkfi:162:944

checkCssHandles	https://www.example.com/w/load.php?debug=false&lang=de-formal&modules=jquery%2Cmediawiki&only=scripts&skin=vector&version=ItpUfkfi:163:774

cssHandle	https://www.example.com/w/load.php?debug=false&lang=de-formal&modules=jquery%2Cmediawiki&only=scripts&skin=vector&version=ItpUfkfi:163:904

fire		https://www.example.com/w/load.php?debug=false&lang=de-formal&modules=jquery%2Cmediawiki&only=scripts&skin=vector&version=ItpUfkfi:45:104

fireWith	https://www.example.com/w/load.php?debug=false&lang=de-formal&modules=jquery%2Cmediawiki&only=scripts&skin=vector&version=ItpUfkfi:46:431

fire		https://www.example.com/w/load.php?debug=false&lang=de-formal&modules=jquery%2Cmediawiki&only=scripts&skin=vector&version=ItpUfkfi:46:474

fireCallbacks	https://www.example.com/w/load.php?debug=false&lang=de-formal&modules=jquery%2Cmediawiki&only=scripts&skin=vector&version=ItpUfkfi:157:607

addEmbeddedCSS	https://www.example.com/w/load.php?debug=false&lang=de-formal&modules=jquery%2Cmediawiki&only=scripts&skin=vector&version=ItpUfkfi:158:681

cssBufferTimer	https://www.example.com/w/load.php?debug=false&lang=de-formal&modules=jquery%2Cmediawiki&only=scripts&skin=vector&version=ItpUfkfi:157:832 load.php:178:449

A fix will be great. Cheers --[[kgh]] (talk) 14:39, 17 August 2018 (UTC)

Sorry about that - I just checked in a fix for this bug a few days ago, by coincidence. Yaron Koren (talk) 14:48, 17 August 2018 (UTC)

Great, good to know! I believe that this was a browser inflicted issue since it worked before and suddenly stopped working without me having changed the setup. Cheers --[[kgh]] (talk) 14:54, 17 August 2018 (UTC)

Right, it only showed up some of the time, depending on the order in which JS files were loaded, which made it hard to debug. Yaron Koren (talk) 14:58, 17 August 2018 (UTC)

How to redirect red links to action=formedit for all categories (PF 4.3.1)?

Hej hej,

I followed Extension:Page_Forms/The_"edit_with_form"_tab#Based_on_category and created [[Project:Category]] with {{#default_form: Category properties}} (using Page Forms 4.3.1) but red links to categories always point to action=edit instead of action=formedit. What can I configure to get action=formedit for all categories? --Andreas P. 11:22, 20 August 2018 (UTC)

I was a little confused about this, but then I understood - you're talking about linking to category pages. What you're doing seems like it should work, so this sounds like a bug in Page Forms; I'll have to look into it. Yaron Koren (talk) 03:55, 22 August 2018 (UTC)

Yes, linking to category pages that do not yet exist. When I was using the old Semantic Forms, this approach worked fine (to set the default form on the page Project:Category) but now I don’t get it done the same way. --Andreas P. 18:44, 22 August 2018 (UTC)

Okay, I just tried this for myself, and actually it's working fine for me. What version of MediaWiki are you running? Yaron Koren (talk) 19:03, 22 August 2018 (UTC)

Version MW 1.31 and 1.30 and both are set to Wiki contentlanguage German.
Are there any configuration variables that I might have missed? --Andreas P. 19:12, 24 August 2018 (UTC)

The fact that it's in German might be the issue... try putting that #default_form call in the page Project:Kategorie. Yaron Koren (talk) 01:45, 26 August 2018 (UTC)

It is already on the Project:Kategorie, e.g. https://wiki.opensourceecology.de/OSE:Kategorie?uselang=en. I cannot use Project strictly or directly, it always redirects to the LocalSettings.php-defined project name of OSE, which is expected, I think. --Andreas P. 11:11, 26 August 2018 (UTC)

Try it on Project:Category, then. Yaron Koren (talk) 15:14, 27 August 2018 (UTC)

Project:Category has no effect --Andreas P. 22:50, 29 August 2018 (UTC)

Special:MyPage redirect in URL

Could a url like https://lol.gamepedia.com/Special:FormEdit/Infobox_Player/Special:MyPage/PlayerName get redirected? (Or an alterantive URL to use that redirects accordingly) This isn't actually something I need currently, I can use MyVariables for every use that I need of this, but it seemed like something that might be useful if linking someone to a creation URL externally from the wiki. --RheingoldRiver (talk) 21:15, 23 August 2018 (UTC)

That's an interesting idea. I assume you could do the same thing in #forminput using a combination of "super_page=" and {{CURRENTUSER}} (assuming the MyVariables extension was installed). Yaron Koren (talk) 22:20, 23 August 2018 (UTC)

Yeah, that was the plan for now. We're going to be allowing users to enter some information about their setup in a game, and we want them to be able to name their builds XYZ and have that build be saved at Special:MyPage/XYZ. So for internal links that works exactly as needed, but if we wanted to be able to link externally (say from a Discord bot), afaik there is no real way to do it. --RheingoldRiver (talk) 05:25, 24 August 2018 (UTC)

About_"formredlink"_parser_function

This is still happening in latest master of Page Forms on MediaWiki 1.27.4 and it is an extremely painful issue. Basically it makes this parser function unusable. That's pretty sad since I would like to use it on many wikis. Basically what I would like to do is to add just the template like e.g. {{TemplateName}} and nothing else, i.e. no content from the originating page (= page holding the red link to the page that should be created automatically by adding the template). --[[kgh]] (talk) 10:07, 26 August 2018 (UTC)

I may note that this even happens if the template to be inserted only holds text, i.e. no fields at all to be filled or no other thrills one might think of then using Page Forms etc. --[[kgh]] (talk) 10:17, 26 August 2018 (UTC)

I am in tears since wikis are loosing so much without this functionality. --[[kgh]] (talk) 10:51, 26 August 2018 (UTC)

The second issue connected to this is that the autocreation takes place serval times (the maximum I observed so far is seven consecutive edits on the page newly created. I think that this parser functions creates a job at every access of a page with the red link. If e.g. the job queue is only cleard every ten minutes there is a chance that many page creation jobs are created during this time instead of just one. Perhaps it is alternatively easier to check if the page exists in the meantime and back off doing further edits. In any case this description makes sense as a possible cause. Cheers --[[kgh]] (talk) 11:41, 26 August 2018 (UTC)

Just to be clear - you can't use #formredlink at all, or you can't use it with the "create page" parameter? Yaron Koren (talk) 11:57, 26 August 2018 (UTC)

This is about the "create page" parameter. Acutally so far I did not use this parser function without it anywhere. Trying to switch this to manual page creation will be the next thing to try. --[[kgh]] (talk) 12:02, 26 August 2018 (UTC)

Just switched to manual creation of pages and there it works, i.e. the content of the page holding the red link is not added. Thus I can confirm that it is only the "create page" parameter which is broken. --[[kgh]] (talk) 16:06, 28 August 2018 (UTC)

Problem with Page Forms: text with autocomplete => values from namespace=category

Dear all, I'm facing a problem with the autocomplete function of a Page Forms text field which should be filled with available category names. This worked perfectly well until I updated my Mediawiki + Extensions to the latest versions some weeks ago.

The problem that I have is that if I start to enter letters into the text field, the list with available category names opens as normal - but it is not limiting the content according to the letters I've typed in. The category names in the list that match to my entered letters show up with bold characters as they should, but the list is not reduced to the entries with matches.

My definition of the text field is as follows:

 
{{{for template|HVG_Kategorie|multiple|label=Kategorien definieren|add button text=Weitere Kategorie definieren}}}
{{{field|Kat|input type=text with autocomplete|default=Archivalien|values from namespace=Kategorie|mandatory}}}
{{{end template}}}  

My version information:

MediaWiki 1.31.0

PHP 7.1.19-nmm1 (apache2handler)

MySQL 5.7.21-nmm1-log

ICU 55.1

Semantic Compound Queries: 1.1.0

Semantic MediaWiki: 2.5.7

Semantic Result Formats: 2.5.5

Does anybody have an idea what the problem could be? Many thanks!

Regards, Tom

How to transform "create page" to the "formredlink" parser function into an manual process?

Since "create page" to the "formredlink" paser function is broken I would like to make this a manual process. My idea for an expected result is that the user clicks on the red link and {{TemplateName}} gets added to the target page. After that the user clicks "Save page" and this is it. Avoiding this extra "Save page" click will be a bonus. I figured just removing "create page" from the functions call like e.g. {{#formredlink:target=TargetPage |form=TemplateName }} might be all needed to do the trick but it does not. I just get directed to the empty target page without {{TemplateName}}. Adding {{#formredlink:target=TargetPage |form=TemplateName |query string=preload=PageHoldingTemplateName}} does not help either. I also tried {{#forminput:target=TargetPage |form=TemplateName |query string=preload=PageHoldingTemplateName }} or the "formlink" parser function respectively but this does not work either. To cut it short, from reading the docu I do not know how to do it. I am sorry for appearing helpless here but I just do not get it. Help will be appreciated. Cheers --[[kgh]] (talk) 14:16, 28 August 2018 (UTC)

Ok. I made a mistake. Senior moments I believe. I seem to have made it work for now. Adding {{#formredlink:target=TargetPage |form=TemplateName }} does indeed do the trick. The form page still looks berserk but at least just {{TemplateName}} gets added. Progress, I guess. --[[kgh]] (talk) 14:34, 28 August 2018 (UTC)

Ok, paradise partially regained. It makes sense to add {{{standard input|save}}} after the {{{end template}}} tag and some explanatory text prior to {{{for template|TemplateName}}} tag to make this user friendlier. To regain paradise in full it will be nice to get the "create page" option working again, but this is apparently another story. --[[kgh]] (talk) 14:46, 28 August 2018 (UTC)

show on select and default values

I have a dropdown field with a default value that's mandatory, but is only available via a show on select. It's totally fine for this field to be empty if the checkbox to show it is unchecked, but when it then is checked, the default value isn't applied. (Looks like this.) Is this intended behavior or a bug?

Similarly, when adding a new field of type dropdown with a default value to a form, and then going to edit the page, the default values aren't applied. But when creating a new page with the new version of the form, they are. This seemed weird but not a big enough problem to report since I can just fill everything myself with AWB as needed.

(Actually I don't care about the field being mandatory or not, I just want the default value to apply.) Thanks --RheingoldRiver (talk) 02:24, 30 August 2018 (UTC)

Is the checkbox you're talking about the "Need more fields?" checkbox? Not to dodge the question, but it seems to me that this would be much easier to implement (and look better on the screen) via a multiple-instance template, if you know what those are. You could even use "display=spreadsheet" to have a spreadsheet-style input of the data, which would look not totally different from what you have now. But to answer your question, that does look like a bug - though I'm not exactly clear on how this whole thing is implemented. Yaron Koren (talk) 21:48, 30 August 2018 (UTC)

Yeah, the need more fields checkbox. I had thought the multiple-instance template was for having separate templates within a page instead of extra arguments for the same template (the template loops over N while teamN is defined by the user). If that interface can be used for this I would definitely switch though --RheingoldRiver (talk) 21:59, 30 August 2018 (UTC)

Right, it involves a separate template, so you would have to remove the fields called "teamN", etc. It's potentially a good amount of work, but I think it will make data entry, storage and querying easier. On that note - are you actually storing these "teamN" values in Cargo? If so, you can't store an unlimited number of them - as you could with a multiple-instance template. Yaron Koren (talk) 23:48, 30 August 2018 (UTC)

No, I'm not, they're just for display on the page. I'm going to rewrite the infobox in Lua probably next month so maybe I could redo what inputs are stored how when I do that, in order to take advantage of a nicer interface in PF, but not sure if it'll be worth it to have to have everything separated like that in the module calls. Storing with Cargo wouldn't be an issue either way though, it's already a while loop in MW and will be a for loop in Lua, so I can have a store at each step if I were to put it in a table. --RheingoldRiver (talk) 01:46, 31 August 2018 (UTC)

Well, you can't have an arbitrary number of fields in a Cargo table - you would have to cap the allowed number of teams (or whatever it is) at some number. Also creating queries for it would be difficult, I would think - wouldn't you have to separately query each field? Yaron Koren (talk) 13:17, 2 September 2018 (UTC)

Input type "datepicker" is not working

Setup

• MediaWiki 1.27.4 (5f5e2a5)
• PHP 7.0.30-0+deb9u1 (apache2handler)
• Page Forms 4.4-rc1 (c35e352)

Issue

The datepicker does not show up.

Exception in module-execute in module ext.pageforms.main: load.php:178:411

TypeError: initFunction is not a function TypeError: "initFunction is not a function"

PageForms_registerInputInithttp://www.example.org/w/load.php?debug=false&lang=en&modules=ext.JSBreadCrumbs%2Cheadertabs%2Cpageforms%7Cext.headertabs.large%7Cext.pageforms.autogrow%2Cbrowser%2Ccheckboxes%2Cdatepicker%2Cdynatree%2Cimagepreview%2Cmain%2Crating%2Cselect2%2Csimpleupload%2Csubmit%2Cwikieditor%7Cext.pageforms.fancybox.jquery1%7Cext.scite.tooltip%7Cjquery.async%2CbyteLength%2CcheckboxShiftClick%2Ccookie%2CgetAttrs%2ChighlightText%2CmakeCollapsible%2Cmw-jump%2Cplaceholder%2Csuggestions%2CtextSelection%7Cmediawiki.ForeignApi%2CForeignStructuredUpload%2CForeignUpload%2CTitle%2CUpload%2Capi%2Ccldr%2Ccookie%2CjqueryMsg%2Clanguage%2CsearchSuggest%2Ctemplate%2Ctoc%2Cuser%7Cmediawiki.ForeignApi.core%7Cmediawiki.ForeignStructuredUpload.BookletLayout%2Cconfig%7Cmediawiki.Upload.BookletLayout%2CDialog%7Cmediawiki.api.edit%2Cmessages%2Cparse%2Cupload%2Cuser%2Cwatch%7Cmediawiki.language.data%2Cinit%2CspecialCharacters%7Cmediawiki.libs.jpegmeta%2Cpluralruleparser%7Cmediawiki.page.ready%7Cmediawiki.page.watch.ajax%7Cmediawiki.widgets.CategorySelector%2CDateInputWidget%2CStashedFileWidget%7Cmoment%2Coojs%2Coojs-ui-core%2Coojs-ui-widgets%2Coojs-ui-windows%2Csite%7Conoi.blobstore%2ClocalForage%2Cmd5%2Cutil%7Coojs-ui-core.styles%7Coojs-ui.styles.icons%2Cicons-content%2Cicons-editing-advanced%2Cindicators%2Ctextures%7Cuser.defaults&skin=vector&version=147e4d416cfa:76:20firehttp://www.example.org/w/load.php?debug=false&lang=en&modules=jquery%2Cmediawiki&only=scripts&skin=vector&version=XZqe3xgv:45:104addhttp://www.example.org/w/load.php?debug=false&lang=en&modules=jquery%2Cmediawiki&only=scripts&skin=vector&version=XZqe3xgv:45:656readyhttp://www.example.org/w/load.php?debug=false&lang=en&modules=jquery%2Cmediawiki&only=scripts&skin=vector&version=XZqe3xgv:49:40<anonymous>http://www.example.org/w/load.php?debug=false&lang=en&modules=ext.JSBreadCrumbs%2Cheadertabs%2Cpageforms%7Cext.headertabs.large%7Cext.pageforms.autogrow%2Cbrowser%2Ccheckboxes%2Cdatepicker%2Cdynatree%2Cimagepreview%2Cmain%2Crating%2Cselect2%2Csimpleupload%2Csubmit%2Cwikieditor%7Cext.pageforms.fancybox.jquery1%7Cext.scite.tooltip%7Cjquery.async%2CbyteLength%2CcheckboxShiftClick%2Ccookie%2CgetAttrs%2ChighlightText%2CmakeCollapsible%2Cmw-jump%2Cplaceholder%2Csuggestions%2CtextSelection%7Cmediawiki.ForeignApi%2CForeignStructuredUpload%2CForeignUpload%2CTitle%2CUpload%2Capi%2Ccldr%2Ccookie%2CjqueryMsg%2Clanguage%2CsearchSuggest%2Ctemplate%2Ctoc%2Cuser%7Cmediawiki.ForeignApi.core%7Cmediawiki.ForeignStructuredUpload.BookletLayout%2Cconfig%7Cmediawiki.Upload.BookletLayout%2CDialog%7Cmediawiki.api.edit%2Cmessages%2Cparse%2Cupload%2Cuser%2Cwatch%7Cmediawiki.language.data%2Cinit%2CspecialCharacters%7Cmediawiki.libs.jpegmeta%2Cpluralruleparser%7Cmediawiki.page.ready%7Cmediawiki.page.watch.ajax%7Cmediawiki.widgets.CategorySelector%2CDateInputWidget%2CStashedFileWidget%7Cmoment%2Coojs%2Coojs-ui-core%2Coojs-ui-widgets%2Coojs-ui-windows%2Csite%7Conoi.blobstore%2ClocalForage%2Cmd5%2Cutil%7Coojs-ui-core.styles%7Coojs-ui.styles.icons%2Cicons-content%2Cicons-editing-advanced%2Cindicators%2Ctextures%7Cuser.defaults&skin=vector&version=147e4d416cfa:100:988<anonymous>http://www.example.org/w/load.php?debug=false&lang=en&modules=ext.JSBreadCrumbs%2Cheadertabs%2Cpageforms%7Cext.headertabs.large%7Cext.pageforms.autogrow%2Cbrowser%2Ccheckboxes%2Cdatepicker%2Cdynatree%2Cimagepreview%2Cmain%2Crating%2Cselect2%2Csimpleupload%2Csubmit%2Cwikieditor%7Cext.pageforms.fancybox.jquery1%7Cext.scite.tooltip%7Cjquery.async%2CbyteLength%2CcheckboxShiftClick%2Ccookie%2CgetAttrs%2ChighlightText%2CmakeCollapsible%2Cmw-jump%2Cplaceholder%2Csuggestions%2CtextSelection%7Cmediawiki.ForeignApi%2CForeignStructuredUpload%2CForeignUpload%2CTitle%2CUpload%2Capi%2Ccldr%2Ccookie%2CjqueryMsg%2Clanguage%2CsearchSuggest%2Ctemplate%2Ctoc%2Cuser%7Cmediawiki.ForeignApi.core%7Cmediawiki.ForeignStructuredUpload.BookletLayout%2Cconfig%7Cmediawiki.Upload.BookletLayout%2CDialog%7Cmediawiki.api.edit%2Cmessages%2Cparse%2Cupload%2Cuser%2Cwatch%7Cmediawiki.language.data%2Cinit%2CspecialCharacters%7Cmediawiki.libs.jpegmeta%2Cpluralruleparser%7Cmediawiki.page.ready%7Cmediawiki.page.watch.ajax%7Cmediawiki.widgets.CategorySelector%2CDateInputWidget%2CStashedFileWidget%7Cmoment%2Coojs%2Coojs-ui-core%2Coojs-ui-widgets%2Coojs-ui-windows%2Csite%7Conoi.blobstore%2ClocalForage%2Cmd5%2Cutil%7Coojs-ui-core.styles%7Coojs-ui.styles.icons%2Cicons-content%2Cicons-editing-advanced%2Cindicators%2Ctextures%7Cuser.defaults&skin=vector&version=147e4d416cfa:71:104runScripthttp://www.example.org/w/load.php?debug=false&lang=en&modules=jquery%2Cmediawiki&only=scripts&skin=vector&version=XZqe3xgv:163:74firehttp://www.example.org/w/load.php?debug=false&lang=en&modules=jquery%2Cmediawiki&only=scripts&skin=vector&version=XZqe3xgv:45:104addhttp://www.example.org/w/load.php?debug=false&lang=en&modules=jquery%2Cmediawiki&only=scripts&skin=vector&version=XZqe3xgv:45:656alwayshttp://www.example.org/w/load.php?debug=false&lang=en&modules=jquery%2Cmediawiki&only=scripts&skin=vector&version=XZqe3xgv:46:865runScripthttp://www.example.org/w/load.php?debug=false&lang=en&modules=jquery%2Cmediawiki&only=scripts&skin=vector&version=XZqe3xgv:162:944checkCssHandleshttp://www.example.org/w/load.php?debug=false&lang=en&modules=jquery%2Cmediawiki&only=scripts&skin=vector&version=XZqe3xgv:163:774cssHandlehttp://www.example.org/w/load.php?debug=false&lang=en&modules=jquery%2Cmediawiki&only=scripts&skin=vector&version=XZqe3xgv:163:904firehttp://www.example.org/w/load.php?debug=false&lang=en&modules=jquery%2Cmediawiki&only=scripts&skin=vector&version=XZqe3xgv:45:104fireWithhttp://www.example.org/w/load.php?debug=false&lang=en&modules=jquery%2Cmediawiki&only=scripts&skin=vector&version=XZqe3xgv:46:431firehttp://www.example.org/w/load.php?debug=false&lang=en&modules=jquery%2Cmediawiki&only=scripts&skin=vector&version=XZqe3xgv:46:474fireCallbackshttp://www.example.org/w/load.php?debug=false&lang=en&modules=jquery%2Cmediawiki&only=scripts&skin=vector&version=XZqe3xgv:157:607addEmbeddedCSShttp://www.example.org/w/load.php?debug=false&lang=en&modules=jquery%2Cmediawiki&only=scripts&skin=vector&version=XZqe3xgv:158:681cssBufferTimerhttp://www.example.org/w/load.php?debug=false&lang=en&modules=jquery%2Cmediawiki&only=scripts&skin=vector&version=XZqe3xgv:157:832 load.php:178:449

Cheers --[[kgh]] (talk) 21:12, 5 September 2018 (UTC)

Could you add "debug=true" to the URL, and let me know what the error message is? Yaron Koren (talk) 23:37, 5 September 2018 (UTC)

Having the same problem here. MediaWiki 1.27.4, PHP 7.0.32, PF 4.4.1. Strange thing is that if I add .../Spezial:Mit_Formular_bearbeiten/Seminar/asdfasdfasdfa?debug=true then the datepicker works, also the wikieditor works. If i remove "?debug=true", both datepicker and wikieditor don't work. --Krabina (talk) 15:39, 16 October 2018 (UTC)

Using default=now in date field for auto-generating the page name only works if field is not hidden

I was trying to auto-generate the pagename using the value of one field plus the date at the time of the page save. Since the info tag didn't like use of magic words, I tried to set today's date using a hidden field of type date with "default=now". It still didn't work. Once I made the field not hidden, it worked. I figured I'd pass this along and suggest some kind of note be added to the documentation. I was going to add the note myself, but I wasn't sure if I was capturing the full constraint details right. --Darenwelsh (talk) 21:28, 10 September 2018 (UTC)

Fixing namespace conflict. How to ?

I had this problem for years. I got namespace ID 106 107 already used (a few dozen pages). Page Forms uses namespaces 106 and 107 and that cannot be changed. I tried several solutions:

(1) Redefining the Page Forms namespace constants in LocalSettings.php :

define ('PF_NS_FORM', 114);
define ('PF_NS_FORM_TALK', 115);
wfLoadExtension( 'PageForms' )

creates PHP warnings, that is understandable. Constant PF_NS_FORM already defined in /data/portails/mediawiki/includes/registration/ExtensionRegistry.php on line 338

(2) I could make changes to the page forms source code and did so in the past, but that is tedious.

(3) Any suggestion what I could do ? That could include instructions on how to move the ID of my conflicting existing name spaced pages to new IDs. I tried namespaceDupes like this:

php namespaceDupes.php  --fix --source-pseudo-namespace=COAP --dest-namespace=6606
checking prefix "COAP" vs namespace 6606
Looks good!

... but it does nothing.

If have seen this, but that answer is incomplete and looks scary.

https://stackoverflow.com/questions/30668048/mediawiki-custom-namespaces-id-change

Is there a way to simply migrate pages to a new namespace ?

- greetings and thanx ! Daniel

PS: Our wiki existed long before semantic mediawiki and also before the MediaWiki community agreed on reserved namespaces.

Probably the easiest solution is to change your custom namespaces at 106 and 107 to use some other, unused pair of IDs. Then, if you have direct access to your database (and know SQL), you should just go into the database and call stuff like "UPDATE page SET page_namespace = 400 WHERE page_title = 'ABCDE' " - that sort of thing, a few dozen times. There might be easier ways to do the updating, but I don't know the current state of your database. Yaron Koren (talk) 02:40, 17 September 2018 (UTC)

Thanx, yes that certainly is a solution, but I am a bit afraid to miss another field with namespace numbers somewhere. For now, I just disabled PHP warnings ;). - Daniel K. Schneider (talk) 12:07, 2 October 2018 (UTC)

Selecting the value from one property and saving the value from another property?

Is it possible to do this?: I have pages for people on my wiki PID00001, PID00002, etc. and would like users to select the name of the person in the form e.g. John Doe and at the same time save the persons PID on the page instead. Thanks for the info. --91.64.57.11 22:20, 17 September 2018 (UTC)

You may be able to do that with one of the "mapping" parameters - see here. Yaron Koren (talk) 23:14, 17 September 2018 (UTC)

Thank you for the information. If it works it will be nice. I can't get it to work though. Basically I can't figure out what is mapping to where. How the “mapping template” should work I do not understand at all. I am only guessing but my interpretation is not making sense at all to me: {{{field|Person|input type=tokens|mapping template=Mapping|values from property=Has ID person|size=20}}} with “Mapping” only containing {{{1|}}}. What I get is a field with not option to select a person's name. Doing {{{field|Person|input type=tokens|mapping template=Mapping|values from property=Has name person|size=20}}} is not working either. Hopefully I am just misusing the parameter. Using “mapping property” also does not work: {{{field|Person|input type=tokens|mapping property=Has name person|values from property=Has ID person|size=20}}} or {{{field|Person|input type=tokens|mapping property=Has ID person|values from property=Has name person|size=20}}} or {{{field|Person|input type=tokens|mapping property=Has name person|size=20}}} or {{{field|Person|input type=tokens|mapping property=Has ID person|size=20}}} What I would like is that a user picks some name of a person with autocompletion from property “Has person name” and on the page {{MyTemplate|Person=PID00001}}} gets added. The display title is “John Doe (PID00001)” and the page name is “PID00001” but this should not matter since always the page name should be saved. Is there an live example? --91.64.57.11 07:09, 18 September 2018 (UTC)

Do you have properties named "Has name person" and "Has ID person" on each person page? If so, what is "Has ID person" set to - just the page name? Yaron Koren (talk) 13:21, 18 September 2018 (UTC)

Yes, with "Has name person" as page and "Has ID person" as text and it is just the page name not the page title. By looking at it mapping property is probably the one taking in the values and values from property is supposed to be shown to the user. Not sure about this. --91.64.57.11 13:41, 19 September 2018 (UTC)

Alright. Is there a category for all the person pages, like "Category:People"? If so, the following might work: {{{field|Person|input type=tokens|values from category=People|mapping property=Has name person}}} Yaron Koren (talk) 00:55, 20 September 2018 (UTC)

Thanks for the suggestion which I would never have come up with by reading the docu. However it still does not work. :( Is there any live example? --91.64.57.11 21:13, 26 September 2018 (UTC)

I can't think of any public examples for the mapping stuff. What happens when you try it? And what happens if you try it without the "mapping property=" setting? Yaron Koren (talk) 02:28, 27 September 2018 (UTC)

Red links in main namespace no longer load with formedit

Hi Yaron,
I use {{#default_form:Artikel}} on a page Secret Wiki:Startseite as discussed here. I'm pretty sure that red links used to open with the form "Artikel". But since I updated both MediaWiki (to 1.27.4) and SemanticForms to PageForms (4.2.) they are no longer opened with formedit but with edit. This page says that there is no extra work needed. So is this feature maybe broken?
Stefahn (talk) 21:04, 19 September 2018 (UTC)

I don't know... these may be dumb questions, but: have you resaved that page recently? And is that page the same one you get to by going to "Project:Startseite"? And is your wiki in German? Yaron Koren (talk) 04:02, 20 September 2018 (UTC)

I moved that page yesterday since I first was not sure where should it be located. Yes, https://secret-wiki.de/wiki/Project:Startseite redirects to https://secret-wiki.de/wiki/Secret_Wiki:Startseite. And yes, it's in German. Stefahn (talk) 13:43, 20 September 2018 (UTC)

Ah - I didn't realize "Secret Wiki" was actually the name of the wiki, not just a code name. :) Could you try actually re-saving that page, not just moving it? It looks like it hasn't been modified in a year. Yaron Koren (talk) 16:39, 20 September 2018 (UTC)

Yes, it's the name of the wiki. I resaved the page but this didn't change things. On some of my other wiki, that still run SemanticForms 3.6 (and MW 1.27.4), this works fine. Stefahn (talk) 13:00, 24 September 2018 (UTC)

It seems to work now, at least somewhat: https://secret-wiki.de/wiki/SomePage?action=formedit Yaron Koren (talk) 15:44, 24 September 2018 (UTC)

But clicking red links still does not work: https://secret-wiki.de/wiki/Spezial:Gew%C3%BCnschte_Seiten - whereas on https://marketingunited.org/wiki/Spezial:Gew%c3%bcnschte_Seiten (running with SemanticForms 3.6) it works fine. Thanks for your support! Stefahn (talk) 16:15, 25 September 2018 (UTC)

I don't know. My current theory is that this is related to the MediaWiki version being used - 1.27. Are you loading Page Forms in LocalSettings.php via wfLoadExtension()? If so, could you try loading it the old way, via require_once() or include_once()? My hunch is that that's indirectly causing the issue. Yaron Koren (talk) 17:55, 25 September 2018 (UTC)

Just for the record: I tried require_once() instead of wfLoadExtension(), but that didn't help. Also updating to PageForms 4.3.1 and MediaWiki 1.27.5 didn't help. I will check if the issue disappears when I update to MediaWiki 1.31.1. Stefahn (talk) 16:19, 27 September 2018 (UTC)

Okay - never mind, then. If you can give me command-line access to the server, I would be willing to log in and try to debug the issue there - if this is a bug in Page Forms, I'd like to be able to fix it, of course. Yaron Koren (talk) 21:39, 27 September 2018 (UTC)

Just for the record: Talked to my hoster about creating a second SSH account, but unfortunately that's not possible. I will update to MediaWiki 1.31 and tell you if the problem is fixed then. Thanks for all your replies and the great support as usual! Stefahn (talk) 15:21, 9 October 2018 (UTC)

Error message "undefined" when closing popups.

Hi,

I'm using #forminput with the parameter "popup" to create/edit pages without leaving the parent page. Everything works as expected but when I click "Save page", the page gets saved but a small window with the error message "undefined" stays open and must be closed manually.

I've already had a look at the Firefox console but didn't see any JavaScript error. Any pointers welcome.

Best regards, Frank

--Nakohdo (talk) 10:32, 21 September 2018 (UTC)

MediaWiki 1.27.4 | PHP 5.6.25 | BlueSpice 2.27.3 | Page Forms 3.6

You're using a rather old version of Page Forms - I'd suggest upgrading. Yaron Koren (talk) 13:31, 21 September 2018 (UTC)

How to avoid page forms auto insert todays date?

Hi Yaron,

When a date field that uses datepicker is not filled out, the system automaticaly prints todays date, but I want the date field to be empty if no dates is entered.

Do you have a solution?

Pretor~nowiki (talk) 21:59, 26 September 2018 (UTC)

Do you have "default=now" in that field's tag in the form definition? If so, you should remove it. Yaron Koren (talk) 02:27, 27 September 2018 (UTC)

Thank you for your quick response!

I did not know about the "default-now". Since i later found out that the imported data in this specific field also includes several comma separated dates, and even text, I had to drop the idea about using "datepicker"/"date". Now I use "List (,) of String" and that seems to be a working solution for both the template/form and browsing (drill-down).

BTW: The opt-in to get notified about updates to my question, did not notify me. (I have selected to get notified for "Talk page message", "Structured Discussion" and other options, cross-wiki.) Pretor~nowiki (talk) 11:00, 28 September 2018 (UTC)

How to create a table of data called in templates/forms?

Hi Yaron,

I have a template and form with a field to input the corresponding government department name. The name of the departments are mostly constant, but sometimes after an election the new government likes to give departments new names and/or split them into more departments. I would like to update the department names from one place and have created a new template that will serve the main template with updated department names.

This is what I have done so far:

Create Template:Departments:

<noinclude>
This is the template for «Departments». It should be called with the following structure:
<pre>
{{Departments
|1=
|2=
|3=
}}
</pre>
Edit the page to see the template text.
{{#cargo_declare:_table=Department|1=Wikitext|2=Wikitext|3=Wikitext}}
</noinclude><includeonly>{{#cargo_store:_table=Department|1={{{1|}}}|2={{{2|}}}|3={{{3|}}} }}{| class="wikitable"
! Department of Agriculture
| [[{{{1|}}}]]
|-
! Department of Commerce
| [[{{{2|}}}]]
|-
! Department of Health-,  Care and Human Services (HHS)
| [[{{{3|}}}]]
|}
</includeonly>

After creating Template:Departments I used ?action=recreatedata in the template URL to create the tables.

I have not created a form for Template:Departments.

In the end I would like Form:Maintemplate to have a dropdown with the department names called from Template:Departments.

Template:Maintemplate look like this:

<noinclude>
This is the template for «Maintemplate». It should be called with the following structure:
<pre>
{{Maintemplate
|Name=
|Date=
|Department=
}}
</pre>
Edit the page to see the template text.
{{#cargo_declare:_table=maintemplate|Name=String (hidden)|Date=Date|Department=String}}
</noinclude><includeonly>{{#cargo_store:_table=Maintemplate|Name={{{Name|}}}|Date={{{Date|}}}|Department={{{Department|}}} }}{| class="wikitable" style="width: 100%;"
! style="width: 120px; text-align: left;" | Name:
| {{{Name|}}}
|-
! style="width: 120px; text-align: left;" | Date:
| {{#time: d-m-Y |{{{Date|}}}}}
|-
! style="width: 120px; text-align: left;" | Department:
| {{{Department|}}}
|}
</includeonly>

Form:Maintemplate look like this:

<noinclude>
This is the 'Maintemplate' form.
{{#forminput:form=Maintemplate}}

</noinclude><includeonly>
<div id="wikiPreview" style="display: none; padding-bottom: 25px; margin-bottom: 25px; border-bottom: 1px solid #AAAAAA;"></div>
{{{for template|Maintemplate}}}
{| class="formtable"
! Name: 
| {{{field|Name|size=60}}}
|-
! Date: 
| {{{field|Date|input type=datepicker|first date=1687-01-01|date format=dd-mm-yy}}}
|-
! Department:
| {{{field|Department|input type=combobox|mapping template=Departments|placeholder=Select department|size=60}}}
|}
{{{end template}}}

{{{standard input|free text|rows=10}}}
{{{standard input|summary}}}
{{{standard input|minor edit}}} {{{standard input|watch}}}
{{{standard input|save}}} {{{standard input|preview}}} {{{standard input|changes}}} {{{standard input|cancel}}}
</includeonly>

The result of this is that I can select different departments in Form:Maintemplate (I would have preferred to get rid of the search field and have a simple dropdown), but when I change the name of an department in Template:Departments (after runJobs.php and cargoRecreateData.php) it does not update the name in pages that uses Template:Maintemplate.

I would also prefer that the Template:Departments table did not show in drill-down, because it's empty and only holds data for other templates.

Mybe I'm doing this all wrong? I would be grateful if you can help me get this right :) Pretor~nowiki (talk) 12:22, 28 September 2018 (UTC)

I'm not sure what you're trying to do here - but that's definitely an incorrect use of "mapping template". This is partly confusing because I think the template and field names could be clearer. The template called "Department" might be better called "Department names" or something, no? And "Maintemplate" might be better called... "Government"? I'm not sure what data that's meant to be storing. Anyway, it seems to me that there's confusion here between field names and field values. My guess is that "1", "2" and "3" are meant to be the possible values for the "Department" field, as stored in the wiki page. Is that true? Because right now, they're field names. Yaron Koren (talk) 16:27, 28 September 2018 (UTC)

What I'm trying to do is to create a table of government department names and use it in several forms as selectable dropdown options (one choice only per form creation). If the government choose to change the official name of a department, I would like to be able to change the name one place (the table) and then update all pages that uses that form and that department name. Hope this was more understandable.

Regarding the names of the templates/forms I've used on this page, they are only fictional examples. Pretor~nowiki (talk) 17:26, 28 September 2018 (UTC)

What kinds of values are supposed to go into the wiki page itself - numbers? In any case, it sounds like the temporary department names should be hardcoded in a mapping template, rather than stored via Cargo. Yaron Koren (talk) 19:57, 28 September 2018 (UTC)

It's text that is going into the wiki page, eg. "Department of Health-, Care and Human Services". I have read the documentation for many hours and testet different solutions, but have'nt been able to figure out how to do this. Could you please point me to a guide that shows exactly how to do this, or please tell me your self? Pretor~nowiki (talk) 20:24, 28 September 2018 (UTC)

Just to be 100% clear, is "Department of Health-, Care and Human Services" a temporary display value, or the permanent value to be placed in the page itself? It seems rather long to be a permanent value, but who knows. Yaron Koren (talk) 22:29, 28 September 2018 (UTC)

The name of the departments are permanent, but the reality is that the government sometimes changes them and then I need to update all pages with that name. The department name will be placed on the page, either by the initial import, the latter form creation or as a later change. Some of the names are rather long, yes, but they are nevertheless the official name. If you want you can get access to the website, then it might be more clear what I'm trying to do here. Pretor~nowiki (talk) 09:18, 29 September 2018 (UTC)

Alright, I think I get it. The main template and form seem basically fine, but the "mapping template" should look something like:

<noinclude>
This is the «Department display name» template.
</noinclude><includeonly>
{{#switch:{{{1|}}}
|Department of Agriculture=Current name of agriculture department
|Department of Commerce=Current name of commerce department
|Department of Health-, Care and Human Services (HHS)=Current name of HHS department
}}
</includeonly>

Then, assuming this template does get called "Department display name", you should have "mapping template=Department display name" in the form definition. Yaron Koren (talk) 15:47, 30 September 2018 (UTC)

So "template:Department display name" shall not be declared, stored or attached to the cargo table? And if so, how do I delete the old table that "Template:Departments" created and now shows in Drill-down? Pretor~nowiki (talk) 21:26, 30 September 2018 (UTC)

That's right. You should go to Special:CargoTables and delete it there. Yaron Koren (talk) 00:37, 1 October 2018 (UTC)