Extension talk:Cargo

Archives
January to May 2015 June to October 2015 November to December 2015 January to March 2016 April to June 2016 July to October 2016 November to December 2016 January to February 2017 March to July 2017 August to September 2017 October to December 2017 January to February 2018 March to May 2018 June to July 2018 August to September 2018 October to December 2018 January 2019 February to March 2019 April to July 2019 August to October 2019 November to December 2019 January to February 2020 March to April 2020 May to July 2020 August to December 2020 January to April 2021 May to June 2021 July to October 2021 November to December 2021 January to May 2022 June to August 2022 September to December 2022 January to April 2023 May to July 2023 August to December 2023 January to March 2024

I have a _parentTables statement that looks similar to:

|_parentTables=Location (_remoteField=locationCustomerID, _localField=_pageID, _alias=Locations)

I get the following error: Error: Invalid field name "_pageID" specified for _localField. This is also true for _pageTitle, _pageNamespace, and _ID. Same results if I try the _remoteField param instead of _localField. _pageName works fine, as well as any other fields declared in the table. Is this a bug? Am I missing something?Yahoobecause (talk) 13:27, 9 July 2024 (UTC)Reply

Here's my Cargo query:

{{#cargo_compound_query:
tables=Site1;fields=site1Name,site1Date;
|tables=Site2;fields=site2Name,site2Date;
|format=calendar}}

When the query runs, I get a series of the following messages (seems like 2-3 per row retrieved):

Deprecated: urlencode(): Passing null to parameter #1 ($string) of type string is deprecated in /var/www/html/includes/GlobalFunctions.php on line 361

This issue has been persistent since I created a clean install of MediaWiki with minimal extensions enabled. Here's my config:

Product	Version
MediaWiki	1.41.1
PHP	8.1.28 (apache2handler)
ICU	72.1
MariaDB	11.3.2-MariaDB-1:11.3.2+maria~ubu2204
Lua	5.1.5
Pygments	2.16.1
Page Forms	5.7.2
Cargo	3.5.1 (c6c8867) 07:28, April 23, 2024

I can reproduce this error on any page the query is executed on by adding ?action=purge to the end of the URL. The error isn't generated if I remove the second query/lookup. Is there a way to suppress this error or fix it? Yahoobecause (talk) 18:14, 21 June 2024 (UTC)Reply

