Extension talk:Cargo

[SOLVED] Show all items from yesterday and today, but at least three items from any date
I'd like to do a Cargo query that will:
 * return all items dated "today/yesterday" (maybe 10 or so, depending on the day)
 * if the above would return fewer than 3 results, display older results to make up the number.

I wonder whether I need something like

where the second query returns the max of 3 or the number of items from today/yesterday.

If I find time to work it out then I'll put it here. Otherwise I'd be grateful for any pointers.

Thanks. Jonathan3 (talk) 00:15, 25 January 2021 (UTC)


 * With logic that specific, I would think the only real way to accomplish it is with the Scribunto extension... Yaron Koren (talk) 16:02, 25 January 2021 (UTC)


 * Challenge accepted :-) Jonathan3 (talk) 17:03, 25 January 2021 (UTC)


 * I seem to have got this to work:




 * Hopefully I've included all the relevant parts above. Jonathan3 (talk) 21:52, 25 January 2021 (UTC)


 * Impressive! Does that really accomplish the full set of criteria? Yaron Koren (talk) 15:13, 26 January 2021 (UTC)


 * Thanks. Yes - it does what I wanted it to, as far as I can tell - though maybe I didn’t set it out perfectly above. Jonathan3 (talk) 15:29, 26 January 2021 (UTC)

Cargo and PostreSQL Port
I upgraded from MW 1.31 to MW 1.35 (1.35.1 (13dc141)) and Cargo is also the latest version (2.7.1 (28b4351)). I'm connecting to PostgreSQL 12.4 (Debian 12.4-1.pgdg90+1) with a custom Port set in the LocalSettings.php. The Mediawiki is correctly connecting to it! But it seems Cargo doesn't respect this setting because I get the following error message when I do a query:

Cheers and thank you Brabi81 (talk) 11:08, 26 January 2021 (UTC)


 * Found a fix that worked for me. Hardcoded the port in the open function in the includes->libs->rdbms->database->DatabasePostgres.php of MW. It seems that $this->port is not correctly set or something like when called from Cargo (it returns 0 ...). Brabi81 (talk) 13:36, 1 February 2021 (UTC)


 * I didn't know about that variable before. I just checked in a fix so that the $wgDBport value gets used with Postgres databases. Ideally there should also be a $wgCargoDBport variable as well, but that doesn't exist yet. Yaron Koren (talk) 17:10, 18 February 2021 (UTC)


 * The fix works as expected. Now I can remove that part again :) Thanks alot! Brabi81 (talk) 07:09, 19 February 2021 (UTC)

Table can't be created because it was "not declared" despite being declared
On our client's wiki, they have made a template and declared a table at Template:Factory, but the Create/Recreate data tab doesn't appear on the page. Manually navigating to it leads to an empty page.

Then we tried running  to no avail.

Is there a specific maintenance script that we need to run in order to fix this issue? We've already tried running update.php and runJobs.php.

Thank you in advance,

--MyWikis-JeffreyWang (talk) 09:57, 29 January 2021 (UTC)


 * This is very strange. The empty page is actually fine, in a sense - it just means that Cargo doesn't think that template contains a #cargo_declare call. (The display should obviously be better - right now it always does look like an error.) Yes, the template page says that the table is defined, but that's a separate set of code from the code that really determines whether the table has been declared. I don't know why it's failing, though. It might because the table name is lowercase, though I doubt it. I would recommend trying to re-save the page a few times (with at least a small change every time) - maybe it's just a temporary glitch. Yaron Koren (talk) 16:14, 29 January 2021 (UTC)

Cargo Order by
I upgraded from MW 1.31 to MW 1.35 (1.35.1 (13dc141)) and Cargo is also the latest version (2.7.1 (28b4351)). Same as above on a PostgreSQL Database. Another "bug" is now visible that I didn't saw immediately. It now makes a difference in the ordering of the fields for the "Order by" clause. I.e. if a query has the fields:

it will NOT get sorted by

Whereas if I rearrange the fields order to

it will be sorted as expected with

I'm totally sure that this was working in the old MW 1.31 Version I was running. Cheers Brabi81 (talk) 11:32, 15 February 2021 (UTC)


 * There was definitely a problem with the handling of ordering in Cargo; I think it was actually fixed a few weeks after the version you have now. If you get the now truly latest version of the code, this problem will hopefully go away. Yaron Koren (talk) 23:00, 15 February 2021 (UTC)


 * Okay my fault ... With the Verison  this problem doesn't exist anymore :) Sorry and thanks. Brabi81 (talk) 07:36, 16 February 2021 (UTC)

Search form [SOLVED]
What's the best way of adding a search form that would allow the user to add text, ideally with autocomplete?

For instance, with the book example:

Date: [...........]

Author: [..............]

Title: [...........]

I suppose the form should end up on the relevant Drilldown page. Thanks. Jonathan3 (talk) 22:54, 24 February 2021 (UTC)


 * Could you explain this desired interface in more detail? I don't understand how you can have searching and editing at the same time. Yaron Koren (talk) 19:42, 25 February 2021 (UTC)

Sorry, ignore “add text” - I just meant the user would type search terms into the form. Jonathan3 (talk) 20:09, 25 February 2021 (UTC)


 * Oh, I get it. You should use the Page Forms extension - see Creating query forms. Yaron Koren (talk) 22:23, 25 February 2021 (UTC)


 * Sorry - I'd seen that ages ago and forgotten. Can it do autocomplete on Cargo fields or is that really a question for the PF page? Thanks Jonathan3 (talk) 23:09, 25 February 2021 (UTC)


 * That's a PF question, but yes. Yaron Koren (talk) 23:12, 25 February 2021 (UTC)


 * Thanks again. Jonathan3 (talk) 23:36, 25 February 2021 (UTC)

