Extension talk:Cargo/Archive January to March 2025

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)