Extension talk:Cargo/Archive March to April 2020

Streamlining uploading images with cargo metadata?

I can upload an image, then on its File page I can include a template that stores some metadata about that image, and later query that template's table in order to create a gallery. However, the manual addition of the template to the File page is tedious and error-prone (e.g. correctly naming other pages in various template fields). Is there an extension, perhaps something like Page Forms, that would allow me to simplify this process, so that I could upload an image and populate its metadata on a single page? Sparr (talk) 01:15, 5 March 2020 (UTC)

Yes - Page Forms. :) You should create a form for that template, and then associate that form with the "File" namespace, so that every File page will automatically get an "edit with form" tab when created. Yaron Koren (talk) 17:11, 5 March 2020 (UTC)

Two wikis and one CargoDB

Is it possible to specify the same database for two different wikis?

1) one and the same table is used in the first wiki for recording data and in the second - only for reading.

2) joint filling table. What is the key when writing data (when cleaning old data) - pageName or pageId? Or is it arranged much more difficult? --StasR (talk) 15:35, 5 March 2020 (UTC)

I don't think having the same Cargo database for two different wikis will work, even if one is just reading. I believe that, in order to query a Cargo table, a wiki has to know about it - know about its structure, etc. - and that is not possible for an unrelated wiki. Yaron Koren (talk) 18:32, 5 March 2020 (UTC)

I declare and create a table in the first wiki. Then I drop the table using SQL command line. Then I declare and create the table in the second wiki. And after that the first wiki writes records to the table. Will it work? --StasR (talk) 09:16, 6 March 2020 (UTC)

What about Extension:External Data? Jonathan3 (talk) 18:49, 5 March 2020 (UTC)

I have here a lot of tables. The shared table is only one of them. It is convenient to use a single tool. --StasR (talk) 09:16, 6 March 2020 (UTC)

I created a small extension for my own use for this purpose. Not really feature complete, but depending on your needs you might be able to use it: www. dropbox. com/s/a00lgim2ke823hs/InterCargo.rar?dl=0 . There is a readme inside. Also, I'm not quite sure how it affects caching, so if traffic is a concern for you, you might want to keep an eye on that. Thorbjørn Steen (talk) 22:02, 1 May 2020 (UTC)

That's very interesting - I checked out the code. It seems well-written, although I think what it does can already be done with a combination of #get_web_data from External Data (accessing the other wiki's Cargo API), #for_external_table, and a template calling #cargo_store. Yaron Koren (talk) 23:08, 3 May 2020 (UTC)

DISPLAYTITLE and Cargo fields with ' in them [RESOLVED]

The following doesn't work when Title contains an ' character:

