Extension talk:Cargo/Archive January to April 2021

[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

{{#cargo_query: ...
|limit = {{#cargo_query: ...

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:

{{#cargo_query:
table=Table_name
|fields=_pageName=Name, Date_field
|order by=Table_name.Date_field DESC
|limit={{#cargo_query: table=Table_name | fields=GREATEST(COUNT(*),3) | where=Table_name.Date_field > CURDATE()-INTERVAL 2 DAY | no html}}
}}

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 $wgDBport = "6846";. 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:

Cannot access the database: pg_connect(): Unable to connect to PostgreSQL server: could not connect to server: Connection refused

Is the server running on host XXX (xx.xx.xx.xx) and accepting
TCP/IP connections on port 5432?

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 php cargoRecreateData.php --table factories 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:

|fields=ab._pageName=Name,ab.Reihenfolge,ab.Artikel,ab.Kommentar

it will NOT get sorted by

|order by=ab.Reihenfolge ASC

Whereas if I rearrange the fields order to

|fields=ab._pageName=Name,ab.Artikel,ab.Kommentar,ab.Reihenfolge

it will be sorted as expected with

|order by=ab.Reihenfolge ASC

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 2.7.1 (f9bd098) 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 &action=delete 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 DATE_FORMAT in Cargo's fields parameter, I think order by=date 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 __precision 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 __precision 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) Date__precision=Precision or just Date__precision 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".

|default=
*''No results.''

Produces:

• No results

Whereas

|more results text=
*''More...''

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 [[Extension:Cargo/Version_history|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. 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#Empty_cargo_table_creates_error_in_cargoRecreateData.php_--quiet. 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 List (,) of String. 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 List (,) of Page 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 —Lakelimbo (talk) 16:47, 23 March 2021 (UTC)

You could probably use Extension:Page_Forms/Page_Forms_and_templates#arraymap 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 needle on Special:Drilldown/_fileData it lists 5 results, fine.

When I sarch for "needle" (or anything like "a needle" 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 "thistextdoesnotexist". 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:

SELECT  "Item_infobox_alias"."subtitle" AS value,COUNT(DISTINCT "Item_infobox_alias"."_pageID") AS total  FROM "cargo__Item_infobox" "Item_infobox_alias"    WHERE (("Item_infobox_alias"."title" = 'Special:Drilldown/Item_infobox'))  GROUP BY "Item_infobox_alias"."subtitle";

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

Perhaps related: cargoRecreateData.php 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 $wgDebugDumpSql or in the debug toolbar, so I've been writing $cdb->lastQuery() to a debug log directly in an attempt to work out what's going on. I'm also seeing problems with simple queries like

{{#cargo_query:
tables=Item
|fields=title,list_of_values
|where=list_of_values HOLDS 'example'
}}

failing because (e.g) _rowID isn't qualified or quoted, so PostgreSQL throws ERROR: column "_rowid" does not exist ... HINT: Perhaps you meant to reference the column "cargo__Item__list_of_items._rowID". (Query works fine when quoted appropriately and executed directly against the PostgreSQL server.) Aggregating queries that use COUNT(*) 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 :

[YH7Iv9Jb5ZSD0bpTvSJy6gAAAAc] /isee135/index.php/Special:Drilldown/Community_Leader?format=map&formatBy=Location TypeError from line 14 of /app/httpd/htdocs/isee135/extensions/Maps/src/Map/CargoFormat/CargoFormat.php: Argument 1 passed to Maps\Map\CargoFormat\CargoFormat::__construct() must be an instance of ParserOutput, instance of OutputPage given, called in /app/httpd/htdocs/isee135/extensions/Cargo/includes/CargoQueryDisplayer.php on line 87

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 |_drilldownTabs=List, Openlayers map (format=openlayers;fields=_pageName=Page name,Type,Coordinates), Google map (format=googlemaps;fields=_pageName=Page name,Type,Coordinates). 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 Error: 1054 Unknown column 'TableName_alias.Type' in 'field list' (localhost). When I changed the template to remove reference to the Type field (i.e. |_drilldownTabs=List, Openlayers map (format=openlayers;fields=_pageName=Page name,Coordinates), Google map (format=googlemaps;fields=_pageName=Page name,Coordinates) 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:

PHP Notice: Undefined index: Coordinates  lat in /var/www/.../extensions/Cargo/includes/formats/CargoMapsFormat.php on line 145
PHP Notice: Undefined index: Coordinates  lon in /var/www/.../extensions/Cargo/includes/formats/CargoMapsFormat.php on line 146

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

{{#cargo_query:

tables         = buildings
|fields        = completion_date=Completed,buildings._pageName=Building,address=Address
|where         = architect='Cargo/Archive January to April 2021'
|order by      = buildings.completion_date
|format        = table
|rows per page = 100

}}

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

$("table.cargoTable").removeClass("sortable");
$("table.cargoTable").removeClass("jquery-tablesorter");

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

{{#cargo_query|...}}

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

table.cargoTable {
	width: 50%;
	margin: auto;
}

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.

{{#cargo_query:
tables=Destinations
|fields=Destinations.Place, Destinations.Date, Destinations.Activity, Destinations.Website
|where=Destinations.Activity="Tango"
|format=table
}}

{{#cargo_query:
tables=Destinations
|fields=Destinations.Place, Destinations.Date, Destinations.Activity, Destinations.Website
|where=Destinations.Activity="Ski"
|format=table
}}

Place	Date	Activity	Coord
Ch?�te	2020-01-01	Ski	46.2669731440354,6.84370355320841
Embrun	2020-01-01	Ski	44.564206867709,6.49563333644402
Flaine	2020-01-01	Ski	46.0095610834591,6.69282016388486
Heiligenblut	2020-01-01	Ski	47.0858206963216,12.8428257931376
Ischgl	2020-01-01	Ski	47.0117025046712,10.2903270705064
Kirchberg	2020-01-01	Ski	47.450505563822,12.3255199636253
la Clusaz	2020-01-01	Ski	45.9043604869346,6.42403853236532
La Villa	2020-01-01	Ski	46.5839209147048,11.8995677592604

Place	Date	Activity	Coord
Amsterdam IJ	2020-01-01	Tango	52.3784747969098,4.91302297555385
Biezenmortel	2020-01-01	Tango	51.6260871871252,5.17811085764316
Buenos Aires	2020-01-01	Tango	-34.6199461873685,-58.3717068827899
Burnontige	2020-01-01	Tango	50.3796733888891,5.63975913213408
Calampiso	2020-01-01	Tango	38.1404304405908,12.7862894084938
De Plantage	2020-01-01	Tango	52.3637458949783,4.91719988094976

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.