Extension talk:Cargo

From mediawiki.org
(Redirected from Extension talk:Cargo/FAQ)


Display Format Table without Sortable[edit]

I would like to display the results of the query in a table, but not allow for that table to be sorted. Format=Table appears to force sorting on. How can I work around this? 2601:C2:8201:6940:0:0:0:42E2 19:20, 16 June 2022 (UTC)Reply[reply]

Well, the table will always be sorted on something. If you want it to look unsorted, you could always add an "order by=" with some random field that's not in the table, like "order by=_pageID". (Though _pageID will reflect the order in which the pages were created, so maybe that's not ideal either - you could instead do something like "order by=_pageID % 100".) Yaron Koren (talk) 20:04, 16 June 2022 (UTC)Reply[reply]
You could use format=template to create a table from scratch.
Maybe you could use css to hide the arrow icons.
Maybe you could use JavaScript to get rid of the class that makes the table sortable. Jonathan3 (talk) 20:11, 16 June 2022 (UTC)Reply[reply]
Oh... maybe I misunderstood the question. Yaron Koren (talk) 20:15, 16 June 2022 (UTC)Reply[reply]
Thank you for the reply. Currently, I am using the workaround of hiding the sorting arrows via css changes. Jonathan3's suggestion to remove the headerSort class via javascript is viable, but I would like to avoid bloating my wiki's common.js with changes like this. 2601:C2:8201:6940:0:0:0:42E2 01:28, 17 June 2022 (UTC)Reply[reply]
Why do you want to disable sorting, if I may ask? Yaron Koren (talk) 02:04, 17 June 2022 (UTC)Reply[reply]

table format in lua[edit]

Hello how to draw a conclusion in a table

local args = { where = 'categories HOLDS "..."', limit = '100', orderBy = '_pageName', format = table }

format = table doesn't work, bottom doesn't show (View (previous 50|next 50) (20|50|100|250|500))

Thanks!

--Oleksii 212.80.62.177 10:54, 20 June 2022 (UTC)Reply[reply]

There is no way to add that specific footer to the end of query results - for the "table" format or otherwise - in Cargo, as far as I know; that interface is really meant for the bottom of special pages. Yaron Koren (talk) 14:07, 20 June 2022 (UTC)Reply[reply]

Do not have permission to recreate Cargo data[edit]

Hello,

I have installed Cargo extension in bluespice free.

I have a sysops role.

When I try to create a cargo table using ?action=recreatedata I get a permission error

"You do not have permission to recreate Cargo data, for the following reason:

You are not allowed to execute the action you have requested."

What have I to do to get it working ? Vn596174 (talk) 11:45, 22 June 2022 (UTC)Reply[reply]

That's odd - are you sure you're part of the "sysop" group"? And what version of Cargo are you running? Yaron Koren (talk) 13:59, 23 June 2022 (UTC)Reply[reply]
I have the same problem. To work around it il did the following:
- deactive all bluespice extensions in settings.d, keeping only mediawiki ones
<?php
return; // Disabled.
- create cargo tables
- active all bluespice extensions
<?php
//return; // Disabled.
Now you can add data to cargo tables but still not use recreate data
I think this is caused by the way BS uses permissions (see BlueSpicePermissionManager Extension:PermissionManager - MediaWiki) 2001:861:4745:7590:9D8B:EFCB:F425:7B79 13:39, 16 July 2022 (UTC)Reply[reply]

cargoRecreateData throws error after upgrade to MW1.38.1[edit]

Hello,

after upgrading to MW 1.38.1, one of my tables is throwing this error for every page when doing cargoRecreateData:

PHP Notice:  Undefined index: Image in /var/www/mediawiki-1.38.1/extensions/Cargo/includes/parserfunctions/CargoStore.php on line 472

'Image' is one of the fields and is set to NULL in every entry. There are other fields within the same table that are set to NULL but those are not giving any problem.

Thank you very much for your support Carloposo (talk) 08:20, 1 July 2022 (UTC)Reply[reply]

This may be a silly question, but does the Cargo table actually contain an "Image" field? Yaron Koren (talk) 13:59, 1 July 2022 (UTC)Reply[reply]
Hello Yaron, yes, it does contain an "Image" field--Carloposo (talk) 07:58, 4 July 2022 (UTC)Reply[reply]
Yes, indeed... what does the line for "Image" look like in the #cargo_declare call? Yaron Koren (talk) 01:16, 5 July 2022 (UTC)Reply[reply]
Hello, the #cargo_declare looks like this:{{#cargo_declare:_table=Documents|Requires_editing=Boolean (hidden)|Type=String|Project=Page|Activity=Page|Topic=List (,) of String|Scope=List (,) of String|Authors=List (,) of Page (hidden)|Tool=Page (hidden)|Contact=Page (hidden)|Attachments=List (,) of String (hidden)|Image=File|Meeting_time=Datetime (hidden)|Meeting_location=String (hidden)|Meeting_participants_CE=List (,) of Page (hidden)|Meeting_participants_CQ=List (,) of Page (hidden)|Meeting_participants_companies=List (,) of Page (hidden)|Meeting_document_date=Date (hidden)|Car_review=Page (hidden)}}
Thanks!--Carloposo (talk) 07:49, 5 July 2022 (UTC)
Reply[reply]
Screenshot Documents table fields.png
Thanks for that listing. You discovered a bug in the handling of "File" fields - sorry about that. I and someone else just checked in a fix for it, so if you get the latest Cargo code, those PHP notices should go away. Yaron Koren (talk) 03:07, 6 July 2022 (UTC)Reply[reply]
Great, thanks. --Carloposo (talk) 07:44, 6 July 2022 (UTC)Reply[reply]
Also, there was another error being thrown, which is still present:

