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)

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)

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)

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)