Extension talk:Cargo

Cargo database shared between wikis
I've created a separate database for my cargo tables. I want multiple wikis to access the same content. However, each wiki has a different $wgDBprefix. Would this stop them from being able to access the same data? -- Prod (talk) 03:30, 4 October 2018 (UTC)


 * I don't think it's possible for a wiki to use another wiki's Cargo content anyway, at least not without some major hacks. If you want another wiki to get and display a wiki's Cargo data, you should use the External Data extension, and specifically the function #get_web_data, and have that access the main wiki's Special:CargoExport page. Yaron Koren (talk) 13:15, 4 October 2018 (UTC)

Special:CargoTables gives Fatal exception of type "Wikimedia\Rdbms\DBQueryError" on view table
I'm getting this error on all tables that contain list of datetimepicker Hopefully you can duplicate the error with this simple template....

JamesDriscoll (talk) 22:15, 4 October 2018 (UTC)


 * Could you add "$wgShowSQLErrors = true;" and "$wgShowExceptionDetails = true;" to your LocalSettings.php? That will hopefully show a more helpful error message. Yaron Koren (talk) 00:27, 5 October 2018 (UTC)


 * they were already on :-(  apache error log isn't showing anything either JamesDriscoll (talk) 06:41, 5 October 2018 (UTC)


 * Yes, I was just able to recreate this myself - there's a bug in the default querying of fields that hold a list of dates. Sorry about the problem; I'll look into it. Yaron Koren (talk) 18:59, 5 October 2018 (UTC)


 * I checked in a fix for this a few days ago - if you get the latest code, the problem should go away. Yaron Koren (talk) 16:12, 9 October 2018 (UTC)


 * Thanks, view is working but sadly the same error is appearing on drill down,sorry I didn't spot that on my first post!JamesDriscoll (talk) 20:30, 9 October 2018 (UTC)


 * Ah, yes. This was a tougher nut to crack, but I checked in some fixes that I think fix the issue for the display of date-list fields in Special:Drilldown. Yaron Koren (talk) 15:26, 16 October 2018 (UTC)

Automatic |no html added when query used in page forms?
Hi, I have a problem with the links not showing in the results of a cargo query when using it from Special/runquery. I think this is the same problem described in this post. I've found a workaround using instead of  to build the links, unfortunately it doesn't work with  and ends in things like ?'"`UNIQ--item-13--QINU`"'?. Any idea ?

Best regards, --Ludovic Strappazon (talk) 10:08, 5 October 2018 (UTC).


 * If you don't know Lua but have Scribunto extension, you can try using this wrapper to be able to effectively use a |format=template without actually using |format=template, and thus get around the bug altogether. --RheingoldRiver (talk) 18:25, 23 October 2018 (UTC)

i18n for dropdowns
Hi, I'm not sure if this is a Pageforms or Cargo issue, or just me misunderstanding :-)

Is there any way to have different label and values for dropdowns?

e.g. if, inside a #cargo_declare, I have something like...

the Pageform will end up producing something like this...

I'd like to be able to change the string displayed to the user without changing the value stored in the database

I'm imagining something on the lines of this in the #cargo_declare

Is there a way to do this already? Thanks JamesDriscoll (talk) 10:57, 12 October 2018 (UTC)


 * This sounds like a Page Forms issue - check out the mapping section, if you haven't seen it already. Yaron Koren (talk) 02:13, 14 October 2018 (UTC)


 * Thanks for the pointer Yaron - a quick experiment on a test page is looking promising. I was surprised the translation also happened on the page that gets created from the form but this may be a good thing in my case :-) JamesDriscoll (talk) 14:48, 14 October 2018 (UTC)
 * on further experimentation the edit form produces this...

editing a page results in the form not being able to pick the correct value - I assume because status = 'Live' rather than 'Label for Live' shouldn't the form look like this... and any display on a page created is a separate problem to what is displayed on the form? Perhaps I should be reporting a potential bug on a pageforms discussion page.... JamesDriscoll (talk) 15:18, 14 October 2018 (UTC)


 * That shouldn't happen. How are you doing the mapping? Yaron Koren (talk) 23:19, 14 October 2018 (UTC)
 * in the form Im going...


 * Okay, that explains it. The set of "values=" should be the actual values, not the labels. And in addition to "mapping cargo field", you also need to set "mapping cargo table" - otherwise it won't take effect. Yaron Koren (talk) 19:19, 15 October 2018 (UTC)
 * so how do I specify what the labels are? (I want the labels to be different to the vales) JamesDriscoll (talk) 20:29, 15 October 2018 (UTC)
 * That's what the mapping is for. It sounds like your best bet is to use a "mapping template" - create a template that calls #switch or some such to display the right label based on the value, which is represented by . Yaron Koren (talk) 20:37, 15 October 2018 (UTC)
 * sorry, I'm not grasping this. is there a way on the page form to have a different label to the value? I'm happy to do the switch on the actual document but I want the form to display one thing on the the drop down to the user but set a different value in the table.like this


 * Yes - have "values=" set to the real values (Prospective, etc.), then create a mapping template that displays the correct label depending on the value of, and set "mapping template=" to the name of that template. Yaron Koren (talk) 02:30, 16 October 2018 (UTC)



produces this in the form....

which would be great if the values were, Live, Retired and Prospective. I hope I've understood this time, thanks for your help. JamesDriscoll (talk) 07:19, 16 October 2018 (UTC)
 * the right bits end up in th database though, when I'm on a real computer I'll have a crack at updating the docs with an example,thanks again JamesDriscoll (talk) 09:47, 16 October 2018 (UTC)

No HTML in API queries
We are trying to generate some API feature with cargo but keep getting UNIQ-QINU elements in the response. From what I have read this need to be addressed by adding "no html" to queries but this option is not available in API query from what we have understood. What can we do about it? Thanks, Wess (talk) 07:01, 14 October 2018 (UTC)


 * I think it is available - try just adding "&no html" to the URL. Yaron Koren (talk) 23:37, 14 October 2018 (UTC)

CargoQuery cannot retrieve all the fields because of the default alias _pageName
Hi,

I was trying to run this query to get all the fields in the table https://dragalialost.gamepedia.com/api.php?action=cargoquery&format=json&tables=Adventurers

However I am met with this error:

It seems like the problem is with cargo table defaults to using _pageName if not provided any fields and API queries do not support underscore.

Is there a way so that if I don't provide any field names it would default to get ALL of the fields for that cargo table? something like fields=* would be fine as well --Pupper75 (talk) 21:17, 25 October 2018 (UTC)


 * Unfortunately, there's no way to automatically get all the fields in a table - that's unrelated to this underscore problem. You'll have to just manually specify each field. Yaron Koren (talk) 21:52, 25 October 2018 (UTC)


 * Are there work to add in this feature? Imagine if you have a SQL language that doesn't have  and you have to look through the table definition to get all the fields you need. --Pupper75 (talk) 02:08, 26 October 2018 (UTC)


 * I looked into supporting "*" before... there was some difficulty with doing that, though I can't remember what it was now. I admit that it's annoying. Yaron Koren (talk) 15:31, 26 October 2018 (UTC)

List table not created, HOLDS query error [FIXED in Cargo 2.0.1]
For test purposes, I created two templates (Book and Author) by copying from https://www.mediawiki.org/wiki/Extension:Cargo/Quick_start_guide. For reference, here is the declare portion:
 * 1) cargo_declare:_table=Books|Authors=List of Page|Genres=List  of String|Year_of_publication=Date|Number_of_pages=Integer

According to https://www.mediawiki.org/wiki/Extension:Cargo/Storing_data#Database_storage_details, there should be a separate table creates for the "Authors" field because it's a list, and there should also be a "Authors__full" column. But neither of those exist, just "Authors", which is a VARCHAR(300). I created the tables via the web interface, but for other tables I've used cargoRecreateData.php to the same effect.

The more important issue, possibly related - I tried to do an example query with "HOLDS":

But I get this error message:


 * Query: SELECT `_pageName` AS `Book`,`Authors` AS `Authors` FROM `cargo__Books` WHERE Authors HOLDS 'Foo' ORDER BY `_pageName`, `Authors` LIMIT 100 Function: CargoSQLQuery::run Error: 1064 You have an error in your SQL syntax; check the manual that corresponds to your MariaDB server version for the right syntax to use near 'HOLDS 'Foo' ORDER BY `_pageName`, `Authors` LIMIT 100' at line 1 (localhost:/var/lib/mysql/mysql102.sock)

Note: I'm using Page Schemas and Page Forms for my normal objects, but I tried to keep things simple for this example.