Recreating data for Cargo table Activities in 5 seconds... hit [Ctrl]-C to escape.
Deleting and recreating table...
Handling template that adds to this table: Activity
PHP Deprecated: Use of Title::$mDbkeyform was deprecated in MediaWiki 1.37. [Called from CargoRecreateData::recreateAllDataForTable in /var/www/mediawiki-1.38.1/extensions/Cargo/maintenance/cargoRecreateData.php at line 153] in /var/www/mediawiki-1.38.1/includes/debug/MWDebug.php on line 377

Thanks for letting me know about that - this, too, is fixed now, I believe. Yaron Koren (talk) 16:53, 6 July 2022 (UTC)Reply[reply]
I confirm it's fixed. Thanks Yaron. --Carloposo (talk) 09:06, 7 July 2022 (UTC)Reply[reply]

Create Class error message "This appears to be a cross-site request forgery - Save cancelled"[edit]

What does this error message mean? I had completed defining all the fields for a table, went to save it and got that message. Before entering it all again and hoping for the best, I would prefer to know what I might have done wrong. I had previously deleted the table and was recreating it with less and altered fields, and was following the same process as for an earlier table that did save successfully. I love the Build Class feature, it is a pity there is no Modify Class as well as manually editing templates to add or edit fields is a painstaking task, hence I have found it easier to start again if there is not much in the table yet. I am using Mediawiki 1.36.2 and Cargo 3.1. Thanks, Robert

I'm guessing/hoping that it's a one-time thing, and if you try it again it'll work fine. That said, if you want to be able to modify the class with a form, check out the Page Schemas extension. Yaron Koren (talk) 13:56, 8 July 2022 (UTC)Reply[reply]

Cargo_query error[edit]

Hello,

Running php update.php after installing the Cargo extension, I have created a cargo table using the following template

Template:MSStandard

