Extension talk:Cargo/Archive January 2019

Latest comment: 5 years ago by Henryfunk in topic Cargo and filecache

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)Reply

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)Reply
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)Reply
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)Reply
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)Reply

Use HOLDS with multiple values

I'd like to do something like this:

|where=fieldname HOLDS 'value1' AND fieldname HOLDS 'value2' AND fieldname HOLDS NOT 'value3'

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

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)Reply
"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)Reply

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)Reply

You can already do that, if I understand the question correctly, with "_drilldownTabs" - see here. Yaron Koren (talk) 14:54, 13 January 2019 (UTC)Reply
Yes, that's perfect! Thanks for your quick reply. Jonathan3 (talk) 16:34, 13 January 2019 (UTC)Reply

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 List (,) of String which uses {{#arraymap...}} 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)Reply

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)Reply
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)Reply
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)Reply
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)Reply
Why do that - why not just use the existing category structure, using "top category="? Yaron Koren (talk) 18:32, 23 January 2019 (UTC)Reply
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)Reply
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)Reply
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)Reply

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)Reply

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 allowed values={{template}}? Jonathan3 (talk) 22:13, 23 January 2019 (UTC)Reply
@Yaron Koren: Good news, I think! I have created a template using DPL3 which takes the name of a category as a parameter and outputs the category tree in the required * and ** format, then added allowed values={{template name}} to the Cargo template page. When I add a new category page to the wiki, I need to (1) do a null edit of the template page so that the "tree" input type on the form discovers the new category, and (2) "recreate data" so that the new category name is able be saved into the table by the relevant page's template.
It would be good if it were possible to change the table structure without recreating the data (saving time with large tables). I guess a problem with changing allowed values that the user might try to remove one that already appears in the data, but that could be checked for. This feature could also be useful for, for example, adding a table column. Is it something you would consider adding? Jonathan3 (talk) 14:37, 28 January 2019 (UTC)Reply
There certainly are specific cases where a Cargo table could be modified without requiring recreating the entire table - adding additional allowed values to a field, adding a still-empty field/column, removing a field/column. (That last one is probably the least risky.) It's conceivable to do, and I thought about adding in that kind of functionality, but I don't know if it's worth the effort, given that it would only be useful in a pretty specific set of cases, and the code to enable it might have to be pretty complex. Ever since the "replacement table" functionality was added, I think long recreate-data times have been less of a major issue. But if you think it's worthwhile, and that there's an easy way to do it, let me know. Yaron Koren (talk) 19:58, 28 January 2019 (UTC)Reply
If it's complicated (or could take ages to work out whether it's complicated) then I agree it's not important :-) Jonathan3 (talk) 23:37, 28 January 2019 (UTC)Reply

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)Reply

Not at the moment, I don't think. Yaron Koren (talk) 23:51, 13 January 2019 (UTC)Reply
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):
/* Special:Drilldown */
/* Show filter values even when value selected; hide "Click arrow to add another value" message; hide arrow icons */
$( function() {
  $('.drilldown-filter-values').show();
  $('.drilldown-filter-notes').hide();
  $('.drilldown-values-toggle').hide();
} );
Jonathan3 (talk) 03:49, 27 January 2019 (UTC)Reply

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)Reply

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)Reply

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)Reply

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)Reply

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)Reply

Join several tables and order by _creationDate [RESOLVED]

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)Reply

@Jonathan3: For that, you'd probably need to be able to use the union 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)Reply
@Samwilson: 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)Reply
@Samwilson and Yaron Koren: 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)Reply
@Jonathan3: 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 {{#cargo_store: _table=photos |date={{{date|}}} |description={{{description|}}} }}{{#cargo_store: _table=news_items |date_and_time={{{date|}}} |summary={{{description|}}} }} 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)Reply
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)Reply
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)Reply
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)Reply
I haven't really followed the full discussion here, but - did you put #cargo_attach in the <noinclude> section of the template? Yaron Koren (talk) 14:27, 25 January 2019 (UTC)Reply
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)Reply
@Yaron Koren: I wonder if it would be possible for cargoRecreateData.php to change $templatesForThisTable = array_merge( $templatesThatDeclareThisTable, $templatesThatAttachToThisTable ); somehow also to include templates that store to the table? Jonathan3 (talk) 14:36, 25 January 2019 (UTC)Reply
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)Reply

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)Reply

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)Reply
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)Reply
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)Reply
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)Reply

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

