Extension talk:Cargo/Archive May to July 2020

Data in cargo table not updating after I renamed a column title

I changed the name of a column header and changed the data type from boolean to text, now when I try to add text to the new field it will not save. The new header name also disappeared from the drilldown menu... I renamed all the references to the old header in the template, am I missing somewhere else where I have to rename the old column header?

Did you recreate the table? And does the listing for that table look correct in its Special:CargoTables page? Yaron Koren (talk) 21:21, 13 May 2020 (UTC)

Cargo equivalent to SMW's #show?

I'm sorry if this is a stupid question or if I missed something obvious. I've been trying to make it where infoboxes on my wiki will display data from another specified page so that information that changes there will be changed on other pages automatically, something I know how to do using Semantic MediaWiki's #show function. However, I can't seem to find any information on how to do anything like that with Cargo, and I don't know if it's because it doesn't exist or because I don't know how to look for it. Does an equivalent function exist in Cargo? Where can I learn how to use it? (P.S. In case you're wondering why I would want to do this over just updating the relevant pages, it's for ranked taxonomy in an ongoing evolution game. Basically, that means information potentially relevant to hundreds of pages is expected to change semi-regularly.) Disgustedorite (talk) 00:55, 14 May 2020 (UTC)

There's no equivalent for #show, although #show itself is not really necessary - it's just slightly different syntax for #ask. Similarly, you can just call #cargo_query to get a specific field value for a specific page. If that seems like too complex a call to make every time, you could always create a "show" template that wraps around #cargo_query and takes in the necessary values: table name, field name and page name, or some subset of those. Yaron Koren (talk) 12:10, 14 May 2020 (UTC)

Apologies for the very, very late response. I have no idea how to actually do it, though. I do not know how to use #cargo_query to display a single value from a single page because I cannot find any information on how to do so, or I am not understanding the information about how to do so, possibly due to the severe lack of examples provided. I asked if I'm missing something and where I can learn. Disgustedorite (talk) 08:15, 13 July 2020 (UTC)

EDIT: Nevermind, I am embarrassed to admit that I immediately figured it out. The pages on Cargo's functions really need examples and previews. Disgustedorite (talk) 08:27, 13 July 2020 (UTC)

Cargo equivalent to SQL arithmetic operations between 2 or more columns?

Greetings.

Considering the following SQL query:

SELECT column1 + column2 AS "add", column3 * column4 AS "multiply" FROM table1;

Is it possible to achieve such behavior in Cargo?

-- N tonio36 (talk) 03:34, 15 May 2020 (UTC)

I don't think so, unfortunately. If there are specific sums, products, etc. you want to display, the only way to do it may be to have the template store those as separate fields - calculating them using #expr from the ParserFunctions extension. Then it's just a matter of querying those fields. Yaron Koren (talk) 04:16, 15 May 2020 (UTC)

Title disambig text

For Cargo. I'm using this template with the following code |history={{Title disambig text|{{PAGENAME}} }}. But when you go to special:CargoTables/Articles, the "history" column appears empty. How can I fix that? The reason is that in my personal wiki I develop fictional content and to differentiate one from another that have the same name, I add a title in brackets. --Hispano76 (talk) 19:26, 16 May 2020 (UTC)

Does {{Title disambig text|{{PAGENAME}} }} display what you expect (i.e. the part of the page title which is within round brackets) when it's just on its own on the page? Does plain text save to the Cargo table? Is history correctly declared in the template? Jonathan3 (talk) 20:50, 16 May 2020 (UTC)

when it's just on its own on the page? yes

Does plain text save to the Cargo table? no, is blank

Is history correctly declared in the template? yes

Greetings. --Hispano76 (talk) 21:41, 16 May 2020 (UTC)

Could you cut and paste here your template for the Articles table? Jonathan3 (talk) 21:47, 16 May 2020 (UTC)

