Extension talk:Cargo/Archive April to September 2024

Drilldown Field Join Issue

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)

Cargo Compound Query PHP Depreciation Warning Issue

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)

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)

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)

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)

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)

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)

What's the Best Option for Field/column Labels

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)

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)

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)

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

Adding part of page name as default value

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)

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

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)

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)

CEIL function adding commas to number, bug?

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)

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)

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

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

Query within a query?

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)

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)

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)

Output format = Wikitext

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)

I agree with this. Sometimes I create content using a Cargo query and would like to be able to cut and paste it for posterity into a wiki page. This would help with that.

I vaguely remember being able to achieve this using templates, at least to a limited extent, but it would be easier if Cargo could just output wikitext as a standard output format. Jonathan3 (talk) 09:56, 4 October 2024 (UTC)

Cannot change the label of the field

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)

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)

Any idea to implement PivotTable in Cargo?

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)

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)

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)

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)

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)

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

htmlspecialchars_decode

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)

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)

_parentTables

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)

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

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)

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)

Unable to query date__precision values

Hi there, I have a date value in a table, and when displaying it I'd like to use different formats based on the precision of the input. I'm led to understand that the {name}__precision field is the way to go, however whenever I try to query on this I receive the following error: Error: No field named "date__precision" found for the database table "events".

Having looked in my database, I can see that date and date__precision columns are both present and being populated with correct-looking values. Is there something I'm missing for using this column in queries? Thanks in advance for any assistance.

{{#cargo_declare:_table=events
|title=String (mandatory)
|class=String (mandatory;allowed values=xxx,xxx,xxx)
|city=Page (mandatory)
|area=Page (mandatory)
|date=date (mandatory)
|blurb=Wikitext string
|link=URL
}}

{{#cargo_query:
tables=events
|fields=events.title, events.class, events.date, events.blurb, events.date__precision
|where=events.date >= '1980' and events.date < '1990'
|order by=events.date ASC
|format=template
|template=event timeline/format
}}

MisfitMaid (talk) 17:12, 30 July 2024 (UTC)

That's a bug - but I believe you can get around it by just changing events.date__precision to CONCAT(events.date__precision) in the query - which is a hack, I admit. Yaron Koren (talk) 18:36, 30 July 2024 (UTC)

Ah, nifty workaround, thank you! I'll just go with that then :) MisfitMaid (talk) 00:17, 31 July 2024 (UTC)

turning result into link breaks grouping

I have a query where I group rooms by a field "floor" concatted to other text. It still groups fine when I add a square bracket, but it I add matched square brackets to turn it into a link, the grouping goes away and the floor is displayed for each row. See example.

• this works as expected: |fields=concat("[", floor, " floor]]")=Floor,_pageName=Room
• this breaks the merge: |fields=concat("[[", floor, " floor]]")=Floor,_pageName=Room

Tenbergen (talk) 03:47, 11 August 2024 (UTC)

I see the problem on your wiki, but I can't reproduce it on my wiki - for me, a similar query with links and "merge similar cells" displays fine. I have no idea why it's failing for you, since the relevant code just does pretty simple string matching. It might be due to your wiki's use of PHP 8, though I can't think of why that would make a difference here. Yaron Koren (talk) 17:06, 14 August 2024 (UTC)

What version of PHP should I try instead? Tenbergen (talk) 02:24, 16 August 2024 (UTC)

