Extension talk:Cargo/Archive October to December 2018

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

{{#cargo_declare:_table=dates|dates=List (,) of Datetime}}
</noinclude><includeonly>{{#cargo_store:_table=dates|dates={{{dates|}}} }}{| class="wikitable"
! dates
| {{#arraymap:{{{dates|}}}|,|x|[[x]]}}

|}
 

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 {{#formredlinks}} instead of [[]] to build the links, unfortunately it doesn't work with {{#display_map}} 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...

...
 status=String (allowed values=Prospective,Live,Retired)
...

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

<span class="inputSpan mandatoryFieldSpan">
<select id="input_2" tabindex="2" name="Document[status]" class="mandatoryField">
<option value=""></option>
<option value="Prospective">Prospective</option>
<option value="Live">Live</option>
<option value="Retired">Retired</option>
</select></span>

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

<span class="inputSpan mandatoryFieldSpan">
<select id="input_2" tabindex="2" name="Document[status]" class="mandatoryField">
<option value=""></option>
<option value="Prospective">label 1</option>
<option value="Live">label 2</option>
<option value="Retired">label 3</option>
</select></span>

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

... 
   status=String (allowed values=Prospective,Live,Retired) (allowed labels= label 1,label 2,label 3)
...

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

<span class="inputSpan mandatoryFieldSpan">
 <select id="input_2" tabindex="2" name="Document[status]" class="mandatoryField">
 <option value="Label for Prospective">Label for Prospective</option>
 <option value="Label for live">Label for live</option>
 <option value="Label for Retired">Label for Retired</option></select>
</span>

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

<span class="inputSpan mandatoryFieldSpan">
 <select id="input_2" tabindex="2" name="Document[status]" class="mandatoryField">
 <option value="Prospective">Label for Prospective</option>
 <option value="Live">Label for live</option>
 <option value="Retired">Label for Retired</option></select>
</span>

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

{{{field|status|mandatory|mapping cargo field=status|values=Label for Prospective ,Label for live,Label for Retired}}}

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 {{{1|}}}. 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

<span class="inputSpan mandatoryFieldSpan">
 <select id="input_2" tabindex="2" name="Document[status]" class="mandatoryField">
 <option value="Prospective">Label for Prospective</option>
 <option value="Live">Label for live</option>
 <option value="Retired">Label for Retired</option></select>
</span>

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 {{{1|}}}, and set "mapping template=" to the name of that template. Yaron Koren (talk) 02:30, 16 October 2018 (UTC)

{{{field|status|mandatory|mapping cargo table =document |cargo field=status|values=Prospective,Live,Retired|mapping template= ReplaceSatusValueWithLabel }}} produces this in the form....

<span class="inputSpan mandatoryFieldSpan"><select id="input_2" tabindex="2" name="Document[status]" class="mandatoryField">
<option value="Label for Live">Label for Live</option>
<option value="Label for Prospective">Label for Prospective</option>
<option value="Label for Retired">Label for Retired</option></select></span><input type="hidden" value="true" name="Document[map_field][status]"/>

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:

{ "error": { "code": "internal_api_error_MWException", "info": "[608513843999683b6491a08e] Exception caught: Error: Field alias \"_pageName\" starts with an underscore (_). This is not allowed in Cargo API queries.", "*": "MWException at /home/hydra/public_html/extensions/Cargo/api/CargoQueryAPI.php(36)\n#0 /home/hydra/public_html/includes/api/ApiMain.php(1567): CargoQueryAPI->execute()\n#1 /home/hydra/public_html/includes/api/ApiMain.php(545): ApiMain->executeAction()\n#2 /home/hydra/public_html/includes/api/ApiMain.php(516): ApiMain->executeActionWithErrorHandling()\n#3 /home/hydra/public_html/api.php(94): ApiMain->execute()\n#4 {main}" } }

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 SELECT * FROM TABLE 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:

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

{{#cargo_query:
tables=Books
|fields=_pageName=Book,Authors
|where=Authors HOLDS 'Foo'
}}

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#In-page list of backlinks). Thanks. Jonathan3 (talk) 20:32, 3 November 2018 (UTC)

P.S. It turns out that this is simple in DPL3 - {{#dpl:linksto = Page name...}} - 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 {{Page B}}, labelled section transclusion {{#lsth:Page B}} or DPL3 {{#dpl:title=Page B...}}.

Would there be a way of using Cargo to transclude the page content up to but not including the first [[Category:...]]? 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). Jonathan3 (talk) 21:09, 4 November 2018 (UTC)

The following sort of works...:

{{#cargo_query:
tables=_pageData
|fields = SUBSTRING_INDEX(_fullText,"\[\[Category:",1)
|where = _pageTitle = "page title here"
|no html
}}

if you're just transcluding a paragraph with italics, bold etc, but anything with a section header is messed up - e.g. it says External links<mw:editsection page="Test page" section="1">External links</mw:editsection> 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...

{{#cargo_query:
tables=_pageData
|fields = _fullText
|where = _pageTitle = "page name"
}}

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

<ref>Example</ref>

Error when using join on HOLDS

When I'm trying to do query of cargo points to other cargo, like this

{{#cargo_query: tables=TABLE_B,TABLE_A |join on=TABLE_A.LIST_OF_TABLE_B HOLDS TABLE_B._pageName |where=TABLE_A._pageName="PAGE_NAME" |fields=TABLE_B.FIELD_a,TABLE_B.FIELD_b, etc |format=table |default= }}

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 |format=tag cloud. 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 group_by to group by 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:

{{#cargo_declare:_table=MYTABLENAME|excerpt=Text|excerpt_text=Searchtext|excerpt_text-string=String}}

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        = {{#if:{{{also_known|}}}|{{{also_known}}}|
{{#if:{{{real_name1|}}}|{{{real_name1}}}
}}}}
    
|   label3        = Birth Name
|    data3        = {{{birth_name|}}}
    
|   label4        = Birth Date
|    data4        = {{#if:{{{birth_day|}}}|{{Birth date and age|df=yes|{{{birth_year|}}}|{{{birth_month|}}}|{{{birth_day|}}}}}|
{{#if:{{{birth_month|}}}|{{Birth year and age|{{{birth_year|}}}|{{{birth_month|}}}}}|
{{#if:{{{birth_year|}}}|{{Birth year and age|{{{birth_year|}}}}}|
{{#if:{{{birth1|}}}|{{Birth date and age|{{{birth1}}}|df=yes}}
}}}}}}}}
    
|   label5        = Age
|    data5        = {{#if:{{{birth_day|}}}{{{birth_year|}}}{{{birth_month|}}}{{{birth1|}}}||
{{#if:{{{1age|}}}|{{{1age|}}}|
{{#if:{{{3age|}}}|{{{3age|}}}|
{{#if:{{{2age|}}}|{{{2age|}}}
}}}}}}}}

|   label6        = Languages
|    data6        = {{#if:{{{languages|}}}|{{{languages|}}}|
{{#if:{{{languages2|}}}|{{{languages2|}}}|
{{#if:{{{languages1|}}}|{{{languages1|}}}|
}}}}}}


    
|   label7        = Birth Place
|    data7        = {{{birth_place|}}}
    
|   label8        = Ethnicity
|    data8        = {{#if:{{{ethnicity|}}}|{{Cl|{{{ethnicity}}}|{{{ethnicity}}}}}[[Category:{{{ethnicity}}}]]|
{{#if:{{{ethnicity2|}}}|{{Cl|{{{ethnicity2}}}|{{{ethnicity2}}}}}[[Category:{{{ethnicity2}}}]]|
{{#if:{{{ethnicity3|}}}|{{Cl|{{{ethnicity3}}}|{{{ethnicity3}}}}}[[Category:{{{ethnicity3}}}]]|
{{#if:{{{ethnicity4|}}}|{{Cl|{{{ethnicity4}}}|{{{ethnicity4}}}}}[[Category:{{{ethnicity4}}}]]
}}}}}}}}

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 .even and .odd 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):

#content table.cargoTable td.even,
#content table.cargoTable td.odd {
	background: transparent;
}

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

{{#cargo_query:
|tables=Risk_Categories,Page_properties,_pageData 
|join on=Risk_Categories._pageName=Page_properties._pageName,Risk_Categories._pageName=_pageData._pageName 
|fields=Risk_Categories._pageName=Title,Page_properties.Description,
CONCAT(Risk_Categories.Risk_Categories__full)=Risk Categories,CONCAT(Risk_Categories.Risk_Scope__full)=Risk Scope,_pageData._creator=Creator,_pageData._creationDate=Created,_pageData._modificationDate=Modified 
|where=( {{Holds Risk Categories|CategoryNames={{{Risk Categories|}}} }} ) AND ( {{Holds Risk Scope|CategoryNames={{{RiskScope|}}} }} ) 
|group by= Page_properties._pageName
|order by= Modified DESC
|format=dynamic table
}}

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 <meta> tags (see here: "Embedded Metadata: The <META> 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 <seo> 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 List (;) of String 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 table1.* FROM `cargo__units` as table1 
    LEFT JOIN `cargo__units` as table2 ON (table2.id=table1.id AND table2.date="2018-12-01") 
    WHERE table2.id IS NULL AND table1.date="2018-11-01"

(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 where=_pageName= I get a database error. Any way of escaping the characters, e.g. {{#replace:pagetitle|’|’’}} or QUOTE()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. Jonathan3 (talk) 15:36, 13 December 2018 (UTC)

Neither of those suggestions work. It avoids the Cargo error but as the where 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, |where=_PageName=@@Page name with 'single' and "double" quotation marks@@. 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 {{#if: {{#pos:{{{1}}}|"}} | ... | ...}} then either do |where=_pageName LIKE "{{#replace: {{{1}}} | " | _ }}" or the usual |where=_pageName="{{{1}}}". 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)

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 [1]). 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 [2] or [3]). 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)

I released Cargo version 2.1 today - it now includes a new field in list tables, _position, which can be used to order on. And the code doesn't crash if _position is not there, thankfully. Thanks for the idea, and for explaining the problem to me. Yaron Koren (talk) 23:56, 31 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):

{{SummonShowcase
|Title=Dragonyule Defenders
|StartDate=December 17, 2018 6:00 AM UTC
|EndDate=December 31, 2018 5:59 AM UTC
|Adventurer=Dragonyule Cleo, Dragonyule Nefaria, Dragonyule Xander
|Dragon=Dragonyule Jeanne
|Wyrmprint=A Wish Upon the Yuletree, The Prince of Dragonyule, Saintly Delivery, Roast Feast
}}

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

...
|EndDate={{{EndDate|}}}
...

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

Title	Dragonyule Defenders
StartDate	2018-12-17 6:00:00 AM
EndDate	2019-12-31 5:59:00 AM
Adventurer	Dragonyule Cleo • Dragonyule Nefaria • Dragonyule Xander
Dragon	Dragonyule Jeanne
Wyrmprint	A Wish Upon the Yuletree • The Prince of Dragonyule • Saintly Delivery • Roast Feast

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

• December 28, 29, and 30 are affected as well.
• Storing in YYYY-MM-DD HH:MM:SS 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

Tracked in Phabricator
Task T187825

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