[SOLVED] Create an on-wiki to do list
I'd quite like to have a to do list on my wiki and have buttons/links beside each item:
 * Edit the item (simple enough - link to the PF form).
 * Mark the item as done.
 * Delete the item entirely. This could link to the  page but could it be done without that intermediate step?

Would this be possible? Thanks.

Maybe the answer instead is just to display the items as a normal list (from a to do list Cargo table) on the page, and to use Special:MultiPageEdit for marking as done or deleting. Jonathan3 (talk) 23:35, 25 February 2021 (UTC)


 * These again sound like Page Forms questions. Yaron Koren (talk) 02:05, 26 February 2021 (UTC)


 * Thanks. I'll ask on the talk page there. Jonathan3 (talk) 10:47, 26 February 2021 (UTC)

[SOLVED] Order by date when some dates are Month/Year and some are Year
If I use the MySQL  in Cargo's   parameter, I think   orders it alphanumerically rather than by date.

Do I need to use the date as it comes from the database (which I think has defaults to 1/Jan for blanks) - and the  field in a template to work out whether to display MMM YYYY or just YYYY?

Thanks Jonathan3 (talk) 10:16, 1 March 2021 (UTC)


 * I've tried and  works, but I wondered whether there is another way. Jonathan3 (talk) 10:24, 1 March 2021 (UTC)


 * "__precision" is the way to go, yes. Yaron Koren (talk) 14:20, 1 March 2021 (UTC)


 * Great, thanks :-) Jonathan3 (talk) 14:44, 1 March 2021 (UTC)

[SOLVED] Use date's __precision field within _drilldownTabs parameter for Special:Drilldown
Is this possible? When I try (for a field called Date)  or just   I get an error. I could turn on debugging to tell you what error, though it might be something already known not to work. Thanks. Jonathan3 (talk) 22:33, 1 March 2021 (UTC)


 * Why would you want that? Yaron Koren (talk) 23:28, 1 March 2021 (UTC)


 * For a template that distinguishes between dates with month/year and dates with only year. Jonathan3 (talk) 23:32, 1 March 2021 (UTC)
 * Cancel that - the standard "Table" tab works fine for dates like that. Sorry. Jonathan3 (talk) 00:04, 2 March 2021 (UTC)

Formatting for "more results text"
I'm able to format "default" text but not "more results text".

Produces:


 * ''No results

Whereas

Produces:

*''More...'

