Extension talk:Cargo/Archive September to December 2022

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

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

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

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

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

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

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

Thanks! Koshob (talk) 00:15, 2 September 2022 (UTC)

I would hope that there's no need for each book page to query Cargo to get its own data, given that its own data is right there on the page... I don't know the specifics of what you're trying to display, though, but that would be the obvious fix for this problem.

You don't need to re-save the page in order to refresh it - all you need to do is purge the cache, via "action=purge" - Cargo provides a "Purge cache" tab/action to let you do that directly. You can also simply disable caching for such pages in the first place, using the MagicNoCache extension, which might be an even better solution. (If you did that, a simple browser reload would be enough to show the correct data.) Though the best solution, I would think, is to avoid having pages querying themselves. Yaron Koren (talk) 13:08, 2 September 2022 (UTC)

Thanks for the response. We use non-default skin and we came up with the same solution (adding a "refresh" action to the menu that uses purge) before some time. But unfortunately that not always help, regarding the showing the data - it more comfortable to query the data and show it (to allow us join some data from other tables and have it sorted + filtered. My main problem is how can I identify pages that should be "updated" (So I can purge them automatically using automation) - do you have any idea for that maybe ?:) Koshob (talk) 10:34, 3 September 2022 (UTC)

No, although I still recommend you take a look at MagicNoCache. Yaron Koren (talk) 13:41, 5 September 2022 (UTC)

Will do, Thanks! Koshob (talk) 16:45, 5 September 2022 (UTC)

I'd like to see your template as without that I can't understand why it doesn't just display the template parameters, e.g. {{{book|}}}. Jonathan3 (talk) 12:54, 8 September 2022 (UTC)

Handling List (,) of String field

Hello,

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

There's no need to split that value; the individual values are saved in a separate table. Have a look at Extension:Cargo/Storing_data#Storage_of_lists. You just need to join on that table, and do whatever you want with the results. Sam Wilson 02:33, 5 September 2022 (UTC)

If you do want to work with the result from the main table, for example using Page Form's #arraymap parser function, the delimiter of a List (,) of list is just , - it's only displayed with the bullet points :-) Jonathan3 (talk) 12:51, 8 September 2022 (UTC)

Save one row (multiple columns) result to variable

Hi!

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

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

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

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

{{#vardefine:Variables| {{cargo_query:

table=MyTable

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

}} }}

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

Thanks! Koshob (talk) 00:22, 9 September 2022 (UTC)

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

Timeline display with a list of start and end dates

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

No, it's not currently possible to have the timeline display just join together a list of start dates with a list of end dates. I don't know what form your table takes, but is it possible to just have a separate row for each instance of an event? Yaron Koren (talk) 21:03, 12 September 2022 (UTC)

Hello Yaron, thanks for confirming. This is the main table I am working on currently: https://atmos.miraheze.org/wiki/Special:CargoTables/Field_Campaigns. Making separate rows could be a workaround, but I think I will just leave Start and End as lists, since the timeline feature would be nice but is not critical here. Lgolston (talk) 23:59, 12 September 2022 (UTC)

Multiple wikis

Hello,

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

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

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

Being able to store data from different wikis in the same database would be wicked. In case that's ever on the table. Devaroo (talk) 00:55, 15 December 2022 (UTC)

No, it's not on the table - there are all sorts of ways in which I think that would be a bad idea, although it obviously would provide some conveniences. I would recommend the External Data extension if you want to display different wikis' data together. Yaron Koren (talk) 18:09, 15 December 2022 (UTC)

External data extension is what I'm using for this purpose now :-) Devaroo (talk) 02:16, 16 December 2022 (UTC)

Display Format: Dynamic Table with hidden fields

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

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

Brabi81 (talk) 12:23, 15 September 2022 (UTC)

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

Yes "every cargo_query" with dynamic table. Brabi81 (talk) 12:28, 19 September 2022 (UTC)

Two questions

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

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

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

Thanks, Phenomist (talk) 08:29, 19 September 2022 (UTC)

For #1 - I don't know if there's better documentation for it than this, but you can find the current set of allowed SQL functions here. But if you have contact with the Miraheze admins, you hopefully can get them to add these other functions by adding lines for $wgCargoAllowedSQLFunctions to LocalSeetings.php. (I don't think there's any specific reason why these two functions are not in the list.)