PHP 8 is fine to use (it's the future, after all); I'm just saying that that might be the reason why we are seeing different behavior. I'm still using PHP 7.4. Yaron Koren (talk) 14:28, 16 August 2024 (UTC)

getting error "Identifier must not contain quote, dot or null characters" when trying to use Concatenate

I have enabled the Concatenate function on a wiki, and it works fine in general, but when I try to concatenate a string into the result it gives error "Identifier must not contain quote, dot or null characters". For example:

• works: no added string: ...cargo_query: table=tool |fields = CONCAT(image_map_coordinates__full,room)...
• gives error: ...cargo_query: table=tool |fields = CONCAT(image_map_coordinates__full,'~',room )... (error is not just for ~ but any string)

See example on wiki. Tenbergen (talk) 02:24, 16 August 2024 (UTC)

I just did a different search for that error in google, and it seems to mostly be on wikis. It actually affects another wiki of mine as well, in a spot that I know worked before. So this may have been broken by some recent update to something. Tenbergen (talk) 02:26, 16 August 2024 (UTC)

I don't know what the exact cause of that error is, but there's the possibility that adding an alias would fix the problem, i.e. CONCAT(...)=Field name. Yaron Koren (talk) 04:47, 16 August 2024 (UTC)

That does indeed fix the problem. I didn't think field names were required. And I still think this used to work before. However, happy to have a solution, thanks! Tenbergen (talk) 04:30, 18 August 2024 (UTC)

Great! I looked into this a little more - it looks like this was validation added to core MediaWiki in MW 1.42. So maybe handling for this needs to be improved in Cargo - though I'm not sure how. Yaron Koren (talk) 13:47, 19 August 2024 (UTC)

Join on a field with multiple values

{{#cargo_query: tables=bookings=b, persons=p

 |join on=b.person__full=p._pageName
 |fields=p._pageName, CONCAT(MIN(b.year))
 |group by=p._pageName
 |where=p._pageName IS NOT NULL}}

works fine, but only for the first Value in bookings.person(__full). Is there a way to have the second and third value too? Ernst Rosser again (talk) 09:54, 30 August 2024 (UTC)

That line should ideally instead be join on=b.person HOLDS p._pageName. Hopefully that will work. Yaron Koren (talk) 14:45, 30 August 2024 (UTC)

Expandable maps?

This is a fantastic extension that has added many useful timesaving features and interesting maps to the wiki. Are there any plans to add expandable maps like in the Karographer extension? Where one can click a button and the map fills the screen. Garuda3 (talk) 21:08, 12 September 2024 (UTC)

Thank you! No, but it's an interesting idea. Yaron Koren (talk) 17:35, 13 September 2024 (UTC)

$wgCargoDBtype defaults to $wgDBtype

@Yaron Koren: Regarding your change here, are you sure $wgCargoDBtype is actually required? I'm using a separate DB and do not set it, and everything's fine. The source has:

$type = $dbr->getType();
if ( $wgCargoDBtype === null ) {
    $wgCargoDBtype = $type;
}

Sam Wilson 22:39, 18 September 2024 (UTC)

Ah, I thought I might be doing something incorrect. I just fixed that section, and generally improved the layout. Hopefully it makes more sense now (and is correct). Yaron Koren (talk) 00:52, 19 September 2024 (UTC)

@Yaron Koren: Looks good! Thanks. Sam Wilson 02:28, 19 September 2024 (UTC)

Dynamic tables (DataTables): filtering with SearchPanes extension

Is there any way to add the functionality of DataTables‘ SearchPanes extension to Cargo? Gnarfoo (talk) 10:40, 20 September 2024 (UTC)

Oh, very interesting! I didn't know about SearchPanes, so I just looked it up - here is a basic demo of it. This obviously is similar functionality to Cargo's Special:Drilldown, although it's all client-side (JavaScript) so it moves a lot faster. It's also similar in concept to the exhibit format, although not many people use that. It certainly would make sense to add this as an option. (Though I don't know why they called it SearchPanes - "FilterPanes" would have made more sense.) Yaron Koren (talk) 14:30, 20 September 2024 (UTC)

Thank you for pointing to the exhibit format – actually, I didn‘t realize, this would be the better choice for filtering. I will, for sure, look into it (and would appreciate it, if SearchPanes could be an option in Cargo, one day). Gnarfoo (talk) 17:31, 20 September 2024 (UTC)

@GnarfooI found that Extension:ContainerFilter is easy to implement, and suitable for Search options. Can give it a try. Duyhungwiki (talk) 16:29, 26 October 2024 (UTC)