Could you print out the full error message, not just the first line of it (assuming there's more to it than that)? Yaron Koren (talk) 18:32, 21 June 2024 (UTC)Reply

That's the entire message. It repeats itself several times, depending on how many rows are returned in the query. Yahoobecause (talk) 18:39, 21 June 2024 (UTC)Reply

That's unfortunate... that error message is coming from the global function wfArrayToCgi(),but Cargo doesn't call that function directly; so there must be at least one intermediate MediaWiki function in there. Which may make it hard to isolate the problem. Yaron Koren (talk) 20:26, 21 June 2024 (UTC)Reply

Thanks for checking this out, Yaron. And thanks for all the tools you've made for the community. Yahoobecause (talk) 20:23, 26 June 2024 (UTC)Reply

If anyone is looking for an immediate solution, adding this to LocalSettings.php worked for me:

error_reporting(0);

Use at your own risk. Yahoobecause (talk) 20:22, 26 June 2024 (UTC)Reply

Here's an example of what I'm trying to track:

Example Table

Site	Wash Windows	Vacuum Carpet	Empty Garbage
12 Main St	June 4, 2024	June 8, 2024	June 15, 2024
34 Second St	March 23, 2024	March 4, 2024	May 12, 2024
...	...	...	...
89 South Blvd	May 5, 2024	June 23, 2024	April 15, 2024

The issue I'm running into is how to store the field label in addition to the field ID. Cargo doesn't allow me to store a field ID of "Wash Windows" because it has a space in it, so I would have to name it something like "Wash_Windows", which doesn't present well to the end user. I could use a #switch function to do a find/replace, but if I need to update dozens of pages, or if I use the field in multiple queries on the same page, it turns into a lot of work and chances to miss something if I ever need to change the field ID or label. If I create a table with field IDs like "Wash_Windows_label" and "Wash_Windows_date", then I'm storing the label of "Wash Windows" for every row (waste of DB space), and still having to figure out how to dynamically update all of the rows if I ever need to change the label. Another option is to create a lookup table and query the label name for each row ID when I need it. This just seems a bit clunky and inefficient. Is this my best option? Yahoobecause (talk) 17:54, 21 June 2024 (UTC)Reply

I solved this by using an intermediate lookup table with a #switch statement. Here's a lookup table example:

{{#switch: {{{1}}}|Wash_Windows = Wash Windows|Vacuum_Carpet = Vacuum Carpet|...|#default = {{{1}}}

When I need to reference the value, I use {{{Wash_Windows}}} and when I need to reference the human-friendly label, I can use {{Lookup Table Template|Wash_Windows}}. Yahoobecause (talk) 20:46, 26 June 2024 (UTC)Reply

Just to clarify, if you query a field called "Wash_Windows", the underscores will automatically be turned into spaces in the display, so it will appear by default as "Wash Windows". I don't know if that affects what you're talking about here. Yaron Koren (talk) 23:30, 26 June 2024 (UTC)Reply

Bad choice on my part. Almost any other example would have been better (ex: WindowsWashed). Yahoobecause (talk) 13:30, 9 July 2024 (UTC)Reply

In my wiki, to create a new page, you call the template for a new page with subst: first, so a basic page structure is inserted into the new page. I am now including a call to a cargo template with this basic structure template. Since all page names are structured the same way (street name street number (town), e.g. Main street 234 (Footown)), I would like to use the page name to prepopulate the fields street name, street number, and town. Since we are creating new pages not by form, but by red links or searches, the default parameter does not work. So, I am trying to set these values in the structure template. I can include the magic word {{PAGENAME}}, but once I use parser functions like #sub and #pos to select just the street name, the street number, and the town name, I get an error. Within the structure template my call looks like this:

{{cargotemplate
|street=''combination of #sub, #pos, and {{PAGENAME}}''
|street number=''combination of #sub, #pos, and {{PAGENAME}}''
|town=''combination of #sub, #pos, and {{PAGENAME}}''}}

Is a "prepopulation" like this possible? How would I do it? Sorry if this has been asked before. Dumpstar (talk) 15:58, 2 April 2024 (UTC)Reply

Is this a Cargo question? It sounds like just a core MediaWiki question. Yaron Koren (talk) 17:33, 2 April 2024 (UTC)Reply

Should string parser functions like #sub and #pos work as value inputs for a field in a Cargo template? Dumpstar (talk) 17:42, 2 April 2024 (UTC)Reply

I personally wouldn't use the term "Cargo template", but yes, I think so. Presumably the fact that you're using subst: complicates things, but that's not a Cargo issue. Yaron Koren (talk) 17:46, 2 April 2024 (UTC)Reply

I have a cargo query that does some math on the returned column value. When using the CEIL function, it appears that the returned number is formatted as a string and suddenly has commas in it. for example:

 {{#cargo_query:
 table=Prices
 |fields=IF(Price<0,0,Price)*1000
 |where=Item='apples' 
 |format=list
 |more results text=
 |no html
 |default=0
 }}

A query like this will return a value like 1234.56

But, if I want to round this up to the nearest whole number and change the fields parameter to:

 fields=CEIL(IF(Price<0,0,Price)*1000)

Now, I get a number back like 1,235

I need that comma to not be there. Any clues why this is happening and how to stop it? I have tested this with MySQL database and the number returned from a CEIL operation does not have a comma, so I am thinking Cargo may be adding it somehow.

My current work around is to use the #expr: ceil() parser function, but this complicates the code and makes it harder to maintain.

Why is the comma a problem? because this gets sent to another template that does more math on the value. AllenKll (talk) 19:17, 10 April 2024 (UTC)Reply

Right, Cargo views CEIL() as returning an integer, and then formats it accordingly. I think you can get around that by putting CONCAT( ) around the whole thing. Yaron Koren (talk) 19:30, 10 April 2024 (UTC)Reply

That worked. Seems hacky, but it's better than nothing. Thanks. AllenKll (talk) 19:55, 10 April 2024 (UTC)Reply

Great! I agree. Yaron Koren (talk) 20:41, 10 April 2024 (UTC)Reply

Is it possible to use the result of one cargo query as an input to another query? In my mind, it would look something like this:

{{#cargo_query: table = Books
|fields = _pageName
|where = Author = '{{#cargo_query: tables = Books|fields = Author|where = _pageName='{{PAGENAME}}'}}'
}}

but using that format produces Error in "where" parameter: the string "--" cannot be used within #cargo_query.

Perhaps there is a better way of doing this that I'm just not thinking of. Penguinaut 22 (talk) 19:26, 14 April 2024 (UTC)Reply

I'm not surprised that that doesn't work, although I don't why it's giving that specific error message. Anyway, depending on what exact query you're trying to do, it might be possible to just do it via a "join". The second best option, I would say, is to move this query into a Lua module (if you have the Scribunto extension), and then store the first query's result in a variable, which you pass to the second query. Another option is to use the "template" format for the inner/first query, and then put the outer/second query into that "formatting" template. Yaron Koren (talk) 13:05, 15 April 2024 (UTC)Reply

Hmmm yes I didn't think of using the template format. That worked like a charm, thanks! Penguinaut 22 (talk) 02:03, 16 April 2024 (UTC)Reply

Is there any way to get Cargo to output a result in wikitext format? DPL3 can, for example using debug=5.

Use cases:

• One-time (or expensive) query output whose result can be converted instead to wikitext.
• Data that changes very infrequently, not warranting live query to repeatedly cache.
• Swapping to wikitext, so data is still displayed while moving, renaming, or changing tables or columns, or especially migrating wiki locations, say if Cargo is not supported on a different wiki platform. Or converting key items (like main page queries) to wikitext if Cargo needs to be temporarily disabled.
• For instant troubleshooting of Cargo interaction with template format, particularly when templates are used for formatting within templates, and queries within queries.

We largely use template format, with table headers in intro/outro, and <pre></pre> in |intro= and |outro= doesn't work, for obvious reasons. Next I'll try doing these tags in header, footer, and formatting template...-- that didn't work ofc (the values never got carried to the rows). Though setting |template = <pre>Template-CargoRow</pre> got us part of the way, thankfully carrying the values to the rows and outputting that as wikitext.

It just feels like Cargo, which works with wikitext input, should ideally be able to output to (pre-tag escaped) wikitext, on MediaWiki. A wikitext output format would be hugely appreciated, and solve several issues for us and perhaps for other users. Thanks!

FrozenPlum (talk) 00:05, 18 April 2024 (UTC)Reply

I changed a couple of fields' labels in a template, but one of them cannot be processed and still shows the past title. What might cause this issue? Saving the template again and recreating the table doesn't help. 83.27.55.123 13:01, 24 April 2024 (UTC)Reply

A number of things could cause this... is your MediaWiki job queue empty, or how many jobs are in the queue? Your question may be impossible to answer without more information, or a link to your wiki's relevant pages. Normally provided/expected information:

• MediaWiki, Cargo, and php versions, which you can get from your wiki's Special:Version page.
• The template wikitext.
• The page wikitext.

FrozenPlum (talk) 19:10, 24 April 2024 (UTC)Reply

Hello. Any idea to implement PivotTable in Cargo?

Pivot table would be a very useful tools to calculate, summarize, and analyze data, by convert row data to column.

Since MySQL has no PIVOT keyword, I tried other solutions using customs SQL function, but still no successful.

The nearest solution for Pivot Table in Mediawiki is I found is Semantic OLAP, which is for Sematic extension, and also unmaintained. This extension also use orbs Javascript library, which has no update since 2015.

Duyhungwiki (talk) 11:44, 3 June 2024 (UTC)Reply

Can't you get a lot of this functionality just via Special:Drilldown? If not, what specifically do you want to be able to do? Yaron Koren (talk) 14:38, 3 June 2024 (UTC)Reply

Thanks for your reply. Special:Drilldown is only for browser the data. While I'm trying to query the data and display on page. My usage case is like below:

1/ My Cargo table is have data like this:

Name	Food	Emotion
Anna	Banana	Love
Anna	Cream	Like
Anna	Egg	Hate
Bob	Cream	Like
Charlie	Cream	Hate
Charlie	Milk	Hate
Diana	Egg	Like

2/ Then I will Query the data to have another table like this:

	Banana	Cream	Milk	Egg
Anna	Love	Like		Hate
Bob		Like
Chalie		Hate	Hate
Diana				Like

|} Duyhungwiki (talk) 11:50, 14 June 2024 (UTC)Reply

Okay, thanks for the very helpful explanation. I knew about this concept, but didn't realize that this was called a "pivot table". I remember having a conversation a long time ago about creating such a result format - actually, back then it was in the context of Semantic MediaWiki. It would be great to have, but I personally don't have plans to add such a thing. For the moment, I think the only way this could be done is via a Lua module. Yaron Koren (talk) 18:46, 14 June 2024 (UTC)Reply

Hello @Yaron Koren .Just want to update that I did query successful, with no need for Lua module. May not be optimal, but get the job done for me.

This usage case, I already know the list of foods, so it's possible to hard code it into the query.

{{#cargo_query:
tables=Emotion
|fields=CONCAT('[[', Emotion.People, ']]') = People,
GROUP_CONCAT(CASE WHEN Emotion.FoodName = 'Banana' THEN Emotion.EmotionName END) = Banana, 
GROUP_CONCAT(CASE WHEN Emotion.FoodName = 'Cream' THEN Emotion1.EmotionName END) = Cream, 
GROUP_CONCAT(CASE WHEN Emotion.FoodName = 'Milk' THEN Emotion.EmotionName END) = Milk, 
GROUP_CONCAT(CASE WHEN Emotion.FoodName = 'Egg' THEN Emotion.EmotionName END) = Egg
|group by=Emotion.People
|format=table}}

Duyhungwiki (talk) 16:10, 19 June 2024 (UTC)Reply

Nice! Impressive use of SQL. Yaron Koren (talk) 19:04, 19 June 2024 (UTC)Reply

One of my wikis recently started to throw the following error when running its crontabbed runJobs.php:

PHP Deprecated:  htmlspecialchars_decode(): Passing null to parameter #1 ($string) of type string is deprecated in /**blanked**/extensions/Cargo/includes/CargoUtils.php on line 529

Deprecated: htmlspecialchars_decode(): Passing null to parameter #1 ($string) of type string is deprecated in /**blanked**/extensions/Cargo/includes/CargoUtils.php on line 529

It doesn't do it every time, and I don't know which jobs are causing it.

Thanks for pointing out that problem - it's another in the endless series of PHP 8-related bugs. I just checked in what I think is a fix for it, here. Yaron Koren (talk) 14:22, 12 June 2024 (UTC)Reply

Thank you for your answer. Now running 3.6 (f6baf05) 00:21, 2024 June 19 and the problem is fixed. (Edit to remove mistake on my part that it was still broken) Tenbergen (talk) 14:20, 23 June 2024 (UTC)Reply

For parent tables, if I have templates in which multiple fields share the same name (e.g. Building.years_built and Church.years_built, Building.image and Church.image, etc.), am I able to put multiple fields into the #cargo_declare or should I just leave the cargo declare as the page name and then do multiple 'join on' in my queries? Also I'm assuming I wouldn't need do join on for queries where I display them using templates and do named args. Rothwell4217 (talk) 09:54, 29 June 2024 (UTC)Reply

Sorry, what do you mean by "leave the cargo declare as the page name"? Yaron Koren (talk) 15:36, 1 July 2024 (UTC)Reply

Sorry, I didn't explain that too well. I have two templates that are essentially the same (sharing about 90% of fields) but one has specific fields related to Churches. I'm trying to figure out which is the best option for linking the two so that queries are easier. Essentially I want to have this diagram showing arrows going to Building for all fields that are the same.

I think there's 3 possibilities, though some may not work:

1. If this is possible, adding more than one field when I set the parent table.

   |_parentTables= tableName1(_localField=localFieldName, _remoteField=remoteFieldName, [... more fields])

2. Just doing lots of 'join on' for all the fields that are the same when I do my queries. What I meant by "leave the cargo declare as the page name" was that I saw in the documentation that the default for the fields in the parent table above is the page name. So if I do multiple join on, should I still do the parent table and just leave the fields as the default.
3. Using cargo_attach to attach the Church template to the Building template. Although I'm not certain how this works. Would it allow me to link fields of the same name in both tables, while still allowing for different fields? And do I have to declare the fields that are the same?

Rothwell4217 (talk) 20:44, 3 July 2024 (UTC)Reply

Okay, I understand better, but I'm still somewhat confused. As far as I can tell, you have two options: (1) have the "Building" and "Church" DB tables look more or less the same as each another (which is how you have it now), or (2) have the "Building" table store info for both regular buildings and churches, and then have a separate DB table, maybe called "ChurchInfo", that just holds that handful of additional fields for churches, like "parish". Under option #1, there's no need to join at all, since the same page will never be in both tables. Under option #2, you would need to join them in queries - on _pageName or _pageID; and each page about a church would have to call, either directly or indirectly, both the "Building" and "ChurchInfo" templates. There are valid reasons to go with either option, but you should pick one; it seems like you might have a mix of both in mind. Yaron Koren (talk) 00:56, 4 July 2024 (UTC)Reply