Keep historical query results on wiki

I guess this could be achieved if Cargo could output unparsed wikitext. That could then be copy and pasted into the wiki page in place of the query. Is that possible?

Are there other ways? Writing this I wonder about the "subst" thing so I'll try that today. Jonathan3 (talk) 10:52, 12 January 2025 (UTC)

Subst doesn't work, of course.

I have a vague memory of using the "template" output type to achieve this with fairly simple queries, probably with "nowiki" tags etc. But that needed two separate queries. It would be cool if Cargo could just output that automatically with the change of a parameter.

Thinking about it more, you wouldn't want it as an output type at all - you'd want it as a generic Cargo parameter like the existing "no html". Jonathan3 (talk) 12:17, 12 January 2025 (UTC)

@Jonathan3: This does sound like an interesting idea. It'd be sort of similar to meta:User:ListeriaBot or wikidata:User:InteGraalityBot I guess, in that the wikitext result of the query would be stored as a page revision and so changes to the output could be tracked. Perhaps you could do it with an export format (e.g. a single-column CSV that could output a wikitext table row per result). Then a bot could fetch the export and write the results to the wiki. Sam Wilson 00:10, 13 January 2025 (UTC)

Thanks. Being able to track changes to query output over time sounds even better. But what I had in mind in mind in my case was just a one-off wikitext rendering of the query result (using any output format) to know what it was on a certain date, and to avoid using Cargo from that point. Jonathan3 (talk) 07:27, 13 January 2025 (UTC)

I have a vague memory of using the "template" output type to achieve this with fairly simple queries, probably with "nowiki" tags etc. But that needed two separate queries.

