Extension talk:Cargo

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

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:

'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:
 * 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:


 * 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

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?

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  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:


 * ...with this:

''


 * 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  table) is saving without issue.

Thanks for any help you can provide. &mdash; 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, &mdash; 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:
 * 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. &mdash; 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 . 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  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? &mdash; MusikAnimal  talk  03:40, 31 July 2022 (UTC)