<includeonly>
{{Metaplantilla de avisos
|type   = aviso
|imagen = 
|texto  = Este artículo perteneciente a la historia alternativa '''{{Title disambig text|{{PAGENAME}} }}''', ha sido clasificado como de importancia '''{{{1|Desconocida}}}''' y de calidad '''{{{2|Desconocida}}}''' en la evaluación de artículos.
}}
{{#cargo_store:_table=Artículos|Historia={{Title disambig text|{{PAGENAME}}}}|Calidad={{{1|Desconocida}}}|Importancia={{{2|Desconocida}}}|Estado={{{3|Sin información}}} }}</includeonly>
<noinclude>{{#cargo_declare:_table=Artículos|Historia=String|Calidad=String|Importancia=String|Estado=String}}</noinclude>

For example (in spanish). Grettings. --Hispano76 (talk) 22:01, 16 May 2020 (UTC)

Multiple Cargo wikis from one database

Is it possible to set up one stand-alone database to store the cargo tables from multiple wikis? I was thinking of using separate prefixes per database, and it looks like it currently uses $wgDBprefix, but I have that overlapping in some wikis. Would it be possible to get $wgCargoDBprefix, or is there another option? -- Prod (talk) 22:09, 18 May 2020 (UTC)

Sure, it sounds possible to have multiple wikis use the same database as their Cargo database - and if each one had a different DB prefix, then you would prevent collisions. You couldn't have wikis then access each others' data, but you could query all the tables together outside of MediaWiki. Yaron Koren (talk) 13:51, 19 May 2020 (UTC)

How to query out a Cargo "Datetime" column in local time

Hi everyone, hope you're well.

I'd like to use #cargo_query to pull out page creation/modification times from the fields in the _pageData table (which I've switched on with $wgCargoPageDataColumns) in the user's local timezone.

What I've managed to do is whitelist CONVERT_TZ using the $wgCargoAllowedSQLFunctions array, and then use something like CONVERT_TZ(pd._creationDate, 'UTC', 'America/New_York')=Created in the Cargo query. This isn't a great solution because now I've hard-coded a time zone in the query, and my users might have a different local time zone in their preferences. What I was hoping for was a way to just default to showing DATETIME fields in the user's local time.

I see that another option might be to use {{#cargo_query: […] format=template}}, then, in the template, wrap the returned DATETIME field with the #timel parser function, and that may be the route I end up going in the end. I just miss the convenience of the "table" output format, because it saves a lot of work (thanks Yaron!).

What I'm wondering is whether there isn't a more Cargo-y way to do this, like something built in that I just missed.

It looks like what's missing is a variable like "{{CURRENTUSERTIMEZONE}}", which would return a value like 'America/New_York' for each user. If such a thing existed, you could pass that in to CONVERT_TZ() within #cargo_query, and I think you'd get exactly the output that you're looking for. I don't believe any such variable exists. I don't know what the best approach is to create it - maybe to use the MyVariables extension, and add this additional variable to it. It'll require some PHP programming... which hopefully you can do. Yaron Koren (talk) 00:38, 25 May 2020 (UTC)

OK, I was initially confused whether magic words or parser functions would be parsed in the field= parameter of #cargo_query, but now it seems obvious that they would be. I'm already using Extension:WikiUserInfo with the "dangerous functions" enabled on a non-public wiki, which provides a parser function version of what you describe, so maybe that's my solution.

As far as Cargo is concerned, do you think there's any merit in defining a DateLocal / DatetimeLocal field type, the results of which always come back formatted using the user's timezone preference, or maybe a tz= field parameter? Or a $wgCargoDateTimeUsesServerTZ to default to displaying Date / Datetime fields using the server's $wgLocaltimezone? I'm not pestering you with a feature request, just wondering if you think that would be a worthwhile addition, or out of the scope of what you believe Cargo's job should be with respect to DATETIME fields. --Ernstkm (talk) 05:00, 27 May 2020 (UTC)

That's an interesting question, of when (if ever) it makes sense for times to be displayed in the user's time zone, rather than the wiki's, if there's a difference between the two. You mentioned a few options: per field, with some new types; per wiki, with a global variable; and of course, per query field, with that CONVERT_TZ() approach you discovered (I'm glad that works, by the way, even if it's "dangerous"). I can think of two more: per user, with a new preference like "Display Cargo times in my timezone"; and per query, with a new parameter to #cargo_query.

I guess the question is, what's the logic to determine whether any specific time should be shown in the user's time zone or not? Does it depend mostly on whether this is an event that someone in a different time zone could participate in? And is there the possibility that having too "clever" a solution could lead to user confusion about which times are in their time zone and which are not? Yaron Koren (talk) 13:46, 27 May 2020 (UTC)

Write to Cargo tables in Lua

Cargo is amazing. Thank you! Just one issue -- Is it possible to write to Cargo tables in Lua? My module is used in the same template that defines the table. It iterates over an unlimited number of infobox-like numbered params (entry1=foo, entry2=bar, etc.) so it would be tedious to do the storage via wikitext. I think I could get away with the Lua module returning the {{#cargo_store}} code along with the generated wikitext... but that seems hacky. — MusikAnimal ^talk 05:39, 24 May 2020 (UTC)

I'm glad you're enjoying Cargo! I don't know that much about Lua programming, but I believe that, instead of passing in that wikitext (which would indeed be hacky), you should use the callParserFunction method to call #cargo_store. Eventually, I hope there will be native Lua methods for #cargo_store and #cargo_declare, like there is for #cargo_query. Yaron Koren (talk) 00:40, 25 May 2020 (UTC)

I do not know Lua very well either, but that's exactly what I was looking for! It's essentially the same as a native call, from a programmer standpoint. What I wanted to avoid was all that string concatentation in building the wikitext. This allows me to pass in key/value pairs, so consider it solved. I have made note of this in docs with Special:Diff/3875998. Thanks! — MusikAnimal ^talk 04:47, 25 May 2020 (UTC)

database error after renaming (moving) a template

I've created a template, called TEMPLATE_foo_bar, which has the following lines in it:

• {{#cargo_store: _table = TABLE_foo_bar |PROPERTY_foo_bar={{{bar}}} }}

to store data and

• {{#cargo_declare: _table = TABLE_foo_bar |PROPERTY_foo_bar=String (mandatory;unique) }}

to declare the respective table. This used to work well. Now I moved the template to something called TEMPLATE_foo_xyz and also replaced any occurrence of "bar" with "xyz". Nothing else was changed. After that I recreated the cargo table which also worked fine. But now if I try to use this template, it keeps throwing error messages at me, namely

A database query error has occurred. Did you forget to run your application's database schema updater after upgrading? Query: SELECT COUNT(*) FROM "cargo__TABLE_foo_xyz" WHERE PROPERTY_foo_xyz = 'TestEntry' Function: Wikimedia\Rdbms\Database::select Error: 42703 ERROR: column "property_foo_xyz" does not exist

Now the funny part is that the column in all lower case does not exist indeed. But it exists exactly as I spelled it in the template. If I enclose PROPERTY_foo_xyz with quotationmarks in the template, it works again. I checked the table and column names in the backend. They look exactly as they should. Again, the only thing I did was to move the template and replace 3 characters in the code with another 3 characters. What do you make of this? How to get this to work again? Thanks in advance.

--Mwarge (talk) 15:26, 26 May 2020 (UTC)

That's strange. What version of Cargo are you running? Yaron Koren (talk) 17:48, 26 May 2020 (UTC)

As of today it is the latest 2.5-release. Downloaded and installed after the error occured. I am not 100% sure which version I used before, but I guess I can figure that out if needed. Also I ran update.php before and after setting up 2.5. --Mwarge (talk) 19:43, 26 May 2020 (UTC)

What about the display of the table in Special:CargoTables, and in the Special:CargoTables subpage for that table - does it show up correctly in both? Yaron Koren (talk) 20:09, 26 May 2020 (UTC)

I am quite sure it did. In the meantime I renamed the template (and table/column) to yet something else and it did not work. Then I restored to the version I originally wanted to work, recreated the tables once again and voila - now it works. Special:CargoTables shows everything correctly. Also the subpage for that table looked correct as it always did after (re)creating the tables, eventhough there is a notice about some jobque (got a localized message and im not sure what the english version is). This notice was there before today and I am not quite sure what kind of job this might be. php runJobs.php does nothing. Anyhow, for the moment my problem got magically resolved. I'll keep an eye on that and report back if something happens. I moved/renamed quite some templates and tables along with their columns, so the issue might show up again somewhere else. Let me know if you'd like more info on something and thanks so far.

I have no idea why any of that happened, but I'm glad it's working now! Yaron Koren (talk) 21:48, 26 May 2020 (UTC)

Subquery expands right in other formats but not calendar

I have the following query with subqueries. When I run it in default format without specifying anything, the subquery expands as I would expect. When I add format=calendar the calendar days just contain the not-yet-executed query code. Here is the query:

{{#cargo_query:
tables= allDates
|fields= dt,
CONCAT( "Days: ", "{","{#cargo_query:
tables = SE
{{!}}fields= sName
{{!}}where = SE.sDay = DATE('", dt, "') AND SE._pageName = 'Gastroenterology Days Staff'
{{!}}default = ''}", "}", "<br>", "Nights: ", "{","{#cargo_query:
tables = SE
{{!}}fields= sName
{{!}}where = SE.sDay = DATE('", dt, "') AND SE._pageName = 'Gastroenterology Nights Staff'
{{!}}default = ''}", "}") = name, 
|where = dt >= DATE("2020-05-01") AND dt <= DATE("2020-05-31")
|limit=50
}}

Here is what shows in a calendar day box when I run it with |format=calendar, so here is a typed version but it will likely have

Days: {{#cargo_query:tables = SE|fields= sName|where = SE.sDay = DATE('2020-05-27') AND SE._pageName = 'Gastroenterology Days Staff'|default = ''}}<br>Nights: {{#cargo_query:tables = SE|fields= sName|where = SE.sDay = DATE('2020-05-27') AND SE._pageName = 'Gastroenterology Nights Staff'|default = ''}}

As I re-read this I realize there might be an easier way to write the query for calendar view (I am re-using this from a table view where I had to us a table with all dates to force blank boxes), but it still seems like a bug that the code that expands fine in other formats doesn't in calendar format. Thanks! Tenbergen (talk) 20:02, 27 May 2020 (UTC)

Wow, that's... impressive. :) I've never heard of constructing a #cargo_query call as the result of another #cargo_query call, although I can see how it would work. Yes, the "calendar" format doesn't parse the contents of its results, and it probably should. Still, I hope there's a less hacky solution than this... Yaron Koren (talk) 14:08, 28 May 2020 (UTC)

You mean others are not doing this? The ability to stick all sorts of things into a CONCAT statement is one of the features that have pulled me from SMW to Cargo, it adds a lot of flexibility in aggregating information. I love that I can do that on one line in Cargo, where if I can do it at all in SMW I would have to do it through a template. Tenbergen (talk) 21:42, 28 May 2020 (UTC)

Right, I've never heard of anyone else doing this. Now I'm curious: could you describe what it is that you're trying to display? I want to know if there's a real use case for this kind of approach. Yaron Koren (talk) 00:12, 29 May 2020 (UTC)

I have pages for shifts that contain multiple entries that encode the date and the name of the person who is to work the shift. In this case, one shift is a night shift and one a day shift. The people who use the data would like a calendar that lists both the day and night person. Of course it should still list the day even if the night is not covered. It seems like I should be able to pull this into one query and concatenate this, e.g. by calling the table twice and filtering one for day shifts and one for night shifts, but that is not working as expected, so also see my question below re joins. To work around that, I did it with the query inside a query.

Are you wondering whether there is a use case for query-in-query in calendars or in general? Tenbergen (talk) 20:46, 1 June 2020 (UTC)

In general. Do you know about the GROUP_CONCAT() function? It works in conjunction with "group by". It could potentially be a simpler approach to displaying what you're trying to display... Yaron Koren (talk) 20:51, 1 June 2020 (UTC)

I did not know about that function, thanks for the tip! It allows further functions inside it, so something like GROUP_CONCAT(if(_pageName = "Gastroenterology Days Staff", "Day: ", "<br>Night: "), sName) gives me the text I need. However, when I turn format=calendar, the <br> doesn't turn into the expected newline, but instead displays as "&ltbr&gt". Tenbergen (talk) 21:23, 1 June 2020 (UTC)

That's looking better already. :) Instead of the <br> tag, how about just putting two actual newlines there? I don't know if that will have any effect, but it's worth trying. Yaron Koren (talk) 21:59, 1 June 2020 (UTC)

You got it: the \n in the following adds the newline: GROUP_CONCAT(if(_pageName = "Gastroenterology Days Staff", "Day: ", "\nNight: "), sName). Thanks Yaron! Tenbergen (talk) 02:10, 2 June 2020 (UTC)

Great! I meant an actual newline, but if "\n" works, that's even better. It probably still makes sense to get the calendar format's parsing to match those of the other formats, but I'm relieved to hear that it's not necessary for this. And even more relieved that that original monstrosity can be avoided... Yaron Koren (talk) 02:28, 2 June 2020 (UTC)

Are those joins really left outers?

I ended up doing #Subquery expands right in other formats but not calendar because I am not sure that the join on actually works as a left outer join as described in here. I have two pages "day shift" and "night shift" that each hold multiple template calls that populate the sDays and sNames for those shifts. Some dates in that list only have either a "day" or "night" entry. If both are not present, the line doesn't show up. For example, I tried to re-write the query above to not use the query-in-query. When I write it as the following I don't get an line for a date where only the "day" has a record:

{{#cargo_query:
tables= allDates, SE = Days, SE = Nights
|join on=allDates.dt = Days.sDay, allDates.dt = Nights.sDay
|fields= dt, Days.sName = D, Nights.sName = N
|where = dt >= DATE("2020-05-01") AND dt < DATE("2020-06-02")
         AND (Days._pageName = "Gastroenterology Days Staff" or ISNULL(Days._pageName))
         AND (Nights._pageName = "Gastroenterology Nights Staff" or ISNULL(Nights._pageName))
|limit=50
|default=nothing here
}}

When I instead only pull in the Day part of the table I get the line. EG Still testing

{{#cargo_query:
tables= allDates, SE = Days
|join on=allDates.dt = Days.sDay
|fields= dt, Days.sName = D
|where = dt >= DATE("2020-05-01") AND dt < DATE("2020-06-02")
         AND (Days._pageName = "Gastroenterology Days Staff" or ISNULL(Days._pageName))
|limit=50
|default=nothing here
}}

If it was a left outer join I would have expected the line to show in the first query, just with the night column empty. I was able to overcome this problem with the Subquery expands right in other formats but not calendar|above]] for non-calendar layout, but it doesn't work in calendar layout. So how would I need to do the query to also get lines that only have an entry for one column (resp one joined table)? Tenbergen (talk) 22:14, 28 May 2020 (UTC)

Error in HOLDS when search value has apostrophe

Hello! After Cargo was updated to version 2.5, the Wiki I'm working on is getting the following error for HOLDS queries that previously worked.

Version: 2.5

Tested Queries

{{#cargo_query:tables=Stages
|fields=_pageName
|where=Drops HOLDS "Lucien's Microphone"
|format=ul
}}

{{#cargo_query:tables=Stages
|fields=_pageName
|where=Drops HOLDS 'Lucien\'s Microphone'
|format=ul
}}

Errors

A database query error has occurred. Did you forget to run your application's database schema updater after upgrading?
Query: SELECT `_pageName` AS `_pageName` FROM `cargo__Stages` WHERE `cargo__Stages`.`_ID` IN (SELECT _rowID FROM `cargo__Stages__Drops` WHERE _value = "Lucien') s Microphone" ORDER BY `_pageName` LIMIT 100 Function: CargoSQLQuery::run Error: 1064 You have an error in your SQL syntax; check the manual that corresponds to your MariaDB server version for the right syntax to use near at line 1 (dbt1.miraheze.org)

A database query error has occurred. Did you forget to run your application's database schema updater after upgrading?
Query: SELECT `_pageName` AS `_pageName` FROM `cargo__Stages` WHERE `cargo__Stages`.`_ID` IN (SELECT _rowID FROM `cargo__Stages__Drops` WHERE _value = 'Lucien\') s Microphone' ORDER BY `_pageName` LIMIT 100 Function: CargoSQLQuery::run Error: 1064 You have an error in your SQL syntax; check the manual that corresponds to your MariaDB server version for the right syntax to use near at line 1 (dbt1.miraheze.org)

Looking at the repo, seems like it's related to the changes in CargoSqlQuery::handleVirtualFields() and CargoSqlQuery::substVirtualFieldName(), which looks like it's picking up the apostrophe in the pattern match.

For anyone else encountering the issue, this can currently be worked around by directly using the helper tables:

Workaround

{{#cargo_query:tables=Stages,Stages__Drops
|join on=Stages._ID=Stages__Drops._rowID
|fields=_pageName
|where=_value = 'Lucien\'s Microphone'
|format=ul
}}

--Elaeagnifolia (talk) 16:02, 29 May 2020 (UTC)

Another user on the same Wiki host also reported issues with HOLDS as well. Just using where=CompetitorInfo.PreviousAliases HOLDS TournamentCompetitorScores.Player works, but anything after will error out the query (eg. where=CompetitorInfo.PreviousAliases HOLDS TournamentCompetitorScores.Player AND CompetitorInfo.Player = 'Todd'). I've shortened the error message, but you can see that there's a closing parentheses being appended to ') Todd'.

...(SELECT _rowID FROM cargo__CompetitorInfo__PreviousAliases WHERE _value = cargo__TournamentCompetitorScores.Player AND cargo__CompetitorInfo.Player = ') Todd' GROUP BY cargo__TournamentCompetitorScores.Tournament ORDER BY cargo__TournamentInfo.StartDate LIMIT 100 Function: CargoSQLQuery::run Error: 1064...

--Elaeagnifolia (talk) 01:42, 30 May 2020 (UTC)

Sorry about that, and thanks for letting me know. There was just a change checked in to Cargo that I believe fixes both issues. Yaron Koren (talk) 15:07, 2 June 2020 (UTC)

DISPLAYTITLE

Any chance on setting a the DISPLAYTITLE to the string from a cargo field? a la {{DISPLAYTITLE:{{ {{#cargo_query:tables=testTable |fields=Name|where=id="123"}} }} Whenever i do this the title defaults back to its PAGENAME, whereas the query works elsewhere on the page, and setting the title to something else also works.

I've searched this talk page but didn't find a definite answer if this is possible or not. For the Extension:DisplayTitle there is an existing thread Topic:Thao0y9d7e9y52bk from which i take it it's possible. But from that I'm left confused whether to use the deprecated Semantic Title, the built in magicword, or the extension and I cannot get it to work with either of these. Keep up the great work! --Fehlerx (talk) 23:39, 2 June 2020 (UTC)

Try adding "|no html" to the #cargo_query call - that might help. Yaron Koren (talk) 23:40, 2 June 2020 (UTC)

Thank you!!--Fehlerx (talk) 01:05, 3 June 2020 (UTC)

Still getting internal error on recent changes

This is a follow-up to Internal error on Recent Changes after running cargoRecreateData.php and possibly also related to "Use of Parser title should never be null was deprecated in MediaWiki 1.34.".

Yaron had suggested changing line 1160 of /includes/CargoUtils.php from $log = new LogPage( 'cargo' ); to $log = new LogPage( 'cargo', false );, which seemed to fix the problem until the overnight scheduled run of our maintenance script breaks it again.

the maintenance script

/usr/local/php73/bin/php /home/xxxxx.ca/maintenance/runJobs.php --quiet /usr/local/php73/bin/php /home/xxxxx.ca/extensions/SemanticMediaWiki/maintenance/rebuildData.php --quiet /usr/local/php73/bin/php /home/xxxxx.ca/extensions/SemanticMediaWiki/maintenance/removeDuplicateEntities.php --quiet /usr/local/php73/bin/php /home/xxxxx.ca/maintenance/cleanupEmptyCategories.php --force --quiet /usr/local/php73/bin/php /home/xxxxx.ca/maintenance/updateSpecialPages.php --quiet /usr/local/php73/bin/php /home/xxxxx.ca/maintenance/rebuildall.php --quiet /usr/local/php73/bin/php /home/xxxxx.ca/extensions/Cargo/maintenance/cargoRecreateData.php --quiet /usr/local/php73/bin/php /home/xxxxx.ca/extensions/Cargo/maintenance/setCargoPageData.php --quiet /usr/local/php73/bin/php /home/xxxxx.ca/extensions/RottenLinks/maintenance/updateExternalLinks.php --quiet

I just updated to the newest version of MW and Cargo hoping that might fix it, but it's still a problem. Tenbergen (talk) 01:28, 12 June 2020 (UTC) This was also reported on https://phabricator.wikimedia.org/T241302

I have given up on a fix for this and instead set up a cron job that deletes the offending lines with a "Delete FROM recentchanges where not (rc_title > ""). This fixes recent changes for me on that wiki. Tenbergen (talk) 16:12, 24 June 2020 (UTC)

Ignore a namespace or a magic word to ignore the #cargo_store in a page ?

Hello Yaron Koren,

First, thank you so much for your great extension.

I run an online dictionary for kids and use a template to show the data nicely.

That template is storing the data in the Cargo database.

I want to use the same template to show the "word of the week" nicely. Problem : the word gets stored twice in the database. Part of the solution, maybe : the word of the week isn't in the same namespace as the actual words.

I couldn't find an option to make it work. Is there some option like $smwgNamespacesWithSemanticLinks from Semantic Media Wiki or a magic word to ignore any #cargo_store ?

Thank you ! DSwissK (talk) 15:00, 14 June 2020 (UTC)

Great site! I'm not sure I understand: are you worried that a page like "Dico:Mot de la semaine/2020/24" will show up in the database as a word? If so - are you planning to copy the contents of the word's page into the "word of the week" page, or to instead use #cargo_query with the "embedded" format, as you are doing now with #ask? Yaron Koren (talk) 19:15, 14 June 2020 (UTC)

Thank you for the kind words. Exactly, I don't want "Dico:Mot de la semaine/2020/24" to show up in the database as a word since it's already there. (Word of the week is picked among the words that are already created and stored in Cargo.)

I did try with #cargo_query instead but, as you can see, if you search for "évaluation des", you get 2 "words" ("test" and "Mot de la semaine/2020/26"). Any workaround idea ? DSwissK (talk) 20:00, 14 June 2020 (UTC)

If the "embedded" format causes a page to get the Cargo values of the page(s) that it embeds, that's a problem. Maybe there is a fix for that - I don't know. Until then, I suppose you can get around this problem by adding " AND _pageNamespace = 0" to the "where" parameter in every #cargo_query call, as annoying as that sounds. Yaron Koren (talk) 03:14, 15 June 2020 (UTC)

Right. I'll use this solution until then. :) Thanks. DSwissK (talk) 12:42, 15 June 2020 (UTC)

Here is the solution we came accross : {{#ifeq:{{NAMESPACE}}|Dico||{{#cargo_store: [...] (on the template page) if that might help anyone. :) DSwissK (talk) 21:05, 15 June 2020 (UTC)

Unable to use Parser Functions or Conditional Expressions on List Output

Greetings, I've been able to create a List Cargo_query which looks up and returns a single output, for example look up a species by Name in the cargo_table and return only its Genus, but am unable to do anything but display the output. All attempts to use the output in a parser function or conditional expression fail, acting like nothing is being passed into them. By using padleft on the output, I can see that 16 invisible characters are getting added to the output, but am unable to see what they might be. Using #pos: on the output doesn't show any actual text being output, indicating only a pointer to the cargo data is being returned instead of returning the stored string data itself. Is there anything I can add to my cargo_query to get rid of those extra invisible characters so that I can use the output like a proper string for #ifeq checks? Thank you, Ertosi 10:29, 18 June 2020 (UTC)

If Genus is your list field, you can get Genus__full from the cargo query instead of Genus, and use it in your own templates/parser functions. Jonathan3 (talk) 12:09, 18 June 2020 (UTC)

Adding "|no html" to the #cargo_query call will hopefully fix the problem. Yaron Koren (talk) 14:10, 18 June 2020 (UTC)

Thank you so much, "|no html" was exactly what I was looking for! I gave it a try and everything is working now. I haven't tried the "__full" option yet, but appreciate that suggestion as well. Yaron Koren, I'm really enjoying Cargo as the potential for it is endless. The "|no html" option was the last ingredient I needed to finish making semiautomated pages for my wiki that fill themselves out after their infobox is completed and I'm looking forward to the time it's going to save. Thanks again, your hard work contribution to the wiki community is greatly appreciated. Ertosi 21:19, 18 June 2020 (UTC)

"Page values" link missing from tools menu in sidebar

I have two wikis use Cargo 2.6 (042d05d) 02:00, 2020 June 11; they no longer show the "page values" links in the tool bar. Two other wikis using Cargo 2.5 (4a45c7a) 2020-05-05T13:08:00 still show the page values link. If I add "&action=pagevalues" to the URL I can still see the page values. I don't see a note in Extension:Cargo/Version_history that the link was removed. How can I get the link back? Tenbergen (talk) 20:11, 24 June 2020 (UTC)

Yes, there was a change about two weeks ago to use a different hook to add the "Page values" link. Somehow, I checked in the patch without actually testing it out! My guess is that it works for MediaWiki 1.35, but not for older versions, so I'll have to change how this code gets called. I should note that this change was made after Cargo 2.6 came out (the next day, actually), so if you use the official Cargo 2.6 code, that sidebar link should work fine. Yaron Koren (talk) 01:37, 25 June 2020 (UTC)

Okay, I just checked in a fix for this. Yaron Koren (talk) 15:54, 25 June 2020 (UTC)

Works in newest version, thanks for the fix, Yaron! Tenbergen (talk) 20:14, 9 July 2020 (UTC)

Cargo results and "What links here"

When my Cargo query returns one page name (page B) in the default list format, which displays as a wiki link on page A, that wiki link does not cause page A to show up in the "What links here" list of page B. It's not a problem, as using "template" format instead, where the template just has [[{{{1}}}]] does make page A show up in the "What links here" of page B. I just thought I might mention it here in case anyone is searching for a solution! Thanks again for a great extension. Jonathan3 (talk) 15:06, 1 July 2020 (UTC)

Thanks for the hint about the template format for fixing the what-links-here. I had noticed that links generated by cargo queries don't show up in the what-links-here, and thought it was just something I'd have to live with. I wonder if there is a sensible place in the main documentation pages to put this. The template format maybe? Tenbergen (talk) 20:14, 9 July 2020 (UTC)

Field _lastUploadDate in table _fileData doesn't update

I have a set of pictures of which we re-upload new versions several times a week. We have a table that lists these files, and their last upload. The date in that field doesn't update when a new version is uploaded. Turns out that the Cargo table when viewed from special pages doesn't update either. If I run php setCargoFileData.php to fix the table, the data in the table is then right. The table on the page still doesn't update until I click the mediawiki refresh tab. Should this update automatically, or do I need cron jobs to regularly run php setCargoFileData.php? Tenbergen (talk) 20:14, 9 July 2020 (UTC)

Are the uploads done "manually", or using some kind of bot? Yaron Koren (talk) 20:46, 9 July 2020 (UTC)

Uploads are done manually. Tenbergen (talk) 04:39, 25 July 2020 (UTC) Should it make a difference? Tenbergen (talk) 23:34, 28 July 2020 (UTC)

If this is just how it works, then should I run php setCargoFileData.php as a nightly cron job? Tenbergen (talk) 21:24, 12 August 2020 (UTC)

Sorry for the delay. I finally looked into this, and indeed Cargo did not update the _fileData table on a re-upload. I checked in a fix for this, so if you get the latest code, I think this problem will go away. Yaron Koren (talk) 20:00, 13 August 2020 (UTC)

I pulled down the newest version and it updates _lastUploadDate correctly now. Thanks for your patience with my persistence, and THANK YOU for the fix. Tenbergen (talk) 21:11, 13 August 2020 (UTC)