Extension talk:Cargo/Archive June to August 2022

Display Format Table without Sortable

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)

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)

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)

Oh... maybe I misunderstood the question. Yaron Koren (talk) 20:15, 16 June 2022 (UTC)

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)

Why do you want to disable sorting, if I may ask? Yaron Koren (talk) 02:04, 17 June 2022 (UTC)

table format in lua

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)

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)

Do not have permission to recreate Cargo data

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)

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)

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)

cargoRecreateData throws error after upgrade to MW1.38.1

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)

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)

Hello Yaron, yes, it does contain an "Image" field--Carloposo (talk) 07:58, 4 July 2022 (UTC)

Yes, indeed... what does the line for "Image" look like in the #cargo_declare call? Yaron Koren (talk) 01:16, 5 July 2022 (UTC)

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)

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)

Great, thanks. --Carloposo (talk) 07:44, 6 July 2022 (UTC)

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)

I confirm it's fixed. Thanks Yaron. --Carloposo (talk) 09:06, 7 July 2022 (UTC)

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

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)

Cargo_query error

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)

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)

There is no more database error. Many thanks Yaron 2001:861:4745:7590:2973:A2FE:A833:3E34 16:35, 14 July 2022 (UTC)

Debugging why Cargo data is not storing

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)

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)

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)

Yes - just use the "--replacement" flag. Yaron Koren (talk) 13:14, 19 July 2022 (UTC)

@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)

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)

@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)

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)

@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)

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)

Best way to remove field from existing table

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)

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)

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

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)

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)

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)

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)

@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)

Constant field not working in query

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)

What do you mean by "add a constant to the fields"? Yaron Koren (talk) 20:09, 4 August 2022 (UTC)

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)

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

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)

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)

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)

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)

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)

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)

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)

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)

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)

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

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)

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)

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)

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)

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)

Hide some tables from Drilldown page

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)

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)

Empty cargo query result

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)

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)

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)

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)

Makes sense, thanks for the help and knowledge ! 151.19.120.33 16:43, 29 August 2022 (UTC)

Data disappearing from Cargo

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)

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)

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)

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)

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)

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)

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)

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)

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)

Sorry, I don't know - that's not even really a MediaWiki question. Yaron Koren (talk) 20:20, 30 August 2022 (UTC)

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)

Duplicate results in Special:Drilldown

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

• https://www.funtoo.org/Make.conf/VIDEO_CARDS/nvidia appears twice because platforms=Vulkan, X
• https://www.funtoo.org/Make.conf/VIDEO_CARDS/Osmesa appears twice because platforms=DRI, X

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

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