For #2 - No, there's no good way to add comments, unfortunately, although it's something I've looked into. Generally the field description should just be the type, although there are other parameters that can be added, within parentheses, like " (allowed values=A,B,C)". Yaron Koren (talk) 13:06, 19 September 2022 (UTC)

If I understand correctly about #2, can't you use for example normal comment sections?

|field_1 = Integer <!-- This is an integer field that stores a value -->

This is what I used a lot when working on templates a few years ago. Perhaps the text you write directly behind the "Integer" definition confuses Cargo, and it converts it to String instead. Pangaearocks (talk) 02:05, 22 September 2022 (UTC)

Yes, the HTML comment solution is what I ended up doing. The comments don't display on the table pages where they are probably the most visible, but that's fine I suppose. It was mostly due to a misunderstanding of the Cargo documentation. Phenomist (talk) 16:24, 22 September 2022 (UTC)

Error 1213:Deadlock found when trying to get lock; try restarting transaction

I have a crontab running cargoRecreateData.php every night to make sure that all pages using Cargo data get updated. This runs fine some of the time, and other times throws an error.

When I manually run cargoRecreateData.php it generally works fine. I can make it throw an error like this if I run the command in two windows at the same time, but that makes sense.

A similar error had been reported as Extension_talk:Cargo/Archive_January_to_May_2022#Database query error - Error 1213: Deadlock found when trying to get lock but had no replies.

Wikimedia\Rdbms\DBQueryError from line 1606 of /home/<details hidden>/includes/libs/rdbms/database/Database.php: Error 1213: Deadlock found when trying to get lock; try restarting transaction (intMedMWdb.umintmed.ca)
Function: CargoBackLinks::setBackLinks
Query: DELETE FROM `mw_cargo_backlinks` WHERE cbl_query_page_id = 2028