{{DISPLAYTITLE:{{#replace:{{PAGENAME}}| {{{Title}}} | <i>{{{Title}}}</i>}} }}

The same thing does work when I replace {{{Title}}} with the text of that field (even if it includes the ' character).

Is this something to do with Cargo's handling of that character? Is there any way to work around this? Thanks. Jonathan3 (talk) 09:18, 6 March 2020 (UTC)

Is this a Cargo question? It sounds like just a MediaWiki issue. Yaron Koren (talk) 21:15, 8 March 2020 (UTC)

OK I'll ask on the Support desk :-) Jonathan3 (talk) 20:29, 10 March 2020 (UTC)

I didn't ask in the end, but it turns out it's caused by a problem mentioned on the Help:Magic Words, i.e.:

"Page titles containing certain characters, such as apostrophes ' or asterisks *, may produce unexpected results when handled with these magic words, e.g. {{PAGESINCATEGORY:{{PAGENAME}}}}. See bugs T16779, T18474, T37628, T37746. One simple way to fix this is wrapping the pagename in {{#titleparts:}} from the ParserFunctions extension."

It can be fixed the same way. Thanks for pointing me in the right direction. Jonathan3 (talk) 13:56, 21 March 2020 (UTC)

Drilldown

I have two questions about the charge.

In occupations and professions, it is occasionally necessary to use the appropriate term according to the person's gender (male-female).

For example King and Queen in English but it is more frequent that distinction in other languages such as Spanish (Senador-Senadora, Presidenta-Presidente, Maestra-Maestro). Currently the same information has been duplicated unnecessarily. There is a solution but it's more focused on categories (somewhat complicated). Could this have a solution in Cargo or not? Maybe it could be used in some way with plurals in Drilldown but I'm not sure (examples: Maestros, presidentes, kings..).

I am using List (,) of String but I have noticed that in every word the first letter must be capitalized. The simple solution is that everything should be in lower case but it doesn't fit well in the infobox. Does that have a solution or do I opt for what I said before?

Greetings. --Hispano76 (talk) 19:46, 9 March 2020 (UTC)

For the first one, I would say the best solution is to have one value representing each pair, like "Senador" and "Senadora". I don't know how it's usually done in Spanish - "Senador(a)"? Just "Senador"? Whatever you pick, it will be better to have one value than two, even though there are different words for the two.

For the second one, I don't understand. Why can't you start words with a lowercase letter? Yaron Koren (talk) 03:09, 10 March 2020 (UTC)

It would be fairly easy to save as one value (eg senador) and have gender as a field too, then display the word based on the individual's gender (eg senador/senadora). In Cargo you can have fields starting with lower case letters, so maybe you mean wiki page titles - have a look at Manual:$wgCapitalLinks. Jonathan3 (talk) 10:56, 10 March 2020 (UTC)

@Yaron Koren: The answer is visualization. In Spanish after a period for example, the first letter must begin in capital letters. For example in the Infobox of this article it appears like this: Abogado, político, escritor, educador, funcionario público, filósofo, rector. And you'd rather do it that way, isn't that fixable?

Capitalisation. Could you maybe use {{ucfirst:string}} (with #arraymap??) and the relevant __full Cargo field to capitalise the first letter of the first word in a list? I’m typing on the phone but could elaborate later if it sounds useful. Jonathan3 (talk) 09:09, 12 March 2020 (UTC)

hum, it seems interesting but it works with the example I gave?

@Jonathan3: Can you give me an example? It's confusing to me what you're trying to say. About wgCapitalLinks I would prefer not to enable it at this time. --Hispano76 (talk) 01:13, 12 March 2020 (UTC)

Let's say that you have a "Person" table with Occupation = List (,) of String and you have entered each occupation in lowercase (e.g. abogado, politico, escritor). You then want to show it as a list, with the first item in the list have an initial capital letter (e.g. Abogado, politico, escritor). I can't get {{ucfirst:}} to work with the results of a Cargo query. This seems to work: |fields=CONCAT(UCASE(SUBSTRING(Occupation__full, 1, 1)), SUBSTRING(Occupation__full,2)). Alternatively, if each string in the list starts with a capital letter, and you want to ensure only the first letter is capital: |fields=CONCAT(UCASE(SUBSTRING(Occupation__full, 1, 1)), LCASE(SUBSTRING(Occupation__full,2))). It will display the list delimited by a comma (or whatever delimiter is in the #cargo_declare) - if you want to format it differently (e.g. add [[]] around each string) you'd need to use #array_map. Jonathan3 (talk) 21:13, 13 March 2020 (UTC)

Gender. You could have Cargo table Person (with fields occupation and gender), and a separate Occupation table (with male and female versions) - which you’d need to join in a query. Or, maybe better, you could have a single Person table with an extra hidden field for the female version if relevant (ie a female lawyer would have occupation=abogado and also female occupation=abogada) - so you could use #if to decide whether to display the male version or it’s female equivalent, while the Drilldown page and search would still use the same word for everybody. Jonathan3 (talk) 09:17, 12 March 2020 (UTC)

hum. I would need an example because it's confusing to me because of the language difference. --Hispano76 (talk) 20:10, 12 March 2020 (UTC)

Voy a hacerlo pronto :-) Jonathan3 (talk) 17:32, 13 March 2020 (UTC)

In the #cargo_declare for the Person table in Template:Person you would have Occupation=List (,) of String | Occupation_female=List (,) of String (hidden). In Form:Person you'd have a note saying only to use Occupation_female if the person is female (but still to use the main Occupation field in all cases). In Template:Person you would have something like '''Occupation:''' {{#if:{{{Occupation female|}}} | {{{Occupation female}}} | {{{Occupation|}}} }}. Special:Drilldown would ignore Occupation_female because of the "hidden" parameter, so you'd search on the male occupation title for everybody. This is just one way that sprang to mind. I imagine there's an accepted way of doing it in Spanish!

Alternatively, you could have a separate Template:Occupation declaring an Occupations table with Male=String | Female=String. On Form:Occupation you'd enter Male as abogado, Female as abogada, and the same for all the professions used. On the Person template you would only have Occupation defined (no Occupation_female). But when displaying Occupation: in Template:Person you'd add an extra Cargo query like {{#cargo_query:table=Occupation|fields=Occupation|where=Occupation={{{Occupation|}}}. I realise I've complicated it by using the word Occupation so many times... and this is from memory so I may have got the syntax wrong. I hope I've not sent you barking up the wrong tree. Jonathan3 (talk) 21:26, 13 March 2020 (UTC)

I'm afraid to say that none of them worked. I tried various ways with your examples @Jonathan3: --Hispano76 (talk) 00:14, 14 March 2020 (UTC)

I guess the only way would be a hidden parameter (|ocupaciónCargo=). That would solve the gender by transforming them into plurals (Senadora, Senador=Senadores). We're still missing the caps that didn't work. --Hispano76 (talk) 00:43, 14 March 2020 (UTC)

I think I know what you mean (plurals of masculine and feminine nouns in Spanish are the same). Could you cut and paste what you've tried and what happens? Jonathan3 (talk) 15:56, 15 March 2020 (UTC)

@Hispano76: Go on, cut and paste the relevant parts of the template here :-) Jonathan3 (talk) 13:54, 16 March 2020 (UTC)

Maintenance script errors

The scripts in the maintenance directory all give errors:

> php cargoRecreateData.php 
1Recreating data for Cargo table demo in 5 seconds... hit [Ctrl]-C to escape.
Deleting and recreating table...
[2c20ef2c94d1d167c49639b2] [no req]   Error from line 557 of /var/www/html/extensions/Cargo/includes/CargoUtils.php: Call to a member function tableExists() on null
Backtrace:
#0 /var/www/html/extensions/Cargo/maintenance/cargoRecreateData.php(101): CargoUtils::recreateDBTablesForTemplate(string, boolean, string)
#1 /var/www/html/extensions/Cargo/maintenance/cargoRecreateData.php(69): CargoRecreateData->recreateAllDataForTable(string, boolean)
#2 /var/www/html/maintenance/doMaintenance.php(99): CargoRecreateData->execute()
#3 /var/www/html/extensions/Cargo/maintenance/cargoRecreateData.php(161): require_once(string)
#4 {main}

> php setCargoFileData.php 
1[145ec0515a167c688c084ec1] [no req]   Error from line 34 of /var/www/html/extensions/Cargo/specials/CargoDeleteTable.php: Call to a member function begin() on null
Backtrace:
#0 /var/www/html/extensions/Cargo/maintenance/setCargoFileData.php(62): CargoDeleteCargoTable::deleteTable(string, boolean, boolean)
#1 /var/www/html/maintenance/doMaintenance.php(99): SetCargoFileData->execute()
#2 /var/www/html/extensions/Cargo/maintenance/setCargoFileData.php(103): require_once(string)
#3 {main}

php setCargoPageData.php 
1[d4f8828a2b4c75c981e8cf15] [no req]   Error from line 728 of /var/www/html/extensions/Cargo/includes/CargoUtils.php: Call to a member function begin() on null
Backtrace:
#0 /var/www/html/extensions/Cargo/maintenance/setCargoPageData.php(79): CargoUtils::createCargoTableOrTables(NULL, Wikimedia\Rdbms\MaintainableDBConnRef, string, CargoTableSchema, string, integer)
#1 /var/www/html/maintenance/doMaintenance.php(99): SetCargoPageData->execute()
#2 /var/www/html/extensions/Cargo/maintenance/setCargoPageData.php(103): require_once(string)
#3 {main}

What version are you running of MediaWiki and Cargo? Yaron Koren (talk) 12:52, 13 March 2020 (UTC)

Querying data

In case of doubt, I am reworking the "Persona" template for several reasons and for better organization because there are more than 20,000 articles that would use a single table.

I would like to see a separate table, with articles from people born in a certain country, for example Mexico (using the same template "Persona" and not another one; unless it is not possible). I have seen that the Where parameter of #cargo_query has a similar function but I would like to get more information and if that is possible.

Example

{{#cargo_declare:_table=Personas|Imagen=File|Género=String|Nacimiento=Date|Fallecimiento=Date|Entidad=String|País=String|Ocupación=List (,) of String}}

{{#cargo_declare:_table=Personas_de_México|Imagen=File|Nacimiento=Date|Fallecimiento=Date|Entidad=String}}

{{#cargo_declare:_table=Personas_de_Canadá|Imagen=File|Nacimiento=Date|Fallecimiento=Date|Entidad=String}}

{{#cargo_store:_table=Personas|Imagen={{{imagen|}}}|Género={{#ifeq:{{{género|}}}|h|Hombres|}}{{#ifeq:{{{género|}}}|m|Mujeres|}}|Nacimiento={{{año nacimiento|}}}|Fallecimiento={{{año fallecimiento|}}}|Entidad={{{entidad|}}}|País={{{país|}}}|Ocupación={{{ocupaciónCargo|}}} }}

{{#cargo_store:_table=Personas_de_México|Imagen={{{imagen|}}}|Nacimiento={{{año nacimiento|}}}|Fallecimiento={{{año fallecimiento|}}}|Entidad={{{entidad|}}} }}

{{#cargo_store:_table=Personas_de_Canadá|Imagen={{{imagen|}}}|Nacimiento={{{año nacimiento|}}}|Fallecimiento={{{año fallecimiento|}}}|Entidad={{{entidad|}}} }}

I preferred to ask instead of testing if it worked, this to avoid causing any errors. I couldn't find a wiki that used that feature either. How could I configure it to do this? --Hispano76 (talk) 23:05, 14 March 2020 (UTC)

I doubt you can get this to work. If you want separate tables, you need to have separate templates. But what's the problem with having a table with 20,000 rows? Yaron Koren (talk) 14:45, 15 March 2020 (UTC)

@Yaron Koren: I understand. There's no problem with quantity, but it seemed more organized in a different division. But if that's too much work, then it'll be in the current form. --Hispano76 (talk) 15:32, 15 March 2020 (UTC)

Date error: 1970-01-01

Oh, I forgot to mention. For some reason, if you don't fill in Death=Date, 1970-01-01 will appear, the same thing happens if you add "Unknown". I tried this code:{{#if: {{{año fallecimiento|}}} | {{{año fallecimiento|}}} | Desconocido }} but it didn't work. I could convert "Date" to "String" but that would eliminate the chronology and photos function (one of the reasons why I chose Cargo). I don't remember this happening before. What did I do wrong? By the way, it's almost the same code as the one above with some differences. --Hispano76 (talk) 20:29, 15 March 2020 (UTC)

I don't know, but you should create separate sections for separate problems. Yaron Koren (talk) 21:02, 15 March 2020 (UTC)

@Yaron Koren: For example: code and display. This appears if you do not add anything to the "Birth/Decease" parameter in an item that uses the Person template. --Hispano76 (talk) 21:43, 15 March 2020 (UTC)

Your #if statement should work. I've tried out {{#if: {{{Date|}}} | {{{Date|}}} | Unknown }} and it works fine, and an empty on its own shows blank. Maybe it's the accented characters (though it shouldn't be that)? But this problem rings a bell from the past... I wonder if you are using an old version of MediaWiki and/or Cargo. Jonathan3 (talk) 22:54, 15 March 2020 (UTC)

@Jonathan3: Um, so it's weird. I have version 2.4 of Cargo (bd152ef; 13 ene 2020) and version 1.34 of Mediawiki --Hispano76 (talk) 23:26, 15 March 2020 (UTC)

I'm on MW 1.31.1 and Cargo 2.4 (01e9645) so am at a loss. Maybe it's something to do with the input type you are using in your form (i.e. maybe it is saving Unix 0 time 1/1/70 if it's left blank)? I use the standard date input type, not the datepicker. Jonathan3 (talk) 13:53, 16 March 2020 (UTC)

@Jonathan3: I didn't use Page Froms when creating the Person template because it's easier for me to modify it manually. Anyway I use the "Date" for the year numbers. --Hispano76 (talk) 18:50, 16 March 2020 (UTC)

hum, that date always appears even if you leave the parameter |nacimiento= empty or add the word "Desconocido" in an article or in the template itself with the #if P.S. That's also the case with my other wiki. --Hispano76 (talk) 19:14, 16 March 2020 (UTC)

If you cut and paste your entire template and form, then the cause of your problems may become clear! Jonathan3 (talk) 20:47, 17 March 2020 (UTC) By that I meant cut and paste it into this wiki discussion page :-) Jonathan3 (talk) 10:01, 19 March 2020 (UTC)

@Jonathan3: First, to clarify. For a while it worked the dates without using PageForms but suddenly it didn't work, that's why the error.

I didn't want to create a namespace or create specific categories but basically PageForms forces me to create at least one of the two, why? --Hispano76 (talk) 15:12, 24 March 2020 (UTC)

I still think it would be good if you pasted your template content here :-) Jonathan3 (talk) 16:39, 24 March 2020 (UTC)

@Jonathan3: For example, that's the code and template I use, I've done it this way to make it easier to understand. --Hispano76 (talk) 16:12, 31 March 2020 (UTC)

I still get that error if I use PageForms --Hispano76 (talk) 19:57, 4 April 2020 (UTC)

@Jonathan3 and Yaron Koren: One question, so I can't use templates and custom infobox modules and I have to use simple predefined CargoTables? because I can't adapt anything because that error comes up. --Hispano76 (talk) 20:17, 4 April 2020 (UTC)

Sorry, I didn't really look into this until now. Thanks for pasting your template. Your #cargo_store call is way too complicated, and I believe that is what is causing the dates problem. You should replace entries like "|Nacimiento={{#if: {{{año nacimiento|Desconocido}}} | {{{año nacimiento|Desconocido}}} | Desconocido}}" with just "|Nacimiento={{{año nacimiento|}}}". Cargo should see a blank value if that field is not set, not text like "Desconocido". As for Page Forms - it doesn't require you to create namespaces or categories, but that sounds like a different issue. Yaron Koren (talk) 13:45, 6 April 2020 (UTC)

The year 2099

I wanted to mark an event as postponed (date TBC) by changing its date to 9/9/99 but although PF saves this OK to to the wikipage as |Date=2099/09/09 it shows up on the form as if it were blank. Strangely enough it appears on Special:Drilldown as 1/1/70 and this is how it is displayed on Special:CargoQuery... What's up? When I change it to 1 Jan 2030 it works fine. Thanks. Jonathan3 (talk) 15:14, 17 March 2020 (UTC)

This sounds like two different issues. For the Cargo issue - is the wikitext value still currently "2099/09/09"? If so, what shows up in "action=pagevalues"? Yaron Koren (talk) 20:08, 17 March 2020 (UTC)

I changed it back to do this. |Date=2099/01/01 (same for 2099/09/09) gives Date 1970-01-01 using "action=pagevalues". Jonathan3 (talk) 20:45, 17 March 2020 (UTC)

That's strange - I don't get that problem. I wonder if this is an issue in the PHP version, OS, database etc. you have, maybe related to the "year 2038 problem"? Yaron Koren (talk) 21:47, 17 March 2020 (UTC)

OK, I'll look into that and report back. Jonathan3 (talk) 22:09, 17 March 2020 (UTC)

Problem with list-type field names and values

• Table declaration: https://wikisandbox.gamepedia.com/Template:CargoListBug/CargoDec

So here we make a list-type field called "Blah"

Now here we store the value Blah into the other field. Then we try to query it. Now it's somehow thinking we're trying to query the field Blah, rather than the value Blah in field OtherField.

And in fact even when the value is Blah with extra text, it still thinks we're querying the list-type field somehow.

Found this as an issue because a tournament has the word "Tournaments" in its name ("H3LL Tournaments/2020 Season") and I have a list-type field in a table ExternalContent.Tournaments. I'll workaround it by renaming the field for now but this seems like potentially a pretty big issue. --RheingoldRiver (talk) 00:49, 19 March 2020 (UTC)

Yes, it's unfortunate. Getting the parsing in #cargo_query just right is hard. I can think of two workarounds until this is fixed: renaming the field, as you're doing, or splitting up the search string using CONCAT() - so having something like "where=OtherField=CONCAT('Bl', 'ah')" instead of "where=OtherField='Blah'". I'm aware that both of these are hacks. Yaron Koren (talk) 13:50, 19 March 2020 (UTC)

Oh the concat workaround is helpful, thanks - I think that's a lower-impact way to fix, I can put a line in my query module to do replacements and then just delete it later, instead of create-recreate a bunch of fields and have to change names everywhere. Can you let me know when it's fixed so I can get us to update? --RheingoldRiver (talk) 21:21, 19 March 2020 (UTC)

Alright. Yaron Koren (talk) 00:00, 20 March 2020 (UTC)

Special:Drilldown - first letter of table lowercase creates error [RESOLVED]

When I type the URL, e.g. ...Special:Drilldown/tablename instead of .../Tablename it gives a database error. I know this isn't a high priority at all, but it should be simple enough to fix I guess! Thanks. Jonathan3 (talk) 14:31, 21 March 2020 (UTC)

That's true - I just checked in a fix for this, so now it displays an error message if there's no table by that exact name. Yaron Koren (talk) 14:30, 22 March 2020 (UTC)

Thanks. It sort of works. When it's completely wrong it shows the nice error message. When it's the name of the table but with the wrong capitalisation (whether lowercase at start, uppercase in middle) it still shows the SQL error. Jonathan3 (talk) 21:21, 23 March 2020 (UTC)

That doesn't happen for me. I wonder if it's due to a different MySQL version, different storage engine, or that sort of thing. Yaron Koren (talk) 01:48, 24 March 2020 (UTC)

Here are all the pieces of information that might possibly be relevant: Cargo database default collation latin1_swedish_ci; each Cargo table engine InnoDB and collation latin1_swedish_ci; MySQL 5.5.52-0ubuntu0.14.04.1-log; PHP 7.0.31 (cgi-fcgi). Jonathan3 (talk) 15:59, 26 March 2020 (UTC)

I also wonder whether it might be that your browser bar autocomplete/autocorrect is changing what you type to the correct version when the page has been visited (with the correct version) before, and therefore avoiding the error. This happens to me on Chrome. Jonathan3 (talk) 15:21, 27 March 2020 (UTC)

Sorry about that! It wasn't due to database or browser issues, it was due to something really silly: for some reason I thought you were talking about Special:CargoTables and not Special:Drilldown the whole time. I think it's because I went to Special:CargoTables right after I saw your bug report, found that exact same issue, and so assumed that that's what you were talking about. I just checked in a change that I believe fixes this problem for Special:Drilldown as well. Yaron Koren (talk) 17:27, 27 March 2020 (UTC)

That works fine now, thanks :-) Jonathan3 (talk) 21:59, 28 March 2020 (UTC)

Cargo queries vs. expensive parser functions

Retrieving file metadata in Lua counts as an expensive parser function. In our wiki's situation it is trivial for us to store this data with Cargo and query it that way instead. Would it actually be more efficient to do it that way? If so, why would that be the case? Phantom Caleb (talk) 18:57, 22 March 2020 (UTC)

I had never heard of this "file" property in Scribunto before, so I can't really say. However, looking at the fields within "file", I'm guessing that at least some of them, like "pages", can't be retrieved through a simple database query, which makes them slower to retrieve. With Cargo, all the data is stored ahead of time, as you noted, so I'm guessing it's faster. On the other hand, maybe these Scribunto properties are labelled as "expensive" simply because they require a database lookup at all, in which case I can't say for sure whether Cargo's approach is faster. Yaron Koren (talk) 22:28, 22 March 2020 (UTC)

It doesn't help that MediaWiki docs are not at all clear on what exactly makes something "expensive". I'll ask around. Thanks :) 184.175.13.217 10:48, 1 April 2020 (UTC)

Fatal exception of type "Error" on Special:CargoTables [RESOLVED]

I upgraded Cargo recently, everything seems to be running correctly, but when I go to the Special:CargoTables page, I get the error: Fatal exception of type "Error", with debugging on, I get:

/Special:CargoTables Error from line 374 of /home/web/mediawiki/extensions/Cargo/includes/specials/CargoTables.php: Call to a member function getLocalURL() on null

Backtrace:

#0 /home/web/mediawiki/extensions/Cargo/includes/specials/CargoTables.php(537): CargoTables->getActionLinksForTable(string, boolean, boolean)
#1 /home/web/mediawiki/extensions/Cargo/includes/specials/CargoTables.php(36): CargoTables->displayListOfTables()
#2 /home/web/mediawiki/includes/specialpage/SpecialPage.php(522): CargoTables->execute(NULL)
#3 /home/web/mediawiki/includes/specialpage/SpecialPageFactory.php(568): SpecialPage->run(NULL)
#4 /home/web/mediawiki/includes/MediaWiki.php(288): SpecialPageFactory::executePath(Title, RequestContext)
#5 /home/web/mediawiki/includes/MediaWiki.php(861): MediaWiki->performRequest()
#6 /home/web/mediawiki/includes/MediaWiki.php(524): MediaWiki->main()
#7 /home/web/mediawiki/index.php(42): MediaWiki->run()
#8 {main}

— Bryandamon (talk)

I upgraded MW and Cargo to the latest versions a couple of days ago and it works fine for me. Incidentally I like the new page but think the icons could do with a legend or other explanation for those using touchscreen who can’t hover over a link. Jonathan3 (talk) 18:02, 14 April 2020 (UTC)

Similar here, I have a few other wikis with the same set-up and this is the only one with issues. This wiki is the only one with multiple-instance templates, not sure if that might be the problem? — Bryandamon (talk) 19:11, 14 April 2020 (UTC)

I'm guessing it's a rather old version of Cargo on that wiki; you should upgrade. Yaron Koren (talk) 01:04, 15 April 2020 (UTC)

It's not too old, 2.5-alpha (e1adfd7) 23:38, 8 April 2020 and oddly the same version of a few other wikis with the same set-up. —Bryandamon (talk) 01:20, 15 April 2020 (UTC)

Oh! Never mind. I should have actually looked at the code. Looking at the code now, my new guess is that there was a template that declared a Cargo table, and the template was deleted but the table wasn't - is that possible? In any case, this is a bug that should be fixed. Yaron Koren (talk) 02:13, 15 April 2020 (UTC)

Possible, but I'm not sure how to check? I checked the database and all the tables (cargo__tablename) are ones I use (including all the field tables, cargo__tablename__extended), I checked cargo_tables and it matched as well (minus the field tables). —Bryandamon (talk) 02:48, 15 April 2020 (UTC)

Alright. Well, I just checked in a fix for this, so if you get the latest code, you at least (hopefully) won't see an error message there. Yaron Koren (talk) 14:07, 15 April 2020 (UTC)

Brilliant, that worked perfectly, thanks Yaron. BTW, I really like the new table overview layout, it really simplifies access to the table information. — Bryandamon (talk) 19:27, 15 April 2020 (UTC)

Cool, I'm glad! Yaron Koren (talk) 19:58, 15 April 2020 (UTC)

Tracking down errors without being a server administrator

Hello!

I would like to request some kind of feature to help tracking down errors in cargo_store / cargo_attach calls. Or if such features already exist where could I find them? :)

When trying to track down errors I've found two main issues:

1. It's hard to find which 3 pages out of several thousand have failed to be recorded in cargo. Some kind of feature to compare the template backlinks with the cargo table page list may be useful.
2. There's no way to find the error message thrown by cargo_store / cargo_attach. Some kind of debugging "Test store to Cargo" command which could output the result (error message or ok) would be fantastic. It could even be a manual call like "Store to Cargo" which would run the whole normal store thing and output the result, it seems like it'd be quite useful.

I know it's possible to find out these things via api calls / error log but those are not user friendly enough (if even available) for me to recommend others use them.

Ypnocsd (talk) 08:59, 18 April 2020 (UTC)

Both of those sound like a good idea. Although trying to store a whole Cargo table without the use of jobs could easily lead to a browser timeout - unless it was restricted to the first 100 rows or something. Yaron Koren (talk) 20:52, 22 April 2020 (UTC)

Recurring Events on Calendar [RESOLVED]

I've been trying to get Cargo based recurring events to show up on a Cargo query with calendar format but haven't succeed. Looking at the Storing a recurring event section, the example shows that the default delimiter is ',' (comma only) but that's not true, testing without declaring a delimiter gives you '; ' (semi-colon and space). There's a note at the bottom to use List (;) of Date, but I think that was based off testing the default delimiter and trying to save a field with that causes Cargo to break (stuck job queue). I think there's two problems:

1. The parser function #recurring_event should be changed so it defaults to ',' (comma only) or perhaps ', ' (comma and space).
2. Cargo needs to be updated to allow List (,) of Date which seems to be more inline with other lists.

I did try to change the delimiter to ',' (comma only) and ', ' (comma and space) with no luck. For the field, List (,) of String was the only one that didn't break the job queue, but also didn't display on the calendar. All of the following seemed to break the job queue: List (;) of Date, List (;) of String, or List (,) of Date
Side question. What date format is Cargo's JS calendar expecting for dates? It looks like 2020-04-22, but if I take a string (or date) with that format and try to display it on the calendar, I can't get it to work. For example, taking a date that is a stored entry and using functions to add a year and display it (e.g. 2021-04-22). —Bryandamon (talk) 17:10, 22 April 2020 (UTC)

Oops, that's a double error! Yes, the default delimiter is a semicolon, not a comma. And there was a bug in the Cargo code (accidentally added in December) that caused storage of lists of dates to fail - I'm guessing that's what you saw as breaking the job queue. Sorry about that. I just fixed the documentation, and checked in a fix for the code as well - so if you get the latest code, everything should work with either a comma or semicolon delimiter. I think a semicolon delimiter is better, because it allows you to include date strings that themselves contain a comma - even though #recurring_event doesn't output commas in the dates, so it doesn't matter that much. If you can try the latest code, please let me know if it works for you.

Yes, the JS expects YYYY-MM-DD. I don't know how you tried to run it yourself - the calendar JS code only reads data from the page Special:CargoExport, and that page in turn is generated by the code. Yaron Koren (talk) 20:45, 22 April 2020 (UTC)

The calendar works now! One weird side effect though, I had a calendar and a list, the list captured a date and the calendar captured yearly (15) occurrences of the date. Previously, the list worked fine but the calendar wasn't working. Now, the calendar shows correctly, but the list is capturing all the recurring dates. The field name for the list is "Birthday" and the field name for the calendar is "Birthday_recurring". Should the names be more different?

Another side question. On the calendar, if I use _pageName for the field and the value is a user page (User:First Last), I get an entry with a link to the user page but it shows as "User:First Last" How can I get it to show "First Last"? Using _pageTitle looks right, but doesn't link (as expected), but if I create a new field and use something like CONCAT( '[[', _pageName, '|', SUBSTRING(_pageName,6),']]' )=Name, I get no link and it looks like [[User:First Last|First Last]] on the calendar. —Bryandamon (talk)

Great! Sorry, I don't know what you mean by "list". Is the problem in the data storage, or the querying? As for your other question: adding "|no html" to the query might help. Yaron Koren (talk) 23:40, 22 April 2020 (UTC)

By list, I mean the display format list, but the same thing is happening with table. Before the fix you just added, the calendar showing birthdays for the next (15) occurrences wasn't working when I was trying to display the field, "Birthday_recurring", but the list or table showing just the actual birthday was (single date). Now the birthday (list or table) is showing (15) occurrences. Actually, I just realized, many fields now show (15) occurrences when queried that have nothing to do with birthday (or dates). The multiple occurrences seems to have leaked beyond the field it's declared. —Bryandamon (talk)

Alright. Do you know if it's a problem with data storage or data querying? If you view the table, it may be easier to find out. Yaron Koren (talk) 00:16, 23 April 2020 (UTC)

It seems to be a problem with querying based off your question. Viewing the table on wiki and in the database shows it's being stored fine. On the template, the consistent part for the ones that are repeated incorrectly are the ones that are queried (#cargo_query:...) vs. just placed ({{{Some field|}}}). Also, just querying this table on any page with any field returns (15) occurrences, other tables are not affected. —Bryandamon (talk) 00:38, 23 April 2020 (UTC)

I have to ask, then: what's the query that's failing? Yaron Koren (talk) 02:35, 23 April 2020 (UTC)

Every query against the table now shows the same amount of repeated data. This only effects the table that contains a recurring event, others tables are fine. So if there are 3 fields in the table:

1. Birthday — Date — {{{Birthday|}}}
2. Birthday_recurring — List (;) of Date — {{#recurring_event:start={{{Birthday|}}}|end=2025-12-31|unit=year}}
3. Foo — String — {{{Foo|}}}

The table looks fine, things are stored as you would assume. Querying any field in the table shows the same amount of repetition as the recurring field has. So, where this query: {{#cargo_query:tables=Table_Name|fields=Foo|where=_pageTitle= '{{PAGENAME}}'|default=}} may have returned: "Bar", now it returns: "Bar", "Bar", "Bar", "Bar", "Bar", "Bar", "Bar". —Bryandamon (talk) 02:57, 23 April 2020 (UTC)

Sorry about that! That was yet another bug, this one in the handling of lists of dates. I just checked in a fix for it, so hopefully that problem will go away. Yaron Koren (talk) 15:56, 23 April 2020 (UTC)

Brilliant, thanks Yaron! Everything seems to be working correctly. —Bryandamon (talk) 16:55, 23 April 2020 (UTC)

Template-less Display Format?

I have been using Extension:WikiDB to manage a course catalog for our school, but am in the process of moving to Cargo because of a few limitations (PageForms, mostly). One benefit of WikiDB, however, is the ability to format the data's display immediately below the query itself within the same template, like this:

WikiDB Query/Display Template

<repeat table="Courses" criteria="{{{1}}}" sort="{{{2}}}">
<h3 style="display:inline;">[[{{{coursename}}}]]</h3> {{{3|<p style="float:right;">{{{teacher}}}</p>}}}
{{{4|
{{{description}}}
}}}
<p style="margin-left:1em;">{{{requiredby}}}</p>
</repeat>

In this way I can use a single template with simple parameters, depending on the page type. (An instructor's page with bio and list of courses, list filtered by discipline, by graduation requirement, etc. all pull from this single template.) The loop is designated by the <repeat> tags.

To achieve an identical result in Cargo, I (think I) need two templates: one for the query, and one for the display:

Cargo Query Template

{{#cargo_query:tables=Courses
|where=Courses.{{{1}}} HOLDS "{{PAGENAME}}"
|fields=Courses._pageName=coursename,{{{3|description,}}}{{{2|teacher,}}}requiredby
|format=template
|template=CourseDisplay
|named args=yes
|delimiter=<br />
}}

Cargo Display Template

<h3 style="display:inline;">[[{{{coursename|}}}]]</h3> <p style="float:right;">{{{teacher|}}}</p>

{{{description|}}}

{{#arraymap:{{{requiredby|}}}|,|x|<p style="margin:0 0 0 1em;">[[x]]</p>|}}

Because other Cargo display formats return the data immediately below the query, is it possible to achieve this templated-display with Cargo immediately below the query? I can share live versions of both if it would clarify things. Thanks so much for all of your work on this!--JStallings29 (talk) 15:53, 25 April 2020 (UTC)

I'm not sure what you mean by "below the query", but using format=template does seem like the correct way to do this kind of display in Cargo. Yaron Koren (talk) 13:14, 26 April 2020 (UTC)

If I want to return rows in a table format in Cargo, I believe I only need one template containing the query, and your code does the rest. Then, I can transclude that template into any page (or even embed it into the page's template) and return a table. I can also hide certain columns within that query with parameters. But, if I want to return data in a format not available, such as the Cargo Display Template and its HTML tags above, I need to call a separate template to achieve that format. I wonder if it would be possible to include the display template code directly below/within the query in the same code/template, like the WikiDB example above with its query:

<repeat table="Courses" criteria="{{{1}}}" sort="{{{2}}}"> ... </repeat>

and format:

<h3 style="display:inline;">[[{{{coursename}}}]]</h3> {{{3|<p style="float:right;">{{{teacher}}}</p>}}}

in the same template.

I pull from the "courses" table often throughout the site, but rarely need all of the same columns. It seems like I need to write a separate query and template if I need to, say, hide the teacher's name, which I could do with parameters that default to null if I were only using one template. I appreciate your time with this.--JStallings29 (talk) 16:30, 26 April 2020 (UTC)

No, you can't put the display code below the query; #cargo_query both queries and displays results. Yaron Koren (talk) 18:39, 26 April 2020 (UTC)

#cargo_store a value obtained through #cargo_query?

I have two entities, "organization" and "branch". An organization has a numerical ID, and a branch is linked to an organization using that numerical ID. I'm trying to also store the organization name in each "branch" row, by querying the "organization" table. I've tried the following:

{{#cargo_store:
_table = branch
|organization_id={{{ID|}}}
|organization_name={{#cargo_query:
tables=organization
|fields=_pageName
|where=organization_id={{{ID|}}}
|default=
}}
}}

However, what is stored in the table is the parser placeholders, such as ?`UNIQ--item-2--QINU`.

Is it possible to do this?

I don't think storing a query result as its own value is ever a good idea; hopefully it's not necessary, since you can do joins and the like. However, to answer this specific question: I'm guessing that adding "|no html" to the #cargo_query call will fix the problem. Yaron Koren (talk) 00:48, 28 April 2020 (UTC)

Thanks, Yaron! That definitely worked, and I have no idea how I missed it in the (extensive) documentation. You're right that it's not the best solution, but I'm working within some constraints right now, and I need a quick and dirty solution. Thanks again! FFS ^Talk 08:25, 28 April 2020 (UTC)