Yes, it works by wrapping the formatting template's name, such as |template = Template-CargoRow in <nowiki> tags, but yeah, still requires more effort than is ideal. I've requested the same, for different reasons (debugging the interaction of Cargo with formatting templates, or queries within queries that use such templates etc., similar to how DPL3's |debug=5 works), but it hasn't been an option as of yet. We too often want to preserve one-time output without having another query to cache every 24 hours, though I'm sure there are other use-cases as well (I've come a cross a couple but can't recall atm). FrozenPlum (talk) 00:03, 16 January 2025 (UTC)

Thanks for that. I've just tried it and get a load of errors like "UNIQ--nowiki-00000001-QINU". It probably works all right on a simple Cargo query though. Jonathan3 (talk) 01:07, 22 January 2025 (UTC)

Example of "tree" output format

Is there an example of this online? Thanks. Jonathan3 (talk) 00:57, 22 January 2025 (UTC)

@Jonathan3: I was just playing around with it here: https://freopedia.org/Items But it seems that it's adding wikilinks for every value, which is annoying. I've tried doing things with CONCAT etc. but can't figure out how to customize the display of each node in the tree. Sam Wilson 01:08, 22 January 2025 (UTC)

Equivalent to SMW's "graph" format

Is there any way to achieve this using Cargo, perhaps along with another extension?

https://www.semantic-mediawiki.org/wiki/Extension:Semantic_Result_Formats

graph

• Graph format (Displays the relation between pages)
• Process format (Displays process graphs)

Jonathan3 (talk) 01:03, 22 January 2025 (UTC)

Are there any actual examples for "format=process"? The examples I see that are ostensibly for the Process format all seem to use "format=graph". Anyway, the Graph format seems to be basically about creating flowcharts. You can do that in Cargo with the "bpmn" format, if that's all that is. Yaron Koren (talk) 04:35, 22 January 2025 (UTC)

It would be for creating a sort of "family tree" of things, based on Cargo fields showing relationships between pages. Jonathan3 (talk) 08:50, 22 January 2025 (UTC)

In fact, something like this on Litmaps would be amazing: https://app.litmaps.com/preview/189679191 Jonathan3 (talk) 10:05, 22 January 2025 (UTC)

That's definitely an informative graph, but something like that seems out of the scope of either SMW or Cargo - it would probably require custom coding. Yaron Koren (talk) 16:11, 22 January 2025 (UTC)

Storing and querying +Infinity and -Infinity

When storing ranges from one number to another, is there a way to store +∞ and -∞ in Cargo in Float fields? And would it be possible to query for these ranges with something like this?

{{#cargo_query:tables=Ranges
|fields=Ranges._pageName
|where=Ranges.from > {{{from|'-Inf'}}} AND Ranges.to < {{{to|'+Inf'}}}
}}

Regadless of trying to store '-Inf' or Inf, it fails to make the row. Yonicstudios (talk) 18:35, 23 January 2025 (UTC)

@Yonicstudios: Could you store null and take that to indicate an open-ended range? That's how I've done it in the past. Otherwise, add an extra boolean field e.g. Ranges.from_infinity and query that. Sam Wilson 23:33, 23 January 2025 (UTC)

Seems like COALESCE(Ranges.from >= {{{from|NULL}}}, TRUE) AND COALESCE(Ranges.to <= {{{to|NULL}}}, TRUE) is doing the trick! Yonicstudios (talk) 01:35, 25 January 2025 (UTC)

PHP Warning: Invalid argument supplied for foreach() in SpecialSwitchCargoTable.php on line 42

PHP Warning: Invalid argument supplied for foreach() in /var/www/html/extensions/Cargo/includes/specials/SpecialSwitchCargoTable.php on line 42, referer: https://www.example.com/Special:SwitchCargoTable/Resources Jonathan3 (talk) 10:33, 24 January 2025 (UTC)

Store value in main table on basis of query on parent table

Let's say we have a Books table and an Editions table. The Editions table has a Publication date field. I'd like to store the earliest publication date as a date field in the Books table. But I can't get it to work. Any ideas? The date field just won't store at all. I've tried the normal way, and also using Lua.

(This is mainly to get round the fact that the Drilldown page will display a load of duplicates if it shows the Books and Editions tables.) Jonathan3 (talk) 00:25, 26 January 2025 (UTC)

I guess it's just not possible, as the #cargo_store happens before any #cargo_query. Does that sound right? Jonathan3 (talk) 01:13, 26 January 2025 (UTC)

Querying _pageTitle in Sitenotice breaks all special pages

I'm running a query in MediaWiki:Sitenotice to add a customized menu to the sidebar, but when I query the _pageTitle, it causes an error message on all special pages (querying _pageName and other fields works fine). Is there a workaround?

The query goes inside this CONCAT to split the string:

{{#cargo_query:table=MyTable|fields=CONCAT(SUBSTRING_INDEX(_pageTitle,' - ',1))}}

But it's not the CONCAT or SQL function that is causing the error as this simplified query doesn't work either:

{{#cargo_query:table=MyTable|fields=_pageTitle}}

MediaWiki internal error.

Original exception: [Z7arKwjorIgKEww9FxwvXwAAAAw] /wiki/Special:CargoTables MWException: Parser state cleared while parsing. Did you call Parser::parse recursively? Lock is held by: #0 /home/customer/www/mysite.com/public_html/wiki/includes/parser/Parser.php(611): Parser->lock()

1. 1 /home/customer/www/mysite.com/public_html/wiki/includes/OutputPage.php(2113): Parser->parse('
   parseInternal('

   parseAsInterface('

   {closure}(false, 600, Array, NULL, Array)
2. 5 /home/customer/www/mysite.com/public_html/wiki/includes/libs/objectcache/wancache/WANObjectCache.php(1539): WANObjectCache->fetchOrRegenerate('db4omxblk1hg1q-...', 600, Object(Closure), Array, Array)
3. 6 /home/customer/www/mysite.com/public_html/wiki/includes/skins/Skin.php(2028): WANObjectCache->getWithSetCallback('db4omxblk1hg1q-...', 600, Object(Closure))
4. 7 /home/customer/www/mysite.com/public_html/wiki/includes/skins/Skin.php(2059): Skin->getCachedNotice('sitenotice')
5. 8 /home/customer/www/mysite.com/public_html/wiki/includes/skins/SkinMustache.php(180): Skin->getSiteNotice()
6. 9 /home/customer/www/mysite.com/public_html/wiki/skins/Vector/includes/SkinVector.php(177): SkinMustache->getTemplateData()
7. 10 /home/customer/www/mysite.com/public_html/wiki/includes/skins/SkinMustache.php(136): SkinVector->getTemplateData()
8. 11 /home/customer/www/mysite.com/public_html/wiki/includes/skins/SkinTemplate.php(146): SkinMustache->generateHTML()
9. 12 /home/customer/www/mysite.com/public_html/wiki/includes/OutputPage.php(2634): SkinTemplate->outputPage()
10. 13 /home/customer/www/mysite.com/public_html/wiki/includes/MediaWiki.php(927): OutputPage->output(true)
11. 14 /home/customer/www/mysite.com/public_html/wiki/includes/MediaWiki.php(940): MediaWiki::{closure}()
12. 15 /home/customer/www/mysite.com/public_html/wiki/includes/MediaWiki.php(546): MediaWiki->main()
13. 16 /home/customer/www/mysite.com/public_html/wiki/index.php(53): MediaWiki->run()
14. 17 /home/customer/www/mysite.com/public_html/wiki/index.php(46): wfIndexMain()
15. 18 {main}

Backtrace: from /home/customer/www/mysite.com/public_html/wiki/includes/parser/Parser.php(6281)

1. 0 /home/customer/www/mysite.com/public_html/wiki/includes/parser/Parser.php(611): Parser->lock()
2. 1 /home/customer/www/mysite.com/public_html/wiki/extensions/Cargo/includes/CargoUtils.php(547): Parser->parse(string, Title, ParserOptions, boolean)
3. 2 /home/customer/www/mysite.com/public_html/wiki/extensions/Cargo/includes/CargoQueryDisplayer.php(261): CargoUtils::smartParse(string, Parser)
4. 3 /home/customer/www/mysite.com/public_html/wiki/extensions/Cargo/includes/CargoQueryDisplayer.php(176): CargoQueryDisplayer::formatFieldValue(string, NULL, CargoFieldDescription, Parser)
5. 4 /home/customer/www/mysite.com/public_html/wiki/extensions/Cargo/includes/CargoQueryDisplayer.php(375): CargoQueryDisplayer->getFormattedQueryResults(array)
6. 5 /home/customer/www/mysite.com/public_html/wiki/extensions/Cargo/includes/parserfunctions/CargoQuery.php(168): CargoQueryDisplayer->displayQueryResults(CargoListFormat, array)
7. 6 /home/customer/www/mysite.com/public_html/wiki/includes/parser/Parser.php(3356): CargoQuery::run(Parser, string, string, string, string)
8. 7 /home/customer/www/mysite.com/public_html/wiki/includes/parser/Parser.php(3041): Parser->callParserFunction(PPFrame_Hash, string, array)
9. 8 /home/customer/www/mysite.com/public_html/wiki/includes/parser/PPFrame_Hash.php(263): Parser->braceSubstitution(array, PPFrame_Hash)
10. 9 /home/customer/www/mysite.com/public_html/wiki/includes/parser/Parser.php(2879): PPFrame_Hash->expand(PPNode_Hash_Tree, integer)
11. 10 /home/customer/www/mysite.com/public_html/wiki/includes/parser/Parser.php(1549): Parser->replaceVariables(string)
12. 11 /home/customer/www/mysite.com/public_html/wiki/includes/parser/Parser.php(639): Parser->internalParse(string)
13. 12 /home/customer/www/mysite.com/public_html/wiki/includes/OutputPage.php(2113): Parser->parse(string, Title, ParserOptions, boolean, boolean, NULL)
14. 13 /home/customer/www/mysite.com/public_html/wiki/includes/OutputPage.php(2064): OutputPage->parseInternal(string, Title, boolean, boolean)
15. 14 /home/customer/www/mysite.com/public_html/wiki/includes/skins/Skin.php(2035): OutputPage->parseAsInterface(string)
16. 15 /home/customer/www/mysite.com/public_html/wiki/includes/libs/objectcache/wancache/WANObjectCache.php(1706): Skin->{closure}(boolean, integer, array, NULL, array)
17. 16 /home/customer/www/mysite.com/public_html/wiki/includes/libs/objectcache/wancache/WANObjectCache.php(1539): WANObjectCache->fetchOrRegenerate(string, integer, Closure, array, array)
18. 17 /home/customer/www/mysite.com/public_html/wiki/includes/skins/Skin.php(2028): WANObjectCache->getWithSetCallback(string, integer, Closure)
19. 18 /home/customer/www/mysite.com/public_html/wiki/includes/skins/Skin.php(2059): Skin->getCachedNotice(string)
20. 19 /home/customer/www/mysite.com/public_html/wiki/includes/skins/SkinMustache.php(180): Skin->getSiteNotice()
21. 20 /home/customer/www/mysite.com/public_html/wiki/skins/Vector/includes/SkinVector.php(177): SkinMustache->getTemplateData()
22. 21 /home/customer/www/mysite.com/public_html/wiki/includes/skins/SkinMustache.php(136): SkinVector->getTemplateData()
23. 22 /home/customer/www/mysite.com/public_html/wiki/includes/skins/SkinTemplate.php(146): SkinMustache->generateHTML()
24. 23 /home/customer/www/mysite.com/public_html/wiki/includes/OutputPage.php(2634): SkinTemplate->outputPage()
25. 24 /home/customer/www/mysite.com/public_html/wiki/includes/MediaWiki.php(927): OutputPage->output(boolean)
26. 25 /home/customer/www/mysite.com/public_html/wiki/includes/MediaWiki.php(940): MediaWiki::{closure}()
27. 26 /home/customer/www/mysite.com/public_html/wiki/includes/MediaWiki.php(546): MediaWiki->main()
28. 27 /home/customer/www/mysite.com/public_html/wiki/index.php(53): MediaWiki->run()
29. 28 /home/customer/www/mysite.com/public_html/wiki/index.php(46): wfIndexMain()
30. 29 {main}

Exception caught inside exception handler: [Z7arKwjorIgKEww9FxwvXwAAAAw] /wiki/Special:CargoTables MWException: Parser state cleared while parsing. Did you call Parser::parse recursively? Lock is held by: #0 /home/customer/www/mysite.com/public_html/wiki/includes/parser/Parser.php(611): Parser->lock()

1. 1 /home/customer/www/mysite.com/public_html/wiki/includes/OutputPage.php(2113): Parser->parse('
   parseInternal('

   parseAsInterface('

   {closure}(false, 600, Array, NULL, Array)
2. 5 /home/customer/www/mysite.com/public_html/wiki/includes/libs/objectcache/wancache/WANObjectCache.php(1539): WANObjectCache->fetchOrRegenerate('db4omxblk1hg1q-...', 600, Object(Closure), Array, Array)
3. 6 /home/customer/www/mysite.com/public_html/wiki/includes/skins/Skin.php(2028): WANObjectCache->getWithSetCallback('db4omxblk1hg1q-...', 600, Object(Closure))
4. 7 /home/customer/www/mysite.com/public_html/wiki/includes/skins/Skin.php(2059): Skin->getCachedNotice('sitenotice')
5. 8 /home/customer/www/mysite.com/public_html/wiki/includes/skins/SkinMustache.php(180): Skin->getSiteNotice()
6. 9 /home/customer/www/mysite.com/public_html/wiki/skins/Vector/includes/SkinVector.php(177): SkinMustache->getTemplateData()
7. 10 /home/customer/www/mysite.com/public_html/wiki/includes/skins/SkinMustache.php(136): SkinVector->getTemplateData()
8. 11 /home/customer/www/mysite.com/public_html/wiki/includes/skins/SkinTemplate.php(146): SkinMustache->generateHTML()
9. 12 /home/customer/www/mysite.com/public_html/wiki/includes/OutputPage.php(2634): SkinTemplate->outputPage()
10. 13 /home/customer/www/mysite.com/public_html/wiki/includes/exception/MWException.php(193): OutputPage->output()
11. 14 /home/customer/www/mysite.com/public_html/wiki/includes/exception/MWException.php(231): MWException->reportHTML()
12. 15 /home/customer/www/mysite.com/public_html/wiki/includes/exception/MWExceptionHandler.php(104): MWException->report()
13. 16 /home/customer/www/mysite.com/public_html/wiki/includes/exception/MWExceptionHandler.php(185): MWExceptionHandler::report(Object(MWException))
14. 17 /home/customer/www/mysite.com/public_html/wiki/includes/MediaWiki.php(565): MWExceptionHandler::handleException(Object(MWException), 'entrypoint')
15. 18 /home/customer/www/mysite.com/public_html/wiki/index.php(53): MediaWiki->run()
16. 19 /home/customer/www/mysite.com/public_html/wiki/index.php(46): wfIndexMain()
17. 20 {main}

Backtrace: from /home/customer/www/mysite.com/public_html/wiki/includes/parser/Parser.php(6281)

1. 0 /home/customer/www/mysite.com/public_html/wiki/includes/parser/Parser.php(611): Parser->lock()
2. 1 /home/customer/www/mysite.com/public_html/wiki/extensions/Cargo/includes/CargoUtils.php(547): Parser->parse(string, Title, ParserOptions, boolean)
3. 2 /home/customer/www/mysite.com/public_html/wiki/extensions/Cargo/includes/CargoQueryDisplayer.php(261): CargoUtils::smartParse(string, Parser)
4. 3 /home/customer/www/mysite.com/public_html/wiki/extensions/Cargo/includes/CargoQueryDisplayer.php(176): CargoQueryDisplayer::formatFieldValue(string, NULL, CargoFieldDescription, Parser)
5. 4 /home/customer/www/mysite.com/public_html/wiki/extensions/Cargo/includes/CargoQueryDisplayer.php(375): CargoQueryDisplayer->getFormattedQueryResults(array)
6. 5 /home/customer/www/mysite.com/public_html/wiki/extensions/Cargo/includes/parserfunctions/CargoQuery.php(168): CargoQueryDisplayer->displayQueryResults(CargoListFormat, array)
7. 6 /home/customer/www/mysite.com/public_html/wiki/includes/parser/Parser.php(3356): CargoQuery::run(Parser, string, string, string, string)
8. 7 /home/customer/www/mysite.com/public_html/wiki/includes/parser/Parser.php(3041): Parser->callParserFunction(PPFrame_Hash, string, array)
9. 8 /home/customer/www/mysite.com/public_html/wiki/includes/parser/PPFrame_Hash.php(263): Parser->braceSubstitution(array, PPFrame_Hash)
10. 9 /home/customer/www/mysite.com/public_html/wiki/includes/parser/Parser.php(2879): PPFrame_Hash->expand(PPNode_Hash_Tree, integer)
11. 10 /home/customer/www/mysite.com/public_html/wiki/includes/parser/Parser.php(1549): Parser->replaceVariables(string)
12. 11 /home/customer/www/mysite.com/public_html/wiki/includes/parser/Parser.php(639): Parser->internalParse(string)
13. 12 /home/customer/www/mysite.com/public_html/wiki/includes/OutputPage.php(2113): Parser->parse(string, Title, ParserOptions, boolean, boolean, NULL)
14. 13 /home/customer/www/mysite.com/public_html/wiki/includes/OutputPage.php(2064): OutputPage->parseInternal(string, Title, boolean, boolean)
15. 14 /home/customer/www/mysite.com/public_html/wiki/includes/skins/Skin.php(2035): OutputPage->parseAsInterface(string)
16. 15 /home/customer/www/mysite.com/public_html/wiki/includes/libs/objectcache/wancache/WANObjectCache.php(1706): Skin->{closure}(boolean, integer, array, NULL, array)
17. 16 /home/customer/www/mysite.com/public_html/wiki/includes/libs/objectcache/wancache/WANObjectCache.php(1539): WANObjectCache->fetchOrRegenerate(string, integer, Closure, array, array)
18. 17 /home/customer/www/mysite.com/public_html/wiki/includes/skins/Skin.php(2028): WANObjectCache->getWithSetCallback(string, integer, Closure)
19. 18 /home/customer/www/mysite.com/public_html/wiki/includes/skins/Skin.php(2059): Skin->getCachedNotice(string)
20. 19 /home/customer/www/mysite.com/public_html/wiki/includes/skins/SkinMustache.php(180): Skin->getSiteNotice()
21. 20 /home/customer/www/mysite.com/public_html/wiki/skins/Vector/includes/SkinVector.php(177): SkinMustache->getTemplateData()
22. 21 /home/customer/www/mysite.com/public_html/wiki/includes/skins/SkinMustache.php(136): SkinVector->getTemplateData()
23. 22 /home/customer/www/mysite.com/public_html/wiki/includes/skins/SkinTemplate.php(146): SkinMustache->generateHTML()
24. 23 /home/customer/www/mysite.com/public_html/wiki/includes/OutputPage.php(2634): SkinTemplate->outputPage()
25. 24 /home/customer/www/mysite.com/public_html/wiki/includes/exception/MWException.php(193): OutputPage->output()
26. 25 /home/customer/www/mysite.com/public_html/wiki/includes/exception/MWException.php(231): MWException->reportHTML()
27. 26 /home/customer/www/mysite.com/public_html/wiki/includes/exception/MWExceptionHandler.php(104): MWException->report()
28. 27 /home/customer/www/mysite.com/public_html/wiki/includes/exception/MWExceptionHandler.php(185): MWExceptionHandler::report(MWException)
29. 28 /home/customer/www/mysite.com/public_html/wiki/includes/MediaWiki.php(565): MWExceptionHandler::handleException(MWException, string)
30. 29 /home/customer/www/mysite.com/public_html/wiki/index.php(53): MediaWiki->run()
31. 30 /home/customer/www/mysite.com/public_html/wiki/index.php(46): wfIndexMain()
32. 31 {main}

Tahoma403 (talk) 04:30, 20 February 2025 (UTC)

Problems with querying and with drilldown of certain table

I use Cargo version 3.4.3 on Mediawiki 1.39.4. Few days ago I noticed that querying Book table for

Books.freeDownload = true

(see link: https://www.franklinova-expedice.cz/w/Speci%C3%A1ln%C3%AD:CargoQuery?title=Speci%C3%A1ln%C3%AD%3ACargoQuery&tables=Books%2C+&fields=Books.title%2C+Books._pageID%2C+&where=Books.freeDownload+%3D+true&join_on=&group_by=&having=&order_by%5B0%5D=&order_by_options%5B0%5D=ASC&limit=&offset=&format= ) returns wrong values: there should be only 3 books returned but in fact 7 are returned.

In the database table itself and on pages which are source for this table is correct data (see e.g. https://www.franklinova-expedice.cz/w/Data:2009_Lost! - Volně ke stažení? ~ Books.freeDownload is set to "Ne" (no), but when queried, it returns "Ano" (yes).

It looks like if Mediawiki works with some wrong / damaged version of table. I tried to recreate the table but nothing changed.

There is another problem with this table: when using Drilldown at

https://www.franklinova-expedice.cz/w/Speci%C3%A1ln%C3%AD:Drilldown/Books

there is undeletable filter for title with value Speciální:Drilldown/Books (which is path to the page). I am not sure if this is related to the above metioned problem with querying. Radouch (talk) 19:11, 2 March 2025 (UTC)

How odd - for that "2009 Lost!" book, there are two rows stored, where there should be just one. Maybe there are other pages with a similar problem - I would try recreating the table. By the way, this is a minor point, but the "firstEditionYear" field should be of type Date, not Integer, even though it will always be an integer. As for the drilldown - what do you mean by "undeletable"? Yaron Koren (talk) 06:58, 3 March 2025 (UTC)

Thanks for your swift reply. I did not notice records are duplicate. After posting my original post I have tried to recreate data and now I know:

1. I can correct the problem with wrong boolean value if I do some edit of the page containg data (e.g. https://www.franklinova-expedice.cz/w/Data:2009_Lost! )
2. Recreating table restores this problem: it seems that all wrong rows are in fact "duplicated" (only in query results: in "real table" and in category https://www.franklinova-expedice.cz/w/Kategorie:Books there is only 57 rows, but Cargo pretends there is 66 rows).

Concerning "undeletable filter": I am not sure how to paste screenshot here, so I am going to post better reply later. Simple explanation in text: if you go to https://www.franklinova-expedice.cz/w/Speci%C3%A1ln%C3%AD:Drilldown/Books?_single do you see any returned records? I do not as there is "preselected" nonsense value for title (which should not be) and this value cannot be removed by clicking on cross in the circle (nothing happens) Radouch (talk) 14:43, 3 March 2025 (UTC)

Oh... I know what's going on with "title". The problem is that "title" is the URL parameter that MediaWiki uses to set the title of the page, so the use of this field name is confusing Special:Drilldown. I would strongly recommend changing the name of this field to just about anything else - even "Title" would work fine.

As for the duplication problem - that's not good. I would try recreating the table from the command line, via cargoRecreateData.php, if you have command-line access - my guess is that one or more pages are leading to an error in #cargo_store, which is messing up the process. (Conversely, the command-line script often works a little better, even if there's no error, so maybe that will fix the problem anway.) Yaron Koren (talk) 17:09, 3 March 2025 (UTC)

Unfortunately, I do not have command line access on my webhosting.

I have noticed there was some strange bug in my scheme for books (a string field for subtitle was limited to the list of allowed values, which was not my intention). I have fixed it and regenerated the table. Now there are no duplicite rows (good news) but only "wrong" rows remained (bad news).

I plan to fix the problem with title first and then see what happens.

I am afraid there is no way to change field name globally so I have to change it in all data pages, am I right? Radouch (talk) 06:00, 5 March 2025 (UTC)

That's (sort of) good news! One problem fixed, at least. No, there's no need to change any of the data pages - please note that the Cargo field and the template field are not the same thing, even though they usually have the same name. You can keep the template name as "title" and just rename the Cargo field - although if you do that, please note that the field will have to be specified explicitly in #cargo_store - if a field is not listed in #cargo_store, the code assumes that the template and Cargo field names are the same. Yaron Koren (talk) 22:25, 5 March 2025 (UTC)

Thanks, I was not aware that Cargo field and template field can have different names. I made some tests on my testing wiki and it seems to work well (and problems with Drilldown disappear), but: I use Page Schemas extension and if I modify template:Book "by hand" and then I change something in Page Schema and regenerate template, all my hand-made changes are lost (which makes sense).

Is it possible somehow define different name for Cargo field in Page Schema? If not I am prepared to make "big change" and modify field name everywhere... :-) Radouch (talk) 21:09, 7 March 2025 (UTC)

SOLVED: Well, now I know what was the cause of problem. Cargo apparently does not like when there is field named title which contains chacracter (’) (apostrophe, right single quotation mark, U+2019). There is no problem if using "typewriter" apostrophe ('). First aid is to replace apostrophe with typewriter apostrophe, then I am going to rename the field title to prevent any future problems similiar to this.. Radouch (talk) 15:23, 15 March 2025 (UTC)

Creation of Cargo table "Xyz" failed.

I'm trying to create a cargo table, but in the web browser I get an error of "Creation of Cargo table "Xyz" failed." I also tried the command line method with cargoRecreateData.php, both directly and using the run.php script and both methods didn't provide any output (good or bad), but it also didn't create the tables.

One thing to note is my database is SQLite. I'm also using mediawiki 1.43.0, cargo 3.7 (fa85d11) 01:39, 27 February 2025, and php 8.4.4. I'm using the default SQLite database setup mediawiki created, without any modifications. The wiki works fine except for this issue.

Any ideas on how I might create a cargo table? Maybe it's something I could do manually? 70.160.223.43 22:54, 5 March 2025 (UTC)

It's strange that calling the command-line script didn't result in any kind of descriptive output. Was it literally just that error message, nothing else? Also, have you only tried to create on table, or has it happened with multiple tables? Maybe there's a problem with the specific #cargo_declare call. Yaron Koren (talk) 04:15, 6 March 2025 (UTC)

That was the only error in the browser.

At the cli I ran it two different ways, and here's all the output from that:

root@3ecf36dbdcdf:/var/w/html# php /var/w/html/---/w/maintenance/run.php /var/w/html/---/w/extensions/Cargo/maintenance/cargoRecreateData.php

root@3ecf36dbdcdf:/var/w/html#‎

root@3ecf36dbdcdf:/var/w/html# php /var/w/html/---/w/extensions/Cargo/maintenance/cargoRecreateData.php

*******************************************************************************

NOTE: Do not run maintenance scripts directly, use maintenance/run.php instead!

      Running scripts directly has been deprecated in MediaWiki 1.40.

      It may not work for some (or any) scripts in the future.

*******************************************************************************

root@3ecf36dbdcdf:/var/w/html# 70.160.223.43 03:10, 8 March 2025 (UTC)

I was able to get it to work by having it create its own database file. 70.160.223.43 15:00, 8 March 2025 (UTC)

Oh, it's a SQLite thing. Do you mean that all the $wgCargoDB... settings have to be set? Yaron Koren (talk) 19:50, 10 March 2025 (UTC)

Hello both of you and first: thanks Yaron for this awesome work with Cargo! I run in the same issue here except I'm under Cargo 3.8. I first set up Cargo to use the same SQLite as Mediawiki but got some crazy hang times. The command cargoRecreateData --table mytable works but the #cargo_store makes the app stop responding for several minutes (database locked).

I tried to set up a different db file for Cargo (from LocalSettings), but it seems it doesn't want to use it, it seems to think there's nothing to do on db side as the extension has already been installed on the main db file.

Any idea on how I can force Cargo to go use its own db file ? CacahueteNC (talk) 22:10, 4 May 2025 (UTC)

You may have run into a bug with Cargo's SQLite handling... I've never tried running Cargo with SQLite, so I don't know how well it works. Did you set all the necessary settings - six in all, I think? Yaron Koren (talk) 20:05, 5 May 2025 (UTC)

Yes all of them, same values as for the main SQLite database except for the file name. By looking at the access logs, I can say that Cargo does not try to look at its db, the main db is accessed instead, as if the parameters are completely ignored. So there might be two issues here: first cargo's access to the main db kind of works. #cargo_store directive causes huge hang times and doesn't store anything; but manually executing the cargoRecreateData command on the target table does work and respond quickly. Second setting up cargo's own db doesn't seem to trigger anything, even when executing manually the cargoRecreateData script. Any hint of what I can look into next? I'm eager to help but don't know much about PHP, even though I can try and wrap my head around. CacahueteNC (talk) 20:30, 6 May 2025 (UTC)

Okay, there might be a few issues here. Let me see if I understand everything you're saying:

• Is your main MediaWiki database also running on SQLite?
• Does all the Cargo data end up in your main database? (I think so, but I'm not 100% sure.)
• Is your job queue running normally? (You can test it by running the MW maintenance script runJobs.php.)
• By "huge hang times", do you mean that saving any page containing Cargo data happens very slowly?

Yaron Koren (talk) 16:54, 7 May 2025 (UTC)

• Yes my main MW db is on SQLite
• Yes cargo data end up in this db, when it does actually save
• The job queue looks alright
• It looks like any cargo storing action leads to minutes (!) of hang time. Except when I trigger it with the cargoRecreateData script

When installing cargo I initially setup page and file metadata for it. But any page save (even without any cargo data) would make the whole db hang (which makes sense as cargo want to save data from this action). So I removed the metadata fields and everything went back to normal.

Then I declared a first cargo table and tried to save to it via the #cargo_store directive but it hung as before. When it stopped hanging, the data wasn't saved so I executed the cargoRecreateData on that table and it executed promptly and saved the data.

I thought it would be better for cargo to have its own db file, so I setup the required parameters, but they didn't seem to have any effect: cargo seems to still use the main db, which is confirmed by the debug logs as I don't see the cargo db file's name, only the main db file's name. CacahueteNC (talk) 12:20, 8 May 2025 (UTC)

Okay so I managed to make Cargo use its own DB file! It happens that one must use $wgCargoDBfilePath = "/path/to/data/dir/cargo_sqlite_file.sqlite" instead of $wgCargoDBname = "cargo_sqlite_file" in conjunction with $wgSQLiteDataDir = "/path/to/data/dir/" used by MW's main DB.

That is because in CargoUtils.php we have:

if ( $type === 'sqlite' ) {
        if ( $wgCargoDBfilePath !== null ) {
                $params['dbFilePath'] = $wgCargoDBfilePath;
        } else {
                $params['dbFilePath'] = $dbr->getDbFilePath();
        }
}
[...]
self::$CargoDB = $services->getDatabaseFactory()->create( $wgCargoDBtype, $params );
return self::$CargoDB;

but getDbFilePath() returns file's path (not only the parent directory), so the call to getDatabaseFactory()->create() returns the main DB, ignoring $wgCargoDBname from LocalSetting.php

If you allow me, I can update the docs accordingly (and warn about the remaining issue below, maybe?).

That being done, we are left with the hanging issue when Cargo shares MW's main DB file. CacahueteNC (talk) 14:55, 8 May 2025 (UTC)

It's great that you fixed that problem! Yes, feel free to update the docs - I'm still not sure what the issue you saw was, but hopefully your edit will make it clearer for me as well.

As for the hanging issue - that's certainly a major problem, but the obvious question is: does using the separate SQLite DB make this any better? Yaron Koren (talk) 16:30, 9 May 2025 (UTC)

Thanks for accepting my contribution to the docs.

Yes, using a separate SQLite DB works better. Haven't tried all features (like temporary tables when changing the #cargo_declare) but so far so good: able to create and populate tables, no hang times whatsoever. CacahueteNC (talk) 16:59, 9 May 2025 (UTC)

Shall I switch over to an issue tracker like Phabricator for the follow-up? CacahueteNC (talk) 17:02, 9 May 2025 (UTC)

Error adding SQL functions

Hey, this extension is supremely useful, praise to everyone who worked on it.

My issue is I can't seem to add the sql functions TO_NUMBER, CAST and CONVERT to use during query. I tried to add them in LocalSettings.php following the given syntax :

$wgCargoAllowedSQLFunctions[] = 'CONVERT';

But I get the classic error page saying "FUNCTION WikiName_mediawiki.CONVERT does not exist", same with CAST and TO_NUMBER. Is there some other requirement to adding SQL functions that I'm missing ? Franck Frost (talk) 10:22, 8 March 2025 (UTC)

I don't think I've ever seen that error message - is that literally the string you see? Do you see the same error message if you don't include that line in LocalSettings.php? Yaron Koren (talk) 19:48, 10 March 2025 (UTC)

Still getting frequent dupes.

I'm not sure why this is happening still, we're still getting frequent dupes on the wiki and I can't seem to find the origin for them at all.

The JobQueue is not running async because I know that has caused it in the past.

I lazily patched Cargo a bit to log a bit more because this has been happening a while, not sure if this is helpful though. https://gist.github.com/gyaru/34d2499974632290374ca896904d19ac

We're running Cargo 3.7.1, mw 1.43.0.

Gyarujk (talk) 20:45, 24 March 2025 (UTC)

from what I can see from the logs is that it might be triggered by mediawikis post save rendering pipeline:

  LintUpdate.php line 86 calls MediaWiki\Page\ParserOutputAccess->getParserOutput()

  MediaWikiEntryPoint.php line 674 calls MediaWiki\Deferred\DeferredUpdates::doUpdates() Gyarujk (talk) 21:12, 24 March 2025 (UTC)

Cargo querying issue, not returning what is expected.

Hello All,

I have been using Semantic MediaWiki for a number of years, but it can't seem to perform a requirement I have so thought I'd try Cargo (after seeking adice from GitHub's copilot), but I am still running into an issue.

What I'm trying to achieve is to create an asset management tool, I have a form that populates the component of an asset, there will be multiple components that will make up an asset. What I want it to do is manage the configuration management, when a component is updated the person doing the maintenance will update the component to state the modifcation has taken place. This could also be used for maintenance of systems as well.

When the maintainer updates the component this would automatically pull through to the overall asset that details which is the current modification status and when the next modification date is set.

I have three templates that make up the component:

Template:Component information top

With the code:

<noinclude>
{{#cargo_declare:_table=AssetDetail
|Asset=Page
|License=Wikitext
}}
</noinclude>
{{#cargo_store:_table=AssetDetail
|Asset={{{Asset|No asset set}}}
|License=[{{{License link|https://domain/waas/index.php?title=No_license_link_provided}}} {{{License|No license text set}}}]
}}
[[Category:Asset components]]
[[Category:{{{Asset|No asset set}}}]]
{{#default_form:Component management}}

This page was last updated on [[Last updated::{{REVISIONDAY}}/{{REVISIONMONTH}}/{{REVISIONYEAR}}]] by [[Last edited by::{{REVISIONUSER}}]].

This component is for the '''[[Admin:{{{Asset|No asset set}}}|{{{Asset|No asset set}}}]]''' asset.<br>

'''License:'''<br>

[{{{License link|https://domain/waas/index.php?title=No_license_link_provided}}} {{{License|No license text set}}}] <br>

'''Description:'''<br>

{{{Component description|No description set}}}

{| class="wikitable"
! Component
! Current version
! Next version
! Component last updated
! Component next update scheduled
! Is this the current install version?
! Is this the next version?
|-

Template:Component information body With the code:

<noinclude>
{{#cargo_declare:_table=ComponentInfo
|Component=Wikitext
|CurrentVersion=Text
|NextVersion=Text
|ComponentLastUpdated=Date
|ComponentNextUpdateScheduled=Date
|LatestVersion=Boolean
|NextVersion=Boolean
}}
</noinclude>

{{#cargo_store:_table=ComponentInfo
|Component=[[{{FULLPAGENAME}}|{{PAGENAME}}]]
|CurrentVersion={{{Current version|No version set}}}
|NextVersion={{{Next version|No next version set}}}
|ComponentLastUpdated={{{Component last updated|Last updated set}}}
|ComponentNextUpdateScheduled={{{Component next update scheduled|Next update scheduled set}}}
|LatestVersion={{{LatestVersion|Yes}}}
|NextVersion={{{LatestNextVersion|No}}}
}}
| [{{{Component extension link|https://domain/waas/index.php?title=No_license_link_provided}}} {{PAGENAME}}]
| {{{CurrentVersion|No version set}}}
| {{{NextVersion|No next version set}}}
| {{{ComponentLastUpdated|Last updated set}}}
| {{{ComponentNextUpdateScheduled|Next update scheduled set}}}
|{{#switch:
{{{LatestVersion|}}}
|Yes=<div style="background-color:#d4edda; color:#000; text-align: center;">Yes</div>
|No=<div style="background-color:#ab000e ; color:#fff; text-align: center;">No</div>
|#default= <div style="background-color:#ab000e ; color:#fff; text-align: center;">No</div>
}}
|{{#switch:
{{{LatestNextVersion|}}}
|Yes=<div style="background-color:#d4edda; color:#000; text-align: center;">Yes</div>
|No=<div style="background-color:#ab000e ; color:#fff; text-align: center;">No</div>
|#default= <div style="background-color:#ab000e ; color:#fff; text-align: center;">No</div>
}}
|-

ending with the template: Template:Standard table end

|}

The form is Form:Component management, should note, the form field isn't showing at the moment. There are other issues with I am working with the supplier with. The second part of this is the asset managment, the Template:Asset management has the following code:

<noinclude>
{{#cargo_declare:_table=AssetInfo
|Asset=Text
|AssetDescription=Text
|LastUpdated=Date
|LastEditedBy=Text
}}
</noinclude>
{{#cargo_store:_table=AssetInfo
|Asset={{PAGENAME}}
|AssetDescription={{{Asset description|Asset description not set.}}}
|LastUpdated={{REVISIONDAY}}/{{REVISIONMONTH}}/{{REVISIONYEAR}}
|LastEditedBy={{REVISIONUSER}}
}}
This page was last updated on [[Last updated::{{REVISIONDAY}}/{{REVISIONMONTH}}/{{REVISIONYEAR}}]] by [[Last edited by::{{REVISIONUSER}}]].

'''Asset:''' [[Asset::{{{Asset|No asset set}}}]]

==Asset description==
{{{Asset description|Asset description not set.}}}

==Asset components==
===Current version===
{{#cargo_query:
    tables=ComponentInfo=CI, AssetDetail=AD
    |join on=CI.LatestVersion=AD.Asset
    |fields=CI.Component, CI.CurrentVersion, CI.LatestVersion, CI.ComponentLastUpdated, CI.ComponentNextUpdateScheduled, AD.License
    |where=AD.Asset="{{PAGENAME}}" AND CI.LatestVersion="Yes"
    |format=wikitable
    |order by=CI.ComponentLastUpdated
    |limit=100
}}

===Next version===
{{#cargo_query:
    tables=ComponentInfo=CI, AssetDetail=AD
    |join on=CI.LatestVersion=AD.Asset
    |fields=CI.Component, CI.CurrentVersion, CI.NextVersion, CI.ComponentLastUpdated, CI.ComponentNextUpdateScheduled, AD.License
    |where=AD.Asset="{{PAGENAME}}" AND CI.NextVersion="Yes" <> "Template:Component information body"
    |format=wikitable
    |order by=CI.ComponentNextUpdateScheduled
    |limit=100
}}


[[Category:Asset management]]
[[Category:{{PAGENAME}}]]
{{#default_form:Asset management}}

[[Category:Asset management]]
[[Category:{{PAGENAME}}]]
{{#default_form:Asset management}}

With the form Form:Asset management

<noinclude>

This is the "Asset management" form.

To create a page with this form, enter the page name below; if a page with that name already exists, you will be sent to a form to edit that page.

<div style="background-color:#ff0000; color:#fff;">'''Please note this form does not work with Internet Exporer.'''</div>

{{#forminput:form=Asset management|query string=namespace=Admin}}

</noinclude><includeonly>

<div id="wikiPreview" style="display: none; padding-bottom: 25px; margin-bottom: 25px; border-bottom: 1px solid #AAAAAA;"></div>

{{{for template|Asset management}}}

{| class="formtable" style="width: 95%"
! Asset name:
|-
| {{{field|Asset|input type=text}}}
|-
! Asset description:
|-
| {{{field|Asset description|input type=textarea|editor=visualeditor|rows=15}}}
|}
{{{end template}}}

'''Further information:'''<br>
{{{standard input|free text|rows=10|editor=visualeditor}}}


</includeonly>

But rather than showing me the row that has been delcared as being the current version it shows me the toprow which isn't the current version. Is what I'm trying to achieve possible? If it is possible, have you any pointers as to what I'm doing wrong? Squeak24 (talk) 08:45, 2 April 2025 (UTC)

I'm glad Copilot recommended Cargo! For the question - are you talking about the query that includes the fields "CI.CurrentVersion, CI.LatestVersion"? If so, isn't it showing both?

As a side note, the part of the form that says "Please note this form does not work with Internet Exporer" looks strange - no one uses IE any more. (I would have guessed that this was AI-generated, but AI probably wouldn't make that spelling mistake - maybe it's a copy/paste from an old form.) Yaron Koren (talk) 14:11, 2 April 2025 (UTC)

Duplicates of doublets

Previously, tables were not duplicated, I have a template {{Contains}}. And on the item page, for example, chest, I called the template

• {{Contains|Apple}}
• {{Contains|Banana}}
• {{Contains|name}}
• {{Contains|name}}
• etc

And one table was created, but now I noticed that they are duplicated

• *1 Values ​​​​"_pageData"
• 2 Values ​​​​"Items"
• 3 Values ​​​​"Contains"
• 4 Values ​​​​"Contains" duplicate
• 4 Values ​​​​"Contains" duplicate
• 4 Values ​​​​"Contains" duplicate

<includeonly>{{item icon|{{{1}}}|{{{2|}}}}}{{#ifeq: {{NAMESPACENUMBER}} | 0 |
{{#cargo_store:_table=Contains
| name          = {{#replace:{{PAGENAME}}|'|\'}}
| contains_item = {{{1|}}}
| quantity      = {{{quantity|}}}
}} }}<!--

--></includeonly><noinclude>
<noinclude>{{#cargo_declare:_table=Contains
| name          = String
| contains_item = String
| quantity      = String
}}

Thanks for the answer ~~ Oleksii 94.153.7.234 20:08, 5 April 2025 (UTC)

Is it possible to update existing orders in the table? for example, to add items via (,)

name = Chest, contains_item = name, name, name

~~ Oleksii 94.153.7.234 20:12, 5 April 2025 (UTC)

Sorry, I'm not sure I understand either question. What do _pageData and Items have to do with it? What exactly is being duplicated? And what do you mean by "update existing orders"? (You can obviously update data by editing any page containing data.) Yaron Koren (talk) 04:39, 6 April 2025 (UTC)

here are the duplicate tables neverwinter.fandom.com/ru/wiki/Набор эпических ошейников на выбор?action=pagevalues pagevalues and this is a template neverwinter.fandom.com/ru/wiki/Template:Содержит

I think the problem is that I call the template 15 times together with cargo_store, fandom updated the wiki to 1.43, and now this template does not work as before.

Previously, it saved to the Contains table only 1 time

"Contains" values

2 rows are stored for this page

and now "Contains" values ​​are duplicated

"Contains" values

2 rows are stored for this page

"Contains" values

2 rows are stored for this page

~~ Oleksii 46.211.140.58 05:56, 6 April 2025 (UTC)

Okay, now I understand - you were describing the text at this URL. It sounds like there's a duplicate row in either the cargo_tables or the cargo_pages DB table - probably cargo_pages, since it doesn't seem to happen for every page that has a row in the table. If/when this happens, I assume just recreating the table would make the problem go away... have you tried that? Yaron Koren (talk) 17:18, 6 April 2025 (UTC)

There are no duplicates on the other pages because I haven't updated them yet. If I make a null edit there, the duplicates will appear too.

I created a new template and a new table, but there are still duplicates on the PageValues ​​page, even though there are no duplicates in the actual table — everything displays correctly there. These duplicates don't affect the functionality — items on the pages display correctly without any duplicates.

Sorry if it's very confusing. ~~Oleksii 46.211.107.149 13:45, 7 April 2025 (UTC)

CargoQuery with more results than Limit

Hi, currently encountered a strange behavior or problem while using Cargo Query. On any table I tried filter with the where clause like table.field='String' (of course with existing tables and fields and strings) I get with the first query perfect results although the query string escapes the = like &where=table.field%3D'String'& and in wikitext |where=table.field='String'. Same in fields (escapes = and ,) &fields=table._pageName%3DName%2Ctable.field%2Ctable.fieldb%2C.

If I go for the next or previous the query still works but it already altered and escapes the ' like &where=table.field%3D%26%23039%3BString%26%23039%3B& or in the wikitext output |where=table.field=&# 039;String&# 039; (need to add a space by hand &# 039;).

And of course going one more back or forth breaks with Error in "where" parameter: the string "#" cannot be used within #cargo_query. because the # that escaped in is causing a problem. If I alter the where statement by hand back to 'String' it works of course again.

Currently on MediaWiki 1.43.1 (e3c2412) and Cargo 3.8 (b6cc262).

Thanks alot! Brabi81 (talk) 07:01, 28 April 2025 (UTC)

Sorry about the problem, and thanks for reporting it! This bug had apparently been there for about six months. I just checked in what I think is a fix for it, here. Yaron Koren (talk) 23:22, 29 April 2025 (UTC)

Works perfect! Noticed only now, because slow but steady the Cargo tables are growing. Brabi81 (talk) 05:16, 30 April 2025 (UTC)

Querying data from an extension

Hi there, I'm just starting out with Cargo for the first time. I'm thinking of writing an extension that uses Cargo. Basically my use case is this: some files on my wiki have some Cargo data associated with it. I want to write an extension with a special page that takes a file as argument, and the page then displays the custom data in a specific way (and does some data wrangling, constructs custom HTML based on the data, and so on). I've figured out, at the very least, that I can do custom queries this way:

$cdb = CargoUtils::getDB();
$res = $cdb->select(
  'my_table',
  ['my_data'],
  ['file' => $filename],
);
if ($row = $res->fetchRow()) {
  var_dump($row); // my_data and so on
}

What I'm wondering is, is this the proper way to do it, and is there some documentation for it? I'm pretty new to making MediaWiki extensions as well as to Cargo so any thoughts from someone with experience would be appreciated. If anyone knows extensions others have made that do this, I'd like to know about it so I can look at their code. Thanks! Dada78641 (talk) 15:40, 5 May 2025 (UTC)

I don't think there's any documentation for running Cargo queries from PHP - and I don't know of any other extensions that use Cargo data - but that does look like the right way to do it. I hope you can get it working! Yaron Koren (talk) 20:07, 5 May 2025 (UTC)

Where does the pagination section of the table need to be able to be translated into other languages?

I want to know where the paginated section of the footer of the table for the query needs to be able to be translated into other languages. If not, is there any alternative way to translate into other languages, thank you. Showing 1 to 5 of 45 entries Previous12345…9Next 公子猫 (talk) 17:22, 8 May 2025 (UTC)

I assume you're talking about the "dynamic table" format. That one uses the DataTables JavaScript library, which by default is English-only. There are i18n plugins you can add (basically, a JSON file for each language) to provide language support - I think no one has asked about adding non-English support until now. (The true MediaWiki solution would be to do it through MW's own i18n messages, but that is a lot more work.) It does make sense to add some of these. Yaron Koren (talk) 17:11, 9 May 2025 (UTC)

...cargo_tables_template_id key doesn't exist.

I got this when running MW's update.php today. I guess it's not a problem, as Cargo works all right, but I thought I'd ask here just in case. Thanks. Jonathan3 (talk) 10:34, 25 May 2025 (UTC)

inconsistent output for HOLDS query

I have a table with a column of type list of pages. Some queries against that table provide the expected results, some no results. One difference seems to be that the pages that are not successfully compared with "HOLDS" use Help:Magic_words#DISPLAYTITLE. I made a demo page of he problem. Tenbergen (talk) 21:03, 6 June 2025 (UTC)

We had this issue and it turned out that some magic words are needlessly HTML encoded like the {{PAGENAME}} you have in your non-working Previous_Location field example. Wrapping these in {{#titleparts:{{PAGENAME}}}} fixed the issue in the HOLDS field for us (we run the latest Cargo version and 1.43.1). Hope that helps! FrozenPlum (talk) 17:21, 18 June 2025 (UTC)

Also, some blank results for us came from ' used in titles, which were fixed by changing the Cargo query to use " double quotes, or {{#replace:{{#titleparts:{{PAGENAME}}}}|'|\’}} which also surprisingly worked! FrozenPlum (talk) 17:25, 18 June 2025 (UTC)

Seems your last example is not working because there are no spaces after "Previous Location" in the templates shown in the working version (spaces only appear in the page text itself, which is not stored by the template). The alternative to fix that one, perhaps, is to either remove the space (Cargo takes these literally), or to join on the _pageData table if you want to search the _fullText field (i.e., full text of the page and not just the template values)? FrozenPlum (talk) 17:37, 18 June 2025 (UTC)

Summing the values of a column via SUM() - Resolved

This started as a question (I felt dumb for not getting SUM(fieldname) to work in Cargo to give a column total). Now I resolved it, hopefully this is a time-saver PSA for others.

Putting |fields = SUM(gmax)=total didn't give me a column total gmax rather it just listed every gmax value, as a comma-separated list, and no combination of grouping seemed work either??? (I'm probably missing something obvious, if so please do educate me)!

My query, and its nested |intro= query, to give the gmax column total above the table:

{{#cargo_query: table = Battles
|fields = m=Mine, b=Battle, gph=Gold Per Hour, gmax=Maximum
|where = _pageNamespace="0" AND gmax IS NOT NULL
|group by = _ID
|order by = m ASC
|format = table
|limit = 100
|intro = The Gold capacity of all mines is: {{#expr:{{#cargo_query: table = Battles
  |fields = TRIM(gmax) <!-- needed, removes commas from number values -->
  |where = _pageNamespace="0" AND m IS NOT NULL AND gmax IS NOT NULL
  |group by = _ID <!-- to eliminate duplicates -->
  |format = list
  |delimiter = + <!-- turns the comma-separated into + separated -->
  |template = CargoSum
  |limit=100
  |no html
  }}}}
}}

• The values output by the |intro= subquery, thanks to the + delimiter setting:

100+1000+10000+250

• In Template:CargoSum is the following:

<includeonly>{{#iferror: {{#expr:{{{1|}}}}} | [[Category:Template Parameter Error]]}}</includeonly>

• It wraps the output values in the ParserFunctions {{#expr:}} expression to sum them. Or, it categorizes the page if an error is encountered instead.
  • Manual use of {{CargoSum|100+1000+10000+250}} works also worked as expected.

Yay! I got my desired column total! (It was the TRIM() function I was missing). FrozenPlum (talk) 22:22, 7 June 2025 (UTC)