#0 /home/<details hidden>/includes/libs/rdbms/database/Database.php(1590): Wikimedia\Rdbms\Database->getQueryException('Deadlock found ...', 1213, 'DELETE FROM `mw...', 'CargoBackLinks:...')
#1 /home/<details hidden>/includes/libs/rdbms/database/Database.php(1564): Wikimedia\Rdbms\Database->getQueryExceptionAndLog('Deadlock found ...', 1213, 'DELETE FROM `mw...', 'CargoBackLinks:...')
#2 /home/<details hidden>/includes/libs/rdbms/database/Database.php(1173): Wikimedia\Rdbms\Database->reportQueryError('Deadlock found ...', 1213, 'DELETE FROM `mw...', 'CargoBackLinks:...', false)
#3 /home/<details hidden>/includes/libs/rdbms/database/Database.php(3574): Wikimedia\Rdbms\Database->query('DELETE FROM `mw...', 'CargoBackLinks:...', 128)
#4 /home/<details hidden>/includes/libs/rdbms/database/DBConnRef.php(69): Wikimedia\Rdbms\Database->delete('`mw_cargo_backl...', 'cbl_query_page_...', 'CargoBackLinks:...')
#5 /home/<details hidden>/includes/libs/rdbms/database/DBConnRef.php(530): Wikimedia\Rdbms\DBConnRef->__call('delete', Array)
#6 /home/<details hidden>/extensions/Cargo/includes/CargoBackLinks.php(51): Wikimedia\Rdbms\DBConnRef->delete('cargo_backlinks', Array, 'CargoBackLinks:...')
#7 /home/<details hidden>/extensions/Cargo/includes/parserfunctions/CargoQuery.php(180): CargoBackLinks::setBackLinks(Object(Title), Array)
#8 /home/<details hidden>/includes/parser/Parser.php(3413): CargoQuery::run(Object(Parser), 'tables=Person', 'fields=External...', 'where=Person._p...', 'default=')
#9 /home/<details hidden>/includes/parser/Parser.php(3096): Parser->callParserFunction(Object(PPTemplateFrame_Hash), 'cargo_query', Array)
#10 /home/<details hidden>/includes/parser/PPFrame_Hash.php(276): Parser->braceSubstitution(Array, Object(PPTemplateFrame_Hash))
#11 /home/<details hidden>/includes/parser/Parser.php(1576): PPFrame_Hash->expand(Object(PPNode_Hash_Tree))
#12 /home/<details hidden>/includes/parser/Parser.php(851): Parser->internalParse(' \n<!-- GeneralI...', false, Object(PPTemplateFrame_Hash))
#13 /home/<details hidden>/extensions/Tabber/TabberHooks.php(74): Parser->recursiveTagParse(' \n<!-- GeneralI...', Object(PPTemplateFrame_Hash))
#14 /home/<details hidden>/extensions/Tabber/TabberHooks.php(48): Tabber\TabberHooks::buildTab('General Info = ...', Object(Parser), Object(PPTemplateFrame_Hash))
#15 /home/<details hidden>/includes/parser/Parser.php(3979): Tabber\TabberHooks::renderTabber('\nGeneral Info =...', Array, Object(Parser), Object(PPTemplateFrame_Hash))
#16 /home/<details hidden>/includes/parser/PPFrame_Hash.php(353): Parser->extensionSubstitution(Array, Object(PPTemplateFrame_Hash))
#17 /home/<details hidden>/includes/parser/PPTemplateFrame_Hash.php(97): PPFrame_Hash->expand(Object(PPNode_Hash_Tree), 0)
#18 /home/<details hidden>/includes/parser/Parser.php(3284): PPTemplateFrame_Hash->cachedExpand('Template:Person...', Object(PPNode_Hash_Tree))
#19 /home/<details hidden>/includes/parser/PPFrame_Hash.php(276): Parser->braceSubstitution(Array, Object(PPFrame_Hash))
#20 /home/<details hidden>/includes/parser/Parser.php(2932): PPFrame_Hash->expand(Object(PPNode_Hash_Tree), 0)
#21 /home/<details hidden>/includes/parser/Parser.php(1579): Parser->replaceVariables('{{Person\n|First...')
#22 /home/<details hidden>/includes/parser/Parser.php(697): Parser->internalParse('{{Person\n|First...')
#23 /home/<details hidden>/extensions/Cargo/includes/CargoUtils.php(569): Parser->parse('{{Person\n|First...', Object(Title), Object(ParserOptions))
#24 /home/<details hidden>/extensions/Cargo/maintenance/cargoRecreateData.php(177): CargoUtils::parsePageForStorage(Object(Title), '{{Person\n|First...')
#25 /home/<details hidden>/extensions/Cargo/maintenance/cargoRecreateData.php(68): CargoRecreateData->recreateAllDataForTable('Person', false)
#26 /home/<details hidden>/maintenance/doMaintenance.php(114): CargoRecreateData->execute()
#27 /home/<details hidden>/extensions/Cargo/maintenance/cargoRecreateData.php(186): require_once('/home/<details hidden>...')
#28 {main}

What versions of Cargo and MediaWiki are you running? Yaron Koren (talk) 19:41, 20 October 2022 (UTC)

MW 1.38.4 and Cargo 3.3 (c684e54) 2022-09-29T01:26:54 - Tenbergen (talk) 21:57, 3 November 2022 (UTC)

Okay, it makes sense that this would sometimes happen, when recreating a big batch all at the same time. I don't know if there's any way to get around this, other than making the use of the "cargo_backlinks" table optional, which is actually not a bad idea. Yaron Koren (talk) 02:20, 8 November 2022 (UTC)

"other than making the use of the "cargo_backlinks" table optional" - is that something I need to change in how I run the command, or something that would be changed in how this is programmed? Tenbergen (talk) 16:49, 10 November 2022 (UTC)

Well, it would really have to be changed in the code itself. For now, you could just delete that DB table - it will just get re-created the next time you run update.php, but until then, everything should work fine. Yaron Koren (talk) 18:49, 10 November 2022 (UTC)

I have deleted that table and will watch if that error happens again. Thanks Yaron!Tenbergen (talk) 16:26, 15 November 2022 (UTC)

Deleting the table has stopped the error, haven't seen it in 2 weeks. Thanks Yaron! Tenbergen (talk) 22:08, 30 November 2022 (UTC)

can cargo store 8 byte integers?

i don't see it documented anywhere... is it OK to use float instead? Schtom (talk) 14:39, 25 October 2022 (UTC)

