User talk:Dcljr

For the record, the user leaving this comment (ajwikiadmin) and the user whose talk page this is (dcljr) are the same person. - ajwikiadmin (talk) 01:25, 12 August 2025 (UTC)

Feedback on new Performances prototype requested

Please have a look at User:Most2dot0/Performances-devel. I added a section describing the new features/solutions, and then there's the actual prototype after that. I'd like to know if you think this is a move in the right direction.

Please note, that the view/edit link to the JSON data are likely not correct (they would be for the final location of the table). The data used is here: User:Most2dot0/Performances.json-devel. --Most2dot0 (talk) 17:11, 1 September 2025 (UTC)

Looks OK on first glance. I'm "very close" to fixing the underlying database problems that happened when I created the "Data" namespace before the job queue was empty (the redlinks issue is not just "cosmetic"). I'll look at what you've done more closely (and reply to other relevant talk page comments) after I've finished that. As usual, the wiki will be uneditable for some time while I'm actually working on that. Will give the usual prior notice, hopefully far enough in advance that I won't cause you any problems while you're actively working on something. - dcljr (talk) 14:41, 2 September 2025 (UTC)

This version now uses the production data file Data:Performances.json, so my remark in the 2nd paragraph is no longer valid. I would still like your feedback on the "context" structure. --Most2dot0 (talk) 22:32, 17 September 2025 (UTC)

