Extension talk:Cargo

From MediaWiki.org
Jump to navigation Jump to search

Query non cargo tables[edit]

Hi, there is any option to do this? (from #cargo_query)? Ty

No - if you want to include non-Cargo DB tables, the best way to do is via the External Data extension. You can use it to store that outside data in Cargo, and then query everything together. Yaron Koren (talk) 03:14, 5 August 2019 (UTC)

Display format: calendar not working with mobile view[edit]

When using the mobile view implemented by the MobileFrontend extension, somehow the format=calendar cannot be shown, regardless of the used skin. Query as format=list or ul works fina, as well as Special:ViewData and Special:CargoTables.

Same issue with format=timeline, although I'm personally mostly interested in the calendar.

Recurring Event Syntax[edit]

What should the syntax for a recurring event be for a table with a single field called "Birthday" where the value is fed from a form and which normally would look like this:

{{#cargo_store:_table=Person|Birthday={{{Birthday|}}} }}

Something like this?

{{#cargo_store:_table=Person|Birthday={{#recurring_event:start={{{Birthday|}}}|unit=year}} }}

Thanks! Bryandamon (talk) 03:37, 7 August 2019 (UTC)

That seems right. Yaron Koren (talk) 13:34, 7 August 2019 (UTC)

So, Cargo queries aren't dynamic?[edit]

This may sound like a stupid question, but I don't see this stated anywhere on the wiki.

I have noticed that when I add a new item, any cargo queries I have in the wiki don't get updated. I have to re-edit the page with the query to see the new item.

This seems to really defeat the purpose of the #cargo_query function. So, am I doing something wrong or is it supposed to work like that?

Metalliqaz (talk) 16:21, 14 August 2019 (UTC)

See here. Yaron Koren (talk) 20:29, 14 August 2019 (UTC)
Understood, thanks. Metalliqaz (talk) 02:52, 15 August 2019 (UTC)

Underscores in field names cause issues[edit]

I have a Cargo table with a field called "Case". Since "Case" is a reserved word I had to rename it to "Case_". This works fine, except for one thing. In Special:CargoTables, when viewing the table, that column is broken. The table shows the column as "Case", and it is empty. The Table Structure list correctly shows the field as "Case_ - String". Cargo queries work fine. Metalliqaz (talk) 16:30, 14 August 2019 (UTC)

The issue there is that the field name ends with an underscore. I should put in a check to not allow that, because it will lead to problems, as you discovered. Yaron Koren (talk) 20:28, 14 August 2019 (UTC)
I changed the field from "Case_" to "CaseType" and rebuilt the data. It took two tries for the table to show up correctly. But now my wiki is essentially broken. Any new items added since then cause Visual editor to throw an error trying to save, the new pages aren't showing up in the Cargo tables and they aren't showing up in the category pages. Is there any way to recover this?
Edit: nevermind, php cargoRecreateData.php seems to have fixed it.Metalliqaz (talk) 19:11, 15 August 2019 (UTC)

VisualEditor compatibility with #cargo_query[edit]

Back again, I'm afraid. I've got everything working pretty well. I have a page that contains a #cargo_query table, and it works as expected. However, I've noticed that if I edit that page with VisualEditor, it will wrap the parser function in nowiki tags and thus break the page if I save it. Is there any setting I have to change to prevent this?

Update: I played around on Wikipedia, and even their VisualEditor doesn't seem to really handle parser functions very well. It thinks they are templates. In my case, I had to move some text after the ":" on the first line, and then it at least recognized my #cargo_query as a template and didn't wrap it in nowiki. So I guess this is a VisualEditor problem (or maybe Parsoid) Metalliqaz (talk) 02:34, 17 August 2019 (UTC)
Not a visual editor solution specifically, but I'd suggest as a general style rule always wrapping cargo_query calls in templates, this should have the side effect of hiding them from VE issues --RheingoldRiver (talk) 08:31, 17 August 2019 (UTC)

Make - a disallowed character in field names[edit]

Maybe I'm doing this wrong but I've never been able to do a query on a field with - in the name if a table specification is required to avoid ambiguity (e.g. |fields=cost-d is fine but |fields=Variants.cost-d doesn't work). If there's some easy way to fix this that idk about then never mind (but how??) - but assuming this is impossible, I think - should just be a global disallowed character in field names. Maybe a setting for backwards compatibility regarding this that defaults to enabling the disallow? --RheingoldRiver (talk)

This is also a good idea - dashes in table and field names tend to cause problems. I just checked in a change so now they're disallowed. I didn't add in any backward compatibility - hopefully not too many people are using them now. Yaron Koren (talk) 18:14, 12 September 2019 (UTC)

Use replacement table when creating _pageData?[edit]

Is this possible? If not could you add support for that? With the _pageNameOrRedirect field I'm going to add a ton of dependencies on this table that would break for any recreate (recreated today so I found out it doesn't use a replacement table now). Thanks! (actually still don't have this field, we upgraded just to 2.2 today but will have that soon hopefully) --RheingoldRiver (talk) 23:55, 20 August 2019 (UTC)

Good idea - I just checked in "--replacement" flags for the setCargoPageData.php and setCargoFileData.php scripts - so now, replacement tables can be created for _pageName and _fileName (at _pageName__NEXT and _fileName__NEXT), and they work the same way as standard replacement tables. Yaron Koren (talk) 23:02, 9 September 2019 (UTC)

Template to test whether page contains Cargo query[edit]

At the minute I've come up with Template:Contains cargo query:

|where=_pageName LIKE "{{#replace: {{{p}}} | " | _ }}"

I can test for an empty/non-empty result but that doesn't always work...

  1. Page does not have query on the relevant table - returns empty result
  2. Page does have ... - returns page name (non empty)
  3. Mistake, e.g. page or table name typed incorrectly - returns error message (non empty)

What would be a better way? Thanks. Jonathan3 (talk) 23:17, 25 August 2019 (UTC)

I don't understand - what are you trying to do, and what have you tried? Yaron Koren (talk) 00:04, 26 August 2019 (UTC)
I previously used Cargo in a template to test whether a page was in a certain category, but then learnt that unless you save the page twice the categories don't get saved by Cargo to the _pageData table.
I'd like to replace that test (i.e. is the page in a category that only a Cargo template would put it in?) with another test (i.e. does the page contain a Cargo query on the relevant table?).
The code above sort-of works but doesn't discriminate between a page title being returned and an error message being returned...
(The LIKE thing is because some of my page titles have both ' and " characters in them, so isn't directly relevant to the question.)
Thanks. Jonathan3 (talk) 00:16, 26 August 2019 (UTC)
I still don't understand.. you want to query for the existence of another query? Why? And how would the query above find that? It seems like just a normal query, not something that would find specific wikitext or some such. Yaron Koren (talk) 23:25, 26 August 2019 (UTC)
I have a template for displaying a page summary, which used DPL3 to display the introductory section of a page. Eventually all these pages will use Cargo; currently only a minority do. The template needs to work out whether to use Cargo to display the summary (from a database field relevant to whichever table the page uses) or DPL3 (from the first section). Using categories is currently unreliable so I just wondered if there is an ideal way of checking whether there is a Cargo query on the page... if there is, then the page summary template would use Cargo, and otherwise it would use DPL3. Maybe this is a more helpful way of describing the problem and/or maybe I am looking for a solution to the wrong problem (see w:XY problem!). Jonathan3 (talk) 01:38, 28 August 2019 (UTC)
Sorry, I still don't understand. Though I'm guessing that there is indeed a simpler solution. Hopefully someone else here can help with this. Yaron Koren (talk) 15:02, 28 August 2019 (UTC)
You're trying to push templates and Cargo way beyond their intended use. In my humble opinion, the correct answer is to properly plan your transition to the new scheme. Make your template follow the old way of doing things (the current majority). Add the new Cargo tables on top of that to each page at your leisure, then change over the template to the new method when you're done. This sounds like a good place to use a bot. Bots are useful and pretty easy to write for a moderately experience programmer. Metalliqaz (talk) 13:47, 29 August 2019‎
I don't think "to push templates and Cargo way beyond their intended use" is necessarily a bad thing, as long as it works (which it seems to now). I will think through your suggestions, though! I didn't want to use a bot to move every page to use the new Cargo template, as I want to add and check data manually for each page, which will take ages, and I wanted the new pages to have been perfected and to be easily identifiable as such. I didn't want the page summary template to do the same with both types of page, because it can show more useful information from the Cargo pages. However, I can see that there could be some benefits to transferring every page and possibly having an "incomplete" field to identify which pages need further work. Thanks :-) Jonathan3 (talk) 00:33, 30 August 2019 (UTC)
Don't get what you are trying to do here either, but for botting you can use AutoWikiBrowser. You can still check all changes manually, but much of the legwork can be done by the program, for instance using regular expressions or simple text replacement. If you only want to check for the existence of a cargo query, you can proably use AWB for that too. Perhaps this could be useful? Pangaearocks (talk) 18:41, 30 August 2019 (UTC)
Thanks. I'll look into AWB. Years ago I used Pywikibot for a simpler task (recategorising pages) so I'll look into that again too. Jonathan3 (talk) 20:56, 30 August 2019 (UTC)

Returning wikitext from Cargo queries[edit]

Suppose I have a table T, and a template A which generates wikitext using T, including links and images:

|fields=CONCAT('[[',_pageName,']] / [[File:',_pageName,'.png|link=]]')
<!-- other fields --> 

I would like to store A into another Cargo table as a wikitext field, say T2:


for example by calling A directly inside #cargo_store:

|desc={{A| <!-- template parameters --> }}

But the problem is, if A doesn't have no html, then T2 will receive strip markers (and sometimes store the row twice), yet if A uses no html, the link disappears while the image is turned into a raw <img> tag, exposing the URL of the cached image file. This makes A unusable as the input to any wikitext field of a Cargo table. One solution is to replace A with a Lua version, for example:

return {main = function ()
  return mw.ext.cargo.query('T', "CONCAT('[[',_pageName,']] / [[File:',_pageName,'.png|link=]]')=x", { --[[other fields]] })[1].x

A's body then becomes just {{#invoke:A|main}}. This allows A to work properly, but in the general case T2.desc may accept any Cargo-based template as its input, and it is simply infeasible to repeat the same conversion on every template that could possibly be used for T2.desc. Is it possible to fix this from the parser functions alone, without using Lua? --HertzDevil (talk) 13:00, 27 August 2019 (UTC)

That's a tricky one, and you may have found a bug. But is all this really necessary? Why do you need to store that concatenated string at all? And if you need to store it, why not store it in the page corresponding to "_pageName", so that you can do it without calling a query? Yaron Koren (talk) 13:46, 27 August 2019 (UTC)

_pageData take columns from actual table, not the setting[edit]

Right now if you add columns to _pageData in localsettings but don't immediately rebuild the table, everything breaks because it tries to add the extra columns immediately. Could you make it instead look at the existing table to discover columns so that if there's some delay between columns being added and the table being recraeted, it's still working? --RheingoldRiver (talk) 20:08, 6 September 2019 (UTC)

I thought about doing it that way when first implementing _pageData - I decided against it because it adds a query every time someone saves a page, which is not a big deal but seems like overkill. Why can't you rebuild the table right away? (And would that "replacement" option help?) Yaron Koren (talk) 20:19, 6 September 2019 (UTC)
Now that we know it works this way, we'll be ok, but we had a ton of wikis break recently because of a change to the default _pageData setting that we wanted to take effect the next time tables were recreated, but not to run the recreate immediately. Is one extra read query that much of a problem? A replacement table actually would help this somewhat since the rebuilds would be lower-impact and could be safely done sooner, but this seems like a pretty unsafe way to do things as-is; _pageData failing is super high-impact since it causes the rest of the tables to be unable to store as well. --RheingoldRiver (talk) 21:44, 6 September 2019 (UTC)