Extension talk:Cargo

Field names in Page names cause Query Errors

Tracked in Phabricator
Task T232190

We are having the problem that when page titles include words that are the same as field names, they're being misinterpreted (as fieldnames) in queries.

For instance, we have the follow query in a template:

{{#cargo_query:tables=Generic |fields=_pageName, subtitle |where=questions HOLDS '{{PAGENAME}}' |format=ul}}

which, on a page named "What if temporary things become included within art practices?", creates an error...

{{#cargo_query:tables=Generic |fields=_pageName, subtitle |where=questions HOLDS 'What if temporary things become included within art practices?' |format=ul}}

Produces the error: Error: operator for the virtual field 'Generic.things' must be 'HOLDS', 'HOLDS NOT', 'HOLDS LIKE' or 'HOLDS NOT LIKE'.

Because "things" is also a field on the Generic table.

Is this a bug, or something that can be otherwise worked around / avoided. We're thinking of prefixing all the field names to avoid this kind of collision in the future, but it feels a bit awkward. Michael Murtaugh (talk) 13:04, 2 April 2026 (UTC)

This is a bug. I've mentioned it here before. I can't remember whether it's fixed in the latest Cargo code, but I have a patch that gets rid of the error. I can upload that here when I'm on the computer next. Jonathan3 (talk) 14:27, 2 April 2026 (UTC)

Oh great, many thanks ! Michael and I are working together. I looked into the talk pages and was surprised that no one had the same issue, happy to see that I just missed it ! About the latest code, we just upgraded to Cargo 3.9, hoping to fix it, but it didn't. Amahiant (talk) 14:42, 2 April 2026 (UTC)

Cool. Unindenting as it'll help syntaxhighlight. I found the old topic: Extension_talk:Cargo/Archive_October_to_December_2024#Problem_when_field_value_contains_one_of_the_"List"_field_names. I also remembered that it only is a problem for names of "List of" fields.

Here is the patch. In includes/CargoSQLQuery.php at line 987 replace

if ( preg_match( $patternSimple[$i], $this->mWhereStr ) ) {

with this:

# Don't want to risk matching a value that is also the field name
# So remove value from comparison string 
if (preg_match('~(?:`_value`|_pageName)\s*=\s*[\'"](.*?)[\'"]~', $this->mWhereStr, $matches) ){
	$temp = str_replace($matches[1], '', $this->mWhereStr);
}
if ( preg_match( $patternSimple[$i], $temp ) ) {

There are probably better ways of doing it but I can just about "order a beer" in PHP regex. I've not noticed any unintended consequences over the past few months. Jonathan3 (talk) 20:41, 2 April 2026 (UTC)

@Michael Murtaugh @Amahiant Did it work all right? Jonathan3 (talk) 00:27, 9 April 2026 (UTC)

Yes!!! Thank you so much. Sorry for the late answer, I had a new bug and thought it was linked somehow ... but it's not :-) Amahiant (talk) 13:21, 13 April 2026 (UTC)

I think my code just gets rid of the error message but doesn't really work properly (for example, $temp might never get set). I've suggested a different solution on Phabricator. Jonathan3 (talk) 10:09, 9 July 2026 (UTC)

Best practice for storing sorting values for an on-going, always changing thing?

To give it a little bit of context here: what I'm doing with is a wiki for a player community which records in-game and community stuff.

Players are indexing and organizing in-game railways and numbering them. The issue is that when trying to sort these railways, as they are stored in strings, we get "10" after "1" (a common issue when sorting via string).

The basic format for this is "Line System + Line number", for example "XXXX Line 9" However, we cannot just switch to numericals since there are multiple naming and numbering formats for all these railways (as they are constructed by different groups of player. For example, some systems prefer using A-Z (XXXX Line B), and some using S1-S3 (XXXX Line S2), so on and so forth).

Editors maintaining this area quickly came up the workaround idea of storing sorting values inside the Cargo table, which I instantly rejected. But the best practice storing of these values in a seperate table is obviously not a good idea because you don't know when someone will build a new system with their own naming conventions, and maintaining it would be a complete mess. To my understading, this method is only good when a system does not change or evolve that often.

I'd like to get some idea on how others' would deal with this situation. I suspect that there will not be an easy solution and all methods will have some trade-offs, the goal is to find a better solution rather than a best one. BCMonomial (talk) 15:45, 4 April 2026 (UTC)

For now what comes to my mind is, nonetheless, storing these values in the same table. Since the sorting will always go "system first, line number second", no one would actually only sort the line number globally (which does not make sense anyway), and the sorting rules are decided by the constructors themselves, which makes a fairly okay situation to do so without too much hassle. BCMonomial (talk) 15:52, 4 April 2026 (UTC)

I certainly understand issues around sorting, although I didn't understand that specific example, of "10" going after "1". Regardless, it seems like storing "line system" and "line number" separately is a good solution. Does that not always result in correct sorting? Yaron Koren (talk) 14:35, 6 April 2026 (UTC)

No it doesn't. Consider that "Line Number" actually has different formats for different systems. For some systems it goes in numericals from 1 to 12 let's say, for other systems the so-called number turned into "A" to "Z", alphabetically. So this "number" field is actually a string. And when you sort it as a string, you get:

• 1
• 10
• 2
• 3
• ...

That's the problem. So the editors solution is to add an invisible sorting value alongside the "line number" column, and sort the sorting values instead of directly sorting the "line number". After some days' thinking I am now also pretty much in favor of this. BCMonomial (talk) 14:40, 6 April 2026 (UTC)

Oh, I get it now - 10 directly after 1. Yes, a separate "order number" field does seem to make sense. Yaron Koren (talk) 14:57, 6 April 2026 (UTC)

Undid edit to manual page

I've removed an edit (and the subsequent translation-related edit) to the manual page because I have a feeling it's wrong, but I'll cut and paste it here in case I'm the one who's wrong.

=== Advanced API exports ===

As of version 3.6 (April 2026), Cargo includes a specialized API endpoint (<code>action=cargoexport</code>) specifically designed for direct integration with external analytics dashboards and business intelligence software.
This allows users to bypass standard wiki formatting and pull structured JSON or CSV data streams in real-time.<ref>
[https://diff.wikimedia.org/2026/04/06/tech-news-2026-week-15/ Tech News 2026, week 15], Wikimedia Diff. Published April 6, 2026.
</ref>

Jonathan3 (talk) 13:46, 22 April 2026 (UTC)

Yes, it was vandalism - thanks. Yaron Koren (talk) 14:32, 22 April 2026 (UTC)

DB error when adding _parentTables

I currently have 2 tables, Streams and Guests, defined with the following:

{{#cargo_declare:_table=Guests|Name=String|Image=File|Twitch=URL|YouTube=URL|Bluesky=URL|X=URL}}

{{#cargo_declare:_table=Streams|_parentTables=Guests(_localField=Guests, _remoteField=_pageID);|Date=Date|Title=String|Guests=List (,) of Integer (hidden)|VODs=List (,) of URL}}

The Guests field is a list of pageIDs for guest pages. I'm doing it this way rather than using the Page type to make things less fragile (From my understanding the Page type just stores the title, which means e.g moving a page will break things).

This all works fine without _parentTable, but when I add it as above in order to filter by guest name on the drilldown page, I get the following DB error:

wiki-1  | 2026-May-10 14:21:07 [mediawiki] ERROR exception: [c94a1f0b909e77b9f0bde2cd] /wiki/Special:Drilldown/Streams   Wikimedia\Rdbms\DBQueryError: Error 1054: Unknown column 'guests.Name' in 'SELECT' 
wiki-1  | Function: CargoFilter::getAllValues 
wiki-1  | Query: SELECT  `guests`.`Name` AS value,COUNT(DISTINCT `Streams_alias`.`_pageID`) AS total  FROM `cargo__Streams` `Streams_alias`     GROUP BY `guests`.`Name`  
wiki-1  |  {"exception":"[object] (Wikimedia\\Rdbms\\DBQueryError(code: 0): Error 1054: Unknown column 'guests.Name' in 'SELECT' 
wiki-1  | Function: CargoFilter::getAllValues 
wiki-1  | Query: SELECT  `guests`.`Name` AS value,COUNT(DISTINCT `Streams_alias`.`_pageID`) AS total  FROM `cargo__Streams` `Streams_alias`     GROUP BY `guests`.`Name`  
wiki-1  |  at /var/www/html/includes/libs/rdbms/database/Database.php:1225) 
wiki-1  | [stacktrace] 
wiki-1  | #0 /var/www/html/includes/libs/rdbms/database/Database.php(1209): Wikimedia\\Rdbms\\Database->getQueryException('Unknown column ...', 1054, 'SELECT  `guests...', 'CargoFilter::ge...') 
wiki-1  | #1 /var/www/html/includes/libs/rdbms/database/Database.php(1183): Wikimedia\\Rdbms\\Database->getQueryExceptionAndLog('Unknown column ...', 1054, 'SELECT  `guests...', 'CargoFilter::ge...') 
wiki-1  | #2 /var/www/html/includes/libs/rdbms/database/Database.php(640): Wikimedia\\Rdbms\\Database->reportQueryError('Unknown column ...', 1054, 'SELECT  `guests...', 'CargoFilter::ge...', false) 
wiki-1  | #3 /var/www/html/includes/libs/rdbms/database/Database.php(1363): Wikimedia\\Rdbms\\Database->query(Object(Wikimedia\\Rdbms\\Query), 'CargoFilter::ge...') 
wiki-1  | #4 /var/www/html/extensions/Cargo/drilldown/CargoFilter.php(342): Wikimedia\\Rdbms\\Database->select(Array, Array, Array, 'CargoFilter::ge...', Array, Array) 
wiki-1  | #5 /var/www/html/extensions/Cargo/drilldown/CargoDrilldownPage.php(1069): CargoFilter->getAllValues(NULL, Array, false, 'Streams_alias', Array, Array) 
wiki-1  | #6 /var/www/html/extensions/Cargo/drilldown/CargoDrilldownPage.php(1341): CargoDrilldownPage->printUnappliedFilterLine(Object(CargoFilter), '/wiki/Special:D...') 
wiki-1  | #7 /var/www/html/includes/specialpage/QueryPage.php(889): CargoDrilldownPage->getPageHeader() 
wiki-1  | #8 /var/www/html/extensions/Cargo/drilldown/CargoSpecialDrilldown.php(276): MediaWiki\\SpecialPage\\QueryPage->execute('Streams') 
wiki-1  | #9 /var/www/html/includes/specialpage/SpecialPage.php(711): CargoSpecialDrilldown->execute('Streams') 
wiki-1  | #10 /var/www/html/includes/specialpage/SpecialPageFactory.php(1729): MediaWiki\\SpecialPage\\SpecialPage->run('Streams') 
wiki-1  | #11 /var/www/html/includes/actions/ActionEntryPoint.php(500): MediaWiki\\SpecialPage\\SpecialPageFactory->executePath('Drilldown/Strea...', Object(MediaWiki\\Context\\RequestContext)) 
wiki-1  | #12 /var/www/html/includes/actions/ActionEntryPoint.php(144): MediaWiki\\Actions\\ActionEntryPoint->performRequest() 
wiki-1  | #13 /var/www/html/includes/MediaWikiEntryPoint.php(184): MediaWiki\\Actions\\ActionEntryPoint->execute() 
wiki-1  | #14 /var/www/html/index.php(44): MediaWiki\\MediaWikiEntryPoint->run() 
wiki-1  | #15 {main} 
wiki-1  | ","exception_url":"/wiki/Special:Drilldown/Streams","reqId":"c94a1f0b909e77b9f0bde2cd","caught_by":"entrypoint"} %exception%

Any ideas what is going wrong here? From the looks of the query it seems Cargo just isn't joining the tables it needs to? Ausernamewhichhasnotbeentaken (talk) 14:25, 10 May 2026 (UTC)

Using the page IDs directly is indeed odd, and may make data entry difficult, but that's probably not the cause of this error. The fact that "guests" is lowercase in the SQL query looks suspicious. Are the two #cargo_declare calls exactly as you've written them above? Yaron Koren (talk) 15:40, 10 May 2026 (UTC)

Yes they are exactly as above. Happy to provide any other info you feel is helpful. Ausernamewhichhasnotbeentaken (talk) 20:08, 10 May 2026 (UTC)

Strange. What versions of MediaWiki and Cargo are you running? Yaron Koren (talk) 22:18, 10 May 2026 (UTC)

Also, that semicolon in the second #cargo_declare call is unnecessary; I doubt that's the cause of the problem, but who knows. Yaron Koren (talk) 22:23, 10 May 2026 (UTC)

Cargo 3.9 (52af7db), MediaWiki 1.45.3.

Tried removing the ; on the offchance but no luck Ausernamewhichhasnotbeentaken (talk) 12:24, 11 May 2026 (UTC)

What's the database type and version? Yaron Koren (talk) 14:05, 11 May 2026 (UTC)

MariaDB 11.8.6. Version page is here if it helps https://wiki.rtgame.co.uk/wiki/Special:Version

Tables are declared in https://wiki.rtgame.co.uk/wiki/Template:CargoDeclare/Guests and https://wiki.rtgame.co.uk/wiki/Template:CargoDeclare/Streams. They might not be exactly the same as above anymore as I've been testing out things. Ausernamewhichhasnotbeentaken (talk) 14:29, 11 May 2026 (UTC)

Okay, everything is as you described. I have no idea why this bug is occurring; my guess is that it's because the table name is getting lowercased in the SQL query, though why that's happening I have no idea.

Since we're already on the subject, let me reiterate that I think using the page IDs directly on the page seems like a bad idea, and you should use the page names instead. If/when you rename a page, you can use the Replace Text extension to rename it everywhere. I doubt this change would solve the drilldown problem, though... who knows. Yaron Koren (talk) 22:22, 11 May 2026 (UTC)

Feature request: Add option to parse wikitext fields in cargoquery API results

When querying a table that contains Wikitext type fields via the cargoquery API action, the raw wikitext is returned as-is without being parsed into HTML. For example, a wikitext field containing

[[Some page]]

or

'''bold'''

is returned as the literal wikitext string rather than the rendered HTML.

This makes it difficult for API consumers (JavaScript frontends in my case) to display formatted content, as they would need to implement their own wikitext parsing. 夕舞八弦 (talk) 08:07, 22 May 2026 (UTC)

3.9.1 zip file link broken

@Yaron Koren: As I type this, the link to the zip file for version 3.9.1 is not working (returns 404). - dcljr (talk) 06:53, 1 June 2026 (UTC)
Note that the link for 3.9 in the page history works, so it's not just a transient error. - dcljr (talk) 07:11, 1 June 2026 (UTC)

Sorry, somehow I never created a 3.9.1 tag! I just did it now, so the link should work. Yaron Koren (talk) 13:39, 1 June 2026 (UTC)

Password reveal

Responding to this revert, this edit was referencing the same problem I warned about here last year. When I first set up my Cargo database (separate from MW's, using cPanel), it was given a random password containing a dollar sign (probably followed by a number, but I can't remember for sure). I had previously set $wgShowExceptionDetails to true while troubleshooting a totally unrelated problem, and had never bothered to turn that off. When I first tried to use the extension, an error was displayed saying the database could not be accessed, and showing the database server, name, user, and (somewhat incomplete) password in the stack trace. The password was showing up incomplete because the dollar sign was being interpreted as referencing an interpolated variable (e.g., $7, or whatever), which, of course, was undefined. I quickly figured out what the problem was and fixed it by creating a new random password. Even though the password was incomplete, showing it at all seems to me to be a pretty big security risk. (Perhaps the same behavior would be observed if one of the other three variable values were wrong, or all were fine but something else caused the database to be inaccessible? The latter possibility is the one I was most concerned about.) - dcljr (talk) 04:12, 11 June 2026 (UTC)

Oh yes, I had forgotten that you had already added that warning to another page. All I can say is that I don't get the same problem. What database type, and version, are you using? Yaron Koren (talk) 15:47, 11 June 2026 (UTC)

I'm using a MariaDB server (11.4.12-MariaDB, although it was probably a different version when the problem actually occurred in September of last year) in a shared hosting environment (Apache web server). The Cargo database was set up under cPanel's "My PHP Databases", most likely using whatever default settings were in play at that time (IOW, I don't know enough to do anything fancy). Is that what you needed? (Also, just FYI, I have found in an error log that the dollar sign in the password was followed by a short string of letters and digits, starting with a letter, so any string of alphanumerics should cause the same problem. The password was double-quoted in LocalSettings.php. I don't know if single-quoting it would have sufficed to fix the problem. I just gave up on it and generated a new password in cPanel.) - dcljr (talk) 00:40, 12 June 2026 (UTC)

Ah, the fact that it's MariaDB is interesting. I'm guessing that you have the "general query log" enabled, based on what I read. Anyway, I just re-added that note, with some different wording. Yaron Koren (talk) 14:44, 12 June 2026 (UTC)

The error log I alluded to is called simply error_log and was placed in MW's install directory. Literally the only thing in the file is two lines showing the same error twice (censored here):

PHP Warning: Undefined variable $eF[...] in /[...]/w/LocalSettings.php on line 369

It's a bit surprising that this is the only thing that has been written to that file in almost 6 years of wiki operation. But whatever. I don't think it has anything to do with the setting you're talking about. - dcljr (talk) 06:46, 13 June 2026 (UTC)

PHP Deprecated message

I am getting the following message in my PHP error log:

PHP Deprecated:  preg_match(): Passing null to parameter #2 ($subject) of type string is deprecated in /home/angelina/public_html/w/extensions/Cargo/includes/parserfunctions/CargoStore.php on line 246

This seems to have started happening on 2026-04-20. I guess my web host's PHP was upgraded on that day, because I didn't upgrade Cargo anywhere near that date. I would have been using version 3.8.5 then. Still happening with the latest version, 3.9.1. Assuming the presence of a null value at that point is not an indication of a more serious problem, I'm thinking you can just add || '' after $fieldValue on that line to fix the issue. Oh, and I just noticed the same kind of errors were occasionally coming from strlen and substr in CargoSQLQuery.php (lines 677, 693, and 697 in version 3.8.5). Haven't seen that since the upgrade to 3.9.1, but that might only be due to chance (over 1300 errors from preg_match but only about 30 from the others). - dcljr (talk) 08:49, 11 June 2026 (UTC)

Thanks for pointing out that problem with preg_match() - I just checked in a fix for it. Yaron Koren (talk) 16:05, 11 June 2026 (UTC)

"Refresh" link not working on Special:CargoTableDiagram

I can see the link text for "Refresh" and other things under tools in the navigation area, but on the CargoTableDiagram the links don't work. Also, on other pages the text changes to underlined on hover to indicate a link, but on CargoTableDiagram it doesn't. If I add &action=purge to the end of the URL, refresh works. Tenbergen (talk) 14:01, 25 June 2026 (UTC)

If you're seeing a link for "Refresh", that's coming from Semantic MediaWiki, I think, not Cargo - Cargo calls its corresponding link "Purge cache". Although there shouldn't be a "Refresh" (or "Purge cache") link for special pages, because "action=purge" has no effect on special pages, as far as I know. (They are not cached.) So that sounds like a bug in SMW. What change do you see after you add that to the URL? Yaron Koren (talk) 14:45, 25 June 2026 (UTC)

Feature request: a link to the defining template on Special:CargoTables/...

Since the tables are defined in templates, it would be useful to be able to get to the defining template form the table page. There is a "breadcrumb"-ish link at the top but it always wants to return to "Cargo tables", even if one arrived on the table page from a template page. I played with the user interface elements a bit by adding &uselang=qqx to the URL, but the template name would need to be exposed as a parameter, and doesn't seem to be for any of the elements. Tenbergen (talk) 14:01, 25 June 2026 (UTC)

Good idea - I just added this in. Yaron Koren (talk) 17:05, 25 June 2026 (UTC)

[SOLVED] Gallery/slideshow display formats won't show image with apostrophe in filename

Tracked in Phabricator
Task T431513
Resolved

Any ideas? Thanks. Jonathan3 (talk) 11:38, 2 July 2026 (UTC)

It tries to use %26#039; in the URL instead of '. Jonathan3 (talk) 13:55, 3 July 2026 (UTC)

Fixed (see Phabricator). Thanks. Jonathan3 (talk) 10:05, 9 July 2026 (UTC)

format=template passes HTML-encoded data to the template

When using format=template, data is encoded at the start (during CargoSQLQuery::run()) but not decoded, unless it is from a "Wikitext" or "Wikitext string" field. For example, a template that passes this input to a Lua module to do table lookups will result in mismatch because ' (apostrophe) is not the same as ' (HTML-encoded apostrophe).

This behaviour is not explained anywhere in the docs. BryghtShadow (talk) 02:26, 12 July 2026 (UTC)

Removing link cargo data in the side menu

Dear ∀,
Is there a way to remove the cargo data link from the side menu?
Thank you in advance.
Yours, Ciciban (talk) 09:50, 31 July 2026 (UTC)

Probably the easiest way to do it is via CSS, by adding a few lines to MediaWiki:Common.css (presumably including "display: none"). Yaron Koren (talk) 13:42, 31 July 2026 (UTC)