I don't know - it might depend on the DB system being used (MySQL, etc.), and maybe even the specific installation. Sure, if Float works better, that's fine too. Yaron Koren (talk) 01:56, 26 October 2022 (UTC)

Thanks for your quick reply. I think my question was not very precise. What I meant was if Cargo allows to set the storage size via the cargo_declare parser function or a config variable. Similar to strings where I can set the length via the size parameter or the $wgCargoDefaultStringBytes config variable. Schtom (talk) 08:51, 26 October 2022 (UTC)

Oh, I see. No, although, it would be easy to add. Would that be useful - do you need to store values greater than 2 billion or so? Yaron Koren (talk) 20:39, 28 October 2022 (UTC)

Date format & timezone conversions in query aren't working

I'm trying to follow the example from DiscourseDB that uses date_format in a query, but it isn't working when I do it.

My query:

{{#cargo_query:tables=bbe22_events
|fields=end,date_format(start, '%a, %b %d %h:%i %p')=start,
nameES,nameEN,zoom,zoomid,zoompw,presenter,tech,interpreter,descriptionES,descriptionEN,recordingES,recordingEN
|format=template
|template=BBE22EventInfo
|named args=yes}}

Every field renders fine via the template except start, which shows up as {{{start}}}, as if I had left it off the list of fields. (It works fine if I leave out the date_format and just include start in the list of fields.)

What am I doing wrong here?

Thank you!

-Darin 67.164.18.219 04:07, 28 October 2022 (UTC)

I'm not sure - if you change it to, say, "format=table", does the data display correctly? If so, I would try using an alias (and template parameter) other than "start" - it could be that the reuse of the Cargo field name is somehow causing problems. Yaron Koren (talk) 20:49, 28 October 2022 (UTC)

Thanks for the suggestion! Unfortunately, it does not display correctly with "format=table". I tried changing the alias, and that didn't help either. Either way, that column of the table was blank - it looks like date_format just isn't returning a value, maybe? -Darin 67.164.18.219 21:39, 28 October 2022 (UTC)

Resolved! I was storing the date in the wrong format. Apparently dates need to be specified in the format 2022-11-11 17:30:00, at least with the MySQL install I'm working with. -Darin 67.164.18.219 23:06, 28 October 2022 (UTC)

Bot checking for record existence

Hi we're writing a bot (Python) that imports data from several external sources regularly and creates records in multiple Cargo tables. Some of the records may be referenced again by future runs of the bot. That is, the bot should be able to check for existence of records in the database BEFORE insertion, to avoid data duplication.

For example, we have a Person in a City. That Person table has a city_idx field. We'd like to insert a City record, have Person records refer to their relevant city_idx. And for every Person insertion from a specific city re-use its relevant city_idx when relevant.

The question is whether there is some API or other way we can use for verifying the existence of records without directly accessing the SQL data from Python?

MW 1.30, PHP 7.1, MYSQL 5.7, Cargo 2.1.1 109.253.167.194 14:08, 19 November 2022 (UTC)

So, does anyone have an idea? would really appreciate it. I believe others might find this useful as well? 109.253.167.194 12:40, 23 November 2022 (UTC)

Why not just do a SQL query? Yaron Koren (talk) 18:54, 1 December 2022 (UTC)

That's what we'll end up doing. But directly SQL querying cargo tables isn't the most convenient/correct programming practice. That why I was wondering if there's some API for that. 109.186.38.240 13:44, 20 January 2023 (UTC)

Oh, okay. Yes - if you're just trying to query Cargo data, the page Special:CargoExport can essentially function as an API - you can create the relevant query at Special:CargoQuery, then select either the CSV or JSON formats - and the resulting URL generated, at Special:CargoExport, can have its contents read directly by the Python code. Yaron Koren (talk) 15:17, 20 January 2023 (UTC)

intro/outro, template & modify query

We're using intro/outro for wikitable start/end wikitext, and |format=template to format rows of output. We so appreciate the support added to intro/outro for such cases! In paginated results, the "modify query" box at the bottom disregards and omits the intro/outro parameters. Our table formatting is then dropped when someone modifies the query (unintended). Farther, there are no fields to add intro/outro back in "Modify Query". The result is, either the automatic pagination must be hidden with manual pagination, or we have to hide the "modify query" box to prevent user complaints. It would be great if "Modify Query" could respect, accept, and keep all query parameters supplied, is there some other way to make this happen?