{{#cargo_query:
  |tables=
    Journals,
    Page_properties 
  |join on=
    Journals._pageName=Page_properties._pageName 
  |fields=
    DATE_FORMAT(Journals.Journal_Date,'%D %M %Y')=Date,
    CONCAT( '[[', Journals._pageName, ']]' )=Title,
    CONCAT( '[{{fullurl:Special:FormEdit/Article/}}', Journals._pageName, '&returnto={{FULLPAGENAME}}#tab=Knowledge_Catalogue Edit]')=Edit,
    Page_properties.Description=Description,
    Page_properties.Content=Content
  |where= (({{Holds Journal Groups|GroupNames={{{GroupNames}}} }}) AND (DATEDIFF(Journals.Journal_Date,NOW()) <= 0))
  |group by=Journals._pageName
  |order by=Date DESC
  |format = template
  |template = Display Journal Article
  |named args = yes
  |max display chars=100000
  |limit = 1000
}}

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

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

{{Display Journal Article|Date=26th January 2019|Title=List of changed templates and forms|Edit=Edit|Description=These should be updated to the live system. They are listed in the order they have been changed.|Content=
      Template:Display All Groups - added 'delete' to table rows.  Can this be combined with Display Groups template?
      Template:News - correction to in template documentation
      [[Templa }}

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 #Text is not placed in a table above? The solution there was to increase the size of the Wikitext field by using Wikitext (size=5000). Jonathan3 (talk) 03:19, 27 January 2019 (UTC)Reply
Great thanks Jonathan, that does look like it solves the problem. I agree also with Yaron, perhaps he should make Wikitext a blob so that users doesn't have to worry about setting an arbitrary size parameter? That gets my vote
Duncan, 28th Jan 2019
Actually, this is already done. In another still-unannounced change, about a month ago I changed the Wikitext type to be stored in the same way as Text, and added a new type, "Wikitext string", which is stored like a String. If you get the latest code, and recreate the relevant table(s) this should work better. Sorry, I didn't realize that this was the issue. Yaron Koren (talk) 20:02, 28 January 2019 (UTC)Reply

Order by "DESC" not working [RESOLVED]

After updating Cargo (I think that's the cause) existing queries containing |order by= _creationDate DESC gives the error Error: 1054 Unknown column '_creationDate DESC' in 'order clause'. 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)Reply

Looks like the problem is in CargoSQLQuery.php:
	function setOrderBy( $orderByStr = null ) {
		if ( $orderByStr != '' ) {
			if ( strpos( $orderByStr, '(' ) === false && strpos( $orderByStr, '.' ) === false && strpos( $orderByStr, ',' ) === false ) {
				$this->mOrderByStr = $this->mCargoDB->addIdentifierQuotes( $orderByStr );
			} else {
				$this->mOrderByStr = $orderByStr;
			}
The problem seems to be that in the first case above it adds backticks to the whole thing, e.g. `_creationDate DESC`. I can work round it by using |order by= _pageData._creationDate DESC so that the . avoids the problem. Jonathan3 (talk) 20:59, 26 January 2019 (UTC)Reply
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)Reply
No problem - works fine again now, thanks. Jonathan3 (talk) 13:38, 28 January 2019 (UTC)Reply

Display field as plain text or wikitext [RESOLVED]

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)Reply

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 |format=template it comes out formatted as wikitext. Jonathan3 (talk) 23:53, 26 January 2019 (UTC)Reply

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)Reply
That works fine for me on the latest version of Cargo, thanks. Jonathan3 (talk) 14:50, 28 January 2019 (UTC)Reply

Hiding some tables from Drilldown tabs

I'd like to hide some tables, e.g. "All pages". I see they're within <li class="tableName"> elements. Perhaps if they were to have an id equal to the table name, then I could use CSS to hide them? Would you be willing to do that? It wouldn't necessitate any major Cargo code changes. Or maybe it's possible already? Thanks, Jonathan3 (talk) 23:07, 28 January 2019 (UTC)Reply

Behaviour of hierarchy in Drilldown

There seems to be an inconsistency:

  • Normally when a value is selected for a field, the page reloads with "(Click arrow to add another value)" for that field - the user is allowed to broaden the search by selecting further values.
  • However, when a value is selected for a hierarchy, the "(Click arrow to add another value)" message does not appear – the user is not allowed to broaden the search by selecting further values. The user is stuck with the selected value - if there are values lower down the hierarchy, he can then pick one but is then similarly stuck with that choice.

Is there a way to change this? I think the normal way is preferable. It would be good to be able to select two or more values from the same level of a hierarchy, or even from a different part of the hierarchy altogether. Maybe I've messed something up by hiding stuff using CSS/JS... Jonathan3 (talk) 23:37, 28 January 2019 (UTC)Reply

cargoRecreateData.php and replacement tables

It would be nice if the script when used with --replacement offered, at the end, to switch in the new table... not important, but if not too complicated it would be good to have. Jonathan3 (talk) 23:44, 28 January 2019 (UTC)Reply

Hide the form on Special:Viewdata [RESOLVED]

Is it possible to create a link, containing a query, to Special:Viewdata and tell the page not to display its table? Jonathan3 (talk) 23:47, 28 January 2019 (UTC)Reply

I don't understand - if you include a query in the query string of Special:ViewData, the form doesn't get shown. Yaron Koren (talk) 03:04, 29 January 2019 (UTC)Reply
Sorry. I’ve been relying on this page too much instead of experimenting more. Jonathan3 (talk) 07:58, 29 January 2019 (UTC)Reply

#if within where= parameter [RESOLVED]

 

Is it possible to have something like |where={{#if:{{{parameter|}}}|x=y}} in a Cargo query. I'm sure it should be but can't get it to work. Thanks. Jonathan3 (talk) 14:24, 29 January 2019 (UTC)Reply

Yes it's possible but you still need the quotes, e.g. x="y". --RheingoldRiver (talk) 10:05, 31 January 2019 (UTC)Reply
Cheers. I’ll check whether that’s the mistake I was making! Jonathan3 (talk) 11:16, 31 January 2019 (UTC)Reply
That wasn't it, unfortunately. Maybe there's something up with my wiki. Maybe it's not parsing the {{{...}}} and is searching for that literal text.
When I have |where = {{#if: {{{parameter|}}} | _pageName="{{{parameter|}}}" | _pageName="Page B" }} it goes for Page B whether I use {{templatename|parameter=Page A}} or just {{templatename}}. In the same template I have put {{#if: {{{parameter|}}} | {{{parameter|}}} | B }} and it correctly either displays the parameter or "B".
When I try something simpler like |where=_pageName="{{{parameter|}}} it displays no results, wheras when I use |where=_pageName="Page A" it correctly selects Page A. Jonathan3 (talk) 13:21, 31 January 2019 (UTC)Reply
I had the Cargo query within a tag extension which meant it wasn't parsing things properly - sorry! Jonathan3 (talk) 13:30, 31 January 2019 (UTC)Reply
Adding image :-) Jonathan3 (talk) 13:43, 31 January 2019 (UTC)Reply
Nice image, although it's not really necessary. :) Yaron Koren (talk) 23:45, 31 January 2019 (UTC)Reply

Adding limit as template parameter not working any more [RESOLVED]

I have a query in a template which contains |limit={{{limit|}}}. It used to work but now no limit is applied at all. Do you know what's up? I'm now on Cargo 2.0.1 (9c4aef9). Thanks. Jonathan3 (talk) 00:22, 30 January 2019 (UTC)Reply

Does it work for you when it's not a template parameter? Yaron Koren (talk) 16:30, 30 January 2019 (UTC)Reply
Yes, it works when I change the template to have limit=1 or any number. Jonathan3 (talk) 16:39, 30 January 2019 (UTC)Reply
I had the Cargo query within a tag extension which meant it wasn't parsing things properly - sorry! Jonathan3 (talk) 13:31, 31 January 2019 (UTC)Reply

Cargo and filecache

I am thinking about migrating from SMW to Cargo. On my site with the latest version of SMW, the rebuildFileCache script reports most pages "not cacheable". Are pages with Cargo data or queries cacheable with filecaching enabled? (I am aware of potential issues with stale data in the cached files, but I am the only contributor to the site and have a CRON script that runs rebuildFileCache, so this is not a big problem in my case). Henryfunk (talk) 22:39, 31 January 2019 (UTC)Reply

I haven't heard of problems with rebuildFileCache.php and Cargo, but then again I haven't heard of problems with rebuildFileCache.php and SMW either... Yaron Koren (talk) 23:53, 31 January 2019 (UTC)Reply
Thanks. I will certainly try Cargo then. FWIW: The caching problem started after upgrading to SMW 3.0 and MW 1.31. Filecaching works OK without SMW loaded. Henryfunk (talk) 11:58, 1 February 2019 (UTC)Reply
Return to "Cargo/Archive January 2019" page.