I don't understand why things like "oc Kongsberg Jazz Festival 2022" are mixed in with the songs. I mean, in another field, sure, but not as a "song". (See, e.g., Performances#2014. [??]) Apart from that — and, again, at first glance — the context field seems OK. Although I would lower-case things like "concert", "cover", "guest appearance", etc., which aren't proper nouns (they can be capitalized in the output using ucfirst^↗, if necessary — and, of course, if used as a page title, the capitalization of the first letter doesn't matter). I'm not seeing how the new "context" is behaving "in the wild", though. Can you point to a page where the effect of "context" is being seen? - dcljr (talk) 19:43, 18 September 2025 (UTC)

Please have a look at User:Most2dot0/Performances-devel. I added a section describing the new features/solutions, and then there's the actual prototype after that. The context aliase was a quick hack, to see how pointing to a different context could work, the final solution could certainly be different. --Most2dot0 (talk) 20:43, 18 September 2025 (UTC)

Ah, yes, of course: User:Most2dot0/Performances-devel. I'm afraid it's a bit overwhelming. Did you have specific questions? I would say it's going in the right direction, if that helps at all. There are some minor wording issues, like I would prefer "on set" to "at set" (sounds better to American ears, at least), and "with X" when she's not playing an instrument rather than "to X", and "on X" (or the more explicit "playing X") when she is playing the instrument. And I think many of these "5th-level" contexts would be better separated from the previous level(s) by a comma rather than just a space. Maybe all three of the "deeper" context levels should be separated by commas? Or would that be too difficult to avoid multiple commas in a row? (I guess a template or module could take care of that.) As for the actual structure you've chosen… I mean… OK. I might have some more ideas later on, but for now… sure. - dcljr (talk) 06:59, 19 September 2025 (UTC)

I implemented the commas before the 5th level contexts. It would be no problem to do it before the 4th level as well. The ucfirst did not work, might be again the question when exactly that is applied --- it might work on the "<" of the computed field <context[5]> instead on its result. It should be easy to add that conversion to the computed field transformations instead, though. I substituted "with->playing" and "to->with". In regards to specific questions,e.g: (1) We have like before three tables, it's just that the first one is now covering all events instead of just those which span years. I still think that the "Events by year" table is in most cases more useful. Currently the songs table jumps to the "All events" table, though. It might make sense to jump to the "Events by year" table instead, then there is the escape via the "◁" to the "All events" table to find possible occurances in other years, would you agree? (2) Do we need external (page) links to the 5th level at all? Possibly we could also use that as an in-page anchor instead, e.g. "Kongsberg Jazz Festival 2016, Gulljazz" ([[Kongsberg Jazz Festival]] [[Kongsberg Jazz Festival 2016|2016]], [[Kongsberg Jazz Festival 2016#Gulljazz|Gulljazz]]). Though in this case this wouldn't work properly, as the 2016 is already a redirect to an anchor. It would work well for like "7th Heaven" or "Million Miles if the page headings macht the database entries. (3) Should we try to add/integrate a "Songs by year" table in the jump sequence? BTW, there's a good reason to have it all on one page: if the embedded YouTube Player is used, it keeps playing when all the jumps are within the same page. — The preceding unsigned comment was posted by User:Most2dot0 at 19:56, 19 September 2025 (UTC)

Specific answers: (1) "Events by year" won't be useful if someone is looking for an event (or a kind of event) and doesn't know the year for it; "would you agree?": see third answer; (2) "do we need": probably not, especially if that makes things easier [grin]; (3) I'm not sure I see the great benefit to having all these tables on the same page. Why not put them on separate pages titled "Events" (where the song titles are linked to our song articles), "Events by year" (same), and "Performances by song title" (where the events are linked to event articles)? We could use one or more icons to provide "jump" links to other tables rather than using the text of the song title or event name. That would have the benefit of maintaining the idea that "linked text" = "go to article about this thing" (unless the link is marked as an external one^↗). BTW, how often will someone be jumping between tables and want to keep playing a video? Would that really be so useful? - dcljr (talk) 07:21, 28 September 2025 (UTC)

Luckily, we don't need to choose, we can have both separate and combinded listings. While the pages are big when rendered, they have small sources. So there is little issue with wasting space, as only the latest rendered version is stored. In regards to keeping a video playing, I have used this a lot when like researching similar performances or performances played at the same event, as it's a treat to listen to Angelina, so having a playlist keep playing until a new song is actively selected, is a blessing. In regards to context hierarchies, I also started to think about how they relate to wiki categories, and put down some ideas here. --Most2dot0 (talk) 18:21, 29 September 2025 (UTC)

My concern is not with storage space but user expectations/experience. There are two issues here: the placement of the tables and the linking between them. I guess my primary concern is how we are linking between them. I don't think anyone would expect links on song titles and event names in one table to go to another table on the same page, especially when not all such links do that (links in the main tables, before any subtables are expanded, go to articles). Yes, people can learn which links do what, but they really shouldn't have to. Using an icon for inter-table links, like  ↕  (if the tables are on the same page) or maybe something like  ▤  (which would "work" wherever the tables are) ["hover" on the icons to see the explanation], would lessen the "cognitive cost" of using the tables (for users who can "hover") and, like I was saying, would preserve the expected behavior of normal text links. (Of course, the use of "title" attributes gives rise to accessibility/usability issues, but there may be a solution to that problem^↗.) - dcljr (talk) 22:28, 29 September 2025 (UTC)

(continue above discussion with reduced indent level, to better work on mobile devices) I do understand the idea of "linked text" = "go to article about this thing"'. However, I don't think that is entirely true, even in the rest of the wiki, with links going (possibly with redirects) to specific sections of other articles or even within the same article. So I think the general idea is just "linked text" = "go somewhere where there is more related information about this", and that is valid for these tables, which list either other performances of the song, or other songs played at the event. But I don't have a big issue with doing it with some icons instead of full text links, though it might be slightly more difficult to hit those, which could also be a usibility concern. If we do with a two table setup, the 2nd table could be seen as sort of a footnote section, just with special formatting. I think I can showcase icons in the prototype within the next couple days. Also, when we move to Cargo we will have articles for all songs, which then hopefully even as a stub list (possibly with the help of Cargo, or simply because we use templates that both display and store the song information, it might not be an issue, because the song article would then contain the same basic information. You might have seen that I started to experiment with Ajax to realize an floating player that survives inter page jumps, which from my point of view would mitigate the negative effects of going to a different page. But that seems to be quite a complex effort, which would need a lot of careful testing. --Most2dot0 (talk) 12:03, 30 September 2025 (UTC)

PS: I now edited the "All Events" table to point both to the article (via text) and to the other table (via icon). It seem like the tooltip does not work when uses in a linked text, though: possibly it gets overriden by the link placing the URL into the lower left of the window in toolip format. I didn't touch the Event/Context entries in the "All Songs" table, as this needs some more consideration how to treat the different levels. --Most2dot0 (talk) 20:10, 1 October 2025 (UTC)

I created the three singular table pages you proposed, but for now in my "User:Most2dot0" namespace: User:Most2dot0/Events, User:Most2dot0/Events by year, and User:Most2dot0/Performances by song title. They are linked the same way together as the table combination on the User:Most2dot0/Performances-devel page. I am open for simplifications here, especially, if going forward, we will have song articles for each title soon. I don't see that for the events happening in the same pace, so the songs table should retain links to at least on of the events or events by year tables. --Most2dot0 (talk) 21:29, 5 October 2025 (UTC)

Storing timeline events in Cargo

It's likely beneficial to also have access to timeline entries via Cargo. To get a feel for it, I created the de Cargo template (DatedEvents), which converts it's input also back into the current timeline format. I created User:Most2dot0/2014 to test this. So basically, instead of ; {{da|2014-02-07}} : event description, one would now write {{de|2014-02-07|event description}}. If there are more events on the same date, they get seperated with "§§" instead of "\n:" This gets stored in Cargo as a "List(§§) of Events", which unfortunately seems to cause some issues in Cargo's display functions (look here to see what I mean) for all entries but the first of the same day. In terms of Cargo it would likely be beneficial to have separate entries of events on the same date, but it would not have been that straightforward easy to reconstruct the existing timeline 2014 page. I also provided a calender view of the data, but that didn't work to well so far either, because the FullCalenar library used by Cargo apparently strips the in-page anchors, like "#2014-07-02" for the link. And we also would need to come up with better constrution of the event name (currently I'm using the date) and its description (that currently displays the raw html format of the descriptions, when the mouse is hovering over the event). So, what are your thoughts on this? --Most2dot0 (talk) 14:51, 27 September 2025 (UTC) PS: I now implemented the calendar with Lua to use in the timeline. The styling is not 100% yet, but you'll get the idea how it utilizes the DatedEvents Cargo table.--Most2dot0 (talk) 22:10, 27 September 2025 (UTC)

I've seen this, obviously. Don't have time to reply to it right now, though. Hopefully tomorrow… - dcljr (talk) 07:37, 28 September 2025 (UTC)

I guess I don't really have anything to say about this at this point. It's certainly interesting. BTW, where are the month headings in the calendars at User:Most2dot0/2014 (e.g., "January 2014")? [grin] - dcljr (talk) 23:03, 29 September 2025 (UTC)

Realization of all the details is sort of pending a decision, if this concept should go intro production use. Some other things are not sorted out yet: so the remarks that are listed at the beginning of a month or year where did not yet covered by Cargo storage. And some slight modification was needed, where there was a qualification behind the date but before the colon. E.g. at 2014-06-13, where I moved the qualification inside the description (which would be required if the would have been a 2nd event at the same date anyhow, I think). I think the concept has a lot of future potential. E.g. we could add tags, if the event described was a performance, or a release, or something else, and use that for color markings and filtering, both in the calenders and elsewhere. --Most2dot0 (talk) 12:15, 30 September 2025 (UTC)

Just to clarify, in case you misunderstood, I was referring to the right-floated calendars at User:Most2dot0/2014 lacking any indication of what months they are for. - dcljr (talk) 03:17, 20 October 2025 (UTC)

That was clear, and it's certainly easy to fix. My point was that it's not worth fixing unless we decicde to actually use it.

— The preceding unsigned comment was posted by User:Most2dot0 at 08:55, 20 October 2025 (UTC)

Oh, I see. - dcljr (talk) 10:03, 20 October 2025 (UTC)

I now implemented a less more lightweight solution, based on just editing the existing {{da}} and {{calendar-month}} templates, which requires no change to other pages. Only the date anchors from the Timeline article get stored in the new "Dates" Cargo table. This could possibly later be extended to store and distingish other entry types, but that needs more thought. What we could do right away is also to store {{d}} entries, which would allow us to query those that don't have a corresponding target anchor defined. --Most2dot0 (talk) 15:20, 11 November 2025 (UTC)

Feedback on Cargo production database rollout / Cargo templates in song articles requested

I've been making good progress on the rollout of the Cargo version of the performance database. If you have not done so yet, please have a look at the transition ideas, open discussion points regarding articles created and the Current Status describing the progress. And of course please have a look at the newly created or expanded articles, and let me know if you see the need for adjustments. My plan ist to next append the other existing articles with Cargo templates. I will sort these into existing sections, but for article stubs that so far don't list performances, I will likely leave them unsorted. Then I will continue with the creation of new, so far missing song articles, also leaving the performances mostly unsorted (they will be listed according to their date, so are somewhat sorted already, just not explicitly grouped). Possibly I'll create the template for orignals on they way, to do those as well. As an alternative to mass-creation of all new songs articles with the performance template calls right away, we couldn't have those in several files e.g. split by starting letter. This way, the file size would be smaller, and changes would have less overhead. We could then delete entries from these files, one they have been copied to new song articles. So what do you think? --Most2dot0 (talk) 21:47, 9 October 2025 (UTC)

No more stopgap measures. Let's just do this (pending ongoing discussions elsewhere). As I have mentioned before, there's quite a lot to look through, so I haven't seen everything you've done. If I want things done differently in the future, I'll just have to bite the bullet and make the changes "manually" (see also User talk:Most2dot0#Mass changes in the future). - dcljr (talk) 03:17, 20 October 2025 (UTC)

Ok, thanks for all the feedback, I'm looking forward to bringing this on... --Most2dot0 (talk) 08:57, 20 October 2025 (UTC)

I now updated the documentation for the {{Performance}} and {{Video}} Cargo templates, and included a new section of how to include them in the Articles about songs article. Please let me now if you'd see the need for further clarifications. --Most2dot0 (talk) 10:06, 21 October 2025 (UTC)

I'm done with creating all misssing cover song articles. To quickly complete the production Cargo database rollout, I will next create the ones missing for the originals, but only via the dynamic preload, not doing any edits for the intros. --Most2dot0 (talk) 12:07, 25 October 2025 (UTC)

OK. It's just been one thing after another preventing me from devoting time to help with any of this. Just to hint at what I mean, in the last 4 weeks I have bought a car tire, three hard drives (two of which had to be returned), and a replacement remote control for my DVR. I'm wondering if I can make it out of October without something else going wrong. - dcljr (talk) 09:08, 26 October 2025 (UTC)

No problem, we all spent our time as available and we see fit. Obviously I had a lot of time to spare during the last week, so I went forward to get this rollout done as fast as possible. The missing partners infos was a bummer, but I don't think it's essential enough to switch back to the devel database. We can now take our time to sort these out. --Most2dot0 (talk) 16:49, 26 October 2025 (UTC)

PS: I started it, and it went quite smooth, so I sort got into the flow, and the missing partner entries are all sorted out now... --Most2dot0 (talk) 22:02, 26 October 2025 (UTC)

Regarding TODO: Compressing old article versions to save lots of space

I would suggest that you could in addition delete revisions that have been followed by changes of the same editor, possibly applying that only if they are within limited time span, like a couple or 24 hours. Change log entries might be combined to the latest one that remains. That way, you'll retain the info who did the changes, and likely still can save a lot of space, if you do this for the biggest files. --Most2dot0 (talk) 11:12, 26 October 2025 (UTC)

Slow job queue

You might have noticed, that editing {{Infobox song}} caused hundredths of jobs being spawned, which took hours to process. I noticed, that it works faster if I reload pages, and asking ChatGPT about it, this is the answer I got: "Likely cause: the job queue is being processed by the web request trigger mechanism, not a background job runner. Explanation: MediaWiki has two main ways to process queued jobs: (1) Via web requests — each page view or edit triggers execution of a few jobs ($wgJobRunRate controls how many). (2) Via a background job runner — a separate process (php maintenance/runJobs.php --maxjobs=N) or a service like jobrunner.php under a cron/systemd job. If the second method is not running, then jobs only run when users load pages. With very few users, the queue sits idle until someone triggers it, which matches your observation: reloading pages causes the queue to advance. Confirm by checking your LocalSettings.php for: $wgJobRunRate = 1; // default is 1, 0 disables, and whether a background job runner is configured. Solution: set up a cron or systemd service to run runJobs.php periodically, or use a job queue backend (e.g. Redis + JobQueueRedis) to process asynchronously." Working on the songs table database does require a lot of updates, so I hope you don't mind that I will help myself for now with a small .js script which will reload a page every couple seconds to keep the jobs processed. --Most2dot0 (talk) 18:04, 1 November 2025 (UTC)

Yeah, I noticed. The job queue is processed every time a page is served up. Most of the time, this includes page reloads, but that might not always work when just reloading the same page over and over. (I've noticed this in the past, but maybe I'm misremembering that.) Does that script-based page-reload scheme actually work?
In any case, when the job queue explodes due to, say, Template:Infobox song being changed, what problem does it actually cause? IOW, why can't you continue to work on the wiki and just let the queue go down slowly as you do stuff? (That's what I have done in the past.) Yes, it is possible to take other approaches (e.g., cron job), but I guess I need to be convinced that it's necessary to do something different.
BTW, I don't know if you've noticed, but there are 9 abandoned jobs in the queue that will have to either be deleted or re-queued (whatever the technical term is). Since these are just "refresh links" jobs, I'm not sure it's crucial to have them actually run, as opposed to merely deleting them. I'll try the former and if that doesn't fix the issue, I'll have to consider doing the latter. Here's the relevant information about the jobs (formatted as a wiki-list). - dcljr (talk) 03:32, 2 November 2025 (UTC)

Looks like there's an error that is preventing the completion of the jobs. Search for "error" in the output I linked to in my previous comment. And now there are 2 more jobs in the queue that are "stuck". It appears to be the 2 jobs that showed errors in their output (requestId=aQSwJ9m8hVLPRAA58Noj7QAABBg). So, me trying to run them again is what pushed 2 more jobs into the queue. - dcljr (talk) 04:28, 2 November 2025 (UTC)

Yes, the pages listed had all "Internal Errors" indicated when called. I had already fixed some, and now the last two, I think. These "Internal Errors" were caused by the older queries fed into the updated module, so I did notice them immediately, only when looking at those pages again. Whenever I updated the module after that, the last two caused the left jobs increase by two, so it got from 0 -> 7 -> 9 -> 11 over the weekend, now at 9. So the last two might have finished when I updated/fixed the pages? (BTW, when I first saw the 7, I thought these might have been longer running maintenance tasks scheduled for the weekend, I did not associate them with what I was doing). The pages are now all updated and display without error again, so it should be save to remove the stuck jobs.
My impression is, that the reload script does speed things up. Pressing the reload button manually on the same page, like the Cargo table overview, definitely works. It might be different for static pages, though.
Cargo has several quirks and bugs. E.g., when I edit the Infobox song to store data differently, that spans about 300 jobs that likely "purge" all the pages. But that will not do any change to the existing database entries! Only editing the page (not even sure if any edit will do, but removing/reading the Cargo template will do) will cause the change to take effect, or "reconstructing" the Cargo table, which will spawn another 300 jobs. And similar, If I do another change related to the Cargo tables effected, the already updated pages will not be updated again without another "reconstruction", so I would still be left after another 300 jobs to finish with an inconsistent table. I also noticed at times, that this might cause double table entries. So once the first 900 jobs were done, I need another 300 to get a clean table. I started to avoid that by using {{Infobox song devel}} on a select few song pages before changing the "real" one, but to see changes for the whole table to take effect, I still need to update all entries (twice}.
I guess I'm not good at multitasking, I prefer to finish one issue (or at least only a few) at a time, so when they get delayed due external reasons, I will still think about them. But without the feedback if the fixes are working, that thinking is less efficient, as it covers items that might have been clarified already if the results were in sooner. --Most2dot0 (talk) 09:08, 2 November 2025 (UTC)

Well, that's weird. The job queue has gone to 0 again without me doing anything. - dcljr (talk) 01:58, 30 November 2025 (UTC)

Wiki and Cargo limits

When expanding the inner tables, I encountered an issue, which is only seen on the full table. If I reduce its size with the limit parameter of the query, the error stopped. If I have a lower limit and use offset, to include the entry that seemed to be causing the issue, it worked. So I now suspect that this is caused by wiki limits. This is also supported by the fact, that there are warnings about templats not being included due to size (that even happens when the table is still working, though). As usual I discussed this with ChatGPT, here's that discussion:

Are there configurable limits in Cargo or MediaWiki that limit the size of what can be returned in a template with a Cargo query?

Yes. Several limits affect how much data a #cargo_query or Lua cargo.query() can return. They come from both Cargo and MediaWiki core.

Key constraints

1. Cargo’s queryLimit setting

Controlled in LocalSettings.php via $wgCargoQueryLimit and $wgCargoMaxQueryLimit.

Default:

$wgCargoQueryLimit = 50;        // default for users
$wgCargoMaxQueryLimit = 500;    // hard upper bound

These restrict the number of rows returned per query.

2. Page expansion limits (MediaWiki core)

Even if Cargo returns many results, the total expanded wikitext size cannot exceed:

$wgMaxArticleSize = 2048;   // in kilobytes, default 2048 KB = 2 MB of wikitext

Also limited by:

• $wgMaxTemplateDepth – recursion limit
• $wgMaxPPExpandDepth – parser expansion depth (default 40)
• $wgMaxPPNodeCount and $wgMaxPPExpandSize – limit parser node size and expansion

3. Lua memory and execution limits (Scribunto)

$wgScribuntoEngineConf['lua']['memoryLimit'] (default 50 MB)

$wgScribuntoEngineConf['lua']['cpuLimit'] (default 10 s)

These restrict large Cargo results fetched via Lua.

4. Database query timeouts

MediaWiki or the database server may kill slow queries after a timeout (depends on $wgDB* settings and server config).

Practical guidance

• Use limit in queries to control result size (for example, limit=100).
• Avoid returning large text blobs into templates.
• For large data exports, use Cargo’s Special:CargoTables or Special:CargoQuery instead of templates.

---

Example configuration block for LocalSettings.php

# ---- Cargo limits ----
# Default: 50 / 500. Raise both for larger queries.
$wgCargoQueryLimit = 200;        // default per-query limit for users
$wgCargoMaxQueryLimit = 2000;    // hard maximum allowed with limit=

# ---- MediaWiki parser limits ----
# Default: 2048 KB = 2 MB of wikitext
$wgMaxArticleSize = 4096;        // allow up to 4 MB expanded page size
$wgMaxPPExpandDepth = 60;        // default 40
$wgMaxPPNodeCount = 1000000;     // default 100,000
$wgMaxPPExpandSize = 2097152;    // 2 MB expansion limit; can raise if needed

# ---- Scribunto (Lua) limits ----
# Default memory 50 MB, CPU 10 s
$wgScribuntoEngineConf['lua']['memoryLimit'] = 100 * 1024 * 1024;  // 100 MB
$wgScribuntoEngineConf['lua']['cpuLimit'] = 20;                    // 20 seconds

# ---- Optional database timeout (for large Cargo queries) ----
# If your DB connection times out on large queries, raise this:
$wgDBTransactionTimeout = 60;    // seconds, if supported by your backend

Notes

• Always raise limits gradually and test on a non-production wiki first.
• Increasing parser or Lua limits increases CPU and memory use for each page render.
• To allow only trusted users to run very large Cargo queries, keep $wgCargoQueryLimit low and raise $wgCargoMaxQueryLimit, then grant cargoquerylimit rights to a specific user group.

I would appreciate it if you could tweak these values so that it works, hopefully with some margin for growth. For you to test if new values improve this, I set the latest version of Template:SongsTable-devel to the not working max. This is the previous iteration with a limit of 250 which is rendered correctly: [1]. I would assume that the issue here is rather the article size than the Cargo specific limits. --Most2dot0 (talk) 19:43, 4 November 2025 (UTC)

I have another proposal to solve this issue, that has the further benefit, that it will reduce the page sizes transmitted: fetching and rendering the inner tables on demand only when expanded via the Cargo API in JSON format, fetching and rendering being done in Javascript. This could be either a Gadget, or (which I would prefer) be in the side wide MediaWiki:Common.js so it works for everybody. If being a Gadget, the placeholder could display a link e.g. to the song listing in the Performances tables, and a hint towards the existance of the Gadget. I have tested pieces of this with my User:Most2dot0/common.js, and I'm confident that it would work. --Most2dot0 (talk) 23:06, 5 November 2025 (UTC)

Ok, I did follow that approach, the result is in {{SongsTable}}, which uses {{SongSection}}, which uses {{SongRow}}. The first defines the per song Cargo subqueries and table renderings, which is similar to what my createTable() in Lua does, but based on Javascript/HMTL instad of wikitext. So template calls are not possible, and mybe some other things need to be worked out. E.g. <a href> tags work, but <sup> and <span> don't seem to work there yet. The 2nd template eliminates the need for the section header pseudo Cargo entries in the Songs table, so I will likely remove those next. It rendes on section with the starting letter header and all songs related. For that the 3rd template is used, which now defines the Cargo placeholder entries instead of of calling the now obsolete {{VideoRow-devel}}. Trusting that you will complain afterwards if need, I put the supporting Javascript code into a new Gadgete, which is enabled by defaullt for all users, including not logged in ones. Logged-in users can disable it via the gadget settigns in the preferences. This will also allow us to work on improved versions withou making the on in use unstable. I still need to check and likely tweak the interaction with the embeded YouTube player gadget, but I think the current version is good enough to replace the numbered list in the Songs article. --Most2dot0 (talk) 16:29, 7 November 2025 (UTC)

So, I guess you still would like increased limits, per your remarks at Template:SongRow/doc? I have not yet started addressing that issue. - dcljr (talk) 10:54, 12 November 2025 (UTC)

Yes, as it would allow to increase the count of tables included statically (this including up two three items would make sense) and also to fine tune the sub-table display in {{PerformanceRow}}. I think static inclusion will overall be more efficient that on-demand loading for all small subtables. But we're not in hurry, as we would have the workaround described. Going forward, as this is only an issue for these very big tables, we could still use the flexibility of template based Cargo queries for most extractions, while if I find the time, I might add the missing features to the Performances module to support the alternative titles. But it's not that easy as the underlying generic concept is different from this particular use case, so I might also come to the conclusion that it's not worth it. Regarding that concept, it's sort of buttom-up, i.e.. it starts with the performance entries and only groups them, so it's inherent that each performance entry is rendered, and each song line has at least one performance in its sub-table. While there are no performances for the alternate sing titles, but the join query with the songs table used provides a row for each of those, which is treated as a performance with missing entries. You can see the result here: User:Most2dot0/Performances by song title#A_Million_Miles. --Most2dot0 (talk) 11:30, 12 November 2025 (UTC)

I did not have time to test out new limits during the maintenance period that just happened. It looks like the main problem is the 2MB article-size limit. Which seems odd, because the final rendered HTML for the mostly OK Template:SongsTable (which apparently only exceeds the limits because of the transcluded documentation) is only about 400KB. Anyway, I will look into this more this evening. The immediate objective is to make Template:SongsTable-devel render properly, right? What other limits (apart from article size, I mean) do you think might be most in need of changing? (If you haven't seen it already, Help:Template limits^↗ might be of interest.) - dcljr (talk) 10:34, 30 November 2025 (UTC)

Yes, that would be neat. I copied the template to User:Most2dot0/Test3, and set the limit to 239 rows, which is on before it breaks. (BTW, I did not transclude the documentation there, and it doesn't make a difference). The limit report output of that page is:

<!-- 
NewPP limit report
Cached time: 20251130110514
Cache expiry: 86400
Reduced expiry: false
Complications: []
CPU time usage: 0.924 seconds
Real time usage: 1.028 seconds
Preprocessor visited node count: 54742/1000000
Post‐expand include size: 2094290/2097152 bytes
Template argument size: 155902/2097152 bytes
Highest expansion depth: 11/100
Expensive parser function count: 0/100
Unstrip recursion depth: 0/20
Unstrip post‐expand size: 0/5000000 bytes
-->

So possibly that the "Post-expand include size" is govererned by ($wgMaxPPExpandSize = 2097152;), indeed at 2 MB, might be needed to be adjusted in addition to the $wgMaxArticleSize = 2048; (in KB). --Most2dot0 (talk) 11:20, 30 November 2025 (UTC)

PS: $wgMaxPPExpandSize might have been a halluzination of ChatGPT, as I didn't find that elsewhere. --Most2dot0 (talk) 16:10, 30 November 2025 (UTC)

According to Extension:Cargo/Querying data^↗, the defaults for $wgCargoQueryLimit and $wgCargoMaxQueryLimit are 100 and 5000, neither of which seem to be relevant for the issue I was trying to fix (100 being so low and 5000 so high), so I have not changed those (nor any of the others besides what I'm about to refer to). I had to increase $wgMaxArticleSize to 3072 (50% higher than the default 2048) to get {{SongsTable-devel}} to display all the entries. That page is currently sitting at 3,090,849 of the allotted 3,145,728 bytes post‐expand include size. This is much higher than I was hoping to go. Obviously, the number of songs is only going to increase over time, so we will have to figure out a more efficient way to generate the tables. I guess that's what you have been doing with Songs (and {{SongsTable}}, and the dynamic-loading stuff you talked about above), since that seemed to be working fine before the limit was changed. BTW, the difference between calling {{SongsTable}} from the "Songs" article and including the equivalent text directly in the article apparently stems from the fact that every time a template is called, the text it renders adds to the post-expand include size. So, in other words, just the fact that you are calling a template reduces the amount of content you can display within any given limit. See my last two edits to User:Most2dot0/Test3. Template:SongsTable-devel can show all the entries now, but not when called from another page, even when the template call is the only thing on that page. - dcljr (talk) 15:41, 8 January 2026 (UTC)

Thanks, I increased the items limit for static includes in {{SongRow}} (effecting {{SongsTable}} from 1 to 2, so now only approximately a remaining third song tables need to get loaded dynamically. Theres also about a 30% margin left until the expansion limit. However, fine-tuning the {{SongRow}} content will also lower that margin, we'll see. --Most2dot0 (talk) 17:34, 8 January 2026 (UTC)

Cargo Helper gadget for adding videos / performances

I created a new gadget named "Cargo Helper", which aids in creating video and performance entries. On song pages (identfied client side by checking traces of use of the {{Infobox song}} template or the "Songs" category (I am not sure if the latter works, though), an "Add video" link will be added to the page tools (adjecent to the "Purge cache" you added a while ago) on both the view and edit pages. If clicked, it will be in additon checked if a "Songs" table Cargo entry exists. If not a message about that is displayed, otherwise the "Add video / performance" dialog is openend. There it can be choosen if the video is to be added to an existing performance entry, which can be choosen, or if a new one is to be generated. If a new one is created, the local id/pid to connect the performance will be generate automatically (assuming the local part starts with a number, it will be one higher than the largest in use). If used on a view page, it will use an add-section preload link, whereas on an edit page, it will create the templates at the cursor position. If that's the start of a line, the "* ...", "*: " prefixes will be generated on two lines, otherwise the two templates will be inserted without additions.
There is room for improvement, e.g. in regards to the Context string selection/construction. Currently you can type a string in the combo box and it will filter for matching entries. But there could be a more suffisticated sub-dialog, helping in constructing a new context by choosing from the existing category/group fields only and adding a new occurrance entry, which could also be used for the event field.
I would still think this gadget is now already in an useful state, and I would recomend to eventually enable it by default. I will try to get ChatGPT to write useful help pages/documentation soon. As always, I'm looking forward to your feedback. --Most2dot0 (talk) 17:59, 15 November 2025 (UTC)