For now we're using css to hide the "modify query" box on pagination pages:

.specialCargoQuery-extraPane-toggle.oo-ui-buttonElement-button {
	display:none;
}

Thanks! TiltedCerebellum (talk) 23:34, 1 December 2022 (UTC)

After updating to Cargo v3.3.1 and MW 1.39, this is still a problem per the topic directly below this one. TiltedCerebellum (talk) 23:59, 7 January 2023 (UTC)

Modify Query namedargs setting dropped

Another problem with the "Modify Query" form is that |named args=yes, set in the query, is unset each time the form is used. The user edits the query, it drops named args (set in the query), causing empty rows/values/results and unexpected defaults). The user doesn't know to re-check it each time, and complaints result. Is there some way for this to be respected when modifying a query on a paginated results page? TiltedCerebellum (talk) 23:34, 1 December 2022 (UTC)

I can't replicate this problem - what version of Cargo are you using? Yaron Koren (talk) 03:06, 5 December 2022 (UTC)

We're using Version 3.2. Has something changed regarding the query form? I see you've released a 3.3 and 3.3.1 recently... We're hesitant to upgrade if the result may be the same, as we've had issues with different versions of Cargo, and we know that 3.2 works (other than query into/outtro dropping reported above). If we're going to upgrade, we'd prefer to upgrade when all query form issues (such as intro/outtro) are resolved. Perhaps the named args problem appears only when into/outtro are set to create wiki table beginning/end, with template to format rows... Doing this always seems to be our problem. TiltedCerebellum (talk) 18:38, 13 December 2022 (UTC)

I should have been clearer, apologies. I was referring to the "Modify query" boxes that specifically appear on a page after clicking "more...(results)" (any page of subsequent results, after clicking the "more... (results)" button, gives the "modify query" boxes at the bottom--this doesn't respect named args selection nor intro/outro, I'm not referring to the Special:CargoQuery page--that remembers named args as expected). We updated to Cargo v3.3.1 and MW 1.39.1 and the form still drops named args on these subsequent "more results" pages. Intro/outtro are still not options in the Special:CargoQuery form (I assume this is the form that appears on "more..." (results) pages, so they are still dropped when modifying any query, and can't be added to any query in Special:CargoQuery because there's no fields at all for them in the Cargo Query form. Basically, if one wants to use |format=template to generate formatted tables with intro/outro setting table start/end wikitext, we're out of luck on queries. TiltedCerebellum (talk) 23:59, 7 January 2023 (UTC)

Complete Config and Permissions List

Is there a complete list of extension config parameters, along with their descriptions, (all) provided in one single place? (They seem to be peace-meal displayed in bits on different pages like this one, yet more undescribed on the extension page infobox and other plaes). Additionally, is there a list of all configurable user permission settings, their descriptions, and their default values? (Again, am finding peace-meal over various pages.) Finding these items in dribs and drabs makes configuration (at least in one or two tries) a bit of challenge. Thanks! TiltedCerebellum (talk) 23:34, 1 December 2022 (UTC)

Yes, it would be nice to have a single listing in one place. Such a list does not exist currently, unfortunately - the closest you can find is in the "config" section in extension.json, although it doesn't explain what each setting is for; hopefully you can figure it out from the names (or the documentation). Yaron Koren (talk) 03:11, 5 December 2022 (UTC)

Thanks for this, that will help in the meantime. TiltedCerebellum (talk) 18:38, 13 December 2022 (UTC)

Issue with recreating table data after upgrading to MW 1.39

We're in the process of upgrading to MW 1.39, and it seems like when we try to add data to a table it isn't adding. Data that we imported from the previous install is fine, but new data isn't getting added to the table. I tried to do a recreate of one of the tables and got this error:

[7c4fa6cab35b855387997d26] /Special:CargoTables/RuleData?_replacement MWException: Error: Table RuleData__NEXT not found.

Backtrace:

from /var/www/html/aa-new/extensions/Cargo/includes/CargoUtils.php(264)

#0 /var/www/html/aa-new/extensions/Cargo/includes/specials/CargoTables.php(104): CargoUtils::getTableSchemas()

#1 /var/www/html/aa-new/includes/specialpage/SpecialPage.php(701): CargoTables->execute()

#2 /var/www/html/aa-new/includes/specialpage/SpecialPageFactory.php(1428): SpecialPage->run()

#3 /var/www/html/aa-new/includes/MediaWiki.php(316): MediaWiki\SpecialPage\SpecialPageFactory->executePath()

#4 /var/www/html/aa-new/includes/MediaWiki.php(904): MediaWiki->performRequest()

#5 /var/www/html/aa-new/includes/MediaWiki.php(562): MediaWiki->main()

#6 /var/www/html/aa-new/index.php(50): MediaWiki->run()

#7 /var/www/html/aa-new/index.php(46): wfIndexMain()

#8 {main}

Any thoughts? Blinkingline (talk) 22:04, 7 December 2022 (UTC)

Please make sure you're using the latest version of Cargo. Yaron Koren (talk) 05:40, 8 December 2022 (UTC)

We also had issues with table recreation after upgrade, but running the maintenenace script to completely rebuild (not recreate) all cargo tables fixed it, I'd recommend trying that (and then rebuilding and specifying explicitly the _pageData and _fileData tables (if you use these), as rebuilding all for some reason didn't rebuild those unless specified explicitly). Once rebuilt once on the new version of MediaWiki, then Cargo re-create worked as expected, no more errors. Can confirm this issue was on Cargo 3.3.1 and MW 1.39.1, and resolved it on these versions. TiltedCerebellum (talk) 23:59, 7 January 2023 (UTC)

