Extension talk:Page Forms

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

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 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 &amp;amp;. 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 &amp;amp; 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)

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   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.  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 --&#91;&#91;kgh&#93;&#93; (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 --&#91;&#91;kgh&#93;&#93; (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

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

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 --&#91;&#91;kgh&#93;&#93; (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 --&#91;&#91;kgh&#93;&#93; (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 for all categories (PF 4.3.1)?
Hej hej,

I followed Extension:Page_Forms/The_"edit_with_form"_tab and created Project:Category with (using Page Forms 4.3.1) but red links to categories always point to   instead of. What can I configure to get  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. Icon_External_Link_E-Mail.png 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. Icon_External_Link_E-Mail.png 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. Icon_External_Link_E-Mail.png 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. Icon_External_Link_E-Mail.png 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 (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.  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). --&#91;&#91;kgh&#93;&#93; (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. --&#91;&#91;kgh&#93;&#93; (talk) 10:17, 26 August 2018 (UTC)


 * I am in tears since wikis are loosing so much without this functionality. --&#91;&#91;kgh&#93;&#93; (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 --&#91;&#91;kgh&#93;&#93; (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. --&#91;&#91;kgh&#93;&#93; (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. --&#91;&#91;kgh&#93;&#93; (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:

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   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.  might be all needed to do the trick but it does not. I just get directed to the empty target page without. Adding  does not help either. I also tried  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 --&#91;&#91;kgh&#93;&#93; (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  does indeed do the trick. The form page still looks berserk but at least just   gets added. Progress, I guess. --&#91;&#91;kgh&#93;&#93; (talk) 14:34, 28 August 2018 (UTC)
 * Ok, paradise partially regained. It makes sense to add  after the   tag and some explanatory text prior to   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. --&#91;&#91;kgh&#93;&#93; (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)

The datepicker does not show up.
 * Issue

Cheers --&#91;&#91;kgh&#93;&#93; (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)

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.