Where am I going wrong? Thanks. Jonathan3 (talk) 13:54, 23 March 2021 (UTC)


 * I read 'added parsing of "intro", "outro" parameters of queries' in the version history] for Cargo 2.8 today. I wonder whether you could do the same for "more results text"? Would that solve the problem here? Thanks. [[User:Jonathan3|Jonathan3 (talk) 21:34, 14 April 2021 (UTC)


 * Sorry, I forgot about this request. Yes, probably. Yaron Koren (talk) 23:09, 14 April 2021 (UTC)

Error: 'Table "..." is not declared in any template.'
I just deleted a template and our nightly cron that calls cargoRecreateData.php now throws an error 'Table "..." is not declared in any template.' I searched the talk page for this extension and it turns out I asked about this before: Extension_talk:Cargo/Archive_August_to_October_2019. The solution Yaron suggests in there works. I just wonder if it would be possible to update the error message to provide the info how to solve this. E.g. change "'Table "..." is not declared in any template. If the template was deleted and the table is no longer needed it can be deleted in Special:CargoTables.' Or something like that that sends the user off in the right direction. Thanks! Tenbergen (talk) 16:09, 23 March 2021 (UTC)


 * Clearly I needed a reminder. :) I just checked in a fix, so that the message is only printed in non-"quiet" mode. By the way, I wouldn't really call it an error message, and I wouldn't say it gets "thrown" - it's just a line that's printed on the screen. I changed the message slightly, so now it reads "Table "..." is not declared in any template; skipping.". I don't think all that instruction is needed, because this is not necessarily an error, from the perspective of this script; it's just a table that the script can't handle. Yaron Koren (talk) 22:30, 23 March 2021 (UTC)

List of Strings and commas
Hello! First of all, I would like to thank you for this incredible extension, it's helping me so much. And I'm not an expert in Cargo, so sorry for my noob-ness.


 * I have a query in a template and one of the declared values is a . The thing is, when I use this query with another table (using other fields as well), the list of strings doesn't show the delimiter (it shows ItemA,ItemB,ItemC... instead of ItemA • ItemB • ItemC...). Is there a way I can make this work with the delimiter? Using   doesn't work (on the query) doesn't work as well, it doesn't even show the links for some reason.
 * Another question: is it possible to set each item on a list of string to be a value on a template? Let's say I have two queries, one of them with simple and plain fields, and other querying a list of string. On the list, each item would use a parameter on the template. So Row1 has just ItemA, so in the template the parameter will be set to ItemA, Row2 has ItemA and ItemB, so in the template there would be two of the parameters, one with ItemA and the other with ItemB, etc.

Sorry if it's confusing. :P &mdash;Lakelimbo (talk) 16:47, 23 March 2021 (UTC)


 * You could probably use Extension:Page_Forms/Page_Forms_and_templates to solve both problems. Jonathan3 (talk) 20:58, 23 March 2021 (UTC)

Tabs for _pageData and _fileData Drilldown tables
Is is possible to add tabs for these tables? I'd like to add a custom tab. Jonathan3 (talk) 22:59, 23 March 2021 (UTC)

[SOLVED] Error on full text search using " or ' characters
When I search for  on Special:Drilldown/_fileData it lists 5 results, fine.

When I sarch for  (or anything like   it correctly states "Showing below up to 5 results in range #1 to #5." but then


 * A database query error has occurred. Did you forget to run your application's database schema updater after upgrading? Query: SELECT `_fileData_alias`.`_pageName` AS `_pageName`,`_fileData_alias`.`_fullText` AS `File text` FROM `wm_cargo___fileData` `_fileData_alias` WHERE MATCH(_fileData_alias._fullText) AGAINST ('" IN BOOLEAN MODE) needle"' ORDER BY _fileData_alias._pageName,_fileData_alias._fullText LIMIT 250 Function: CargoSQLQuery::run Error: 1064 You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near 'ORDER BY _fileData_alias._pageName,_fileData_alias._fullText LIMIT 250' at line 1 (localhost)

Should I just upgrade to the latest Cargo or is this an known problem? Jonathan3 (talk) 23:10, 23 March 2021 (UTC)


 * I've just upgraded but it's the same. Jonathan3 (talk) 23:28, 24 March 2021 (UTC)

P.S. If the answer is "There are no results for this report." then there is no error shown (e.g. searching for . Jonathan3 (talk) 00:04, 24 March 2021 (UTC)


 * Sorry about that; there was a problem with Cargo's parsing of "MATCHES" queries. I just checked in an improvement; the parsing is still not perfect, but this query, at least, should work now. Yaron Koren (talk) 15:19, 8 April 2021 (UTC)


 * Thanks. The query (using double quotation marks around a phrase) now works without any errors, but the "results in context" shows seemingly random text (instead of showing some words before/after the emboldened search term). Jonathan3 (talk) 16:18, 8 April 2021 (UTC)


 * How strange! I looked into it - Cargo uses MediaWiki's own code to find the "search context", and by default the MW code is pretty bad, apparently for performance reasons. If you add the line "$wgAdvancedSearchHighlighting = true;" to LocalSettings.php, it works a lot better. Maybe Cargo should be changing the value of this variable; I'm not sure. Yaron Koren (talk) 16:37, 8 April 2021 (UTC)


 * I changed Manual:$wgAdvancedSearchHighlighting to true and it started to work properly! Thank you. This is something that could be noted in the Cargo manual somewhere. Jonathan3 (talk) 08:57, 9 April 2021 (UTC)

[SOLVED] Context of full text search term in query
On the Drilldown page there is a nice feature in which the words surrounding the search term are shown.

Is it possible to replicate this in a #cargo_query? Thanks. Jonathan3 (talk) 23:12, 23 March 2021 (UTC)


 * Sorry for the delay. This is already done by default for queries that use the MATCHES keyword - see here. Yaron Koren (talk) 20:14, 29 March 2021 (UTC)


 * That's great, thanks. Jonathan3 (talk) 16:18, 8 April 2021 (UTC)

[SOLVED] Ability to search full text for phrase rather than separate words
Currently if you search for Joe Bloggs, you'll get pages with Joe and pages with Bloggs. Is it possible to restrict it to the exact words "Joe Bloggs"? I guess if the error with the quotation marks gets fixed it might allow for this - would that be right? Thanks. Jonathan3 (talk) 23:33, 24 March 2021 (UTC)
 * Yes. Yaron Koren (talk) 15:20, 8 April 2021 (UTC)


 * Thanks. But see the problem with the lack of "context" results mentioned in the topic above this one. Jonathan3 (talk) 16:19, 8 April 2021 (UTC)

Unable to get Drilldown working
I'm struggling to get the Drilldown function working. I have a table with data in it, but every filter but one shows "(There are no values for this filter)". The SQL query executed by Cargo that returns no results is:

For the only filter that appears to work, the  clause is omitted, and, indeed, the above query returns values when the   clause is removed.

Perhaps related:   recreates the table just fine, but clicking the "Recreate data" button from the template page returns a replacement table with 0 rows.

What am I doing wrong?

Thanks so much!


 * What version of Cargo are you running? Yaron Koren (talk) 14:47, 4 April 2021 (UTC)


 * Sorry -- Cargo 2.7.1, Mediawiki 1.34.0 (but the problem first manifested with Cargo 2.5, and I upgraded to the latest version as part of my efforts to debug). php7.3 and a PostgreSQL backend in case that might be relevant.  Any hints where I should be looking?  Thank you!  Wilo108 (talk) 16:02, 4 April 2021 (UTC)


 * I have no idea - I haven't heard of that particular problem happening before. I'm guessing that it's somehow due to the use of PostgreSQL, but I'm not sure about that either. What are the other queries getting called? There should be various queries, not just that one. Yaron Koren (talk) 20:52, 4 April 2021 (UTC)


 * hmm, that's concerning. There are other queries, but none of the cargo queries are being logged when using   or in the debug toolbar, so I've been writing   to a debug log directly in an attempt to work out what's going on.  I'm also seeing problems with simple queries like


 * failing because (e.g)  isn't qualified or quoted, so PostgreSQL throws  .  (Query works fine when quoted appropriately and executed directly against the PostgreSQL server.)  Aggregating queries that use   also return empty columns, but the same queries generate the expected results when executed directly against PostgreSQL (my development server is running PostgreSQL 11.11 on Debian 10.9, fwiw.)
 * Has there been any testing with PostgreSQL? Would I be better just seeing if I can get this moved to MySQL/MariaDB?


 * That's pretty bad. Testing on PostgreSQL has been quite limited; I haven't tested directly on it in a long time, so testing is basically confined to whatever bugs people report (I do try to fix whatever bugs I hear about). Switching to MySQL would most likely get rid of these problems in the short run, though, yes. Yaron Koren (talk) 15:18, 5 April 2021 (UTC)


 * Okay, no worries. Do you have a bug tracker somewhere, or is this it?  Also, what's the state of the test suite?  I'm not really a php guy, but migrating this to MySQL/MariaDB properly looks like it will take more work than I'd first imagined (doable, but not trivial by any means), and if that time could be better spent fixing SQL queries so that they execute properly against PostgreSQL... Wilo108 (talk) 16:53, 7 April 2021 (UTC)
 * There is a bug tracker of sorts on the Wikimedia Phabricator; see here. The testing code for Cargo is pretty limited; just some unit tests. I don't think any of them involve DB operations, unfortunately. I do want this problem to get fixed, one way or another. Yaron Koren (talk) 02:09, 12 April 2021 (UTC)
 * Just to update on this: I converted my installation to MySQL (it was a pretty gnarly process), and the Drilldown still doesn't work :(  Regular querying of data does now work as advertised, however :) Wilo108 (talk) 05:56, 28 May 2021 (UTC)

Irrelevant results and $wgAdvancedSearchHighlighting
I set Manual:$wgAdvancedSearchHighlighting to true, which fixed a problem above where search terms within double quotation marks were not highlighted in Cargo "MATCHES" results.

Strangely, it leads to another problem.

I've got a Cargo query which joins a normal Cargo table, the _pageData table, and the _fileData table (joined when the filename matches a File field in the normal Cargo table).

I use it to search both _pageData._fullText and _fileData._fullText for the search term.

In a situation where the search term is found in the file but not the page, the term is highlighted in the _fileData._fullText cell but:


 * With $wgAdvancedSearchHighlighting = false, the _pageData._fullText cell in the results table is blank (as expected)


 * With $wgAdvancedSearchHighlighting = true, the _pageData._fullText cell in the results table irrelevantly contains the first part of the Cargo template call's wikitext (|Field=contents|Field=contents etc).

Is there any way round this? Thanks. Jonathan3 (talk) 09:16, 9 April 2021 (UTC)


 * P.S. When the search term is found in both the page and the file, the correct parts are highlighted for each.


 * And when the search term is found in the page but not the file, the _fileData._fullText cell is blank (as expected). Jonathan3 (talk) 09:18, 9 April 2021 (UTC)

Fixing the plaintext image HTML glitch without disabling ConfirmEdit?
Hi! So I’m aware this is an issue that has been addressed before a couple of times (here and here) and I’m also aware that it seems to be linked to the extension ConfirmEdit. However, I’d prefer not to disable that extension if I can help it. Is there no other way to fix this issue? (And yeah, I’m aware the second link included a lua workaround, but... well, I can’t understand lua, so.) --Kiwibasket (talk) 20:20, 10 April 2021 (UTC)

Empty string vs NULL
Has something changed recently with how Cargo is handling an empty string? We've noticed some odd behavior in a lot of our queries that were looking for empty strings now seem to want NULL instead. We can modify the queries if need be, but wanted to make sure something hadn't gone amiss from the extesnion side itself.


 * Nothing has changed recently on purpose related to that, though of course things could have unintentionally changed. What version did you upgrade from, and to? Yaron Koren (talk) 02:20, 19 April 2021 (UTC)


 * I don't have any saved queries that this affects but noticed this last week that I had to use IS NOT NULL where before I'd have checked for "". I upgraded to the latest Cargo version in the last couple of weeks. Jonathan3 (talk) 07:49, 19 April 2021 (UTC)


 * We are currently on 2.7.1 (d31ffcc) 06:35, 31 March 2021. To be honest, I'm not sure what version we came from. Gee Barger (talk) 23:46, 25 April 2021 (UTC)

Map tab error when drilldown with a Coordinates field
I am using MW 1.35 with Maps 8.0.0 and a new installation of Cargo 2.8. I defined a table with 3 fields, 2 "String" and 1 "Coordinates", without customization of the drilldown. The drilldown page then displays correctly with the 2 "String" fields, but clicking on the "Map" tab gives a PHP error : Are there compatibility issues between Cargo and Maps, or is this another problem ? --Emmanuel Touvier (talk) 12:41, 20 April 2021 (UTC)


 * If it helps I've had the same problem for months using Mw1.34 and without the Maps extension, with previous versions of Cargo (around the time of MW1.34?) and the current latest code. I can set up debugging on the computer later and see if it's a similar error message. Jonathan3 (talk) 13:09, 20 April 2021 (UTC)


 * I looked into it tonight and worked out what was causing me the problem. In the template page I had . Type is a List  of String. I had wanted it to appear below the Page name the way it can do in normal queries. Anyway, the error message on the Drilldown page was  . When I changed the template to remove reference to the Type field (i.e.   the error disappeared. I'd still like to be able to have the Type field appear on the map but at least now the map appears instead of the error! Anyway, this is probably entirely separate from the original question here, sorry. Jonathan3 (talk) 18:53, 20 April 2021 (UTC)

Special:Drilldown and full text search
If use the "Full text" field AND another field (say, type of document), I'd expect it to "drill down" by showing me the results for the relevant type of document which contains the relevant words. Instead it shows me all everything that either contains the relevant words OR is the relevant type of document. Strangely, though, in the "Showing below up to 1 result in range #1 to #1" sentence it does show (what I could consider) the correct number of pages - the problem is that the results tabs show more than that.

This problem seems to be to do with the "Full text" search. When a combination of other filters are used, the results show show pages where field1 AND field2 AND field3 are of the selected values. Can the "Full text" behaviour be changed? Jonathan3 (talk) 08:28, 24 April 2021 (UTC)

[SOLVED] Potential bug relating to coordinates fields in CargoMapsFormat.php
I'm running Manual:RefreshLinks.php (because a page just wouldn't go into a category...) and am getting stacks of the following:

is the name of a coordinates field in one of my Cargo tables.

My initial idea of what's wrong was itself wrong so I've deleted it from here... but what's up? Thanks. Jonathan3 (talk) 21:29, 25 April 2021 (UTC)

Maybe it's just happens for pages without any value in the Coordinates field. Anyway, everything seems to work. Jonathan3 (talk) 22:20, 25 April 2021 (UTC)


 * I have 24 rows in that table with no value for the Coordinates field and there are 24 sets of the two errors above. Jonathan3 (talk) 19:04, 26 April 2021 (UTC)


 * I just checked in a fix for this. Yaron Koren (talk) 20:56, 26 April 2021 (UTC)


 * Thanks - I ran refreshLinks.php again and there weren't any errors. Jonathan3 (talk) 22:37, 26 April 2021 (UTC)

[Solved] Formatting tables
Is there a way to have a "non-dynamic" table? In looking over the display format page there seems to be two output formats, table and dynamic table. I don't see how to specify table, and all my tables are "dynamic."

I'm new at this wiki editing, so I'm not sure how to enter the code correctly below, but here is my query:

What am I missing?


 * That code looks fine. Are you sure the resulting table is "dynamic"? What does it look like? Yaron Koren (talk) 01:00, 27 April 2021 (UTC)

I apologize in advance if I don't respond on this page correctly--I didn't see any instructions, so I assume editing the thread is correct. This wiki is a public wiki, so you can see for yourself. Let's see if I can put a link here: http://wiki.martenet.com/index.php/Charles_L_Carson The table there listing the buildings looks dynamic to me. Am I looking at something wrong?


 * You're doing fine with the editing. No, that's just a regular table, not a dynamic table. I mean, it's dynamic in the sense that it's sortable, but it's not the "dynamic table" format. Do you want to turn off sorting capability? Yaron Koren (talk) 01:47, 27 April 2021 (UTC)

Yes, actually. I'd like a barebones table. Is that not an option?


 * Not really, no. I don't know if anyone has asked to turn off sorting before... you can do it by adding "merge similar cells=yes" to the query, but that will merge similar cells, which is not quite a barebones table either. Yaron Koren (talk) 14:16, 27 April 2021 (UTC)


 * You could add this to MediaWiki:Common.js




 * It's not ideal as flashes up the sorting stuff before it disappears, and applies to all Cargo tables on your wiki, but it might do. Jonathan3 (talk) 22:11, 4 May 2021 (UTC)
 * worked like a charm. Thanks. --Parma100 (talk) 00:29, 12 May 2021 (UTC)

[Solved] Table position
How can I get a table centered on the page rather than left justified. I tried the following

  

(And my html tags are not showing up on this page, but I'm wrapping the query in a div and then styling the div with "margin: 0 auto.")

But it has no effect. Is something internal overriding it?


 * I don't think so. Try different CSS, maybe - I don't think a margin of 0 will cause something to be centered. Yaron Koren (talk) 01:01, 27 April 2021 (UTC)


 * Try putting this in MediaWiki:Common.css:




 * Jonathan3 (talk) 10:37, 2 May 2021 (UTC)
 * That worked! Thanks. --Parma100 (talk) 00:29, 12 May 2021 (UTC)

[SOLVED] Run Query:xxx with one value gives results, with another one nothing is returned
I have a query "Run query: Map for Activity" looking for places linked to certain activities. If I select e.g. activity "Tango" I get the desired results, if I select activity " Ski" nothing comes up.

When I execute similar queries under "Special Pages" "Cargo query" however, both give the desired results.


 * It sounds like the problem is with either the template or the form, then. I would try calling the template directly, with these values, to try to figure out which of the two it is. Yaron Koren (talk) 13:07, 30 April 2021 (UTC)


 * Thank for your assistance Yaron. I'm afraid it was related to improper characters (ë, â) in some of the Place names.

The problem disappeared when I corrected the character set for the imported data.

[BUG?] Recategorisation and _pageData table
I have a feeling that when the Replace Text extension has been used, the pages disappear from the _pageData table, or at least the pages don't show up on Cargo queries on that table. I haven't tested this out though, but can do if you think it would be useful. Jonathan3 (talk) 08:48, 1 May 2021 (UTC)

I've had a think again. I was using Replace Text to recategorise pages. I then recategorised some remaining pages manually (by editing the page) which had the same effect. I don't think it's to do with the Replace Text extension after all.

I think what's happening is this. Page X is in categories A, B, C and D. I replace. Cargo now realises that page X is in category E, but has forgotten that it's also in categories B, C and D. _pageData._categories only contains "E". I am 99% sure of this from what I've seen of the effects of recategorisation, though I've not yet tried to reproduce it deliberately. Jonathan3 (talk) 09:15, 1 May 2021 (UTC)

A further observation. Page X again is in categories A, B, C and D. If I remove (talk) 09:39, 1 May 2021 (UTC)


 * It's true that categories are handled differently from all the other fields within _pageData - that's because MediaWiki does category setting via jobs, so it doesn't happen instantaneously on page save. I don't know what's happening with this particular bug, though. Does it only happen when the page is modified via Replace Text? Yaron Koren (talk) 03:55, 3 May 2021 (UTC)


 * I've had a look using the query below, and changing the categories to see what it says.


 * When the job queue is empty, it works fine. When I add/remove/edit a category, the query prints the correct sentence as soon as the page is saved.
 * When the job queue is not empty (e.g. when I edit a template) it does not work but, instead, does as described above.
 * Then, even when the job queue is empty again after running runJobs.php, it still doesn't "catch up" and show the correct categories, even when the page is purged. At that stage, I need to recreate the _pageData table, or (unrealistically) remove the category definitions, save the page, add them back to the page, and save the page again.
 * I don't think Replace Text is relevant except that it fills up the job queue, which in turn stops Cargo from working properly. Jonathan3 (talk) 06:54, 3 May 2021 (UTC)
 * I don't think Replace Text is relevant except that it fills up the job queue, which in turn stops Cargo from working properly. Jonathan3 (talk) 06:54, 3 May 2021 (UTC)

I've had a think about this. The following code in CargoHooks.php, function addOrRemoveCategoryData, called by the CategoryAfterPageAdded or CategoryAfterPageRemoved hooks, is trying to get the page's existing categories from the _pageData table:

When the job queue is not running, it works fine, and returns an array of the page's categories from the _pageData table. The next parts of the code either remove or add the new category to that array.

When the job queue is running, it returns an empty array even when the _pageData table contains the correct categories information. This in turn leads to the problems described above: (1) when you add a category, it ends up being the only category in the Cargo table; and (2) when you remove a category, there end up being no category in the Cargo table.

Maybe I should add that I have  and run the job queue as a cron job and/or at the command line. The problem seems to appear when runJobs.php is running (not merely when there are jobs in the queue). Jonathan3 (talk) 22:11, 7 May 2021 (UTC)


 * I think maybe it's getting the wrong $rowID (i.e. one which doesn't yet exist in the _pageData table). Jonathan3 (talk) 22:40, 7 May 2021 (UTC)


 * OK here is my last guess for now. I'm filling the job queue by making a minor edit to a Cargo template. Maybe while the job queue is running, the _ID in _pageData for the pages (or at least the page in question) changes... when the code above wrongly gets an empty array the _ID has increased by 2... this'll be why when the code above looks up the _ID there is nothing in _pageData__categories... if you look in the database, the old orphaned _rowID rows remain in _pageData__categories. Maybe the answer is to work on a replica database for both queries, or turn them into a single query using a join, then when updating use the real database having checked for any new row ID. Or don't let the the _ID in _pageData for the pages ever change. Jonathan3 (talk) 22:59, 7 May 2021 (UTC)


 * Having slept on it, it's clear that it's getting the correct (new) row id for the page data table but it's not matching up with the same row id in the categories full table (which still has the old row id).


 * There's a function that stores page data but ignores categories. I think it deletes the page data table row before recreating it. Maybe this is when the row id changes? Maybe instead of ignoring categories it should at least ensure the categories full row id matches the page data row id? Jonathan3 (talk) 07:41, 8 May 2021 (UTC)

Maybe the _rowID of _pageData___categories should be the page's ID (which stays the same even when a page is moved) instead of being _pageData's _ID field (which seems to change sometimes). Otherwise you'd need to keep them in sync somehow in the Cargo code. Jonathan3 (talk) 15:11, 8 May 2021 (UTC)

Stream of consciousness collapsed......................................................................


 * There's a lot to go over here. Could it be that the main _pageData storage code (called by the PageSaveComplete hook) is being called after the category info storage code (called by the two hooks you listed before)? If so, that would definitely explain what you're seeing - and if that's the case, I can't think of any way around it at the moment. Yaron Koren (talk) 18:03, 12 May 2021 (UTC)


 * More stream of consciousness...


 * Might it be the other way round? Basically addOrRemoveCategoryData checks a page's _pageData._ID row and associated _pageData__categories._rowID rows - but sometimes (caused by the job queue running) by the time it does that the page's _pageData._ID has changed and the _pageData__categories._rowID has not. So it gets the correct, new _pageData._ID but can't use it to obtain anything from _pageData__categories because _ID is no longer equal to _rowID. It then bases the add/remove on an empty array (or once, I think _ID coincided with an orphaned _rowID with category rows, so instead of an empty array it was just completely wrong).


 * Possible alternative solutions might be:
 * Use _pageID as the link between _pageData and the _pageData__categories rows (e.g. either set _ID=_pageID and _rowID=_pageID, or just set _rowID=_pageID and change the code) as _pageID (I think) rarely/never changes.
 * When onPageSaveComplete deletes the _pageData row it should either:
 * keep a record of the _ID/_rowID and send it to storeValuesForPage so that if _ID changes so does _rowID and the _pageData__categories rows therefore continue to be linked with the newly-created _pageData row.
 * delete the _pageData__categories rows too, and storeValuesForPage/storeAllData should recreate those rows from the MW database.


 * Jonathan3 (talk) 21:47, 12 May 2021 (UTC)


 * That seems implausible to me, though maybe I haven't thought about it enough. I still like my theory - do you think it could be right? Yaron Koren (talk) 02:13, 13 May 2021 (UTC)


 * I'm not sure. Which is the implausible part? I don't know what in the job queue changes the _ID (could be something odd about my wiki) but I did some debugging and the logs show the other stuff happening (changed _ID and unchanged _rowID wrongly getting empty array). I gave up when I couldn't fix it so wasn't 100% thorough though. Jonathan3 (talk) 06:34, 13 May 2021 (UTC)

Duplicate rows again
Did we ever get to the bottom of what causes duplicate rows?

I've just run the following query:

It showed four pages which had two rows each. Doing a null edit (edit and save with no change) gets rid of a duplicate row. Purging the page does not.

It would be good if Special:CargoTables would identify whether a table has duplicate rows.

Alternatively, can you suggest an improved Cargo query that identify duplicate rows across various tables on a wiki? Maybe using Scribunto (which I downloaded this week...)

Maybe I should do it with plain PHP and get it to email me when it finds duplicates.

Or maybe the answer is to run the various recreate table scripts nightly?

I'm using MW1.34 and Cargo code from about a week ago.

Thanks. Jonathan3 (talk) 21:52, 4 May 2021 (UTC)

I've put that query (modified to make it look nicer) into a template, and notice that in each table, the pages with duplicate rows are mainly pages I've not even looked at for ages, and also that there are never more than two identical rows. Jonathan3 (talk) 22:00, 4 May 2021 (UTC)

To contradict something above, a file I uploaded tonight appears on the list now... every time I edit the File: page the count (of rows) increases by one... Jonathan3 (talk) 22:51, 6 May 2021 (UTC)

Do you think maybe the duplicate rows thing could be linked with the recategorisation problem? E.g. a List's __fieldname rows get orphaned when their _rowID no longer is the _ID of its main table, so a proposed new main table row has an incorrect fieldname__full field which means that the "is this a duplicate row?" check wrongly thinks it's different. I've recreated all my tables recently so can't check... Jonathan3 (talk) 20:29, 8 May 2021 (UTC)

Disable storing on User namespace
Hello again!

So, as the header suggests, I'm trying to find a way to disable  and   on the User namespace, is that possible? Currently I have some very important templates with a lot of data, and would be very awkward to query the pages and randomly there's rows with junk data.

I think it's possible to disallow certain templates to be rendered with AbuseFilter, but I'm not sure if there's another way or if that will work for most of the time. Unfortunately, I can't guarantee that all users will respect the rules by just throwing an alert.

Thanks! Lakelimbo (talk) 20:02, 5 May 2021 (UTC)


 * I don't think there's a way to automatically disable #cargo_store for certain namespaces... I suppose you could use #if and the variable to only call #cargo_store for certain namespaces. Or you could check the namespace in the query, like "where=_pageNamespace != 2". Yaron Koren (talk) 20:15, 5 May 2021 (UTC)
 * I see. Could you take this as a suggestion, then? Would be awesome if we could just simply turn off any storage of data on specific namespaces. Thank you! Lakelimbo (talk) 01:54, 6 May 2021 (UTC)


 * Why are people putting these templates in the User namespace (presumably, in their own user page, or a subpage of it) if they're not supposed to? Is it for testing purposes, or do they just not know? My concern with shutting off certain namespaces entirely is that the usefulness of it might be limited - since there could be certain templates that you do want people to put in user pages, or in other namespaces. (Actually, there's probably more of an argument for being able to shut off storage in other namespaces, like "Talk", where there's no real reason to store data.) Yaron Koren (talk) 17:06, 6 May 2021 (UTC)
 * I don't know why, but it does happen, however I imagined like it being possible to disable within the  itself, not as a "global parameter" (something like  ). But I do understand why this may raise concerns. In any way, thanks again. Lakelimbo (talk) 12:47, 7 May 2021 (UTC)
 * That's an idea also. Actually, the more I think about it, the more I think a global variable like $wgCargoDisabledNamespaces (or $wgCargoEnabledNamespaces) could make sense, precisely for all those non-content namespaces. Or would only a parameter like "ignore namespace" work for this case? Yaron Koren (talk) 18:15, 7 May 2021 (UTC)
 * On my case specifically, I think just "ignore namespace" would work, but making something like  would be very useful I suppose, especially for wikis that heavily rely on Cargo. And sorry for not responding yesterday, I was a bit busy . Lakelimbo (talk) 20:41, 9 May 2021 (UTC)

[SOLVED] Date display
I'm wrestling with date displays in infoboxes using Cargo dates. The Page Values page displays the date as I intend (January 1, 1883) but the infobox insists on displaying 1883-1-1. When I try to format the date within the infobox (using MW date formatting), I can get full dates to work, but partial dates (for instance only the year) insert TODAY'S date info in the missing sub-fields. That's no good. Is there a date formatting procedure that I'm missing? Here's an example: http://wiki.martenet.com/index.php/Pratt_Library_Branch_4 You can see the page values link displays the full month and year (I have the $wgAmericanDates set to "true"). But the infobox is listening to something else, apparently. --Parma100 (talk) 00:37, 12 May 2021 (UTC)


 * You could check the __precision field for the date: Extension:Cargo/Storing data.


 * Having said that, here's what I did within a date-displaying template:




 * Jonathan3 (talk) 06:56, 12 May 2021 (UTC)
 * Thanks for that. I think it would be more precise to depend on the __precision field in this date template. However, I can't seem to find how to retrieve that field within a query template. I see on a 2015 thread where Yoren says "I just added in (re-added, really) the ability to display date precision fields in the query. Is that by itself enough to get this working, though? Or would you also need the ability to call "CASE", or something like it, in the "fields=" parameter?", but I don't see how to incorporate that. The internal date translations work well enough for me--I just can't find how to grab the __precision field to make the magic happen. What am I missing? --Parma100 (talk) 14:14, 13 May 2021 (UTC)


 * If your date field is called Startdate you'd use Startdate__precision, I think. Jonathan3 (talk) 14:20, 13 May 2021 (UTC)
 * That's what I figured. I seem to be getting null values, and that makes me think the fetch from the database isn't occurring. Those "hidden" fields (coord lat & long, this precision value, etc) aren't mentioned in the actual fields listing, and I'm not able to get any values, so I'm wondering if they're not being fetched. I've checked the actual MySql db, and the values are there, so storage is working. I can't figure out the retrieval. --Parma100 (talk) 14:31, 13 May 2021 (UTC)
 * It works now, with no processing at all, although I don't know why. It has something to do with being edited in the form. If I modify the (correct) date in the form, then save and go back to the page, the correct format appears -- month and year only, if no day is specified, and year only, if that is what is specified. I'm not going to argue with success, but I don't know why that edit vehicle works while the original form input does not. And this is without any of the processing you kindly shared above. Go figure.--Parma100 (talk) 20:16, 13 May 2021 (UTC)
 * Maybe an upgrade in Cargo since you last saved the pages? I've just done a quick query on a table with date fields and the dates all show properly, according to their precision... I had expected the missing parts to be filled with 1s (e.g. 2000 to show as something like 2000-01-01, May 2000 to be 2000-05-01). What happens if you just do a null edit on the page, or edit something unrelated? Maybe if you recreate the table it'll sort it out for every page. Jonathan3 (talk) 21:35, 13 May 2021 (UTC)
 * Actually I think it is due to the evolving nature of my coding here. Early on I used Cargo, but not Page Forms (because I didn't understand what Page Forms might be doing behind the scenes) and just used the editor for infoboxes inside the VisualEditor. That, of course will allow you to change the text, and Cargo picked up those changes. All good. But I don't think the secondary fields like __precision were getting updated as well. When I checked the MySql table, I saw lots of NULLS, but not all, in the __precision fields. I (incorrectly, now, I think) supposed that everything was getting saved properly. Later, I incorporated the Page Forms editor, abandoning the VisualEditor editing for infoboxes. Yesterday I stumbled on the fact that editing one of the "wrong" entries in Page Forms, and then saving it, automatically corrected the display. I went through and changed all of the incorrect displayed entries, and now they're all good. So I think the silver bullet is editing them in Page Forms, not using VisualEditor. This Cargo package is a well-thought-out suite of programs, and got me close to the finish line with a minimum of effort. It deserves high praise. The biggest problem may be the "nut behind the wheel!" --Parma100 (talk) 13:26, 14 May 2021 (UTC)
 * It's great that you got it working! Although it should work the same whether the template calls are being edited with Page Forms or VisualEditor (or by hand); so I don't know what the problem was here. Yaron Koren (talk) 18:09, 19 May 2021 (UTC)

[SOLVED] Compound, compound queries
Is it possible to get a compound, compound query without resorting to SQL? I'd like to fetch records which satisfy Criteria A AND either Criteria B OR Criteria C. I thought I could wrap the B or C code in parenthesis, as below, but that doesn't fly. The parenthesis trigger an error. What is the method of combining these tests? --Parma100 (talk) 19:08, 18 May 2021 (UTC)


 * This probably doesn't help you but I've used the above to create materially the same query with a table of mine and it worked all right (I changed the ='{{PAGENAME parts to <> just to get a result on a test page). Maybe something else is causing the error. It's not really a compound query without the second tables= line but I guess that's next. Jonathan3 (talk) 23:05, 18 May 2021 (UTC)


 * Thanks for the hint. Apparently more "nut behind the wheel" stuff. I'd labeled one of my fields incorrectly. The code does work with the parenthesis. --Parma100 (talk) 16:33, 19 May 2021 (UTC)

Maintenance script to switch in Cargo table
To work round the duplicates problem, I'm going to recreate all the Cargo tables each night.

It would be good if I could use the  parameter then, once the existing maintenance scripts have run, use another script to switch in the newly created replacement tables.

In the meantime I'll just choose an "Ungodly hour" to recreate the tables and hope nobody is using the website then :-) Jonathan3 (talk) 22:10, 24 May 2021 (UTC)

Annoyingly, after not using the  parameter, for the first time there are duplicates pretty much straight after running the scripts :-( Usually I use that parameter and the recreation scripts clear the duplicates. Jonathan3 (talk) 22:48, 24 May 2021 (UTC)


 * ...or how about a new parameter  which means the script creates a replacement table and at the end switches it in? It would mean that the Cargo tables are only incomplete for a split second and save the bother of using the web interface and all those clicks to switch the tables in :-) Jonathan3 (talk) 17:58, 25 May 2021 (UTC)

_pageData and Extension:UserMerge
When UserMerge deletes a User: page, the _pageData details aren't updated fully (unsurprisingly I suppose). I did a query out of curiosity and the deleted page appeared at the top of the list, probably because it is still in the Cargo table but doesn't have a date field any more.

Thanks. Jonathan3 (talk) 20:22, 25 May 2021 (UTC)


 * P.S. This resolves itself when the _pageData table is recreated. Jonathan3 (talk) 09:01, 28 May 2021 (UTC)

Cargo and Extension:Popups
I'd like to use Extension:Popups, but most of my pages these days are formed from Cargo template queries, and Extension:TextExtracts, which gets the page extract for the popup, returns "..." (nothing plus a standard "..."). It would be great if somehow the popup text extract could be based a Cargo field - so when it extracts text from a page, it checks whether there's a Cargo template, and if so returns the contents of the predetermined field for that template. I think this may be a relevant link: Extension:Popups. Is this something you'd consider adding? Thanks. Jonathan3 (talk) 08:59, 28 May 2021 (UTC)

Cargo and Scribunto/Lua
For my first Lua script I'd like to display the contents of a Cargo table in the following format (where Name and About are fields):

Name
 * About
 * About

Name
 * About

Name
 * About
 * About
 * About

I imagine something similar has been done before so wonder if anyone can point me to anything. Thanks in anticipation :-) Jonathan3 (talk) 06:33, 29 May 2021 (UTC)

I've made a start by modifying the example on Extension:Cargo/Other_features but it seems only to be returning the first row:

It prints "1..." but I'd have expected "1... 2... 3... 4... " etc. Where am I going wrong? Thanks. Jonathan3 (talk) 07:10, 29 May 2021 (UTC)

I don't usually ping people but User:RheingoldRiver I heard you on Yaron's podcast and wonder whether you would be willing to share your expertise here :-) Jonathan3 (talk) 07:53, 29 May 2021 (UTC)


 * Got the following code to work:




 * I changed it to make it more generic so hope no errors crept in. I'd be interested to hear whether I could have done things better. Thanks. Jonathan3 (talk) 22:43, 29 May 2021 (UTC)

Merge similar cells and "striping" or rows
Each separate column is alternately grey or white in its background. This is all right for normal tables, but when "merge similar cells" is used it can create a patchwork effect. Would it be possible for the background colour to reset as soon as there is a full unmerged row? Thanks. Jonathan3 (talk) 22:08, 29 May 2021 (UTC)