Here are my versions:
 * MediaWiki 1.31.1
 * PHP 7.0.27
 * MariaDB 10.2 - separate Cargo database (main wiki database is MariaDB 5.5.60, but I was getting Cargo errors with that)
 * Cargo 2.0
 * Page Forms 4.4.1
 * Page Schemas 0.4.8

Please let me know if there's any other information I can provide to help. --Samh78537 (talk) 20:47, 30 October 2018 (UTC)


 * Yikes, sorry about that - there turned out to be some pretty major bugs that snuck in to Cargo right before the release of version 2.0, a few weeks ago; clearly I didn't adequately test it. I just released a new version of Cargo, 2.0.1, that should work a lot better - please upgrade to that when you get the chance. Yaron Koren (talk) 03:40, 31 October 2018 (UTC)


 * Thanks! I was afraid I was doing something wrong. I've updated Cargo to 2.0.1 (dec2d3a) (also Page Forms to 4.4.2), but it still seems to be doing the same thing. Is there something else I need to do to make it take effect? I tried using the web link and cargoRecreateData.php, and I tried deleting the tables first, as well as the rows in cargo_tables. --Samh78537 (talk) 16:48, 31 October 2018 (UTC)


 * You just need to re-save the template, and recreate the table, and then everything else should work. Yaron Koren (talk) 16:50, 31 October 2018 (UTC)


 * Re-saving was the missing step; I didn't realize that saving the template did something before you recreate the table. --Samh78537 (talk) 13:52, 1 November 2018 (UTC)

In-page list of backlinks [RESOLVED]
Before I look into it myself I hope you don't mind me asking whether the following can be replicated with Cargo. "With the extension Semantic MediaWiki (SMW) links are categorized by specifying relations. For a given relation the backlinks of a page can be produced in-page. A series of queries, one for each relation (which seems cumbersome but can be put in a template like [1]), provides an in-page list of backlinks sorted by relation. Moreover, forward links and attributes of the resulting pages can also be provided, and also backlinks of backlinks." (from Help:What links here). Thanks. Jonathan3 (talk) 20:32, 3 November 2018 (UTC)
 * P.S. It turns out that this is simple in DPL3 - - but I still wonder about using Cargo. Jonathan3 (talk) 00:01, 4 November 2018 (UTC)


 * Yes, it can definitely be done with Cargo. I didn't realize the general "What links here" documentation mentions SMW - that should probably be updated. Yaron Koren (talk) 16:27, 5 November 2018 (UTC)


 * Thanks. How does it work? Jonathan3 (talk) 15:08, 6 November 2018 (UTC)


 * Do you understand the explanation about SMW there? It's a bit convoluted, but they're basically saying, run queries to display all the possible (SMW-based) connections that various pages can have to the current page. The same thing can be done with Cargo queries. It's not really the same as "What links here", since it doesn't cover all the links from one page to another that aren't being stored via SMW/Cargo. I'm not sure if that text is even worth including there at all. Yaron Koren (talk) 21:28, 6 November 2018 (UTC)


 * I didn't completely understand it, but it sounds like a right rigmarole, and I agree with you that it (either about SMW or edited to include Cargo) isn't very helpful there, especially when there are simple ways to achieve the same or a better result. Thanks. Jonathan3 (talk) 02:15, 8 November 2018 (UTC)

Transclude a page without its categories
If page A transcludes page B (which is is category B) then page A ends up in category B too... this happens whether I use normal transclusion, labelled section transclusion  or DPL3.

Would there be a way of using Cargo to transclude the page content up to but not including the first ? Thanks, Jonathan3 (talk) 23:58, 3 November 2018 (UTC)
 * There is Extension:NoCat which can prevent all categories on page A. That might be a bit too much for what you're after. I use it in conjunction with Cargo when listing e.g. a blog index page (which never needs its own categories). Sam Wilson 00:31, 4 November 2018 (UTC)


 * Thanks for that. Unfortunately I need the existing categories. As it happens, when you use DPL3 as a parser function and use reset=categories it has the same effect. When you use it as a tag with the same parameter it only removes the transcluded category (perfect) but then I can’t use it the way I need to in a template... Jonathan3 (talk) 10:28, 4 November 2018 (UTC)