Special characters stored in encoded form by Magic words

Good evening,

I'm storing custom page paths in Cargo using magic words. I've noticed that, when pagenames contain special characters, they are stored in encoded form in Cargo tables. Since {{PAGENAME}} stores special characters html-encoded and {{PAGENAMEE}} percent-encoded, adding a template with these magic words to a page named "E=MC2" stores the pagename in Cargo as E=MC2 or E%3DMC2, respectively. I presume this happens because magic words provide pagenames in encoded form to Cargo (despite displaying them in decoded form). Nevertheless, given that this only becomes an issue when using magic words with Cargo, should I add this to the list of known bugs?

Greetings,
Devaroo (talk) 18:17, 17 December 2022 (UTC)

If it affects the display of the data, then definitely. Yaron Koren (talk) 15:52, 19 December 2022 (UTC)

Done Devaroo (talk) 18:35, 19 December 2022 (UTC)

Please add debug mode (to wikitext)

Please consider adding a |debug= parameter for users who need to debug the wikitext output of a query result as it interacts with various templates and parser functions. This would function similarly to how DynamicPageList3 provides a debug mode, which when a value of '5' is set, provides full wikitext output for troubleshooting the above mentioned interaction... particularly when |format=template is set. Additionally, this would be great since Special:ExpandTemplates doesn't work with Cargo (though it does with DPL3, so, ironically it didn't really need a debug mode other than for convenience).

It is for this reason that we don't migrate some custom formatted tables to Cargo from DPL3, we can't debug the resulting interaction between cargo query, templates, and parser functions. We also use wikitext output for other random stuff, and would miss it, but we'd love to use one extension rather than two. Thanks --| TiltedCerebellum (talk) 06:58, 18 December 2022 (UTC)

I agree that would be nice, although format=table is already a good way to at least see what the query itself returns. Yaron Koren (talk) 15:51, 19 December 2022 (UTC)

