Angelina Jordan Wiki talk:Extensions
Extension:Cargo
@Dcljr: You suggested it yourself before to use mw:Extension:Cargo to get rid of the problems of the large JSON files for storage of changes, and to make contributions of others easier. I agree, and I would really like to try it out pretty soon, because it likely will have an effect on which further developments to Module:Performances and Data:Performances.json still do make sense and which do not. And that leaves me currently in a somewhat frozen state in regards to that. --Most2dot0 (talk) 07:12, 17 September 2025 (UTC)
- OK, hang on. The installation and configuration of Cargo is not trivial, so I need to devote some time to it. (Was dealing with spotty wifi yesterday. Hopefully that won't happen again this evening.) BTW, this doesn't work. I only get the notification if you ping me successfully when you first leave your message. Any attempt to ping someone by editing an existing message won't cause a ping. The workaround is to just leave a new message with the correct ping in it (it can be a reply to your own message). - dcljr (talk) 18:52, 18 September 2025 (UTC)
Extension:Page Forms
Preload Template
Create a template (e.g., Template:NewSongPage) that contains the standard wikitext structure for a new song page, including placeholders for Cargo templates (Performance, Video).
Form Collects Data
Build a Page Form (or any external form) that gathers all needed fields.
Pass Data to Preload
When calling the new page creation, use the preload parameter:
[[Special:CreatePage?preload=Template:NewSongPage&preloadparams=Song=MySong|Performer=Artist1|...]]
The form can generate the URL dynamically with the collected values substituted.
Page Creation
MediaWiki loads the new page with the template pre-filled with your form data. The user can review or edit before saving.
Notes
- This approach avoids overwriting any free text already present on manually maintained pages because the form does not directly write the page.
- Partial structured data can coexist with manually written prose.
- Ensure the template uses so that saving the new page stores the data in Cargo.
mw:Extension:Page Forms is sort of recommended in the preload feature description. It states itself that it supports Cargo. I assume we could use it to create an page with multiple elements, where all the essential information needed to create an article stub with Cargo data could be requested. A short discussion with ChatGPT encourages that thought (see box on the right), as it states its possible. Thus I would appreciate it if we eventually could have this extension --Most2dot0 (talk) 15:45, 11 October 2025 (UTC)
- Acknowledged. I'll install it the next time I upgrade MW (which should be soon). - dcljr (talk) 02:42, 20 October 2025 (UTC)
ReplaceText
@Dcljr: We talked about ReplaceText↗ elsewhere (it is already listed as being considered), and it would come in very handy to rework certain context trees for the performances entries, so just a slight hint that your could have a look at that today as well, just in case you didn't have it on your screen already. --Most2dot0 (talk) 09:32, 30 November 2025 (UTC)
- I think I'd still need more permissions to be able to use that? --Most2dot0 (talk) 11:25, 1 June 2026 (UTC)
- Thanks for the reminder. I have assigned you the appropriate permissions (including the ability to not leave redirects behind when pages are moved — please use that power wisely [i.e., try not to break lots of links].) - ajwikiadmin (talk) 14:22, 1 June 2026 (UTC)
Possible use cases for Page Forms
Since I had just created the CargoHelper Gadget when Page Forms was installed to help with the most urgent problem, I hadn't taken a closer look until now. Page Forms has a rather strict patterned approach, which makes it difficult to use it for editing existing pages which have multiple entries of a template, like the {{Performance}} and {{Video}} entries on Songs pages. The issue is that upon saving, it will typically relocate the templates that are adressed by the form to the top of the page. There apparently are ways around that (e.g. having a form use section fields, or uses list of templates within a form field), but those reduce the flexibility and still likely lead to a rearangement of templates within sections. Thus, it's not feasible for those kind of template use on pages.
Thus the primary use would be on pages that only have exactly one of the addressed templates in use, like {{Infobox song}}, {{Infobox album}}, or {{Infobox musician}}. It should be possible to use different forms for covers vs original songs, even though they populate the same infobox template.
We could also make special forms for just the creation of a new article, e.g. a new song article, which only sports at that moment one instance of {{Performance}} and {{Video}}. To avoid misuse, it could possibly be build on the preload-feature as the ChatGPT suggestion outlined it above. That would likely also make it easier to keep the instructions in form of html comments that we have today. Later edits could then utilize the normal form for the infobox edits, and CargoHelper for the addition of new performance and video entries. --Most2dot0 (talk) 09:27, 14 June 2026 (UTC)
- Having not actually used Page Forms to do anything (AFAIR), I can't really discuss this in an informed way. I guess the root of the problem lies in not sticking to a "one page = one object" philosophy? For a time, before you even got involved with the wiki, I was thinking along those lines (which is why I was trying to list out the various kinds of objects that the wiki would have to deal with and how they're related [look especially for the phrase "an event takes place"]), so I was envisioning a separate page for "everything": every song, performance, event, video, etc. This is more or less why I initially created the "YouTube" namespace (at the time called "YT"), although that idea never really went anywhere (I used it for redirects instead). Could subpages possibly help in some way?
BTW, the page MediaWiki:Gadget-CargoHelper - User Handbook should be moved into the "Project" namespace (i.e., "Angelina Jordan Wiki:…"), since "MediaWiki" is reserved for "system messages" and other aspects of the user interface (like the sitewide CSS). - dcljr (talk) 12:43, 14 June 2026 (UTC)- Yes, Page Forms was (initally) likely created with that one page = one object design idea in mind, and also, that the primary supported template type on such an object page would be an infobox design.
Currently, this wiki (like wikipedia) seems to be more based on a mark-up approach, and I think that is the more reasonable approach when the goal is to soon get to a nicely user readable wiki. Because having the need to create additional pages (which then likely get transcluded or reused by other types of references, like Cargo table queries) whenever someting new is mentioned in an article seems tedieous. If that is the price to pay for the widespread use of Page Forms, it's probably no productivity gain. That's why I tend more to using it only in a few selected cases. --Most2dot0 (talk) 17:23, 14 June 2026 (UTC) - PS I moved the CargoHelper handbook as requested to CargoHelper Gadget--Most2dot0 (talk) 17:31, 14 June 2026 (UTC)
- Yes, Page Forms was (initally) likely created with that one page = one object design idea in mind, and also, that the primary supported template type on such an object page would be an infobox design.
Issues with Page Forms
Multiple page edits on Cargo table listing
Pages forms introduces a multiple forms "edit" feature on the Special:CargoTables view, in this case it's there for the "Events" table, as I created that with Page Forms, so it has all the definitions that should make this work in place. However, I tried it and it turned out to be a disaster, essentially removing part of existing information, and adding a lot of empty {{Event}} templates to the pages (and in case of the Kongsberg Jazz Festival, it did it 4x, as it has 4 entries). So this is not usable! --Most2dot0 (talk) 15:57, 19 June 2026 (UTC)