Here's the latest. I'd thought of trying Cargo with SUBSTRING_INDEX to get rid of everything after the first [[Category: but Cargo seems to render the full page text as it was typed (e.g. template calls, wikitext) so I didn't go down that route. I found another DPL3 paramater, eliminate=categories, which had the desired effect of transcluding a page without its categories (but keeping existing categories). [[User:Jonathan3|Jonathan3]] (talk) 21:09, 4 November 2018 (UTC)


 * The following sort of works...:


 * if you're just transcluding a paragraph with italics, bold etc, but anything with a section header is messed up - e.g. it says  instead of just "External links" - and links seem not to work either. Jonathan3 (talk) 21:03, 5 November 2018 (UTC)


 * I assume you've figured out a workaround, but for future reference you can use onlyinclude/noinclude etc to do this.


 * Do you mean a way to avoid transcluding the categories? (Wouldn’t that make it only possible to view the page content when transcluded? Good idea if that’s the desired outcome.) Or do you mean a way to avoid the bad rendering of some content transcluded by Cargo? (In which case - could you expand on this, as I don’t understand?) I’m currently using DPL as a solution (see question below, which is linked). Thank you. Jonathan3 (talk) 10:27, 8 November 2018 (UTC)

Transclude page with wikitext [RESOLVED]
When I do something like...

...it displays the wikitext on screen rather than applying it, e.g. bold text instead of bold text, and anything within appears as it was typed. Is there any way round this? Thanks. Jonathan3 (talk) 20:26, 4 November 2018 (UTC)


 * Try adding "|no html" to the query. Yaron Koren (talk) 16:26, 5 November 2018 (UTC)


 * Thanks, that works perfectly (for wikitext like ''' for for – template calls too). Jonathan3 (talk) 18:49, 5 November 2018 (UTC)

SimpleTooltip and Cargo Query = UNIQ...QINU error
When I query a page with SimpleTooltip and output the result as a table, the string that has a tooltip attached returns an error “UNIQ...QINU”.

Here’s an example page with tooltip: https://triglav.miraheze.org/wiki/Evilfang

And here’s what happens when I query it: https://triglav.miraheze.org/wiki/Axe

Any help would be appreciated. Thank you!


 * I can't actually see the error, but I can imagine. It might fix the problem to change any of those fields that can hold a tooltip from type "String" to type "Wikitext". Yaron Koren (talk) 16:37, 5 November 2018 (UTC)


 * Not the OP, but we ran into the same issue while trying to store/query certain non-core HTML tags and thought it was a deliberate limitation of Cargo? Possibly similar situation to this post, except in our case the Wikitext wouldn't even store in the cargo table itself eg. trying to store the following text would return UNIQ--ref-00000011-QINU:

Error when using join on HOLDS
When I'm trying to do query of cargo points to other cargo, like this

I am getting this query error

Query: SELECT FIELDS FROM `cargo__TABLE_A` RIGHT OUTER JOIN `cargo__TABLE_B` ON ((`cargo__TABLE_A__LIST_OF_TABLE_B`._value=`cargo__TABLE_B`._pageName)) LEFT OUTER JOIN `cargo__TABLE_A__LIST_OF_TABLE_B` ON ((`cargo__TABLE_A`.`_ID`=`cargo__TABLE_A__LIST_OF_TABLE_B`.`_rowID`)) WHERE `cargo__TABLE_A`.`_pageName`="PAGE_NAME" LIMIT 100 Function: CargoSQLQuery::run Error: 1054 Unknown column 'cargo__TABLE_A__LIST_OF_TABLE_B._value' in 'on clause'

(cargo__TABLE_A__LIST_OF_TABLE_B._value is exits in DB, I checked)


 * That's odd... does that table have a "_value" column? If not, what columns does it have? Yaron Koren (talk) 16:39, 5 November 2018 (UTC)
 * Yes, it have. I have wild guess the error happening because the way the query build. anysite (talk)
 * It appears that you've found a bug, although you may be able to get around it by just switching the order of the two tables in the "tables=" parameter in the query. Yaron Koren (talk) 17:18, 5 November 2018 (UTC)
 * Switching tables solve it! thank you vary much. anysite (talk)

Disable full text search on Drilldown page
I'd like to be able to do this. I guess you don't want too many options - but if you would add a CSS id then I'd be able to hide it! I'd be grateful if you would consider this. Thanks Jonathan3 (talk) 14:02, 10 November 2018 (UTC)


 * Having an ID sounds like a good idea - though I should note that you can already "disable" this search input by just removing "_fullText" from the list of fields stored in the "_pageData" table. Would that work for you? Yaron Koren (talk) 13:57, 11 November 2018 (UTC)


 * I hadn't done that as I think I might want to use "full text" in future for other tables... but for now I've removed _fullText and it works fine :-) Thanks. Jonathan3 (talk) 22:56, 11 November 2018 (UTC)

'_fullText' for RTF?
'_fullText' - the full text of the file; this is only stored for PDF files:

Is there any way to extend this to RTF files? Thanks in advance. Jonathan3 (talk) 22:53, 11 November 2018 (UTC)


 * That's interesting - I don't think I had heard of people uploading RTF files to MediaWiki. I'm guessing it's possible, though I wouldn't call it high-priority for me. I'd be happy to add in a patch to handle this, though. Yaron Koren (talk) 14:36, 12 November 2018 (UTC)

Tag cloud blank [RESOLVED]
When I try to use tag cloud, for queries that work fine for tables etc, it is just blank with a "More..." link to the ViewData page. Have you an example of it in operation, for me to check to see what I'm doing wrong? I'm just adding. Thanks. Jonathan3 (talk) 23:00, 11 November 2018 (UTC)


 * Sorry, I realize now that the documentation for the "tag cloud" format is pretty lacking. There should (usually) be two queried fields, one of which is a string and the other an integer, where the integer is used to set the font size of each string. The integer value will usually be "COUNT(*)", using "group by". I just put together an example here. Yaron Koren (talk) 02:27, 12 November 2018 (UTC)


 * Thanks. Unfortunately on my wiki, the same Cargo query (a) works on Special:ViewData, but (b) only shows one item as a query on a normal page. I've just switched & and | characters so can't see why it doesn't work properly - any ideas? Jonathan3 (talk) 13:57, 12 November 2018 (UTC)


 * I don't know, I might have to see the query. Yaron Koren (talk) 13:58, 12 November 2018 (UTC)


 * Apologies. I hadn't changed  to   for the in-page query. It works grand now, thanks. Jonathan3 (talk) 14:01, 12 November 2018 (UTC)


 * It works well. I used the "template" parameter to make a tag cloud where each item links to the relevant Special:Drilldown page and also has the count in brackets :-) Jonathan3 (talk) 14:45, 12 November 2018 (UTC)


 * Great! That sounds pretty neat. Yaron Koren (talk) 19:09, 12 November 2018 (UTC)

MAX(Date) returns an integer
I have a table with column Release_date of type Date: https://wow.gamepedia.com/Special:CargoTables/Patches Querying the table with field MAX(Release_date) returns 2,018.0 which is for some reason an integer representation of just the year and not a date. Please advise. --pcj (talk) 12:47, 14 November 2018 (UTC)


 * This only indirectly answers your question, but you can obtain a full date in your choice of format by using MySQL's DATE_FORMAT function, e.g. in this modified query. Jonathan3 (talk) 00:01, 18 November 2018 (UTC)


 * Yes, Cargo assumes the type of every SQL function that is called, and usually that works fine, but for the case of MAX, MIN and maybe a few others, the type that is assumed (Float) is not always correct - it could be a Date, an Integer or even a String. I hope to make Cargo's parsing smarter for these specific functions - until then, wrapping the MAX call in a function like DATE or DATE_FORMAT does indeed seem like the best approach. Yaron Koren (talk) 16:21, 19 November 2018 (UTC)


 * Okay, I just checked in a fix that tries to improve this, by setting the assumed type of MIN and MAX to be the type of whatever is inside those calls. Yaron Koren (talk) 00:53, 21 November 2018 (UTC)

Log for table creation/recreation
Would it be possible to add? I'd like to see it in recent changes. --RheingoldRiver (talk) 18:41, 16 November 2018 (UTC)


 * Great idea - I just checked in code that does logging of the "create", "recreate", "replace" and "delete" actions for Cargo tables. Hopefully it works fine, and hopefully it'll get to you soon. Yaron Koren (talk) 19:14, 21 November 2018 (UTC)


 * Awesome, thanks! --RheingoldRiver (talk) 23:05, 21 November 2018 (UTC)


 * This is good, but the email which arrives worried me the first time I saw it! Here are the relevant parts:
 * Subject: [Website name] page has been changed by anonymous user 127.0.0.1
 * Message: ... The [Website name] page has been changed on 18 January 2019 by anonymous user 127.0.0.1, see [Website main URL] for the current revision. ...
 * I'm happy with it now, but wonder if the email should somehow refer to Cargo :-) Jonathan3 (talk) 14:03, 18 January 2019 (UTC)


 * Do you get an email for every log action? Cargo itself is not doing any emailing. Yaron Koren (talk) 15:32, 18 January 2019 (UTC)


 * ”Every log action” - do you mean like deletions? No. I only get emails for pages updated by other/anonymous users. MW seems to think the Cargo action is a page change for this purpose. Jonathan3 (talk) 16:41, 18 January 2019 (UTC)

Problem with cargo_declare: tables recognized as missing even exits in DB
We had some errors with cargo declare - tables were not created, or created in DB but their view page throw error: "table X not found". (from CargoUtils.php line 231);

After digging in the code we found that entries in "page_props" table, that ought to define the problematic cargo table was missing. When we copied the values defined in includes/parserfunctions/CargoDeclare.php line 296-300 and inserted them by hand to DB, and executed maintenance/cargoRecreateData.php the tables started working again. Anysite (talk) 21:52, 19 November 2018 (UTC)
 * Wild guess: the problem maybe related to declares with fields that has '-' in their names, leading the part of code which creating indexes for tables to fail silently and the init process get stuck in middle. Could it be?
 * As I said, its a sql ERROR. here's more details:
 * CREATE INDEX excerpt_text-string_MYTABLENAME ON `cargo__MYTABLENAME` (`excerpt_text-string`);
 * ERROR 1064 (42000): You have an error in your SQL syntax; check the manual that corresponds to your MariaDB server version for the right syntax to use near '-string_MYTABLENAME ON `cargo__MYTABLENAME` (`excerpt_text-string`)' at line 1
 * Here's cargo_declare:


 * It looks like this bug was fixed about two weeks ago. Are you running the latest code? Yaron Koren (talk) 21:29, 27 November 2018 (UTC)

Cargo and capiunto template
Hi,

I have been building a wiki that I am going to bulk upload pages to from CSV files. I have been dilligently writing a template that automates the page including categorising, this may be complete rubbish until last week I had never edited or altered a wiki! Now I have come across SMW & Cargo. Clearly in the long term building a more usable database is something that will be invaluable but right now it is a daunting task rewriting the template. As I have been using capiunto and therefore lua the data layout is different to what is shown when templates are created with the PageForm extension. If I write the "declare" and "store" properties to match my current template can I keep using it with little modification?

Below is some of my current template: header1       = Personal Info
 * label2       = Alias
 * data2       =
 * label3       = Birth Name
 * data3       =
 * label4       = Birth Date
 * data4       =
 * label5       = Age
 * data5       =


 * label6       = Languages
 * data6       =


 * label7       = Birth Place
 * data7       =
 * label8       = Ethnicity
 * data8       =

Hopefully someone has some input, if not I will crack on and report back!

Thanks, P.s. Apologies if this is in the wrong place, format, etc. I am very new to this and just trying to muddle my way through!


 * I think so - you just need to add #cargo_declare and #cargo_store calls to the right places in the template, and everything should work, regardless of the fact that the template is otherwise just calling Lua. Yaron Koren (talk) 14:34, 21 November 2018 (UTC)


 * Thanks Yaron, better support than many commercial teams I deal with! You are absolutely right, cargo doesn't even know about the call as it is all processed in the template, hadn't really thought throught the question. Safe to say Cargo is a far better method of data management than categories! Loving it so far and thanks for the support. --185.92.25.2 00:35, 1 December 2018 (UTC)

Recreate data tab and action.
Ok, so I have been playing around seems like I can use parser functions in field inputs however I cannot find a (Re)Create Data tab anywhere. I have also tried appending "?action=recreatedata" to the URL and I get a blank page. Also I have tried php cargoRecreateData.php and it says that the table is not declared in any template.

I feel like I am missing something obvious somewhere...

I was, seems the jobqueue was pretty full and clearly holding things up. runjobs.php fixed it and now I can create tables.... On to the next problem to solve!


 * You just need to add #cargo_declare and #cargo_store to the template, I think. Yaron Koren (talk) 14:35, 21 November 2018 (UTC)


 * Thanks Yaron, #cargo_declare and #cargo_store were present I simply had a very full job queue, after running runJobs.php the tab appeared and all was well. Hopefully this may help someone in future! --185.92.25.2 00:29, 1 December 2018 (UTC)

More information on text input types
I'd be interested to know more about the differences between: Page - holds the name of a page in the wiki String - holds standard, non-wikitext text Text - holds standard, non-wikitext text; intended for longer values Wikitext - holds text that is meant to be parsed by the MediaWiki parser Searchtext - holds text that can be searched on, using the MATCHES command URL - holds a URL Email - holds an email address

I can tell from the names what they are designed for, but how are they treated differently? E.g. when I use wikitext in a String field it does appear as wikitext. Thanks. Jonathan3 (talk) 14:08, 26 November 2018 (UTC)


 * This should probably be spelled out better in the documentation...
 * In query results: Page values are links, Wikitext values are parsed, URL value are shown as links... I can't remember what happens with Email values.
 * In Special:Drilldown: of the types you listed, only Page and String values are shown at all. (That part is documented already.) Yaron Koren (talk) 04:18, 27 November 2018 (UTC)


 * Cheers. In the database are they all stored the same way? There used to be different default sizes I think - does this still apply? Jonathan3 (talk) 14:40, 27 November 2018 (UTC)

Suggested change for table.cargoTable styling
table.cargoTable td.odd { background: #fff; }

table.cargoTable td.even { background: #eee; } to .cargoTable tr:nth-child(even) { background: #eee; }

This will preserve the zebra styling in sortable tables, and I think also let you remove the  and   classes altogether. --RheingoldRiver (talk) 17:32, 26 November 2018 (UTC)


 * I seem to remember deciding against using the "nth-child" option, though now I can't remember why. (Not fully supported by browsers at the time, maybe?) Anyway, what would the advantage of this approach be, other than fewer class names in the HTML? Yaron Koren (talk) 04:20, 27 November 2018 (UTC)


 * As-is, when you sort a table, the same rows maintain their even/odd classes, so you get random colors in each row instead of zebra striping, which looks weird / is harder to read. Using nth child maintains the every-other striping even when you sort. --RheingoldRiver (talk) 16:06, 27 November 2018 (UTC)


 * I’d noticed that too. If it could be fixed then I’d be in favour! Thank you. Jonathan3 (talk) 17:39, 27 November 2018 (UTC)

You can fix on your own wiki, add this to common.css (or whichever css page you want): background: transparent; }
 * 1) content table.cargoTable td.even,
 * 2) content table.cargoTable td.odd {

.cargoTable tr:nth-child(even) { background: #eee; } --RheingoldRiver (talk) 20:08, 27 November 2018 (UTC)


 * Mega. That worked perfectly. Jonathan3 (talk) 01:04, 28 November 2018 (UTC)


 * I had forgotten why Cargo was not using this "nth-child" approach - it turned out that Cargo actually was doing it that way, until just about a year ago, when the "merge similar cells" parameter was added to the "table" format; the "nth-child" approach didn't work with cells that span multiple rows. I think I didn't realize, though, that the alternate approach of using classes fails when the table gets sorted. So I just checked in a change where it goes back to the "nth-child" approach, using the alternate approach only when "merge similar cells" is set. Hopefully this works fine in all cases now. Yaron Koren (talk) 21:29, 29 November 2018 (UTC)


 * Ah that makes sense. Thanks for the update! --RheingoldRiver (talk) 23:07, 29 November 2018 (UTC)

Using AND in a hold clause
I have a query that tests two separate fields in a table to see if they contain one or more of a list a values. It looks like this:

The "Holds Risk Categories" template and the "Holds Risk Scope" template generate the hold statement for the the respective lists of values passed to the query in the "Risk Categories" and "RiskScope" parameters. For example this generates the following 'where' clause for a query with a single risk category and risk scope value passed to it:

Where ( Risk_Categories HOLDS "Governance Failure" ) AND ( Risk_Scope HOLDS "Protect consumers" )

This generates the following error:

A database query error has occurred. Did you forget to run your application's database schema updater after upgrading? Query: SELECT `cargo__Risk_Categories`.`_pageName` AS `Title`,`cargo__Page_properties`.`Description` AS `Description`,CONCAT(`cargo__Risk_Categories`.`Risk_Categories__full`) AS `Risk Categories`,CONCAT(`cargo__Risk_Categories`.`Risk_Scope__full`) AS `Risk Scope`,`cargo___pageData`.`_creator` AS `Creator`,`cargo___pageData`.`_creationDate` AS `Created`,`cargo___pageData`.`_modificationDate` AS `Modified`,`cargo___pageData`.`_creationDate__precision` AS `Created__precision`,`cargo___pageData`.`_modificationDate__precision` AS `Modified__precision` FROM `cargo__Risk_Categories` LEFT OUTER JOIN `cargo__Risk_Categories__Risk_Scope` ON ((`cargo__Risk_Categories`.`_ID`=`cargo__Risk_Categories__Risk_Scope`.`_rowID`) AND (cargo__Risk_Categories__Risk_Scope._value="FCA')) LEFT OUTER JOIN `cargo__Risk_Categories__Risk_Categories` ON ((`cargo__Risk_Categories`.`_ID`=`cargo__Risk_Categories__Risk_Categories`.`_rowID`) AND (cargo__Risk_Categories__Risk_Categories._value="Governance Failure")) LEFT OUTER JOIN `cargo__Page_properties` ON ((`cargo__Risk_Categories`._pageName=`cargo__Page_properties`._pageName)) LEFT OUTER JOIN `cargo___pageData` ON ((`cargo__Risk_Categories`._pageName=`cargo___pageData`._pageName)) WHERE ( `cargo__Risk_Categories__Risk_Categories`.`_value`="Governance Failure"

) AND ( `cargo__Risk_Categories__Risk_Scope`.`_value`="FCA's objectives"

) GROUP BY `cargo__Page_properties`.`_pageName` ORDER BY Modified DESC LIMIT 100  Function: CargoSQLQuery::run Error: 1064 You have an error in your SQL syntax; check the manual that corresponds to your MariaDB server version for the right syntax to use near 'Governance Failure")) LEFT OUTER JOIN `cargo__Page_properties` ON ((`cargo__Risk' at line 1

If I try the same query but with just one of the 'holds' clauses (ie without the AND and the second hold clause) it works fine. It is only when I combine the two hold clauses with the AND that I get the problem. I've tried various different levels of bracketing the two hold clauses with the same result. However, it worked fine before I upgraded to Cargo 2.0.1 from 1.7. I wonder if I've got my syntax wrong somehow?

Many thanks

Duncan, 28 November 2018


 * Yes, having multiple HOLDS checks in the same "where=" clause leads to problems - that's a known issue. Sorry about that. For now, I think the only solution is to a more explicit query, including the helper tables - much like the SQL statement that was printed out in the error statement, but correct. Yaron Koren (talk) 04:51, 30 November 2018 (UTC)

Something like Extension:Semantic Meta Tags
I'd like to expose metadata to Zotero within  tags (see here: "Embedded Metadata: The  tags in the header of many webpages will be parsed and used by Zotero. This fairly standard embedding of RDF metadata can use any RDF vocabularies; Zotero supports most major RDF vocabularies used for bibliographic metadata. For details on this approach, see the Dublin Core description. The translator will also interpret metadata expressed in the Google/Highwire key-value system.").

This would be for a wiki page containing details of an external item, e.g. journal article, so that Zotero can automatically extract the author, title, publication, date etc of the external item from that wiki page.

It looks like Extension:Semantic Meta Tags might do something similar for SMW, but how would I do this with Cargo? Thanks, Jonathan3 (talk) 14:17, 30 November 2018 (UTC)


 * That's interesting. The Add HTML Meta and Title extension might be usable here - you may be able to pass in #cargo_query calls into the &lt;seo&gt; tag. Yaron Koren (talk) 14:54, 30 November 2018 (UTC)


 * Cheers. I found Extension:WikiSEO which is an updated version of that, and edited it to allow some Dublin Core tags to be added, and to work with a Cargo  of multiple authors in the format Surname, Forename :-) Jonathan3 (talk) 01:10, 1 December 2018 (UTC)


 * Great! Yaron Koren (talk) 04:58, 3 December 2018 (UTC)


 * It works well with Cargo. It had a sentence about SMW and Semantic Forms, which I've updated (see diff). Jonathan3 (talk) 23:37, 3 December 2018 (UTC)

Gallery Query - Image size caption
Hi again,

I may be being a total idiot, again, but I cannot work out if there is a way to remove the image size from the gallery caption in the gallery query.

Thanks in advance! --185.92.25.2 00:59, 1 December 2018 (UTC)


 * You do it with "show dimensions=0" - sorry, that parameter was added a few months ago, in version 2.0, but it was never added to the documentation. I just added it now. Yaron Koren (talk) 01:02, 3 December 2018 (UTC)


 * Thanks Yaron, much appreciated! --185.92.25.220 06:23, 8 December 2018 (UTC)

Text is not placed in a table
Is it possible to increase the number of letters in the table? 1500 or 2000 characters -(Oleksiy) 212.80.62.177 20:10, 2 December 2018 (UTC)


 * Do you mean, how to not minimize the text when it is displayed in the "table" format? Yaron Koren (talk) 01:03, 3 December 2018 (UTC)


 * In these tables text of is not placed "Special:CargoTables". And one more problem. Duplicate rows. Null edit does not help.
 * Link: (neverwinter-ru.gamepedia.com/index.php?title=Фолиант_Вознесения&action=pagevalues) - RealShpak (talk) 06:47, 3 December 2018 (UTC)


 * What should I be looking at on that page? Yaron Koren (talk) 14:27, 3 December 2018 (UTC)


 * Duplicate values is not removed. MW 1.31.1 Cargo 2.0.1-hydra RealShpak (talk) 15:02, 3 December 2018 (UTC)


 * Oh, I see. "2.0.1-hydra" is not an official release, by the way - I assume that's some Gamepedia thing. Still, I don't know why this problem is happening. But what is the field or value that is not getting displayed in Special:CargoTables? Yaron Koren (talk) 18:53, 3 December 2018 (UTC)


 * See this screenshot. (imgur.com/a/0M7OwCS) Is there a limit of characters?  RealShpak (talk) 20:10, 3 December 2018 (UTC)


 * I don't know what I'm supposed to be looking at there... Do you know if the missing value, whatever it is, is getting stored correctly? Yaron Koren (talk) 20:27, 3 December 2018 (UTC)


 * I try to explain that text is not placed in a table. Limit (imgur.com/a/xq8gF4B) RealShpak (talk) 06:26, 4 December 2018 (UTC)

In relation to the "number of letters in the table" query, I think you might be referring to this change in version 1.6: added automatic minimizing of large texts in "View table" (though it may be a separate issue). Yaron, if you look at the CargoTables/Skills page, for instance, the description field for Астральный щит contains less text than the equivalent text on the page. I guess it might be cut short when the plain text ends and the first HTML tag (div, span or whatever) begins. Jonathan3 (talk) 10:02, 4 December 2018 (UTC)


 * RealShpak - is that the issue? Yaron Koren (talk) 15:49, 4 December 2018 (UTC)


 * Oops. I found a solution "Wikitext (size=5000)". Sorry, sorry. -RealShpak (talk) 17:39, 4 December 2018 (UTC)


 * Okay, great. No need to apologize - though your descriptions of the problem could have been a little longer! But I wonder if the "Wikitext" type should be stored as a limitless Blob, like the "Text" type is - or if maybe there should be two different types, like "Wikitext string" and "Wikitext text". Yaron Koren (talk) 21:19, 4 December 2018 (UTC)


 * It would be easiest if you would just get rid of the Text/String distinction. Is the effect for the user only that the default PF input type is different? What is the benefit from a database storage point of view? Jonathan3 (talk) 13:28, 5 December 2018 (UTC)


 * There are differences in forms, drilldown and storage. There are some advantages to using VARCHAR for smaller strings, instead of TEXT/BLOB - I think the biggest one is that you can index VARCHARs. Yaron Koren (talk) 14:41, 5 December 2018 (UTC)

What can and can't go in a Cargo field?
I'd like to use a Cargo field, instead of "Free text", on some pages. This is just for formatting reasons (though there may be other ways to achieve the same end). Is there anything that can't appear in a Cargo text field? I've tried DynamicPageList3 and Cargo queries, and both seem to work fine. Thanks. Jonathan3 (talk) 10:48, 4 December 2018 (UTC)


 * I think it can hold anything... the bigger issue with having a template field in place of true "free text" is form handling - you have to be more careful with brackets and pipes, so it won't get messed up in the form, though I can't remember now what the exact issues are. Yaron Koren (talk) 14:57, 4 December 2018 (UTC)


 * Ok, I'll look through old talk pages for PF, as I'm sure I remember something about that. Thanks. Jonathan3 (talk) 13:25, 5 December 2018 (UTC)

Non-standard query. Available?
Is it possible to implement such a query using Cargo? (select records where ID exists for one date, but is missing for another). --StasR (talk) 08:16, 10 December 2018 (UTC)


 * Well, you can't do a "SELECT *" - you have to enumerate the fields. And you can't do a "SELECT AS". But you could do a simple join... maybe that would get more or less the same results? Yaron Koren (talk) 15:54, 10 December 2018 (UTC)


 * “SELECT *” − I just did not correct it. The problem is with this complex JOIN. Is it possible to somehow drag it through the syntax restrictions of #cargo_query? --StasR (talk) 16:57, 10 December 2018 (UTC)


 * I don't think so. Yaron Koren (talk) 16:56, 12 December 2018 (UTC)


 * Thanks. --StasR (talk) 19:13, 12 December 2018 (UTC)

Error message when table can't be created due to problematic field name
Currently if you have a field name with a  in it, clicking Create data table brings you to an empty page with no indication of what's broken. I'm not sure if this is the case for other potentially invalid field names. Could this behavior be changed to provide some error message? Thanks --RheingoldRiver (talk) 01:17, 11 December 2018 (UTC)


 * Hm, seems like I might have misinterpreted what's happening. Actually it seems like the Create button simply doesn't show up at all on the page until the template is edited (not just blank edited). I'm not sure exactly what's going on here, but I'll try and do some troubleshooting when I can and make a more complete report of the issue. But there's definitely an issue where sometimes the Create button doesn't show up at all when it should. --RheingoldRiver (talk) 08:42, 12 December 2018 (UTC)

Database error when page name contains both single and double quotation marks
I have some pages with both “ and ‘ characters in their titles, so whether I use ‘ or “ to enclose the string following  I get a database error. Any way of escaping the characters, e.g.  or  means the string changes and the page name isn’t recognised in the query. (The query and page titles use plain quotation marks - the iPad seems to be changing them to fancy ones in this message.) Is there a way round this? Thanks. Jonathan3 (talk) 04:06, 13 December 2018 (UTC)


 * What about using #replace to replace  with , or   with  ? Yaron Koren (talk) 15:05, 13 December 2018 (UTC)


 * I’ll try that tonight. I’d tried to escape using \ on a string (not via a template) and it didn’t work, though. 5.198.41.149 15:36, 13 December 2018 (UTC)


 * Neither of those suggestions work. It avoids the Cargo error but as the  clause is using the changed page title (with \ characters) it doesn't recognise pages which do exist. If there were some other delimiter used within Cargo (e.g. @@ which I use for #arraymap), maybe that would be good. For instance,  . Jonathan3 (talk) 23:40, 13 December 2018 (UTC)


 * As a workaround you could try using LIKE/RLIKE and putting a wildcard there --RheingoldRiver (talk) 09:52, 15 December 2018 (UTC)


 * Thank you very much. That worked fine. I check for a " using  then either do   or the usual  . I guess that is more efficient than doing using LIKE every time. Jonathan3 (talk) 01:06, 21 December 2018 (UTC)

Feature request - order List fields by the order the data inserted to cargo_store. (Branch already uploaded to gerrit for review)
The problem: using semantic forms with multi value fields, combined with cargo, the user expected the data to viewed on the same order they inserted it. But cargo ordering multi values by value only.

We (openfox) solved it like this:


 * At cargo_declare we added to each sub-table column named _weight.
 * At cargo_store we populated it by the order of the data.
 * At cargo_query we added order by to this tables.
 * Additionally, we added new config, $wgCargoOrderListByWeight, to toggle between weight and value ordering.

TODO: add back compatibility - add all already created sub-tables, column named _weight. if not, cargo_store and cargo_query results sql errors.

--Anysite (talk) 10:54, 17 December 2018 (UTC)


 * I looked at the patch, and this explanation, but I'm still not sure I understand: is the idea that, if some field of type "List of String" or "List of Page" holds a value like "C, B, A", the values will instead get displayed in the order "A, B, C" when the data is queried? If so, have you tried just sorting on _rowID? Yaron Koren (talk) 16:22, 17 December 2018 (UTC)


 * As far as I can understand, _rowID is reference to origin table row id, so multiple rows have the same value. I can't sort by this field between rows in this table. Here image for example ( that's query from sub-table). Anysite (talk) 18:32, 19 December 2018 (UTC)Example.table.cargo.2018.png


 * Okay - yes, that's right. Sorry, I think I was right, but for the wrong reasons. :) I don't know what exactly what your query looks like, but my guess is that the only queried field is _value. By default, if no "order by" parameter is specified, sorting is done on the first queried field - which would be _value. So if you just add "order by=_rowID" to the query, it will no longer sort on _value, and you should have the correct, natural sorting. Yaron Koren (talk) 19:37, 19 December 2018 (UTC)


 * Sort order in MySQL without "ORDER BY" is not guarenteed, AFAIK (see for example ). Therefore the order might be random in such cases - which indeed is the case on my own wikis.


 * Yes - that's why I said adding "order by=_rowID" could help. Yaron Koren (talk) 17:38, 15 January 2019 (UTC)
 * After checking in several environments I can agree to the above comment - It's unreliable solution, even with "order by=_rowID". Anysite (talk) 11:36, 16 January 2019 (UTC)
 * I don't understand - does "order by=_rowID" not work? Yaron Koren (talk) 14:21, 16 January 2019 (UTC)
 * You are correct that no sorting will take place, but mySQL (and SQL in general) is not guarenteed to return rows in the same order they were entered into the DB (see or ). Our testing so far showed us that the order is indeed not consistent. FFS Talk 00:29, 17 January 2019 (UTC)


 * Sorry, I think I got confused again and thought that "_rowID" was the actual ID of the value. It's good to know that the lack of an ordering field does indeed cause problems, not just theoretically. I do want to add a new field to hold this order/index/etc. (the field called "_weight" in the current patch - I don't know how that name was picked). What I'm trying to figure out now is how best to add handling for it without causing problems for list tables that don't have this field, i.e. that were last recreated before the field was added to the code. Yaron Koren (talk) 16:48, 18 January 2019 (UTC)

Specifying December 31, 2018 stores the date as December 31, 2019.
We're experiencing an issue on the Dragalia Lost Gamepedia Wiki with Datetime (maybe Date as well) where when storing December 31, 2018, the year is stored as December 31, 2019.

Here is a snippet of the source from the Dragonyule Defenders page we're storing from (EndDate is the parameter in question):

The  template itself doesn't do any additional parsing on the EndDate parameter, just a straight store. ... ...
 * EndDate=

However, the stored values are as follows (from Page values, bolded EndDate):

From tests, these are other things we observed trying to fix this:


 * December 28, 29, and 30 are affected as well.
 * Storing in  format still resulted in 2019 being stored.
 * This seems to affect every year. The values tested were:
 * 2000 -> Stored as 2001
 * 2017 -> Stored as 2018
 * Removing / changing the time did not have any effect. Year was still stored as 2019.

Thanks in advance for any help or insight you might have on this issue. Elaeagnifolia (talk) 20:27, 17 December 2018 (UTC)


 * Is it something to do with this? Sam Wilson 02:07, 18 December 2018 (UTC)
 * Yep, it looks to be related to Yaron's use of the 'o' date format (based on the ISO week date). He should be using 'Y' instead because 'o' varies depending on the week number. --pcj (talk) 17:30, 18 December 2018 (UTC)


 * Ah - I never really understand what the difference between 'Y' and 'o' was, or why 'o' sometimes failed. Nor did I consider that my clever hack for getting the year to work right for dates at the beginning of the year would mess things up for dates at the end of the year. :( Sorry about that, and thanks to all of you for your diagnosis of the problem. I just checked in a fix so that it uses 'Y', and just removes leading zeros in the year on its own, which is what the code should have done from the very beginning. Yaron Koren (talk) 15:33, 19 December 2018 (UTC)

cargo_store in Scribunto
Hi, will there be support for cargo_store (similar to cargo.query) at some point? Would prefer if I don't have to use "frame:callParserFunction". --BryghtShadow (talk) 06:35, 25 December 2018 (UTC)


 * I hope so! I didn't create the code to handle #cargo_query in Lua, and I'm not sure I could create code for #cargo_store either, but hopefully someone can. Yaron Koren (talk) 23:36, 25 December 2018 (UTC)


 * I see. Thank you --BryghtShadow (talk) 05:37, 26 December 2018 (UTC)


 * There's a ticket for this: T187825. Sam Wilson 16:16, 29 December 2018 (UTC)

Add time to _creationDate and _modificationDate
After enabling the _pageData table, I only see the date stored for _creationDate and _modificationDate but not time. Is there a parameter to turn on storage of time as well? Or could this feature be added?

Longphile (talk)


 * No, there's no parameter. Is it useful to have the time for both of these fields? Yaron Koren (talk) 22:54, 28 December 2018 (UTC)


 * I think it is useful for folks using Cargo for content management. We often query for creation and modification date down to the time and were able to get time stamps for CDAT and MDAT via $smwgPageSpecialProperties when using SMW.  Would be nice to have this also for Cargo which we are implementing for a new media content management system. Longphile (talk) 18:07, 7 January 2019 (UTC)


 * You make a good point - I just checked in a change so that these two fields, plus the "upload date" field in the _fileData table, are now all of type Datetime. Yaron Koren (talk) 20:37, 23 January 2019 (UTC)


 * Great, I think this will be useful for me too, thanks. Jonathan3 (talk) 21:19, 23 January 2019 (UTC)

User group right for viewing Special:Drilldown
Would it be possible to add a user right for viewing Special:Drilldown? We had some slowness on Leaguepedia that was caused from some IPs repeatedly pinging expensive queries and would like to restrict access to logged-in users. --RheingoldRiver (talk) 07:46, 8 January 2019 (UTC)


 * That sounds like a reasonable idea (though it's sad to hear that Special:Drilldown can cause performance issues). What do you think about a single permission that would encompass both that page and Special:ViewData? Yaron Koren (talk) 17:43, 9 January 2019 (UTC)


 * TBH I was unaware of Special:ViewData until now, I always make sandbox pages when I want to run temporary queries, hah - I'll probably start using it now. That sounds like a good idea to combine, then. --RheingoldRiver (talk) 11:05, 10 January 2019 (UTC)


 * Okay, that sounds good. I'm glad you learned about Special:ViewData! I admit its interface is quite primitive, but hopefully it's enough for your purposes. There's actually a planned project to make it more useful and user-friendly. Yaron Koren (talk) 03:54, 11 January 2019 (UTC)


 * I just checked in a new permission, 'runcargoqueries', that governs access to those two special pages. By default it's true for everyone. Hopefully it'll work out for you. Yaron Koren (talk) 22:48, 15 January 2019 (UTC)

Use HOLDS with multiple values
I'd like to do something like this:

Is this possible, and if so what's the syntax? Thanks. Jonathan3 (talk) 12:56, 13 January 2019 (UTC)


 * That's possible in theory - I guess it's not actually possible at the moment due to a bug in query parsing. The only way to do it right now, I think, is to actually query on the underlying tables, instead of using the "HOLDS" syntax - see here for somewhat of a hint on how to do that. Yaron Koren (talk) 17:11, 13 January 2019 (UTC)


 * "So you're telling me there's a chance!" :-) I'll give it a go and put the answer here if I find it. Jonathan3 (talk) 17:17, 13 January 2019 (UTC)

Custom tab for Special:Drilldown
Would it be possible to allow a custom tab on Special:Drilldown? I'd like to be able to include a template (which would provide a summary of each page in the Drilldown results).

I proposed a patch to allow something like this ages ago, before you had tabs, but didn't persuade you to include it. You did agree to add a hook but I never followed this up.

A separate custom tab per table would be good. It could maybe be set in the table definition (the relevant template could be named there). Alternatively, Drilldown could check for a custom template (which would have to follow some naming convention).

Also it would be good if the custom tab could optionally be set as the main tab.

What do you think? Jonathan3 (talk) 13:13, 13 January 2019 (UTC)


 * You can already do that, if I understand the question correctly, with "_drilldownTabs" - see here. Yaron Koren (talk) 14:54, 13 January 2019 (UTC)


 * Yes, that's perfect! Thanks for your quick reply. Jonathan3 (talk) 16:34, 13 January 2019 (UTC)

MW categories and Cargo hierarchy
I'm currently migrating my plain pages to Cargo template pages. I've been using categories and would like to continue to use these (at least for the time being) so have a Cargo field  which uses   to allocate the pages to categories. Would I be able to have this field as a hierarchy to mirror the current category structure (so that it autocompletes on the relevant existing main category and and sub-categories, and perhaps also only allows existing category names as values)? Sorry if I've missed something obvious in the documentation again. Jonathan3 (talk) 17:14, 13 January 2019 (UTC)


 * That sounds like a Page Forms, rather than Cargo, question. Check out the tree input type with "top category" - it may be helpful here. Yaron Koren (talk) 23:50, 13 January 2019 (UTC)


 * That form setting worked perfectly, thank you. I can't understand the Cargo "hierarchy" fully, though:
 * It looks like the allowed values have to be set using bullet points in the table definition. Is there any way of linking this (automatically) with the category names and structure?
 * What is the benefit of having a hierarchy? I guess it has an effect on Drilldown, so that if you click a heading name it is as if you clicked on all its sub-headings too. Is that right?
 * Thanks Jonathan3 (talk) 01:05, 14 January 2019 (UTC)


 * Hierarchies can be defined within a Cargo declaration, within a form input, or by using an existing hierarchy from the category structure. I don't know what it would mean to link a Cargo field to a category structure, given that the set of categories can change at any time. Cargo-defined hierarchies get special handling within forms, drilldown, and regular queries (via the "WITHIN" keyword). Yaron Koren (talk) 02:02, 14 January 2019 (UTC)


 * Thanks. Do you know any way to convert a category structure into bullet-point format? If I were to put that into a template, would I be able to use that template within #cargo_declare to define the allowed values, and recreate the table when the category structure changes? Is there anyway to change the allowed values of the field without having to recreate the entire table, rows and all? Jonathan3 (talk) 14:27, 23 January 2019 (UTC)


 * Why do that - why not just use the existing category structure, using "top category="? Yaron Koren (talk) 18:32, 23 January 2019 (UTC)


 * Is it possible to define a field as a hierarchy in Cargo without listing the allowed values? I thought “top category” was a PF parameter for the tree input type, which wouldn’t lead to the benefits of having a hierarchy in Cargo (queries, Drilldown). I was considering using both (ie top category in PF and somehow defining the Cargo hierarchy allowed values to be the same hierarchy as the categories. Jonathan3 (talk) 19:11, 23 January 2019 (UTC)


 * That's true - it would be a Page Forms-only solution, and it wouldn't let you do the hierarchy handling in queries and drilldown. But having it defined in two places sounds like a hack. Let me ask you this: what about removing those categories altogether, and only using a Cargo hierarchy field? Yaron Koren (talk) 20:41, 23 January 2019 (UTC)


 * I've got about 2000 pages to move across to Cargo. These will probably take 5-10 mins each, as I'm adding data as well as just copying across old data, so can't just automate it... until that's all done I need to maintain the categories :-) After that then, yes, I could probably do without categories, I think. The category pages are like dead-end Drilldown pages, especially now that I am able to add a tab to Drilldown the same as I had for the category pages.


 * Is it possible to use a template to set the allowed values of a Cargo hierarchy field? If so then I can look into how to turn the category structure into the bullet-point format required. Jonathan3 (talk) 21:25, 23 January 2019 (UTC)

I see. What about just hardcoding it in #cargo_declare? If the category setup is just a legacy system, then presumably it won't change much more? Yaron Koren (talk) 21:49, 23 January 2019 (UTC)


 * That would be possible (not much more work as - you're right - there won't be many changes, and any will involve other work anyway). Am I right to infer from your answer that it's not possible to use ? Jonathan3 (talk) 22:13, 23 January 2019 (UTC)

Make selected filter field collapsible rather than collapsed on Drilldown page
At the minute it says "(Click arrow to add another value)". It would be more intuitive it the whole thing were visible on page load, maybe with a message like "(Click on another value to add it)".

This is particularly the case if the Drilldown page (with filter selected) has been reached via a direct link rather than clicking on a value.

Is there any way of changing this? Thanks. Jonathan3 (talk) 17:41, 13 January 2019 (UTC)


 * Not at the moment, I don't think. Yaron Koren (talk) 23:51, 13 January 2019 (UTC)


 * This worked for me, in MediaWiki:Common.js, without needing to change the Cargo code (I went further and hid the the arrows and message entirely):


 * Jonathan3 (talk) 03:49, 27 January 2019 (UTC)

Drilldown tab headers
On the iPhone when the Drilldown page is loaded in portrait mode (if that's the word) the headings appear as an unordered list, then disappear instead of becoming tabs.

When the page is loaded in landscape mode, they appear as normal, then disappear when you rotate the screen to portrait, and don't reappear when you return to landscape.

It would probably be better to keep them even in narrow screens, either as tabs or (if that's not possible) as an unordered list. Would that be possible? I guess there's some CSS that could be changed somewhere. Jonathan3 (talk) 18:53, 13 January 2019 (UTC)

Hierarchy/grouping of fields
Do you have any plans to implement something like the following? Using your Books table as an example, a group of fields could be called something like "Contributor", and within that there could be fields like "Author", "Editor", "Illustrator". On the Drilldown page the entries for these fields could (optionally) be merged, so that if you click on "John Smith" you get to see all the books he has contributed to (written, edited, illustrated or whatever). Thanks, Jonathan3 (talk) 14:33, 14 January 2019 (UTC)


 * No. I can think of two ways to do something like that, if that's what you want: one is to create a query form in Page Forms, to run that exact query on any person the user selects; the other is to define contributors using a multiple-instance template, so instead of having different fields for "Author", etc., you would have a "Contributor" template that lets you input each person and what they did. Then you could drill down based on that, using "parent tables". Yaron Koren (talk) 17:31, 14 January 2019 (UTC)

Storing categories in page data table
I have a feeling that this isn't working right. I have a Cargo infobox template A that assigns the page to a category. Another template B uses a Cargo query to work out which category the page is in (as a different further Cargo query is required depending on that answer) - this template B never gets it right for a new page (doesn't realise it's in the assigned category) until I run setCargoPageData.php, after which it works fine. Am I doing something wrong? Jonathan3 (talk) 14:41, 20 January 2019 (UTC)
 * P.S. I have switched template B (which checks the category of the page) to use DPL3 rather than Cargo, and it works fine now [i.e. it's a problem with my use of Cargo]... Jonathan3 (talk) 15:37, 20 January 2019 (UTC)

Join several tables and order by _creationDate
Would it be possible to devise a Cargo query to join four tables, all of which have a "Summary" field but which are otherwise different, and display them in order of page _creationDate (most recent first)? I guess I'd need to use SQL on the actual database tables for this. Jonathan3 (talk) 14:48, 22 January 2019 (UTC)


 * For that, you'd probably need to be able to use the operator, which I don't think is possible with Cargo. Another way would be to modify each of the four table's templates so that they also add data to a fifth table, one that contains only 'date_created' and 'summary', and then query that one. Sam Wilson 14:57, 22 January 2019 (UTC)


 * Thanks. The separate table sounds ideal. It's for automatically creating updates to the website, so it would be good to have a separate updates table for a historical record, and also to be able to add to it manually if required. Jonathan3 (talk) 14:23, 23 January 2019 (UTC)


 * Looking into this now - what is the best way to do this? Do I define the new ("Updates") template, then put a #cargo_attach into the existing templates? If the existing and new tables share field names, will #cargo_attach send these automatically to the new table? Thanks. Jonathan3 (talk) 00:15, 25 January 2019 (UTC)


 * I don't think you even need to attach it, just call cargo_store twice in one template (one for each table) and pass the same parameters to both. e.g. 'Template:Photo' might have 'date' and 'description' fields, and 'Template:News' 'date_and_time' and 'summary', so in 'Template:Photo' you call both  with the end result being that every photo would have an entry in the 'news_items' table, along with all the other non-photo news items. If that makes any sense. :) Sam Wilson 01:18, 25 January 2019 (UTC)


 * That does make sense, thank you. What does this part of the documentation mean? “You do not actually need this call [#cargo_attach] in order for a template to add rows to some table; a #cargo_store call placed anywhere, via a template or otherwise, will add a row to a table (assuming the call is valid). However, #cargo_attach lets you do the "Recreate data" action for that template - see "Creating or recreating data", below.” Does it have an impact on templates that call #cargo_store twice, on separate tables? Jonathan3 (talk) 10:19, 25 January 2019 (UTC)


 * I've tried this out. When I added a new "News" template/form/table, and added #cargo_store to an existing template: (1) the #cargo_store worked fine when a page is saved, but (2) recreation of new and/or old tables did not re-add the row to the News table. Jonathan3 (talk) 14:03, 25 January 2019 (UTC)


 * Adding #cargo_attach to the existing template gives: "Error: #cargo_attach must be called from a template page." Any more ideas? Thanks. Jonathan3 (talk) 14:13, 25 January 2019 (UTC)


 * I haven't really followed the full discussion here, but - did you put #cargo_attach in the &lt;noinclude&gt; section of the template? Yaron Koren (talk) 14:27, 25 January 2019 (UTC)


 * You're right. Now that it's in the right place the error doesn't appear... But now that the old template is attached to the News table, how can I get the old template to save anything to the News table? I've tried having field names which are the same in both tables but it doesn't do anything... I must be missing something simple... Jonathan3 (talk) 14:51, 25 January 2019 (UTC)


 * I wonder if it would be possible for cargoRecreateData.php to change  somehow also to include templates that store to the table? Jonathan3 (talk) 14:36, 25 January 2019 (UTC)


 * The answer seems to be that: (1) a second #cargo_store does the work of storing data from template A to table B, and (2) #cargo_attach is what lets cargoRecreateData.php know to check Template A when recreating data for Table B. It works fine now with both #cargo_store and #cargo_attach included in template A :-) Thanks to both of you for your help! Jonathan3 (talk) 15:02, 25 January 2019 (UTC)

Case Sensitivity in stores
I think there's an issue where if two rows on the same page are exactly identical up to case sensitivity, only one of the rows is stored. This came up for me on this page - https://lol.gamepedia.com/index.php?title=PiPiXuan&action=pagevalues#.26quot.3BPlayerRedirects.26quot.3B_values - there should be one line for each of the pages that redirects (visible here - https://lol.gamepedia.com/PiPiXuan#Redirects). However since there are two sets of lines that are identical up to casing, for those sets only one is stored. A workaround would of course just be to add another column that's a unique identifier of the line (which I'll probably do now that I've identified the problem) but maybe this is unintended behavior. --RheingoldRiver (talk) 09:44, 23 January 2019 (UTC)


 * I see - you're trying to store both "XuanXuanPI" and "XuanXuanPi". That's a bug, although it's not clear to me how big an issue this is. Why do you need a separate table for redirects? Why not just use the existing "IDList" field value, which seems to have that same information? Yaron Koren (talk) 18:31, 23 January 2019 (UTC)


 * Often players change names, and sometimes even mid-event, and redirects reflect all of the name changes. So I'll do a series of 3 joins across 4 tables to group players together - the data table (e.g. Team Rosters from a tournament), two copies of PlayerRedirects, and InfoboxPlayer, to get data about a player. So I join on the AllName field of PR and then _pageName, and in the where I add BINARY conditions to avoid getting extra results when case insensitivity is a problem. Example module - https://lol.gamepedia.com/Module:TournamentPlayerInformation, and example use of the module - https://lol.gamepedia.com/Special:RunQuery/TournamentPlayerInformation?TPI%5Bpage%5D=LVP%20SuperLiga%20Orange/2018%20Season/Summer%20Season&pfRunQueryFormName=TournamentPlayerInformation (the redlinked coach "Gil" as no page so that's caught with an OR IS NULL in the where). It's definitely possible there's some better way to do all of this, but if so I'm not sure how.


 * Also, HOLDS still seems kinda buggy sometimes (though it's been a while since I used it) so some wikis at Gamepedia (at least me & the Path of Exile admins) try to avoid it overusing fields of list type, unless they're for display only and never querying on. --RheingoldRiver (talk) 22:43, 23 January 2019 (UTC)


 * That said this definitely isn't a huge issue since adding a UniqueLine field (or even an N field) is a very easy workaround for this --RheingoldRiver (talk) 23:20, 23 January 2019 (UTC)
 * Alright. I think the case-sensitivity thing depends on the MySQL configuration, since I believe the check is done in SQL itself. But I do hope you try out HOLDS again - maybe it works better now than last time you tried it. Yaron Koren (talk) 16:15, 24 January 2019 (UTC)

Problem recreating tables
I am trying to recreate a table from a template. When the new table is generated and I choose to replace the old table, I get an error saying the old table doesn't exist. If I try and look at the existing table I get the same message. Also, the table doesn't show up on the special page that lists Cargo tables. However, if I go to the template page it thinks the table does exist (e.g. it only offers me the option to recreate data, not to create data). If I look in the database itself, the table does exist with the prefix 'cargo_' as I'd expect. I've tried the maintenance script to recreate all of the cargo tables but it ignores this one. I tried using the same script to recreate just this table which went through without error (after I removed the '_NEXT' table left from trying to recreate the table) but I'm still getting the same problems.

It seems like I'm in a catch 22 here, any suggestions how I can get around this issue? All my other tables seem just fine?

Many thanks, Duncan (24 Jan 2018)


 * Sorry about that. It sounds like the table exists but doesn't have an entry in the "cargo_tables" DB table. The code needs to be better about handling both cases - the table exists but doesn't have an entry, or the table has an entry but doesn't exist. I would try manually deleting that table from the database - hopefully that will fix the problem. Yaron Koren (talk) 16:19, 24 January 2019 (UTC)


 * Hi Yaron, thanks that did indeed solve the problem. Duncan, 26 Jan 2019

Using Template Format in Cargo Query gives an error when a field has data type WikiText
I have a query that formats data in a cargo query using a template, as follows:

The 'Content' field has a datatype of WikiText. For the example below, the 'Content' field contains the following:

  Template:Display All Groups - added 'delete' to table rows. Can this be combined with Display Groups template?  Template:News - correction to in template documentation  Template:Group - changed tab back to news from journal and added journal tab  Form:Sub News - reverted from Journal and made selective on News Groups  Form:Sub Event - made selective on Calendar Groups  Form:Sub Assignment - made selective on News Groups  Form:Sub Article - made selective on Interest Groups  Form:Sub Journal - new form for inputting journal items</li>  Template:Journal - new template or processing journal items</li>  Template:Display Journal - new template for displaying journal information</li>  Template:Holds Journal Groups - new template for use in Display Journal template</li>  Form:Article - included Journal option on 'additional processing' tab</li>  Template:Display Journal Article - Template to format journal for Display Journal template</li> </ol>

The resulting output shows as follows, where the template doesn't seem to be recognised and so has failed to be parsed correctly.

It looks a bit like the problem is because the Content field was being truncated, so I increased 'max display characters' to a very large number but that didn't change the output. I do find, however, if I remove the 'Content' field the query works as expected. I have also tried formatting the 'Content' field as Text but then the wikitext is displayed un-parsed.

I wonder if there's something else I could try?

Many thanks, Duncan 26 Jan 2019


 * Do you think this might be a similar problem to the one in above? The solution there was to increase the size of the Wikitext field by using  . Jonathan3 (talk) 03:19, 27 January 2019 (UTC)

Order by "DESC" not working
After updating Cargo (I think that's the cause) existing queries containing  gives the error. When I remove "DESC" it works fine, though obviously isn't in the order I want... Is this something to do with now saving the time (as well as date) in _creationDate, or something I'm doing wrong? Thanks. Jonathan3 (talk) 17:45, 26 January 2019 (UTC)


 * Looks like the problem is in CargoSQLQuery.php:


 * The problem seems to be that in the first case above it adds backticks to the whole thing, e.g. . I can work round it by using   so that the   avoids the problem. Jonathan3 (talk) 20:59, 26 January 2019 (UTC)


 * Sorry about that - it was due to a fix from a week ago. I just checked in a fix for this fix... hopefully everything works now. Yaron Koren (talk) 03:36, 28 January 2019 (UTC)

Display field as plain text or wikitext
I'd like to use #cargo_query (in one place) to be able to display a field to display as plain text (e.g. links, italics ) and (in another place) to be able to display it rendered as wikitext (e.g. links, italics). What's the best way to do this? Thanks. Jonathan3 (talk) 23:42, 26 January 2019 (UTC)

What seems to work is to save the field as Text (previously I'd been using Wikitext). Then in a normal query (no format specified) it comes out as plain text, but in with  it comes out formatted as wikitext. Jonathan3 (talk) 23:53, 26 January 2019 (UTC)


 * Yes, what Cargo needs is a way to declare the type of any field in a query. Right now the code just tries to figure out the type, which usually works but doesn't always, clearly. I actually added in a fix for this particular case about two months ago - it's not publicized yet, because there hasn't been a new release since then. But if you're using the latest code, you can wrap a TRIM function around the field name - Cargo now treats TRIM as being of type String, as opposed to Wikitext. So I would change the type back to Wikitext, then try that TRIM hack. Yaron Koren (talk) 03:42, 28 January 2019 (UTC)