I should have been clearer, it is specifically debugging the interaction between format=template (and the formatting template's contents, i.e. the contents of "my template" in: |template=mytemplate) as they interact with Cargo that is the main issue, however. It's not just checking Cargo query output. So, I'm afraid that format=table isn't much help with how these function together as a unit. A lot of people don't desire plain text-based tables, often they want images/icons and other templates inserted to go with the text and rarely do they want to insert such into parameter values, wanting to keep data as data (and usable for other puposes). This is an area that would be helpful possibly to a number of users TiltedCerebellum (talk) 01:51, 20 December 2022 (UTC).

How to add a new field?

Is the following the proper way to add a new field?:

1. Edit template (add new field details)

2. Recreate data

3. Edit form (add new field details) Gvorster (talk) 14:07, 18 December 2022 (UTC)

That's right! For the first step, depending on how the template is structured, you may need to add that field in two or three places, not just #cargo_declare. Yaron Koren (talk) 15:49, 19 December 2022 (UTC)

Links/File Use

How would one access a list of links used on a page, similar to MW Api's MW api /api.php?action=query&titles=Page Title&prop=links? I don't see a way to set a _pageData column, nor a file use column for _fileData settings. I'm hoping to find a way to replace DPL3's linksto and linksfrom functions. Thanks!

Also, |where=_categories HOLDS 'Events' AND _fullText MATCHES '"Sylvan|i"', to do an exact match search, produces the following error: "Error: unclosed string literal", yet these also don't work: '"Sylvan\|i"', '"Sylvan\|i"' ESCAPE '\' (all result in the same error). How to escape the pipe? --|TiltedCerebellum (talk) 05:59, 20 December 2022 (UTC)

To be clear, {{!}} also doesn't work. --|TiltedCerebellum (talk) 08:10, 20 December 2022 (UTC)

Cargo unfortunately doesn't store link information, although that would be a nice addition to _pageData. For the other one, I don't know... are you sure the pipe is the problem? The double quotes might be the issue, I don't know. Yaron Koren (talk) 02:57, 21 December 2022 (UTC)

Thanks for confirming. It would make a nice addition to _pageData indeed, and quite useful to us.

Since currently we can't include links, we're trying to use _fullText to instead search for wikitext syntax, however when doing that, we're running into multiple issues:

• First, none of the following work: 'Sylvan|i', 'Sylvan\|i', 'Sylvan{{!}}i'; so the pipe does seem to be the problem (second set of quotes appear irrelevant and partially works for other things per MySQL manual page). The same error message is received: Error: unclosed string literal.
• Second, if Cargo's MATCHES is equivalent to MATCHES...AGAINST as the Cargo docs state, according to the MySQL page linked in Cargo manual, I should be able to do an exact phrase match using two sets of quotes. The linked page states: '"some words"' - Finds rows that contain the exact phrase “some words” (for example, rows that contain “some words of wisdom” but not “some noise words”).. This does seem to partially work, for example:

{{#cargo_query:
tables=_pageData
|fields=_pageName=Page,_fullText=Result
|where=_fullText MATCHES '"type=Sylvan" "location=Sylvan"'
}}

The above does almost give an exact match search narrowed to pages containing "type=Sylvan" or "location=Sylvan" (MySQL page says that space functions as an OR operator); however, it also strangely includes results whose pages only contain "location=Sylvan" so, it matches anything with "=Sylvan" or "=Something Else Sylvan", which is not specified in the MATCHES statement (it includes no other unexpected results, of which there are many), here are the only contents of an example extra page(s) erroneously included in results (I think, if my syntax is not incorrect):

{{Infobox
|type=Overgrowth
|location=Lakeside
|other=Sylvan
}}

So, we almost have the desired result, but the extra result(s) (and the pipe problem) suggests to me that perhaps Cargo's MATCHES is having problems differentiating some wikitext characters such as | pipe and = equals? I don't know, but two similar issues involving wikitext characters seems odd. Escaping these or using replacement templates have zero effect, the same result are provided. (If I'm doing something else wrong please do correct me, as I'm learning SQL as I go). Hopefully this helps clarify, thanks for the reply above! --|TiltedCerebellum (talk) 21:45, 21 December 2022 (UTC)

Right, yes, double quotes do make sense to have within a "MATCHES" value. And it makes sense that pipes would break the whole query, since the MediaWiki parser splits up the #cargo_query call by pipes, so the entire input would get messed up. Using the {{!}} hack instead should work, though - I don't know why it's failing for you. I just tried it on my wiki, and it works fine for me. Having an '=' in the value worked fine for me too. Does it really give you that same "unclosed string literal" error message? Yaron Koren (talk) 03:24, 22 December 2022 (UTC)

Yes, that was on Cargo version 3.2. I upgraded to Cargo 3.3.1 and MediaWiki 1.39.2 and the problems appear to have been resolved! TiltedCerebellum (talk) 23:59, 7 January 2023 (UTC)