Extension talk:Cargo/Archive August to December 2023
This page is an archive. Do not edit the contents of this page. Please direct any additional comments to the current talk page. |
Can Cargo Store Data with Units?
One of the infobox templates in my wiki has a need to store units with the data. For example, imagine an infobox template for mountains, wherein the peak elevations and base elevations may be entered in meters or feet. To illustrate, the input for a field may be "2,600 m" or "8,530 ft" and I want the software to recognize/convert the values so no matter which unit is entered, all entries can be compared and/or output consistently.
It looks like Semantic Mediawiki has this feature (see [1]) but I like the simplicity of Cargo so I'm hoping it's possible.--Lost Student (talk) 22:28, 10 December 2023 (UTC)
- Unfortunately, Cargo does not have a "Quantity" type. The best approach for something like this is probably to have two fields/inputs: a number, and then a dropdown for the units (which might be just "m" and "ft"). Then you could put an #ifeq (and #expr) within #cargo_store so that the value is always stored in meters, or something like that. Yaron Koren (talk) 03:02, 11 December 2023 (UTC)
- I appreciate the quick response--and for all your contributions to the Mediawiki ecosystem!--Lost Student (talk) 04:07, 11 December 2023 (UTC)
Magic Words and Fields
I'm using CONCAT in fields
to take one database field and construct some special wikitext before it displays. I do need to use magic words which is causing an issue I can't resolve.
As a simple test |fields=CONCAT("{{#replace:Actor|r|x}}")
works fine with the "r" in "Actor" converting to an "x" to make "Actox".
However, if I had add a database field it no longer works. |fields=CONCAT("{{#replace:", Role.position, "|r|x}}")
. Role.position returns "Actor", and even with the magic word conversion, it still returns "Actor" instead of "Actox". 70.160.223.43 11:53, 12 August 2023 (UTC)
- I would recommend doing the whole thing within SQL, i.e. using the function REPLACE() instead of creating a call to #replace - that should work better, if I understand what you're trying to do correctly. Yaron Koren (talk) 13:08, 15 August 2023 (UTC)
- You can escape curly braces by creating templates that return {{ and }}, e.g: Template:(( that contains
<includeonly>{{</includeonly>
and a matching Template:)) which you then call likeCONCAT("{{((}}#replace:", Role.position, "|r|x{{))}}")
to get a working template Ivlvlvllvlvlvlvlvlvl (talk) 13:50, 2 September 2023 (UTC)- That is a really useful comment, thanks. I wish I'd thought of that years ago. Jonathan3 (talk) 22:23, 2 September 2023 (UTC)
Store a different boolean value
How to I store a different value than "Yes" or "No" in the Cargo table when using a checkbox in Page Forms? I thought adding something like to #cargo_store in the template would do it, but I still see Yes or No values:
|Test={{#ifeq:{{{Test|}}}|Yes|first|second}}
Alternatively, can a different value be stored by adding parameters to the form itself? Tahoma403 (talk) 09:25, 2 September 2023 (UTC)
- What do you want to do? If it's to display things as "first" or "second" then you could handle that in the template displaying the infobox/query. Jonathan3 (talk) 22:19, 2 September 2023 (UTC)
- Don't ask me why, but I actually want to reverse the stored Yes or No values, so that an unchecked box stores Yes in the Cargo table and vice versa. I'm aware that I can query the data to display different values. Tahoma403 (talk) 04:38, 3 September 2023 (UTC)
- Why are "first" and "second" in that call? Shouldn't it be "No" and "Yes"? Yaron Koren (talk) 12:24, 6 September 2023 (UTC)
- Sorry, I put "first" and "second" to clarify that I wanted different values stored than the standard Yes or No, but in reality I want the reversed No/Yes for the checkbox/boolean entry. Neither first|second or No|Yes seem to work. Tahoma403 (talk) 13:20, 8 September 2023 (UTC)
- I have no idea - that seems like it should work. Yaron Koren (talk) 15:09, 8 September 2023 (UTC)
- I figured I needed to change the field type from Boolean to String to make it work. Tahoma403 (talk) 12:06, 9 September 2023 (UTC)
- I have no idea - that seems like it should work. Yaron Koren (talk) 15:09, 8 September 2023 (UTC)
- Sorry, I put "first" and "second" to clarify that I wanted different values stored than the standard Yes or No, but in reality I want the reversed No/Yes for the checkbox/boolean entry. Neither first|second or No|Yes seem to work. Tahoma403 (talk) 13:20, 8 September 2023 (UTC)
- Why are "first" and "second" in that call? Shouldn't it be "No" and "Yes"? Yaron Koren (talk) 12:24, 6 September 2023 (UTC)
- Don't ask me why, but I actually want to reverse the stored Yes or No values, so that an unchecked box stores Yes in the Cargo table and vice versa. I'm aware that I can query the data to display different values. Tahoma403 (talk) 04:38, 3 September 2023 (UTC)
- Somewhat related to this query: is it possible to have Cargo recognize True/False rather than Yes/No? Wingu.gamez (talk) 19:16, 8 December 2023 (UTC)
- It's a reasonable idea - but why do you want that? Yaron Koren (talk) 19:47, 8 December 2023 (UTC)
- We accidentally input True/False on about 300 pages before realizing our mistake--whoops--but also because it's a common form for Boolean values. ^^; Wingu.gamez (talk) 19:59, 8 December 2023 (UTC)
- That's true, yes. But for now, do you know about the Replace Text extension? Yaron Koren (talk) 21:23, 8 December 2023 (UTC)
- We accidentally input True/False on about 300 pages before realizing our mistake--whoops--but also because it's a common form for Boolean values. ^^; Wingu.gamez (talk) 19:59, 8 December 2023 (UTC)
- It's a reasonable idea - but why do you want that? Yaron Koren (talk) 19:47, 8 December 2023 (UTC)
Queries fail depending on the order tables are listed
Testing the staging version of a wiki that will be upgraded from MW 1.37.2 and Cargo 3.0 to MW 1.40.0 and Cargo 3.4.1, we have come across an issue on the updated site where queries that were working are now failing. The cases l've encountered happen when you are joining 3 tables: if the primary table (the one included in both join clauses) is listed last, the query that is generated looks like ...FROM `cargo__skill`,`cargo__skill_gems` LEFT OUTER JOIN `cargo__items` ON ((`cargo__skill`.`_pageID`=`cargo__items`.`_pageID`) AND (`cargo__skill_gems`.`_pageID`=`cargo__items`.`_pageID`)) WHERE
..., which fails with a sql error. If the primary table is listed first or second, you instead get a working query: ...FROM `cargo__items` LEFT OUTER JOIN `cargo__skill` ON ((`cargo__items`.`_pageID`=`cargo__skill`.`_pageIdD`)) LEFT OUTER JOIN `cargo__skill_gems` ON ((`cargo__items`.`_pageID`=`cargo__skill_gems`.`_pageID`)) WHERE
... Ivlvlvllvlvlvlvlvlvl (talk) 14:07, 2 September 2023 (UTC)
- Handling of the "join on" order was improved a lot in the latest Cargo version, 3.4.3 - I would recommend upgrading to that one. Yaron Koren (talk) 00:58, 3 September 2023 (UTC)
Compound queries overall order
Hi everyone, I'm looking to make compound queries to output in the "template" format but for my application I need an overall order option, so the output of the two queries are mixed. Currently, the output is the output of the first query, followed by the output of the second query. Is it possible to change this? Thanks Garuda3 (talk) 15:36, 2 September 2023 (UTC)
- Until you get a better answer - I think that recently I thought about this and concluded that it wasn't possible, as there are very few possible options outside the individual queries within #compound_query. I guess that it would be possible via a Lua/Scribunto module. Jonathan3 (talk) 22:22, 2 September 2023 (UTC)
Query showing each item of "List" field on separate row
If Field_A is a Cargo list field, could you do a query ending up with a table like this?
A | Page -------+------- abc | Page1 def | Page1 xyx | Page2
Jonathan3 (talk) 21:52, 13 September 2023 (UTC)
- Sorry for asking too soon. I worked it out with #arraymap and the template output format. Jonathan3 (talk) 22:01, 13 September 2023 (UTC)
- You could also do this by just directly querying the "field table", i.e. the table named MainTableName__FieldName. Yaron Koren (talk) 13:06, 14 September 2023 (UTC)
Dynamic Table format issues
When testing dynamic tables format, seems there's no way to disable "hidden fields" toggles and text, or is there? --There's no unique class around the toggle text, but there are for toggle links (I can hide part, not all). I had to wrap the query in a div (with a matching page background color) and then set a negative margin, to moving the dynamic table up/over the unwanted "hidden" field toggles, to truly hide them. This allows such columns to be searched on still (say if they contained keywords, or text for images/icons I don't want displayed in the table). Though this isn't ideal, as there's a flash of all content on load before it "hides".
I tried to move said fields under "details fields" instead, but these are unexpectedly not searchable, why? Further, specifying a field in "details fields" that's already been added to the "hidden" ones, removed it from "hidden fields" (now they're no longer searchable... which is an issue, though perhaps making these work together is problematic). I ended up having to double-specify the same fields in both places, with different names, to be both searchable and folded up below each record in bottom (+) section.
The above seems unituitive, to just move the cell value toggles from between record to below them... also while still having them searchable--and it all displays initially until full page load, creating a bit of a visual snarl. Is this the intended behaviour in either case? After a certain number of columns, it makes better sense to have fields below, rather than between, especially for mobile... however, they need to be searchable. FrozenPlum (talk) 01:31, 17 September 2023 (UTC)
I wish the DataTables maker had labelled toggle columns as "toggle columns" (accurately describing function), and that Cargo had an option for toggle label/link visibility. Further, it would be great for all fields to be searchable by default, with an optional field to exclude some as desired (it's unclear what the logic was behind the different functions of the two similar features, displayed in different locations).
Also, for the "details fields" fold out, if the data is from the same table all fields are confined to the first cell only, even though the fold-out is quite wide--the only exception to that is list data, which does a colspan and extend through all columns. I can see from other examples that maybe join data goes left to right, but same-table "more details" goes from top to bottom in a left-to-right layout.
Hopefully Yaron doesn't mind that I added to the docs a couple things I found the hard way:
- "details fields" are not searchable (currently).
- Only indexed fields can display in "details fields".
FrozenPlum (talk) 01:31, 17 September 2023 (UTC)
- The fact that "details fields" are not searchable is definitely worth including in the documentation, yes. And you're right that the functionality of "dynamic tables" is generally constrained by whatever is in the DataTables JS library, for better or worse. What did you mean by "Only indexed fields can appear"? Is that the same as what's in the previous sentence in the documentation, "each such field must be included in the
fields
parameter as well"? Yaron Koren (talk) 13:27, 18 September 2023 (UTC)- Thanks for confirming the first. For the second, no, fields of a type that are "unindexed" as listed here will not appear at all in the details fields drop down (these were specified in the "fields" parameter)... I could not get any "Wikitext" type (non-indexed) fields to appear in "details fields" fold-dowm, despite being included and successfully useable elsewhere in the same table. MW 1.39.4, Cargo 3.4.2. Php 8.0.28. FrozenPlum (talk) 10:50, 20 September 2023 (UTC)
- Oh, you're talking about database indexing. I just tried a "dynamic table" query, and I was able to get a field of type Wikitext to display fine in "details fields", though. I don't know how much testing you did - you may well be seeing some sort of bug in the "dynamic table" handling, but I don't think it's related to the field types per se. Yaron Koren (talk) 12:51, 20 September 2023 (UTC)
- Thanks for confirming the first. For the second, no, fields of a type that are "unindexed" as listed here will not appear at all in the details fields drop down (these were specified in the "fields" parameter)... I could not get any "Wikitext" type (non-indexed) fields to appear in "details fields" fold-dowm, despite being included and successfully useable elsewhere in the same table. MW 1.39.4, Cargo 3.4.2. Php 8.0.28. FrozenPlum (talk) 10:50, 20 September 2023 (UTC)
Outdated API endpoints?
The list of API endpoints at Extension:Cargo/Other features#API lists 9 items, but my wiki's /api.php only lists 7 Cargo items. Have "cargofields" and "cargotables" been retired? I tried to use them, but they don't return any result. BrownKDocs (talk) 17:35, 20 September 2023 (UTC)
- While I'm asking questions about the API-- what is the difference between "cargorecreatedata" and "cargorecreatetables"? It looks like "recreatedata" only works on one table at a time, but are they different beyond that? BrownKDocs (talk) 18:06, 20 September 2023 (UTC)
- Some of these endpoints say they require a CSRF token, which should be requested using the "tokens" API parameter. However, the api.php page says "tokens" is deprecated. Will the Cargo API endpoints be updated if "tokens" gets removed? BrownKDocs (talk) 18:33, 20 September 2023 (UTC)
- Hi -
- It's the other way around, those are the newest Cargo API actions. You probably need to upgrade to a newer version of Cargo.
- I believe "cargorecreatedata" recreates the tables and populates them, while "cargorecreatetables" only recreates the tables.
- Are you talking about this? The use of tokens wasn't deprecated, just the way in which they're retrieved was (nine years ago). I believe Cargo is handling this correctly.
- Yaron Koren (talk) 00:35, 21 September 2023 (UTC)
- Thank you so much!!
- Re #3, I'm running MW 1.35 and the "tokens" line on api.php says "Deprecated. Get tokens for data-modifying actions" -- but after reading the page you linked, I guess that's an unclear warning about the things that were removed in 2021. BrownKDocs (talk) 14:57, 21 September 2023 (UTC)
- Hi -
Embed "more results" page?
I have a page with a table limiting the query results to 50 rows. When clicking the "More..." link under the table, I want to load the next 50 results in the same page/table, keeping the page title and surrounding elements - instead of loading a Special page titled "Cargo query". Is this possible? Tahoma403 (talk) 14:34, 28 September 2023 (UTC)
- No, but it's an interesting idea. Yaron Koren (talk) 19:37, 28 September 2023 (UTC)
Map display error in drilldown request
When querying locations through the Special:Drilldown page, the "list" format works well but the "leaflet" format displays a blank map. The error in the browser console is :
Uncaught Error: Invalid LatLng object: (NaN, NaN)
at new D (LatLng.js:32:9)
at j (LatLng.js:123:11)
at R.extend (LatLngBounds.js:67:29)
at new R (LatLngBounds.js:39:8)
at N (LatLngBounds.js:250:9)
at i.fitBounds (Map.js:288:12)
at CargoMap.displayWithLeaflet (<anonymous>:542:48)
at CargoMap.display (<anonymous>:536:182)
at HTMLDivElement.<anonymous> (<anonymous>:546:712)
at Function.each (load.php?lang=en&modules=jquery%2Coojs-ui-core%2Coojs-ui-widgets&skin=vector-2022&version=1d5er:5:285)
The Cargo declaration is :
{{#cargo_declare:_table = expert
|Program=String
|Domain=String
|Subdomain=String (dependent on=Domain)
|FieldOfExpertise=List (,) of String
|Location=Coordinates|Level=String
|Country=String
|_drilldownTabs=List(format=list;fields=_pageName;limit=2000), Map(format=leaflet;fields=expert.Location__full, expert._pageName;width=1000;limit=2000;)}}
Any idea on what is causing the error ? Emmanuel T. (talk) 12:02, 3 October 2023 (UTC)
- Does the same problem happen with other map formats, do you know? Yaron Koren (talk) 17:36, 3 October 2023 (UTC)
- When I replace "leaflet" with "openlayers" or "googlemaps" in the #cargo_declare, the drilldown is in error :
MWException: Error: No field named "." found for any of the specified database tables.
- When I query the same table with #cargo_query the "leaflet" display works well. Emmanuel T. (talk) 10:41, 4 October 2023 (UTC)
- Okay, thank you. My guess is that a value of simply
Location,_pageName
would work better forfields
- that might be the issue. Yaron Koren (talk) 12:34, 4 October 2023 (UTC)- I first used these values for fields, it causes the following DB query error :
Error 1054: Unknown column 'expert_alias.Location' in 'field list'
Function: CargoDrilldownPage::reallyDoQuery
Query: SELECT `expert_alias`.`Location` AS `Location`,`expert_alias`.`_pageName` AS `_pageName` FROM `iseecargo__expert` `expert_alias` ORDER BY `expert_alias`.`_pageName` LIMIT 251
- (The tables prefix for this wiki is "isee")
- That is why I used
Location__full
instead ofLocation
Emmanuel T. (talk) 12:49, 4 October 2023 (UTC)- It's odd that you're getting that error message. I should have asked before: what version of Cargo are you running? Yaron Koren (talk) 13:02, 4 October 2023 (UTC)
- Here are the data from Special:Version
MediaWiki 1.39.4
PHP 7.4.30 (fpm-fcgi)
MySQL 5.7.38-log
ICU 69.1
Elasticsearch 7.10.2
Pygments 2.11.2
Cargo 3.4.3 (133918d) 10:15, 21 September 2023
Emmanuel T. (talk) 13:32, 4 October 2023 (UTC)- That's very odd. Could you try recreating the "expert" table? Maybe some old settings are still being stored there. Yaron Koren (talk) 13:48, 4 October 2023 (UTC)
- You are right, Yaron, the issue comes from a bad formatting of coordinates in the table. Emmanuel T. (talk) 14:25, 5 October 2023 (UTC)
- Okay, that's interesting. I'm glad you got it to work! Yaron Koren (talk) 14:59, 5 October 2023 (UTC)
- You are right, Yaron, the issue comes from a bad formatting of coordinates in the table. Emmanuel T. (talk) 14:25, 5 October 2023 (UTC)
- That's very odd. Could you try recreating the "expert" table? Maybe some old settings are still being stored there. Yaron Koren (talk) 13:48, 4 October 2023 (UTC)
- It's odd that you're getting that error message. I should have asked before: what version of Cargo are you running? Yaron Koren (talk) 13:02, 4 October 2023 (UTC)
- Okay, thank you. My guess is that a value of simply
cargo_store silently fails if string too long
Using
- MediaWiki 1.39.5
- PHP 8.1.24
- MariaDB 10.6.12
- Cargo 3.4.3
If you attempt to invoke #cargo_store and try to store a String that's longer than the field limit (default 300 characters) the query will silently fail and, more surprisingly, stop any subsequent cargo_stores from executing. The expected behaviour would be either (a) the too-long string is truncated or, (b) an error is logged. It would be appreciated if either a or b is implemented, or at least a note is written on the common problems or known bugs page.
- Skairunner (talk) 08:59, 17 October 2023 (UTC)
Getting link target and link text in the same query
So, I'm trying to make a template that generates a wikilink, where both the target page and the link text are different values in the Cargo database. But I haven't been able to find a way to get it to work.
I initially tried |fields=CONCAT("[[", _pageName, "{{!}}", name, "]]")
. This seemed to work just fine in Special:CargoQuery, but when I put it in an actual page there was no output at all.
So, then I tried splitting it like |fields=CONCAT("[[", _pageName), CONCAT("{{!}}", name, "]]")
, but this results in something like [[Foo (CONCAT("|", name, "]]"): |bar]]). I couldn't find any documentation for a way to change this multi-field formatting behavior to the way I want.
How do you actually do this? Saucy (talk) 03:37, 20 October 2023 (UTC)
- The first one seems like it should work... maybe the string in the middle should be an actual pipe? Yaron Koren (talk) 17:49, 20 October 2023 (UTC)
- I've tried it both ways; doesn't make a difference. I did figure out what the problem was though: I was performing the query through a template that automatically adds the "no html" parameter to the cargo query. Once I told it not to do that, it worked just fine! Saucy (talk) 21:20, 20 October 2023 (UTC)
Recreating table stops after 500 records
We recently needed to add a field to one of our tables. After adding the field, we tried to recreate the data for the table. The recreation seems to start out fine, but then it stops after creating 500 records in the table. Blinkingline (talk) 13:44, 24 October 2023 (UTC)
- Do you see any JavaScript errors in the browser console? It would appear that the recreate process, which handles pages 500 at a time, is failing when it gets to the 2nd batch. Also, what version of Cargo are you running? Yaron Koren (talk) 13:53, 24 October 2023 (UTC)
- Using Cargo 3.3.1 on MW 1.39.0. I do see this error in the console:
- CardData?_replacement:1396 This page is using the deprecated ResourceLoader module "mediawiki.pager.tablePager". Deprecated in 1.38. Use `mediawiki.pager.styles` Blinkingline (talk) 14:01, 24 October 2023 (UTC)
- Okay, thanks. That deprecation issue needs to be fixed, but it's not the reason for this error. You are using a somewhat old version of Cargo, though - there's a chance that whatever problem you are seeing has been fixed, so I would recommend upgrading to the most recent version. Yaron Koren (talk) 14:07, 24 October 2023 (UTC)
- Sounds good. I'll update it and get back to you if there's still an issue. Thanks for your help, as always! Blinkingline (talk) 15:11, 24 October 2023 (UTC)
- Okay, thanks. That deprecation issue needs to be fixed, but it's not the reason for this error. You are using a somewhat old version of Cargo, though - there's a chance that whatever problem you are seeing has been fixed, so I would recommend upgrading to the most recent version. Yaron Koren (talk) 14:07, 24 October 2023 (UTC)
- I believe I'm facing the same issue @Yaron Koren. I'm using MediaWiki 1.39.3 and Cargo extension 3.4.1. Every time I attempt to recreate a "replacement table" and run the runJobs.php script, I encounter the error "PHP Notice: Uncommitted DB writes (transaction from Wikimedia\Rdbms\Database::begin) in /var/www/wiki/includes/libs/rdbms/database/TransactionManager.php on line 583," and the table is never fully recreated with the total number of rows from the original 189.6.17.146 16:56, 24 October 2023 (UTC)
- This sounds like a different sort of error. (I'm guessing your number of rows is never a round number like 500.) Could you try recreating the table(s) via the command-line script cargoRecreateData.php, and see if any error messages show up during the process? Yaron Koren (talk) 17:12, 24 October 2023 (UTC)
- I tried to do that, but it's showing many errors.:
- php cargoRecreateData.php --table NewsSources Recreating data for Cargo table NewsSources in 5 seconds... hit [Ctrl]-C to escape. Deleting and recreating table... Handling template that adds to this table: NewsSource Saving data for pages 1 to 500 that call this template... PHP Deprecated: Use of InternalParseBeforeSanitize hook (used in VariablesHooks::onInternalParseBeforeSanitize) was deprecated in MediaWiki 1.35. [Called from MediaWiki\HookContainer\HookContainer::run in /var/www/wiki/includes/HookContainer/HookContainer.php at line 137] in /var/www/wiki/includes/debug/MWDebug.php on line 381 PHP Deprecated: Use of ParserOutput::addModuleStyles with non-array argument was deprecated in MediaWiki 1.38. [Called from {closure} in /var/www/wiki/LocalSettings.php at line 262] in /var/www/wiki/includes/debug/MWDebug.php on line 381 PHP Deprecated: Use of ParserOutput::addModules with non-array argument was deprecated in MediaWiki 1.38. [Called from {closure} in /var/www/wiki/LocalSettings.php at line 263] in /var/www/wiki/includes/debug/MWDebug.php on line 381 Wikimedia\Rdbms\DBQueryError from line 1618 of /var/www/wiki/includes/libs/rdbms/database/Database.php: Error 1406: Data too long for column 'url' at row 1 Function: Wikimedia\Rdbms\Database::insert Query: INSERT INTO `wiki_cargo__NewsSources` (`source`,`url`,`_pageName`,`_pageTitle`,`_pageNamespace`,`_pageID`,`_ID`) VALUES ('Twitter','https://twitter.com/NKT_Esports/status/1665724427147812864?ref_src=twsrc%5Etfw%7Ctwcamp%5Etweetembed%7Ctwterm%5E1665724427147812864%7Ctwgr%5E9fa3d560c637e2dea3bcf589075d7e178781045c%7Ctwcon%5Es1_&ref_url=https%3A%2F%2Fdotesports.com%2Fcounter-strike%2Fnews%2Fcsgo-pro-admits-to-committing-fraud-against-his-own-teammates','News/CS:GO Pro Confessed Fraud','News/CS:GO Pro Confessed Fraud',0,1718,21)
- 0 /var/www/wiki/includes/libs/rdbms/database/Database.php(1602): Wikimedia\Rdbms\Database->getQueryException('Data too long f...', 1406, 'INSERT INTO `wi...', 'Wikimedia\\Rdbms...')
- 1 /var/www/wiki/includes/libs/rdbms/database/Database.php(1576): Wikimedia\Rdbms\Database->getQueryExceptionAndLog('Data too long f...', 1406, 'INSERT INTO `wi...', 'Wikimedia\\Rdbms...')
- 2 /var/www/wiki/includes/libs/rdbms/database/Database.php(952): Wikimedia\Rdbms\Database->reportQueryError('Data too long f...', 1406, 'INSERT INTO `wi...', 'Wikimedia\\Rdbms...', false)
- 3 /var/www/wiki/includes/libs/rdbms/database/Database.php(1838): Wikimedia\Rdbms\Database->query('INSERT INTO `wi...', 'Wikimedia\\Rdbms...', 128)
- 4 /var/www/wiki/extensions/Cargo/includes/CargoUtils.php(1207): Wikimedia\Rdbms\Database->insert('NewsSources', Array)
- 5 /var/www/wiki/extensions/Cargo/includes/parserfunctions/CargoStore.php(439): CargoUtils::escapedInsert(Object(Wikimedia\Rdbms\DatabaseMysqli), 'NewsSources', Array)
- 6 /var/www/wiki/extensions/Cargo/includes/parserfunctions/CargoStore.php(167): CargoStore::storeAllData(Object(Title), 'NewsSources', Array, Object(CargoTableSchema))
- 7 /var/www/wiki/includes/parser/Parser.php(3443): CargoStore::run(Object(Parser), Object(PPTemplateFrame_Hash), Array)
- 8 /var/www/wiki/includes/parser/Parser.php(3126): Parser->callParserFunction(Object(PPTemplateFrame_Hash), 'cargo_store', Array)
- 9 /var/www/wiki/includes/parser/PPFrame_Hash.php(276): Parser->braceSubstitution(Array, Object(PPTemplateFrame_Hash))
- 10 /var/www/wiki/includes/parser/Parser.php(3317): PPFrame_Hash->expand(Object(PPNode_Hash_Tree))
- 11 /var/www/wiki/includes/parser/PPFrame_Hash.php(276): Parser->braceSubstitution(Array, Object(PPFrame_Hash))
- 12 /var/www/wiki/includes/parser/PPTemplateFrame_Hash.php(178): PPFrame_Hash->expand(Object(PPNode_Hash_Tree), 4)
- 13 /var/www/wiki/includes/parser/PPTemplateFrame_Hash.php(190): PPTemplateFrame_Hash->getNamedArgument('sources')
- 14 /var/www/wiki/includes/parser/Parser.php(3923): PPTemplateFrame_Hash->getArgument('sources')
- 15 /var/www/wiki/includes/parser/PPFrame_Hash.php(293): Parser->argSubstitution(Array, Object(PPTemplateFrame_Hash))
- 16 /var/www/wiki/extensions/WikiSEO/includes/WikiSEO.php(451): PPFrame_Hash->expand(Object(PPNode_Hash_Tree))
- 17 /var/www/wiki/includes/parser/Parser.php(3443): MediaWiki\Extension\WikiSEO\WikiSEO::fromParserFunction(Object(Parser), Object(PPTemplateFrame_Hash), Array)
- 18 /var/www/wiki/includes/parser/Parser.php(3126): Parser->callParserFunction(Object(PPTemplateFrame_Hash), 'seo', Array)
- 19 /var/www/wiki/includes/parser/PPFrame_Hash.php(276): Parser->braceSubstitution(Array, Object(PPTemplateFrame_Hash))
- 20 /var/www/wiki/includes/parser/Parser.php(3317): PPFrame_Hash->expand(Object(PPNode_Hash_Tree))
- 21 /var/www/wiki/includes/parser/PPFrame_Hash.php(276): Parser->braceSubstitution(Array, Object(PPFrame_Hash))
- 22 /var/www/wiki/includes/parser/Parser.php(2955): PPFrame_Hash->expand(Object(PPNode_Hash_Tree), 0)
- 23 /var/www/wiki/includes/parser/Parser.php(1610): Parser->replaceVariables('{{News\n|seo_tit...')
- 24 /var/www/wiki/includes/parser/Parser.php(724): Parser->internalParse('{{News\n|seo_tit...')
- 25 /var/www/wiki/extensions/Cargo/includes/CargoUtils.php(576): Parser->parse('{{News\n|seo_tit...', Object(Title), Object(ParserOptions))
- 26 /var/www/wiki/extensions/Cargo/maintenance/cargoRecreateData.php(181): CargoUtils::parsePageForStorage(Object(Title), '{{News\n|seo_tit...')
- 27 /var/www/wiki/extensions/Cargo/maintenance/cargoRecreateData.php(75): CargoRecreateData->recreateAllDataForTable('NewsSources', false)
- 28 /var/www/wiki/maintenance/includes/MaintenanceRunner.php(309): CargoRecreateData->execute()
- 29 /var/www/wiki/maintenance/doMaintenance.php(85): MediaWiki\Maintenance\MaintenanceRunner->run()
- 30 /var/www/wiki/extensions/Cargo/maintenance/cargoRecreateData.php(190): require_once('/var/www/wiki/m...')
- 31 {main}
- PHP Notice: Uncommitted DB writes (transaction from Wikimedia\Rdbms\Database::begin) in /var/www/wiki/includes/libs/rdbms/database/TransactionManager.php on line 583 189.6.17.146 04:20, 26 October 2023 (UTC)
- That's very helpful, thank you. Those first set of deprecation notices aren't coming from Cargo, I don't think - at least one is from the Variables extension. But the key error message here is
Data too long for column 'url'
. I assume the "url" column is of type "URL", whose default maximum size is 300 characters - and this URL is about 320 characters long. Cargo should not be crashing on that, but regardless, the best fix for you would be to increase the size of that column, with something like|url=URL (size=500)
in #cargo_declare. (Or, alternatively, just remove some unnecessary stuff from that URL, if this is a unique case.) Yaron Koren (talk) 13:20, 26 October 2023 (UTC)- Thank you for your response, @Yaron Koren! We managed to resolve the key error, but now we encounter an issue where creating a replacement table gets stuck at 500 189.6.17.146 22:24, 27 October 2023 (UTC)
- We encountered the same error as the person above. From the console, we can see this message: 'This page is using the deprecated ResourceLoader module "mediawiki.pager.tablePager." Deprecated in 1.38. Please use 'mediawiki.pager.styles' 189.6.17.146 22:36, 27 October 2023 (UTC)
- That's too bad that you are seeing the same problem. I don't know why you are both getting this - my guess is that the API action is failing somehow when the "offset" parameter is applied. For not, you both might be better off calling cargoRecreateData.php for that table, rather than doing it from the web interface. Yaron Koren (talk) 16:41, 30 October 2023 (UTC)
- We encountered the same error as the person above. From the console, we can see this message: 'This page is using the deprecated ResourceLoader module "mediawiki.pager.tablePager." Deprecated in 1.38. Please use 'mediawiki.pager.styles' 189.6.17.146 22:36, 27 October 2023 (UTC)
- Thank you for your response, @Yaron Koren! We managed to resolve the key error, but now we encounter an issue where creating a replacement table gets stuck at 500 189.6.17.146 22:24, 27 October 2023 (UTC)
- That's very helpful, thank you. Those first set of deprecation notices aren't coming from Cargo, I don't think - at least one is from the Variables extension. But the key error message here is
- This sounds like a different sort of error. (I'm guessing your number of rows is never a round number like 500.) Could you try recreating the table(s) via the command-line script cargoRecreateData.php, and see if any error messages show up during the process? Yaron Koren (talk) 17:12, 24 October 2023 (UTC)
Calendar not displaying events
I have copied the source code for a calendar and events from the DiscourseDB example. I tried to add them here, but had difficulty - I've literally copy and pasted the examples shown there into my wiki with the same page names. The Items table is populated with the event page's data; however, the calendar does not display the event.
Potentially relevant symptoms
- The event is visible if the format is set to table
- I receive an internal server error if I set the format to a timeline
- Setting the format to a CSV or icalendar yields no results
- I've noticed that the Items table on DiscourseDB stores dates in the MM dd, YYYY format, whereas my wiki stores dates in the YYYY-mm-dd format (mine is clearly better)
- There is an error message on the event page about the Items_reference table not existing
- This struck me as irrelevant
- Apache HTTP has no relevant error logs
108.203.6.24 15:13, 31 October 2023 (UTC)
- What do the #cargo_declare and #cargo_query calls look like? Yaron Koren (talk) 17:13, 31 October 2023 (UTC)
- I had tried to copy them earlier but wasn't able to due to links. Here are those calls isolated:
{{#cargo_declare:_table=Items|Author=List (,) of Page|Source=Page|Date=Date|URL=URL|Quote=Text|Summary=Wikitext (size=600)}}
{{#cargo_query:tables=Items|fields=_pageName,Source,Date|format=calendar|width=100%}}
108.203.6.24 17:43, 31 October 2023 (UTC)- I had previously been receiving an internal server error when using the recurring event method, which I fixed by enabling the calendar extension in php.ini (Arch Linux). Unfortunately, I am still receiving errors on timelines and the calendar still does not display events. 108.203.6.24 12:27, 1 November 2023 (UTC)
- Going a bit in the weeds here, I noticed the following in the HTML for a calendar:
<div class="cargoCalendar" dataurl="{{removed url}}/index.php?title=Special:CargoExport&tables=events&&fields=_pageName%2Cstart&&order+by=%60_pageName%60%2C%60start%60&limit=100&format=fullcalendar&&" style="width: 100%" startview="month"></div>
- CSV, iCalendar, and Calendars all use the page Special:CargoExport and all return no data. At least by looking at the HTML, a Cargo Table does not use this page. It seems my issue is with CargoExport. 108.203.6.24 12:37, 1 November 2023 (UTC)
- Playing around with the page Special:CargoQuery, I was able to see that the event is being captured by the cargo query, but is not being displayed on the calendar itself. With an event that exists in the future, I can set the where parameter to
start > NOW()
orstart < NOW()
to see 1 vs 0 results. Both display an empty calendar. 108.203.6.24 12:48, 1 November 2023 (UTC) - After fruitlessly tailing the Apache error log, I found the separate MediaWiki error log:
PHP Warning: Trying to access array offset on value of type null in /usr/share/webapps/mediawiki/extensions/Cargo/includes/specials/CargoExport.php on line 44, referer: {url removed}/index.php/Special:CargoQuery?title=Special%3ACargoQuery&tables=events%2C+&fields=&where=&join_on=&group_by=&having=&order_by%5B0%5D=&order_by_options%5B0%5D=ASC&limit=&offset=&format=json
- I am going to try dropping the events table and building from scratch, then creating a new event table with a single date field for testing. 108.203.6.24 18:09, 1 November 2023 (UTC)
- still nothing... 108.203.6.24 18:24, 1 November 2023 (UTC)
- Here is what I would recommend: in the browser, open the console and go to the "Network" tab (or whatever it's called in that browser). Then in the calendar, go to the month that should be displaying data. Once you do, a new line should appear in that tab. Right-click on it to open that URL in a new tab, and please let me know what you see on that page. Yaron Koren (talk) 23:11, 1 November 2023 (UTC)
- It is a CargoExport query. The page loads but nothing is displayed. I've listed some other symptoms this feature is presenting above - ultimately I think CargoExport is in some way malfunctioning... 2600:1700:760:2120:D6D2:52FF:FE6E:732D 11:46, 2 November 2023 (UTC)
- Actually, pulling up the console (Firefox), MediaWiki is returning a 500 on the CargoExport endpoint. Currently investigating. 2600:1700:760:2120:D6D2:52FF:FE6E:732D 11:56, 2 November 2023 (UTC)
- Enabling php errors revealed this:
Deprecated: Accessing $wgHooks directly is deprecated, use HookContainer::getHandlers() or HookContainer::register() instead. [Called from CargoHooks::initialize in /usr/share/webapps/mediawiki/extensions/Cargo/CargoHooks.php at line 39] in /usr/share/webapps/mediawiki/includes/debug/MWDebug.php on line 382
Deprecated: str_replace(): Passing null to parameter #3 ($subject) of type array|string is deprecated in /usr/share/webapps/mediawiki/extensions/Cargo/includes/CargoSQLQuery.php on line 118
- I am using php version 8.2.12. 108.203.6.24 15:27, 2 November 2023 (UTC)
- Yikes. I tried changing
trigger_error
towfDeprecated
inincludes/debug/MWDebug.php
(which does not exist in the repositories?) and have a new error: - /index.php?title=Special:CargoExport&tables=events&&fields=_pageName%2Cstart&&order+by=`_pageName`%2C`start`&limit=100&format=fullcalendar&&&start=2023-10-29&end=2023-12-10&_=1698925073432 InvalidArgumentException: MediaWiki version must either be a string or false. Example valid version: '1.33'
- Backtrace:
- from /usr/share/webapps/mediawiki/includes/GlobalFunctions.php(761)
- #0 /usr/share/webapps/mediawiki/includes/debug/MWDebug.php(382): wfDeprecated()
- #1 /usr/share/webapps/mediawiki/includes/debug/MWDebug.php(352): MWDebug::sendRawDeprecated()
- #2 /usr/share/webapps/mediawiki/includes/GlobalFunctions.php(791): MWDebug::deprecatedMsg()
- #3 /usr/share/webapps/mediawiki/includes/HookContainer/FauxGlobalHookArray.php(46): wfDeprecatedMsg()
- #4 /usr/share/webapps/mediawiki/extensions/Cargo/CargoHooks.php(39): MediaWiki\HookContainer\FauxGlobalHookArray->offsetGet()
- #5 /usr/share/webapps/mediawiki/includes/Setup.php(562): CargoHooks::initialize()
- #6 /usr/share/webapps/mediawiki/includes/WebStart.php(92): require_once(string)
- #7 /usr/share/webapps/mediawiki/index.php(44): require(string)
- #8 {main}
- Notice: Uncommitted DB writes (transaction from Wikimedia\Rdbms\Database::beginIfImplied (MessageCache::loadFromDB(en)-big)) in /usr/share/webapps/mediawiki/includes/libs/rdbms/database/TransactionManager.php on line 586
- Notice: DB transaction writes or callbacks still pending (LCStoreDB::finishWrite, LCStoreDB::finishWrite, LCStoreDB::finishWrite, LCStoreDB::finishWrite, LCStoreDB::finishWrite, LCStoreDB::finishWrite, LCStoreDB::finishWrite, LCStoreDB::finishWrite, LCStoreDB::finishWrite, LCStoreDB::finishWrite, LCStoreDB::finishWrite, LCStoreDB::finishWrite, LCStoreDB::finishWrite, LCStoreDB::finishWrite, LCStoreDB::finishWrite, LCStoreDB::finishWrite, LCStoreDB::finishWrite, LCStoreDB::finishWrite) in /usr/share/webapps/mediawiki/includes/libs/rdbms/database/Database.php on line 3526
- No idea if I'm moving in the right direction here - at this point it might be better to just use webdav... 108.203.6.24 15:52, 2 November 2023 (UTC)
- Interestingly,
update.php
displays the same errors (both before and after the change, though they cause a failure on the latter). 108.203.6.24 15:59, 2 November 2023 (UTC)- Oh - I should have asked this before, but what versions of MediaWiki and Cargo are you running? Yaron Koren (talk) 16:30, 2 November 2023 (UTC)
- I am using MediaWiki 1.40.1-1 and Cargo REL1_40-b3df937, though I think those php errors are a red herring as they appear on every page when the debug settings are enabled. Worth looking into, but not the root cause here. 108.203.6.24 17:37, 2 November 2023 (UTC)
- Well, I think most or all of those error messages would go away if you switched to the latest Cargo version. (The "REL" branches of Cargo should generally be avoided.) But you're right that those might not be the issue. Yaron Koren (talk) 23:31, 2 November 2023 (UTC)
- Thank you!!! V. 3.4.1 was giving this error --- just updated to 3.4.4 and no errors! School4schools (talk) 04:37, 30 December 2023 (UTC)
- That's great to hear! Yaron Koren (talk) 17:17, 1 January 2024 (UTC)
- Thank you!!! V. 3.4.1 was giving this error --- just updated to 3.4.4 and no errors! School4schools (talk) 04:37, 30 December 2023 (UTC)
- Well, I think most or all of those error messages would go away if you switched to the latest Cargo version. (The "REL" branches of Cargo should generally be avoided.) But you're right that those might not be the issue. Yaron Koren (talk) 23:31, 2 November 2023 (UTC)
- I am using MediaWiki 1.40.1-1 and Cargo REL1_40-b3df937, though I think those php errors are a red herring as they appear on every page when the debug settings are enabled. Worth looking into, but not the root cause here. 108.203.6.24 17:37, 2 November 2023 (UTC)
- Oh - I should have asked this before, but what versions of MediaWiki and Cargo are you running? Yaron Koren (talk) 16:30, 2 November 2023 (UTC)
- Interestingly,
- Yikes. I tried changing
- Actually, pulling up the console (Firefox), MediaWiki is returning a 500 on the CargoExport endpoint. Currently investigating. 2600:1700:760:2120:D6D2:52FF:FE6E:732D 11:56, 2 November 2023 (UTC)
- It is a CargoExport query. The page loads but nothing is displayed. I've listed some other symptoms this feature is presenting above - ultimately I think CargoExport is in some way malfunctioning... 2600:1700:760:2120:D6D2:52FF:FE6E:732D 11:46, 2 November 2023 (UTC)
- Here is what I would recommend: in the browser, open the console and go to the "Network" tab (or whatever it's called in that browser). Then in the calendar, go to the month that should be displaying data. Once you do, a new line should appear in that tab. Right-click on it to open that URL in a new tab, and please let me know what you see on that page. Yaron Koren (talk) 23:11, 1 November 2023 (UTC)
- still nothing... 108.203.6.24 18:24, 1 November 2023 (UTC)
Parser lock fails on "More..." results
Have a page that presents properly though all the template shenagginins I had to work though to get what I want. But when I click through for more results certain portions fail on parser locks:
Parser state cleared while parsing. Did you call Parser::parse recursively? Lock is held by: #0 /var/www/mediawiki-1.35.11/w/includes/parser/Parser.php(621): Parser->lock()
- 1 /var/common/extensions/1.35/Cargo/includes/CargoUtils.php(543): Parser->parse()
- 2 /var/common/extensions/1.35/Cargo/includes/formats/CargoTemplateFormat.php(83): CargoUtils::smartParse()
- 3 /var/common/extensions/1.35/Cargo/includes/CargoQueryDisplayer.php(391): CargoTemplateFormat->display()
- 4 /var/common/extensions/1.35/Cargo/includes/CargoQueryPage.php(191): CargoQueryDisplayer->displayQueryResults()
- 5 /var/www/mediawiki-1.35.11/w/includes/specialpage/QueryPage.php(736): CargoQueryPage->outputResults()
- 6 /var/common/extensions/1.35/Cargo/includes/specials/SpecialCargoQuery.php(36): QueryPage->execute()
- 7 /var/www/mediawiki-1.35.11/w/includes/specialpage/SpecialPage.php(600): SpecialCargoQuery->execute()
- 8 /var/www/mediawiki-1.35.11/w/includes/specialpage/SpecialPageFactory.php(635): SpecialPage->run()
- 9 /var/www/mediawiki-1.35.11/w/includes/MediaWiki.php(307): MediaWiki\SpecialPage\SpecialPageFactory->executePath()
- 10 /var/www/mediawiki-1.35.11/w/includes/MediaWiki.php(947): MediaWiki->performRequest()
- 11 /var/www/mediawiki-1.35.11/w/includes/MediaWiki.php(547): MediaWiki->main()
- 12 /var/www/mediawiki-1.35.11/w/index.php(53): MediaWiki->run()
- 13 /var/www/mediawiki-1.35.11/w/index.php(46): wfIndexMain()
- 14 {main}
AahzKarrde (talk) 20:03, 7 November 2023 (UTC)
- What versions of Cargo and MediaWiki are you running? Yaron Koren (talk) 20:35, 7 November 2023 (UTC)
- MediaWiki 1.35.11
- Cargo 3.2 (d5db9a5) 07:54, 7 September 2022
- I'm on a managed site, so I don't have control over these versions. AahzKarrde (talk) 12:45, 8 November 2023 (UTC)
- Those versions seem fine. Does that error happen every time you load that Special:CargoQuery page? Yaron Koren (talk) 13:39, 8 November 2023 (UTC)
- Yes, I ca make all the edits on the main page I want, shorten or lengthen the number of results from the query and everything displays fine. Once I click More I receive that list of errors in each item that goes through the templates I added. I can't post the link here, but you can see this live at the following
- site: swuholocron . com
- path: /wiki/User:AahzKarrde/ParseLockFail AahzKarrde (talk) 13:58, 8 November 2023 (UTC)
- Oh, it's a public wiki - that makes things a lot easier. (Here is the page.) So, there's a lot going on here: the query this page calls uses the DispTran2 template, which itself also calls #cargo_query, as well as calling four other templates - CardsInTopics, DisplayMainCard, GetMainCardImage and ShowCardsOrTransmissionIcon - all of which themselves also call #cargo_query. In theory, that should all still work, although it's very elaborate. The issue might be the GetMainCardImage template, whose query also uses the "template" format (with the template DisplayMainCardImage, which thankfully does not call a query). But my guess is that that chain of two template queries is causing parsing problems, though in theory Cargo should support it.
- Regardless, though, this is a complex setup you have. Is there any way to simplify it? One option is to have the DispTran2 template simply call a Lua module, which handles all the remaining querying and display. I see that your wiki does have Scribunto installed. Yaron Koren (talk) 15:53, 8 November 2023 (UTC)
- I'm certainly open to suggestions for simplification. This was me hacking together to get things to work. If it didn't work on the top level I wouldn't have batted an eye and dug around for something else, it jsut that it broke at the subsequent level that bothered me.
- I've confirmed Scribunto works. I'll start digging through that to see if I can simply the stack. AahzKarrde (talk) 16:08, 8 November 2023 (UTC)
- Those versions seem fine. Does that error happen every time you load that Special:CargoQuery page? Yaron Koren (talk) 13:39, 8 November 2023 (UTC)
Incorrect parameter count in call to native function
I have a query calling REGEXP_SUBSTR
(which has been properly added to the allowlist of functions), but it only properly functions when I pass in 2 parameters. If I attempt to pass in 3, or 4, or 5 (the last 3 of which are optional in the MySQL spec), I get the following error:
Error 1582: Incorrect parameter count in the call to native function 'REGEXP_SUBSTR' (wiki_db)
This and other functions (REGEXP_INSTR
) are pretty useless if they're not used with their optional parameters. Is this a bug, or is there some other way I'm supposed to invoke native functions with optional params? Teltura01 (talk) 23:24, 17 November 2023 (UTC)
- I don't know if this is a Cargo issue, or an issue with your installation of MySQL. Do you have direct access to the database, and if so, could you try calling a SELECT statement there with REGEXP_SUBSTR(), to see what it allows? Yaron Koren (talk) 14:08, 20 November 2023 (UTC)
WITHIN statement error when a Hierarchy item has an apostrophe
I first posted about this some months ago: I have a hierarchy definition in a template that includes the item "St. Mary's Anglican Church". When I try to query this with a WITHIN statement, I get an error that appears to split the query at the apostrophe. At the @Yaron Koren confirmed that this is a bug. As far as I can tell this has not been fixed. I have tried to have a look at the code but the regular expressions are boggling my mind a bit. Would someone else be able to fix this? Tenbergen (talk) 01:45, 28 November 2023 (UTC)
- Hi, I'm not sure if this is the place to put this but I am running into the same problem. Any fix or workaround is appreciated! 206.45.51.2 02:59, 28 November 2023 (UTC)
- I haven't found a solution, but looking through the code it appears they had realized the "other quote" problem in Cargoutils.php line 305. But I have no idea how I would use the solution from that spot for the WITHIN problem.Tenbergen (talk) 04:08, 28 November 2023 (UTC)
- No progress here either, PHP is way out of my wheelhouse. 206.45.51.2 15:45, 12 December 2023 (UTC)
- I haven't found a solution, but looking through the code it appears they had realized the "other quote" problem in Cargoutils.php line 305. But I have no idea how I would use the solution from that spot for the WITHIN problem.Tenbergen (talk) 04:08, 28 November 2023 (UTC)
Cargo mixing fields from two tables
I have declared two tables. First table is declared as:
{{#cargo_declare: _table = test01|nek_integer=Integer|nek_float=Float|nek_string=String|koordinate=Coordinates|nek_datum=Date|nek_boolean=Boolean}}
An second table as:
{{#cargo_declare: _table = kataster|kat_st=Integer|code=String|geografska_lega=String|ime=String|sinonimi=String|tip1=String|tip2=String|koordinate=Coordinates|kota_vhoda=Integer|lega_po=String|dolzina=Integer|globina=Integer|datum_ekskurzije=Date|datum_zapisnika=Date|organizacija=String|udelezenci=String (size=512)|zapisnikar=String|zapisnik=String|nacrt=String|vecje_pomanjkljivosti=String|dostop=String|splosno_stanje=String|onesnazenost=String|arheoloska=Boolean|grobisce=Boolean|jamski_sistem=Integer|opombe_k_dolzini=String|razne_opombe=String|kat_st_vg=Integer|rezim_vstopa=String|natancnost_lege=Integer|smer_vhoda=String (size=2;allowed values=UP,N,NE,E,SE,S,SW,W,NW)|tezavnost_dostopa=Integer|tezavnost_svetli_del=Integer|tezavnost_temni_del=Integer|bivalnost=Integer|ognjeprimerna=Integer|vir_vode=Integer|arheoloski_potencial=Integer|obdeluj=Boolean|obdeluj_kaj=String|pregledanost_svetli=Integer|pregledanost_temni=Integer|pregledanost_okolice=Integer|model3d_pokriva=Integer|model3d_kvaliteta=Integer|nacrt_obsega=Integer|nacrt_kvaliteta=Integer|bivalna_okolica=Integer|dotaknjena=Integer|najdena_arheologija=Integer|datum_zadnjega_dotika=Integer|znamenitost=Integer|razgled=Integer|svetli_del_delez=Integer}}
When I want to create table test01, I get error Creation of Cargo table "test01" failed. But table is actually created in PostgreSql server with correct columns. On querying table01 I get this error:
Query: SELECT "_pageName" AS "Page","kat_st" AS "kat st","code" AS "code","geografska_lega" AS "geografska lega","koordinate__full" AS "koordinate","kota_vhoda" AS "kota vhoda","lega_po" AS "lega po","dolzina" AS "dolzina","globina" AS "globina","datum_ekskurzije" AS "datum ekskurzije","arheoloska" AS "arheoloska","datum_ekskurzije__precision" AS "datum ekskurzije__precision" FROM "gis_test01" ORDER BY "_pageName","kat_st","code","geografska_lega","koordinate__full" LIMIT 100
Cargo diagram also shows incorrect columns for table test01. Cargo somehow does not respect table declaration and takes first few columns from declaration of another table as list of columns. Clearing cache of pages, templates, server does not help. Restarting server does not help. Where does Cargo get list of those columns?
Vanja24 (talk) 10:19, 29 November 2023 (UTC)
- After deleting table01. Clearing all cache I recreated table01 under different name. This time it works OK. Columns are OK and table_schema in cargo_tables table in my wiki db is correct. Vanja24 (talk) 10:54, 29 November 2023 (UTC)
Critical Issues with Cargo Extension: Unable to Recreate Tables, Empty Table Results, and Deprecated PHP Errors
I am using :
MediaWiki 1.39.3
PHP 7.4.33
Cargo 3.4.1
Something seems completely broken with the Cargo extension. Recreating table just leaves you an empty table (didn’t need a full recreation - just tried to recreate when I found out that even new pages / saving pages didn’t add or change anything in the table, but it is broken). Moreover, when trying to recreate any table via the Command Line Interface (CLI), an error is encountered, preventing the successful recreation of the table:
Saving data for pages 1 to 500 that call this template...
PHP Deprecated: Use of InternalParseBeforeSanitize hook (used in VariablesHooks::onInternalParseBeforeSanitize) was deprecated in MediaWiki 1.35. [Called from MediaWiki\HookContainer\HookContainer::run in /var/www/wiki/includes/HookContainer/HookContainer.php at line 137] in /var/www/wiki/includes/debug/MWDebug.php on line 381 PHP Deprecated: Use of ParserOutput::addModuleStyles with non-array argument was deprecated in MediaWiki 1.38. [Called from {closure} in /var/www/wiki/LocalSettings.php at line 264] in /var/www/wiki/includes/debug/MWDebug.php on line 381 PHP Deprecated: Use of ParserOutput::addModules with non-array argument was deprecated in MediaWiki 1.38. [Called from {closure} in /var/www/wiki/LocalSettings.php at line 265] in /var/www/wiki/includes/debug/MWDebug.php on line 381 Saving data for pages 501 to 670 that call this template...
189.61.116.159 16:51, 29 November 2023 (UTC)
- That's not good. I would try upgrading to the latest version of Cargo. I don't know if those PHP warnings are causing this problem, though I don't think they're coming from Cargo, in any case - at least one is coming from the Variables extension, and others may be coming from custom code in your LocalSettings.php file. Yaron Koren (talk) 17:22, 29 November 2023 (UTC)
Is there anyway to save data in same row from different template?
For example, I have template A with field A,B,C,D,E,F and template B with field G. Either A and B will be called in same page. Is there any way to make cargo store field A,B,C,D,E,F,G in same row? I have tried use cargo_attach in B, but it results in every page has two row: one row stores A,B,C,D,E,F and another has G. 夕舞八弦 (talk) 03:21, 9 December 2023 (UTC)
- Unfortunately, no - you would have to store these as two separate tables, and then join them for queries if you want to show all the data in one place. Yaron Koren (talk) 03:00, 11 December 2023 (UTC)
Deprecated: array_key_exists(): Using array_key_exists() on objects is deprecated.
Hello Yaron,
I am currently troubleshooting a "List (,) of Pages" error where my page was displaying as a 0 so I installed the latest version of PageForms and Cargo. That seemed to fix that error but when I went to my Special:CargoTables pages I am now getting this error:
Deprecated: array_key_exists(): Using array_key_exists() on objects is deprecated. Use isset() or property_exists() instead in ...\extensions\Cargo\includes\specials\CargoTables.php on line 141
Thank you so much for your help! Issiegainsley (talk) 15:38, 11 December 2023 (UTC)
- What version of Cargo are you running? I don't see that code on that line. Yaron Koren (talk) 20:34, 11 December 2023 (UTC)
- Sorry. I should have included that.
- Cargo: 2.6 (eb19b30) 00:55, November 27, 2023
- PageForms: 4.9.4 (6a813df) 01:20, December 11, 2023
- MediaWiki 1.35.5 (a900bce)
- PHP 7.4.28 (cgi-fcgi) Issiegainsley (talk) 21:19, 11 December 2023 (UTC)
- Line 141
- // Skip "hidden" fields.
- if ( array_key_exists( 'hidden', $fieldDescription ) ) { Issiegainsley (talk) 21:24, 11 December 2023 (UTC)
- Okay, you must be using the REL1_35 branch of Cargo. I would recommend switching to using the latest version of Cargo - it still works with MW 1.35. Hopefully this problem no longer exists there. Yaron Koren (talk) 21:52, 11 December 2023 (UTC)
- That worked. Thank you Yaron! Issiegainsley (talk) 16:09, 14 December 2023 (UTC)
- Okay, you must be using the REL1_35 branch of Cargo. I would recommend switching to using the latest version of Cargo - it still works with MW 1.35. Hopefully this problem no longer exists there. Yaron Koren (talk) 21:52, 11 December 2023 (UTC)
Where/How to define default values?
I am still a complete newbie when it comes to MediaWiki and Cargo. So maybe I am missing something obvious. But my question has to do with where/how to define default values for parameters.
If I use just a plain template, with no page forms, no cargo etc. I know the syntax for coding a default value for a missing/undefined parameter. No problem.
But I used the Create Class page to define a Template/Category/Page Form and am completely lost on a maze of parameter declarations, Cargo table definitions and table display definitions.
Can someone tell me where/how to define a template parameter's default value if it's not specified in the template invocation when using Page Forms and Cargo-defined templates?
Thanks Calvin Powers Calvin27516 (talk) 13:50, 16 December 2023 (UTC)
- OK, I just realized that defaults for fields can be set in the PageForm definition.
- https://www.mediawiki.org/wiki/Extension:Page_Forms/Defining_forms
- in the field definition. So that is a mystery solved. Calvin27516 (talk) 14:23, 17 December 2023 (UTC)
Bar Charts not working
Bar chart Format hasn't been working for a while. Bar charts which used to work have been displaying as simply blank. They will work if Format is switched to pie chart or table. I've got an example page at https://nms.miraheze.org/wiki/Biome#Worlds_Documented_by_Biome
This page and several others with bar charts on my wiki used to work as is, but stopped with a previous Cargo update. It's been a while but no others have reported it, so I wanted to give a heads up. Thanks for all the great work! Ertosiangel (talk) 00:20, 18 December 2023 (UTC)
- I don't understand - the bar chart seems to be displaying fine there. What's not working? Yaron Koren (talk) 13:47, 18 December 2023 (UTC)
Group by field, but get "latest" determined by other date field
This may just be a SQL problem, but the queries I make come back with "where select" responses and since I can't do that here.
I have a table with two key fields I'm keying off here. Creator and Date. I want to get the record with the latest Date for each creator.
I try:
group by=Creator
order by=Date DESC
But it just gives me the first record of each creator ordered descending on those first dates.
I saw some references to GROUP_CONCAT here, but when I try and get a MAX value of the Date grouping I get errors. Fatal exception of type "Wikimedia\Rdbms\DBQueryError"
Any thoughts on direction? AahzKarrde (talk) 19:11, 19 December 2023 (UTC)
- Doing
MAX(Date) DESC
should work, in theory. You should add the following to LocalSettings.php to be able to see the SQL-related error:$wgShowExceptionDetails = true;
Yaron Koren (talk) 04:23, 20 December 2023 (UTC) - I think that's now ordering by the latest post from each creator, but the entry it's returning is still the first entry.
- I'm on MyWikis, so I don't see that I have access to that config option. AahzKarrde (talk) 13:17, 20 December 2023 (UTC)
- Oh, so it's just GROUP_CONCAT that gives the error. What do you mean by "the record" - what exactly are you trying to display? Yaron Koren (talk) 13:45, 20 December 2023 (UTC)
- The table is a list of "posts" from Creators. I'm trying to get the latest post from each Creator. AahzKarrde (talk) 14:24, 20 December 2023 (UTC)
- Oh, I see. This is a very common type of query to want to do - StackOverflow even has a tag just for it. Unfortunately, doing it in a single query requires a SELECT within a SELECT, which means that I don't think there's a way to do this within a single #cargo_query call. I would recommend instead creating a Scribunto Lua module (assuming Scribunto is available) that calls a Cargo query to get the list of creators and dates - then loops through that list, and finds (and displays) the full row for each one. Yaron Koren (talk) 16:55, 20 December 2023 (UTC)
- The table is a list of "posts" from Creators. I'm trying to get the latest post from each Creator. AahzKarrde (talk) 14:24, 20 December 2023 (UTC)
- Oh, so it's just GROUP_CONCAT that gives the error. What do you mean by "the record" - what exactly are you trying to display? Yaron Koren (talk) 13:45, 20 December 2023 (UTC)
Display format
{{#cargo_query:table=Items|where=categories HOLDS "Magic Stone" AND stat_critical_severity|fields=name, stat_critical_severity|format=template|template=...|delimiter=<br>}}
This question has probably been asked a hundred times already. You can somehow do without using format=template, and make the display in format = {{icon|name}} (+stat_critical_severity)
--Oleksii 212.80.47.83 18:35, 28 December 2023 (UTC)
- If you are asking whether this can be done without the "template" format, I think it can, with something like
fields=CONCAT('{{icon|'', name, '}} (+', stat_critical_severity, ')')
. Yaron Koren (talk) 17:17, 1 January 2024 (UTC)