<noinclude>
{{#template_params:MSSReference|MSSTitle|MSSAbstract|MSSPublicationDate|MSSEdition|MSSStatus|MSSType|Language}} {{#cargo_declare:_table=MSStandard|MSSReference=String|MSSTitle=String|MSSAbstract=Text (size=3500)|MSSPublicationDate=String|MSSEdition=String|MSSStatus=String (allowed values=WD,CD,DIS,FDIS,IS)|MSSType=string (allowed values=MSS-A,MSS-B)|Language=String (allowed values=English,Français)}}</noinclude><includeonly>{{#cargo_store:_table=MSStandard}}
{{#template_display:_format=standard}}
[[Category:MSStandard]]
</includeonly>

When I add a page using the template everything is OK, the page is created and the cargo table is populated.

Every time I add a cargo query to the page there is an error message

A database query error has occurred. This may indicate a bug in the software.
[efdb63d66f6075643dec9f82] /index.php/MSStandard-0010 Wikimedia\Rdbms\DBQueryError from line 1700 of C:\laragon\www\BS412Cargo\includes\libs\rdbms\database\Database.php: A database query error has occurred. Did you forget to run your application's database schema updater after upgrading?

{{DISPLAYTITLE:{{#cargo_query:table=MSStandard | fields=MSSTitle | where=_pageID = {{PAGEID}} AND Language = {{#switch: {{int:lang}}|fr="Français"|en="English"}}|no html}} }}

Error 1064: You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near 'ORDER BY `cargo_MSStandard`.`_pageID`,`MSSTitle` LIMIT 100' at line 1 (localhost:3306)
Function: CargoSQLQuery::run
Query: SELECT `cargo_MSStandard`.`_pageID` AS `cargo_backlink_page_id_MSStandard`,`MSSTitle` AS `MSSTitle` FROM `cargo_MSStandard` WHERE _pageID = 7 AND Language = ORDER BY `cargo_MSStandard`.`_pageID`,`MSSTitle` LIMIT 100
Backtrace:

With Special:CargoQuery the problem occurs if the "Where" field is completed. Filling "Table" and "Fields" gives the expected results

One more point, looking at cargo_backlinks there is no data. All ohter cargo tables have data

Thanks for your support 2001:861:4745:7590:4027:16E4:389A:2D1F 11:20, 14 July 2022 (UTC)Reply[reply]

I'm guessing that the issue there is that {{int:lang}} is, for whatever reason, returning a value that's neither "en" nor "fr", and thus messing up the query. I would try replacing this part of the query:
{{#switch: {{int:lang}}|fr="Français"|en="English"}}
...with this:
'{{#switch: {{int:lang}}|fr=Français|en=English}}'
Hopefully that will at least prevent the query from crashing. Yaron Koren (talk) 13:26, 14 July 2022 (UTC)Reply[reply]
There is no more database error. Many thanks Yaron 2001:861:4745:7590:2973:A2FE:A833:3E34 16:35, 14 July 2022 (UTC)Reply[reply]

Debugging why Cargo data is not storing[edit]

This is using Cargo v3.2. The example page is https://spcodex.wiki/wiki/Haenim. Under the "Releases" section, we use Template:Release (see source if needed). When I made this edit, which doesn't even touch the Releases section, Cargo removed the row from the releases table (see query). I can't for the life of me figure out why this is. Given I don't have sysadmin access, are there are debugging tips to figure out what's going on? This may have been effected by the MediaWiki 1.38 upgrade on Miraheze. There's at least one other page (The End Is the Beginning Is the End) that seems to have the same problem. In both cases, other Cargo data (such as the infobox which stores into the songs table) is saving without issue.

Thanks for any help you can provide. MusikAnimal talk 21:45, 18 July 2022 (UTC)Reply[reply]

That's strange. Normally, I would say calling cargoRecreateData.php from the command line is the best way to see what problems are coming up, but it sounds like you don't have command-line access. If that's the case, then maybe the best approach is to find a call to the "Release" template that does store correctly, and make incremental changes to the non-working one to match the working one, until you find the difference that makes it work/not work. Hopefully that won't take too long. Please let me know if you do! Yaron Koren (talk) 02:23, 19 July 2022 (UTC)Reply[reply]
Well I know it doesn't save if something doesn't pass validations (say you didn't provide a required field). In this case though, there have been no changes to Template:Release, or the wikitext that uses it. That's what had me thinking it had something to do with the MediaWiki upgrade and/or Cargo (which I assume was upgraded in tandem).
Anyway, I've already compared this use of Template:Release with others that are still working and don't see any obvious reasons the one doesn't work. I will reach out to the sysadmins and see if they can run the script for me. Speaking of which, is it possible to use cargoRecreateData.php and store into a replacement table (keeping the normal one still there for querying), just like you can in the UI? Thanks, MusikAnimal talk 03:51, 19 July 2022 (UTC)Reply[reply]
Yes - just use the "--replacement" flag. Yaron Koren (talk) 13:14, 19 July 2022 (UTC)Reply[reply]
@Yaron Koren Finally got a sysadmin to the run the script, and they said it worked without any errors. The table was fully regenerated, restoring rows that were previously missing. So I'm afraid what's going on is a bit of a mystery... I tested re-saving some of those effected pages and sure enough, it still removes the row from the db.
Miraheze staff did mention there were lots of these warnings generated by the script: Notice: Undefined index: wgCargoLegacyNullLuaFieldsAsEmptyString in /srv/mediawiki/w/extensions/Cargo/includes/CargoLuaLibrary.php on line 94
That doesn't seem related, but I'm sharing it just in case.
My question for you is, does action=recreatedata not do the same thing as the cargoRecreateData.php maintenance script? I've noticed that when I use the UI (action=recreatedata), data regeneration is very slow and often does not finish at all. I have to go through each page that's still missing and do a null edit, then it will appear in the replacement table. I'm guessing this is an issue with the job queue? It may be specific to Miraheze. But at any rate, I'm a real bind here as my wiki is vulnerable to having data be removed slowly over time, anytime someone edits one of the effected pages :(
Assuming I were to have sysadmin access, what's the best way to debug what's happening with those page saves and it removing rows from the db? If it helps, I maintain this wasn't an issue some months ago, likely aligned with the MediaWiki/Cargo upgrade to REL1_38. MusikAnimal talk 18:17, 28 July 2022 (UTC)Reply[reply]
Thanks for letting me know about that PHP warning - it's indeed unrelated, but it was good to know about. I just checked in a fix for it. In your case, there are three things: cargoRecreateData.php, action=recreatedata, and individual page saves - and it sounds like the last two are failing. It does sound like there's a problem with the job queue running very slowly. But I still recommend that approach of taking a non-working page, and modifying it until its data gets saved correctly, to try to figure out what is causing the problem. I can't think of another solution at the moment. Yaron Koren (talk) 21:23, 28 July 2022 (UTC)Reply[reply]
@Yaron Koren Alright, so I think I'm on to something! As it turns out, it's not just Template:Release that's failing to store, but any of the templates on the page that use {{#cargo_store}}. I did a test by moving Template:Release to the very top of the page, and then it always saves correctly. But, things further down may or may not save. None of it seems consistent, but it's clear to me there's an issue with multiple uses of cargo_store on the same page. In one case, I managed to get all data properly saved when it didn't on the previous try.
Can you think of anything that changed in REL1_38 from REL1_37 that might have caused this? I tried to review the code changes myself, and one thing that stood out is the removal of lockForUpdate in CargoStore.php. Could that be it, perhaps?
I went to debug this on my local dev environment, but alas Cargo apparently doesn't support SQLite (which I only use as it's the default dbms for MediaWiki-Docker). I may make a patch to fix that, assuming all you need are the SQLite equivalents of the files in /sql? MusikAnimal talk 03:40, 31 July 2022 (UTC)Reply[reply]
I actually didn't know that Cargo is not working with SQLite - it's supposed to. Yes, whatever you can do to help provide/restore SQLite support would be great. As for the change between branches - I have no idea. I don't really know what's in either of those branches, and I don't recommend that anyone use the REL branches for Cargo or any of my other extensions. I doubt the "lockForUpdate" removal is the issue, but you never know. Yaron Koren (talk) 14:10, 1 August 2022 (UTC)Reply[reply]
@Yaron Koren Okay so I haven't had much time to debug this, but I have come to a few conclusions. First, SQLite is supported, except in my case the transactions (Database::begin() and ::commit()) are not. This functionality apparently doesn't ship with SQLite out of the box. Seems like something MediaWiki should handle on its own, but whatever, at least we know why it isn't working. The symptoms by the way are after starting a transaction, no further code is executed and the process just hangs indefinitely until the request times out.
Secondly, the job queue on Miraheze quite simply sucks. I can trigger the building of a new replacement table using the Cargo API (or UI), and it just sits indefinitely. It will only populate rows after edits to the effected pages (or null edits). So my question now is, does populating the databases on a page save also use the job queue? If so, the mystery is probably solved and we can blame it on Miraheze.
Remember that the first use of {{#cargo_store}} on the page seems to always save. It's the subsequent ones that sometimes do, sometimes do not. So I'm wondering if Cargo is programmed to do those latter saves via job queue? MusikAnimal talk 18:33, 31 August 2022 (UTC)Reply[reply]
Okay, that SQLite problem definitely sounds like it requires a patch - to either Cargo or maybe MediaWiki itself?
Saving a page directly (which calls #cargo_store) does not use the job queue, but recreating or creating a Cargo table does. So yes, this might be a problem with the job queue. I should note that just viewing pages over and over again should trigger jobs to run as well - it shouldn't be necessary to re-save pages in order to get jobs to run. Yaron Koren (talk) 20:54, 31 August 2022 (UTC)Reply[reply]

Best way to remove field from existing table[edit]

What about this?

  1. Remove field from PF form page.
  2. Remove field from Cargo template page.
  3. Recreate table.
  4. Remove field values from content pages using Extension:ReplaceText.

With ReplaceText, what would be the best regex to remove a whole line (including its line return) like this:

|Fieldname=value

Thanks. Jonathan3 (talk) 12:14, 2 August 2022 (UTC)Reply[reply]

Sure, that sounds right. For the regex - I haven't tried it, but this might work: |Fieldname=.*\n. Yaron Koren (talk) 14:03, 2 August 2022 (UTC)Reply[reply]

[SOLVED] How to use field values from one table as the allowed values of an other?[edit]

How can I use field values from one table as the allowed values of an other?


Example case:

Table A has field B that holds values x,y and z

Table D has field D

Can I somehow dynamically use the values from field A.B as the allowed values in Table C, field D?

I've tried to define it like in the below example but this results in a "QINU issue"

{{#cargo_declare:_table=C
|D=Page (allowed values={{#cargo_query:tables=A|fields=A.B}})
}}

Am I missing something?

Is this at all possible?

SOLVED (see thread below)

Limit the allowed values from the page form by:

{{{for template|WhateverTemplateYouUsedToDeclareCargoTable_C}}}
Value D:{{{field|D|cargo table=A|cargo field=B}}}
{{{end template}}}

Wim (talk) 11:39, 3 August 2022 (UTC)Reply[reply]

I wonder whether you could set up a separate page containing the allowed values (ie your cargo query). Jonathan3 (talk) 11:56, 3 August 2022 (UTC)Reply[reply]
Whether or not this is doable, it seems like a bad idea, because the set of values can change at any time. Much better, I think, would be to set the allowed values in the form, assuming you are using Page Forms. Yaron Koren (talk) 13:27, 3 August 2022 (UTC)Reply[reply]
I've had to do this today. It's possible with the cargo table, cargo field and cargo where parameters: see Extension:Page_Forms/Defining_forms. Jonathan3 (talk) 22:23, 4 August 2022 (UTC)Reply[reply]
@Jonathan3
That's exactly what I needed.
Took me a while to figure out the correct syntax though, but I got it to work.
Thanks for pointing that out! Wim (talk) 14:53, 8 August 2022 (UTC)Reply[reply]

Constant field not working in query[edit]

When I try to add a constant to the fields I keep getting an error that the field doesn't exist in the table. Any idea why?

MediaWiki  1.30.1, PHP 7.1.33, MySQL 5.7.38, Cargo 2.1.1

109.253.216.196 19:25, 4 August 2022 (UTC)Reply[reply]

What do you mean by "add a constant to the fields"? Yaron Koren (talk) 20:09, 4 August 2022 (UTC)Reply[reply]
A constant value in the fields paramter of #cargo_query. But nevermind, I realized I was expecting it to work using something like '1' AS SomeField. Worked using '1'=SomeField 109.253.216.196 21:03, 4 August 2022 (UTC)Reply[reply]

Using display format "dynamic table" with a template for the rows? Or some other way to format the rows?[edit]

I'm using the External Data extension's #get_db_data function to pull from a database, and its #format_external_table function to pass the data to Cargo for formatting. My initial, very basic, tests worked fine. But since I started looking into something more complex, I've gotten the feeling that I'm missing something.

I then decided I wanted pagination, sorting, searching and so forth. It looks like the "dynamic table" format is intended for this. But I don't understand how to format the rows. In the past, I had used Cargo directly, and (without dynamic table) I would typically format the rows using the "template" display format. But with dynamic table, I don't see a way to specify a template... or any other way to format the rows.

I've read the help page on the display formats, but I haven't been able to get a hint from them. And of the two external examples it links to, one ("HUES list of technology entries") seems to be dead, at least for the time being (504 gateway timeout); the other ("Traveler Wiki - list of sophonts") is clearly formatting the rows *somehow*, but I don't understand how from the source. I guess it has something to do with the <DPL> tag? Which I know nothing about, and doesn't seem to be mentioned in the Cargo help file.

All else equal, I think I'd like to pass the data from each row to a wiki template, but I'd be interested in pretty much any way to format the data. Thanks in advance. -Rwv37 (talk) 05:25, 8 August 2022 (UTC)Reply[reply]

Thanks for letting me know about the dead link - I just updated the list of examples. There's no easy way to format the rows or cell contents in "dynamic table", and there's no formatting going on in that Traveler Wiki example. (The <DPL> tag you see is for the table below the dynamic table.) What kind of formatting do you want to do? Yaron Koren (talk) 14:09, 8 August 2022 (UTC)Reply[reply]
Oh, I see about the <DPL> thing now. Thanks.
The Traveler link has hyperlinks in its rows. I don't see how that's happening from the source.
I'd like to be able to "wikify" raw data pulled out of the external DB. Basically anything I can do with the "template" format. Easy-seeming example is just hyperlinks, like that Traveler page, but not necessarily to pages with the exact same names as the raw data.
Anyway, if this sort of thing is not possible with "dynamic table", is there perhaps some other way to get the pagination/search/sorting kind of things that are all I really want from "dynamic table"?
Thanks again. -Rwv37 (talk) 18:07, 8 August 2022 (UTC)Reply[reply]
You can do a lot with functions like CONCAT(), CASE() and IF() in the query - for example, if, in the "fields=" list, you replace SomeField with CONCAT('[[', SomeField, ']]'), it will turn each value into a wiki-link. (That doesn't need to be done for fields of type "Page", which get displayed as links automatically.) But no, I don't think there's a way to get that in-page pagination and search outside of the "dynamic table" format. Yaron Koren (talk) 18:25, 8 August 2022 (UTC)Reply[reply]
Thanks - I've done the CONCAT (etc.) sort of thing fairly often with Cargo alone, and I actually have tried it with External Data + Cargo. I can get it working to some degree, but not as much as I had with Cargo alone. I might be doing something wrong, but are you sure it works with ED+C?
For example, CONCAT(FirstName, ' ', LastName) comes out as expected, like "Arthur Fonzarelli", but CONCAT('[[', FirstName, ' ', LastName, ']]') comes out (from the end user's point of view) as "[[Arthur Fonzarelli]]" (as if it were wrapped by nowiki), not as the text "Arthur Fonzarelli" hyperlinked to the page "Arthur Fonzarelli". -Rwv37 (talk) 18:55, 8 August 2022 (UTC)Reply[reply]
Oh, I didn't notice (or didn't fully think about) the fact that all this data comes from an external data source. In that case, it's not surprising that calling CONCAT() won't really work - sorry for the bad advice. The wiki is getting a certain set of text from an outside data source - it has no way to know whether it should be parsed as wikitext. I think the right solution for this problem is to be able to set, within #format_external_table, the "type" of each field - I'm not sure how best to do that, though. For now, maybe the best solution for you is to add some custom JavaScript to MediaWiki:Common.js that would apply whatever formatting is desired to the values in this table. Not very convenient, but I can't think of a better approach. Yaron Koren (talk) 23:52, 8 August 2022 (UTC)Reply[reply]
OK, so for now I'll just use the "template" display type and show the whole table, then later worry about adding JS/CSS to deal with pagination and whatnot. Thanks again. -Rwv37 (talk) 01:14, 9 August 2022 (UTC)Reply[reply]
Alright. Just to be clear, I meant adding JS on to "dynamic table", not "table" - I think changing around the values to be links, etc. would be much easier than adding custom controls. Yaron Koren (talk) 03:20, 9 August 2022 (UTC)Reply[reply]
Seems like the other way around would be way easier as a first step (the "template" display format is pretty easy to use). Then I imagine I could find an existing JS library to manually hook up to the table (potentially the same one Cargo's "dynamic table" uses), at my (relative) leisure. Plus, it seems like the final result would degrade to a better user experience (if the user has javascript disabled, for example). -Rwv37 (talk) 03:56, 9 August 2022 (UTC)Reply[reply]

Unable to query for a single item when all other items work fine. String length limit?[edit]

Situation: We have a system of pulling information from various sources for data on where items are used in the game. We have one item called Eternal Lord of The Undying Ember which seems to be causing problems. The only information being returned is the quest data which I had to create a custom wrapper to generate to bypass our tooltip system (Not an issue for the recipe data which is stored as a normal string). The problem is that I can't for the life of me figure out how to solve this problem, or even diagnose exactly where it is failing. Some pages (in a table because the site took offense to offsite links):

Description Plain text link
Page showing Item that displays the queried Data idleon.info/wiki/Eternal_Lord_of_The_Undying_Ember
Page storing the item through it's ForgeSlot template idleon.info/wiki/Deuscythe
Another item stored by the previous page that correctly shows it is being queried. idleon.info/wiki/Black_Lense
Cargo Database AnvilCraft containing the "Duescythe" entry with the offending item listed under Resource 3. idleon.info/wiki/Special:CargoTables/AnvilCraft
Usedin template used to query the data itself. idleon.info/wiki/Template:Usedin

Kiokurashi (talk) 07:25, 11 August 2022 (UTC)Reply[reply]

Sorry, what specifically is the page where the data isn't showing up, and what's the data? By the way, you can link to these pages directly - here is that "Undying Ember" page, for example. Yaron Koren (talk) 00:00, 12 August 2022 (UTC)Reply[reply]
I know I can link directly, but when I tried to do so the site told me that I couldn't because this is not wikipedia and then didn't actually submit the post. So that's why I made text links.
Eternal Lord of The Undying Ember is the page where the information should be appearing within that first table. We currently have two tables with one being manually added just so the information is there while we sort out this problem.
What it should be doing is pulling the information from the AnvilCraft database (and a few others) for smithing recipes that item is used in. The fact that the quests are being pulled from shows that the Usedin template call that contains the query for all of the data across all tables is actually being called. The Black Lense page shows that the same template call is working since it shows the smithing recipes it is used in.
What I'm trying to figure out is why there's a disparity between these two pages when, as far as I can tell from the respective databases, everything is set up the same. My only assumption is that the lenth of the page name is causing an issue, but I have no way to test that or even be certain since the quests still work. Kiokurashi (talk) 04:46, 12 August 2022 (UTC)Reply[reply]
Okay, I think I understand. I looked at "Deuscythe", one of the pages that should be appearing but isn't. For that page, I think the issue is that the "Eternal Lord ..." value has an extra space in it. That might be the issue with all the pages, I haven't checked. Yaron Koren (talk) 18:00, 15 August 2022 (UTC)Reply[reply]
Sorry for the late reply (I wasn't at home for a few days), but you're absolutely right! It's also something that's been a problem before, but I didn't remember it since it's been a while since that was a problem. Thank you for your help! Kiokurashi (talk) 21:51, 17 August 2022 (UTC)Reply[reply]

Hide some tables from Drilldown page[edit]

Is this possible?

It would be good if there were a parameter for #cargo_declare to achieve this.

I wondered about hiding it with CSS. I see the table tab items are within html li class="tableName" but there aren't any ids. Without ids, I guess it'd be possible using "nth" item CSS, but I'd likely forget to change it when new tables get added.

Or maybe Javascript but that might be a sledgehammer to crack a nut. Jonathan3 (talk) 10:47, 14 August 2022 (UTC)Reply[reply]

Right - as you suspect, it's not possible. It probably would be good to allow hiding a whole table - or at least, as you suggest, adding an HTML class with the table name in it. Yaron Koren (talk) 17:57, 15 August 2022 (UTC)Reply[reply]

Empty cargo query result[edit]

Hello,

I wish to test whether or not the specific field of a specific row (located by an Id) is defined or not to then proceed with different actions. I thought it'd be as simple as doing #if: #cargo_query:tables=table| fields = field| where = Id='id' | route1 | route2 and call it a day but it seems like although the cargo query result looks empty, it's somehow not so I can't differentiate between the fields that are defined or not. (It doesn't accept the default argument btw, meaning it does seem to find a result that shouldn't exist and that isn't displayed either)


I've tried going around the issue by using ifeq to compare the result to another undefined field but to my surprise both results are apparently different although both look empty and haven't been defined. I'm at a loss. 151.35.40.188 21:02, 26 August 2022 (UTC)Reply[reply]

You might just need to add "|no html" to the #cargo_query call(s). Although I don't know why "default=" isn't working. Yaron Koren (talk) 13:26, 29 August 2022 (UTC)Reply[reply]
That actually worked, great, thanks. I'm confused as to why that'd be the solution though, any clue for future reference ? (Also, it's still not accepting the default parameter even though "no html" did make it register as empty towards the #if) 151.35.109.90 14:54, 29 August 2022 (UTC)Reply[reply]
The #cargo_query is, by default, parsed by the MediaWiki parser - which means that even a blank result gets some tags around it, which the MW parser adds. Adding "no html" keeps the parsing from happening. I don't know why "default=" isn't working, though. Yaron Koren (talk) 16:30, 29 August 2022 (UTC)Reply[reply]
Makes sense, thanks for the help and knowledge ! 151.19.120.33 16:43, 29 August 2022 (UTC)Reply[reply]

Data disappearing from Cargo[edit]

Hello,

My cargo table has started randomly losing a few entries and I have no idea why. I didn't change anything to the way I store the entries and such. The last change I made was adding a few fields, currently at 23, I doubt that's enough to trigger a maximum cap, is it ?


I have to recreate the data everything for it to get every entries again but 20-30mins later it just starts losing a few entries again. The number of entries lost stays around 20 and it's always amongst the latest entries. It loses them all at once and then it stays stable. I have no clue what's going on. I'd appreciate any idea. 151.43.184.169 16:54, 27 August 2022 (UTC)Reply[reply]

Are you using the Page Forms "pop up" editor? I found that sometimes (always?) after using that a page disappears from the Cargo table until it's recreated. I've not noticed the same problem as you describe, though. Jonathan3 (talk) 21:04, 28 August 2022 (UTC)Reply[reply]
I'm not using that editor, no. Thanks for letting me know though, I'll keep that in mind for when this issue is solved, hopefully soon. 151.35.109.90 12:43, 29 August 2022 (UTC)Reply[reply]
I've never heard of this happening - rows disappearing from a Cargo table in a way that's apparently unrelated to any user actions. (I also haven't heard of problems with popup forms, but that's another story.) I doubt adding fields, or any other changes to the table, would cause this problem - if the rows never showed up at all, then the table structure would be a possibility, but given that they show up but then go away again, I have no idea. Yaron Koren (talk) 15:33, 29 August 2022 (UTC)Reply[reply]
It has actually stopped happening since yesterday and I haven't made any change to the cargo so not sure what that was. What I'm still annoyed about is how often the recreate data process fails, creating an empty replacement table that I have to delete and then repeat the process. It usually works after 3-4 tries but sometimes, like today I've tried it 22 times and it's still not working.
Is that something I can fix ? Not sure if it's because of the cache or anything I have control over. I'm using fairly small tables too, all under 100 entries. 151.19.120.33 16:09, 29 August 2022 (UTC)Reply[reply]
That's odd as well. Is the recreate being done from the web interface? If so, I'm guessing it's due to a very slow job queue. Yaron Koren (talk) 16:19, 29 August 2022 (UTC)Reply[reply]
I'm doing it from the web interface, yes, though not sure what else would be on the queue for it to take this long. Thankfully I don't have to recreate the tables often but when I do, it's often a drag 151.19.120.33 16:43, 29 August 2022 (UTC)Reply[reply]
Alright. If you have command-line access, the command cargoRecreateData.php should generally work much more reliably - and you could also run the MediaWiki command runJobs.php, to see what (if anything) is clogging up the job queue. Yaron Koren (talk) 19:51, 29 August 2022 (UTC)Reply[reply]
The wiki's owner doesn't seem to know how to run command lines, much less give me access. We're both new in handling wiki's. Sorry that this is getting further away from Cargo but do you know anywhere I could get precise instructions for setting up command line access for both of us ? 151.35.47.56 19:44, 30 August 2022 (UTC)Reply[reply]
Sorry, I don't know - that's not even really a MediaWiki question. Yaron Koren (talk) 20:20, 30 August 2022 (UTC)Reply[reply]
Yes, you definitely want to have command line access, as the web-based table recreation doesn't display any errors and will just stop when it comes to the first page that causes an error. With the command line table recreation script it also stops suddenly but shows an error. It could be something as simple as a problematic character in a page name. Jonathan3 (talk) 12:58, 8 September 2022 (UTC)Reply[reply]

Duplicate results in Special:Drilldown[edit]

I never got to the bottom of Extension_talk:Cargo/Archive_January_to_May_2022#Duplicate_rows_again,_but_this_time_only_in_Special:Drilldown.

Essentially, a page which matches n selected values on a filter field is displayed n times in Special:Drilldown.

For example, here's something I found on a public wiki at https://www.funtoo.org/Special:Drilldown/video_cards?_single&platforms%5B0%5D=DRI&platforms%5B1%5D=Vulkan&platforms%5B2%5D=X

Any ideas? Thanks. Jonathan3 (talk) 21:02, 28 August 2022 (UTC)Reply[reply]

I've filed a bug report on Phabricator: phab:T317306. Jonathan3 (talk) 12:47, 8 September 2022 (UTC)Reply[reply]

Best practice when storing data to avoid double null edits each time[edit]

Hi! Let's say I have a wiki about library and have a lot of books pages, each book page uses "{{Template:Book| name=...| year=... }}"

The template parameter are being saved to cargo from the Book template.


Moreover, the Book Template Will show the Book data but it will do it from the cargo db using queries because the it will be eaiser to have it structured (and joined maybe with other tables).


In this case, When I'm changing any data to Book "A" for example, I'll need 2 saves in order to "refresh" the page, 1 edit will be for the save and the second in order to refresh the data that is being shown to the user.


Unfortunately that very time consuming and sometimes the data is not updated after even 2-3 null edits.


I assume I'm not the only one who saves the data using this approach, there are maybe any best practices/ideas about how can I avoid this extra time when adding/changing data?


Thanks! Koshob (talk) 00:15, 2 September 2022 (UTC)Reply[reply]

I would hope that there's no need for each book page to query Cargo to get its own data, given that its own data is right there on the page... I don't know the specifics of what you're trying to display, though, but that would be the obvious fix for this problem.
You don't need to re-save the page in order to refresh it - all you need to do is purge the cache, via "action=purge" - Cargo provides a "Purge cache" tab/action to let you do that directly. You can also simply disable caching for such pages in the first place, using the MagicNoCache extension, which might be an even better solution. (If you did that, a simple browser reload would be enough to show the correct data.) Though the best solution, I would think, is to avoid having pages querying themselves. Yaron Koren (talk) 13:08, 2 September 2022 (UTC)Reply[reply]
Thanks for the response. We use non-default skin and we came up with the same solution (adding a "refresh" action to the menu that uses purge) before some time. But unfortunately that not always help, regarding the showing the data - it more comfortable to query the data and show it (to allow us join some data from other tables and have it sorted + filtered. My main problem is how can I identify pages that should be "updated" (So I can purge them automatically using automation) - do you have any idea for that maybe ?:) Koshob (talk) 10:34, 3 September 2022 (UTC)Reply[reply]
No, although I still recommend you take a look at MagicNoCache. Yaron Koren (talk) 13:41, 5 September 2022 (UTC)Reply[reply]
Will do, Thanks! Koshob (talk) 16:45, 5 September 2022 (UTC)Reply[reply]
I'd like to see your template as without that I can't understand why it doesn't just display the template parameters, e.g. {{{book|}}}. Jonathan3 (talk) 12:54, 8 September 2022 (UTC)Reply[reply]

Handling List (,) of String field[edit]

Hello,

I have a field defined as List (,) of String so its arguments are registred as "A • B • C" and such. For further operations, I'd like to query then split the result. I've made a split function for it but unlike what I assumed the delimiter isn't &nbsp;&bull;&nbsp;. The bullet is &bull; I'm sure but it seems like the white spaces on each sides aren't &nbsp; nor (en,em or thin space either). Any clue what the delimiter here is ? 151.37.147.239 15:51, 4 September 2022 (UTC)Reply[reply]

There's no need to split that value; the individual values are saved in a separate table. Have a look at Extension:Cargo/Storing_data#Storage_of_lists. You just need to join on that table, and do whatever you want with the results. Sam Wilson 02:33, 5 September 2022 (UTC)Reply[reply]
If you do want to work with the result from the main table, for example using Page Form's #arraymap parser function, the delimiter of a List (,) of list is just , - it's only displayed with the bullet points :-) Jonathan3 (talk) 12:51, 8 September 2022 (UTC)Reply[reply]

Save one row (multiple columns) result to variable[edit]

Hi!

I'm using a query that count some items in my table, the query result is a oneline with several columns (each one represent one kind of a count).

I would like to save these result into variables (#vardefine), what will be the best practice regarding it?

The default way that I can think of is to use a template that will just return {{{1}}}, {{{2}}} and so on. any other idea ?:)


Desired behaviour (or similar, but that the general idea)

{{#vardefine:Variables| {{cargo_query:

table=MyTable

|fields=SUM(CASE when column = 1 then 1 else 0 end)=First, SUM(CASE when another_column = 1 then 1 else 0 end)=second

}} }}


I would expect it to be format=list, but list return the second parameter and above as "named argument" and not as raw

Thanks! Koshob (talk) 00:22, 9 September 2022 (UTC)Reply[reply]

I'm not sure what you are trying to do - but maybe it would work better to call #vardefine separately for each variable/value? Yaron Koren (talk) 15:16, 9 September 2022 (UTC)Reply[reply]

Timeline display with a list of start and end dates[edit]

I have a table where there is one field with a list of Start date and a second field with a list of End date. I was wondering if this is supported? Viewing the data as a timeline, the rows where there are a single start/end date display correctly but if there are multiple values they do not show up on the timeline. My use case is that the table includes events (a few weeks to months in length) with the same name and otherwise the same information, but that may reoccur several times. Lgolston (talk) 20:44, 12 September 2022 (UTC)Reply[reply]

No, it's not currently possible to have the timeline display just join together a list of start dates with a list of end dates. I don't know what form your table takes, but is it possible to just have a separate row for each instance of an event? Yaron Koren (talk) 21:03, 12 September 2022 (UTC)Reply[reply]
Hello Yaron, thanks for confirming. This is the main table I am working on currently: https://atmos.miraheze.org/wiki/Special:CargoTables/Field_Campaigns. Making separate rows could be a workaround, but I think I will just leave Start and End as lists, since the timeline feature would be nice but is not critical here. Lgolston (talk) 23:59, 12 September 2022 (UTC)Reply[reply]

Multiple wikis[edit]

Hello,

I'd like to have multiple wikis located on the same server (a wiki-family).

Is there a preferred strategy (see Manual:Wiki family) for Cargo to work at its best, or any of the listed solutions are fine? Carloposo (talk) 09:14, 13 September 2022 (UTC)Reply[reply]

From Cargo's perspective, they're all equally fine - with the one potential issue being that, if you're going to have a separate Cargo database for any or all of the wikis, you have to just make sure that it's a different DB for each one. Yaron Koren (talk) 16:02, 13 September 2022 (UTC)Reply[reply]

Display Format: Dynamic Table with hidden fields[edit]

Hello, I tested "hidden fields" for dynamic tables. I just updated to 3.3 (74bd41c) 15:18, 14. Sep. 2022. And I noticed an "error" or strange behavior:

This setting for hidden fields acts on every cargo_query on a page (with matching fields) and not only the one where I added that parameter.

Brabi81 (talk) 12:23, 15 September 2022 (UTC)Reply[reply]

That's definitely a bug - I think I was aware of that problem. By "every cargo_query", I assume you mean every one that uses the "dynamic table" format - and, as you note, has those same fields. Yaron Koren (talk) 13:06, 15 September 2022 (UTC)Reply[reply]
Yes "every cargo_query" with dynamic table. Brabi81 (talk) 12:28, 19 September 2022 (UTC)Reply[reply]

Two questions[edit]

Hi, I'm using Cargo on a wiki in the Miraheze wikifarm. I think the underlying database is MariaDB, if that affects any answers here.

1) Is there a good reference on what SQL functions are permissible to use for the built-in Cargo table? For example, when casting a float type to an integer, I noticed that FLOOR(x) is acceptable, but CAST(x AS INT) and TRUNCATE(x, 0) fail because CAST and TRUNCATE aren't allowed functions.

2) According to the Storing Data section, "The field description must start with the type of the field, and in many cases it will simply be the type." I'm not sure I understand the first part of this sentence; I have previously tried to add descriptive comments to the field e.g. by doing |field_1 = Integer This is an integer field that stores a value. I was under the impression that this would set field_1 to be an integer type, but it is instead a string type (e.g. doing order_by sorts the field lexicographically). Am I doing something wrong (and there is a good way to add such comments) or does the field description have to exactly be the type of the field?

Thanks, Phenomist (talk) 08:29, 19 September 2022 (UTC)Reply[reply]

For #1 - I don't know if there's better documentation for it than this, but you can find the current set of allowed SQL functions here. But if you have contact with the Miraheze admins, you hopefully can get them to add these other functions by adding lines for $wgCargoAllowedSQLFunctions to LocalSeetings.php. (I don't think there's any specific reason why these two functions are not in the list.)
For #2 - No, there's no good way to add comments, unfortunately, although it's something I've looked into. Generally the field description should just be the type, although there are other parameters that can be added, within parentheses, like " (allowed values=A,B,C)". Yaron Koren (talk) 13:06, 19 September 2022 (UTC)Reply[reply]
If I understand correctly about #2, can't you use for example normal comment sections?
|field_1 = Integer <!-- This is an integer field that stores a value -->
This is what I used a lot when working on templates a few years ago. Perhaps the text you write directly behind the "Integer" definition confuses Cargo, and it converts it to String instead. Pangaearocks (talk) 02:05, 22 September 2022 (UTC)Reply[reply]
Yes, the HTML comment solution is what I ended up doing. The comments don't display on the table pages where they are probably the most visible, but that's fine I suppose. It was mostly due to a misunderstanding of the Cargo documentation. Phenomist (talk) 16:24, 22 September 2022 (UTC)Reply[reply]