Extension talk:Cargo/Archive January to March 2024

Latest comment: 7 months ago by Yaron Koren in topic InstantCommons & Cargo

Table not re-populated with data until page is edited

Hi Yaron,

When recreating table data, the table isn't populated with data until the page that contains #cargo_store: is edited (true or null edit). I don't believe it's an issue with the job queue because a high run rate is specified; and running runJobs.php confirms that the job queue is empty.

Any ideas what might be causing this?

Cheers + happy new year :)

Product Version
MediaWiki 1.39.5
Cargo 3.4.4 | same behavior in 3.4.3.; not sure before.
PHP 8.0.30 (fpm-fcgi)
MariaDB 10.5.23-MariaDB-1:10.5.23+maria~ubu2004-log
ICU 66.1
Lua 5.1.5
Pygments 2.11.2

Devaroo (talk) 19:26, 1 January 2024 (UTC)Reply

Happy new year! That doesn't sound good. If you can, please try calling cargoRecreateData.php, to see if that has the same problem. Yaron Koren (talk) 04:00, 2 January 2024 (UTC)Reply

Calling cargoRecreateData.php didn't solve the issue but it provided clues for where the bug might be.

It showed that out of the 3 declared Cargo tables one was working as expected and two showed the behaviour described above.

I checked for differences in the table declarations and found that both misbehaving tables, but not the working table, contained parameters of type Integer. I temporarily changed the types of those parameters to string and then the table was immediately populated with data.

So maybe there's an issue with parameters of type Integer? Not sure if relevant, but at least one page that should store data in an affected table definitely contains only correct values for the parameters (I created a test page for that purpose). Some other pages might contain invalid characters for those parameters, so I don't know if that might cause the entire data retrieval to fail silently.

Devaroo (talk) 20:29, 2 January 2024 (UTC)Reply

Update: I've just created a test table with 1 parameter and 1 test page and could not reproduce the issue, even when parameter is of type Integer. So regarding the original issue, most likely some pages are storing invalid values and this causes the entire data retrieval to fail silently. Devaroo (talk) 20:46, 2 January 2024 (UTC)Reply
Update 2: Ok now it suddenly works...Besides editing and thus re-saving the template pages that contain the table declarations I didn't change anything else. So pretty lost for what might have caused it. But even better if it works I guess! Sorry for the noise – if the same issue re-appears I'll report back here but for now it seems solved. Thanks for this great extension by the way. Devaroo (talk) 20:55, 2 January 2024 (UTC)Reply
I'm glad you like the extension! That's both good and bad news... the worst kinds of bugs are the ones that only show up sometimes. Please let me know if you get more insight on this one. Yaron Koren (talk) 21:00, 2 January 2024 (UTC)Reply
You're right about that. Will let you know if there's anything useful to share :) Devaroo (talk) 21:09, 2 January 2024 (UTC)Reply
I can confirm this problem with a table that contains just a string and an enumeration. A page containing a #cargo_query is not updated until it is edited. The interesting thing is, if you edit the page with the VisualEditor, the missing entry is shown, when you switch back to read view, it is gone again. Running cargoRecreateData.php doesn't help, restarting php-fpm doesn't help.
I am using MediaWiki 1.39.6 with Cargo 3.2 and PostgreSQL 13 as database backend. Joernc unibi (talk) 07:41, 6 February 2024 (UTC)Reply

uksort error

I get error

Deprecated: uksort(): Returning bool from comparison function is deprecated, return an integer less than, equal to or greater than zero in <hidden>/extensions/Cargo/includes/CargoSQLQuery.php on line 1030

when I try to run mediawiki maintenance script rebuildAll.php . The error happens during the part of the script after it says "refreshing links tables".

I also get the error on the top of some of my pages.

Product Version
MediaWiki 1.39.5
Cargo 3.4.4 (3d6f3b6)
PHP 8.2.7 (apache2handler)
MariaDB 10.11.4-MariaDB~deb12u1
ICU 72.1

Tenbergen (talk) 23:38, 1 January 2024 (UTC)Reply

This is likely an issue of using PHP 8.2+, but might be one way to fix this. We are using a debian repository on raspberry pi that comes with PHP 8.2, though, so moving back to an older version would be messy. Tenbergen (talk) 00:05, 2 January 2024 (UTC)Reply
changing lines 1030+ to the following made the error go away:
uksort($this->mAliasedTableNames, static function ($key1, $key2) use ($orderedTableAliases) {
   $position1 = array_search($key1, $orderedTableAliases);
   $position2 = array_search($key2, $orderedTableAliases);
   return $position1 - $position2;
});
Thanks for the fix - I just checked in a variation of this, here. Yaron Koren (talk) 20:57, 2 January 2024 (UTC)Reply

Templates as parameters. Durations.

I'm testing cargo in my wiki and wanna know if I can continue using templates as parameters. For example, I have this parameter for a person

|name={{name|Bill|Gates}}

which produces first and last name but Cargo takes it literally and prints the whole template. Also, how do you handle album lenghts?

|duration={{duration|03:54}}

In movie and music pages duration is a thing, should I add it as a string? Cojoilustrado 20:29, 5 January 2024 (UTC)

It's surprising that Cargo is storing the wikitext and not the output of the template. What type is the "name" field? As for the duration - I would actually store it as an integer - the number of seconds - if that's possible to do with parsing. Yaron Koren (talk) 20:53, 5 January 2024 (UTC)Reply

cargoRecreateData.php vs WebUI

Hi. My problem might be related to two sections above. But my table won't populate unless I edit a page or when cargoRecreateData.php is run from the commandline. Using the WebUI only creates an empty table. And my wiki is hosted by a third party, so I can't run the command line whenever I want. Any suggestions what might differ between the two? Dajasj (talk) 15:06, 7 January 2024 (UTC)Reply

The big difference is the use of jobs - could it be that the job queue is backlogged, or otherwise slow? Yaron Koren (talk) 01:59, 8 January 2024 (UTC)Reply

TypeError

I am getting the following error. I don't know what causes it, it happens when I run my nightly maintenance scripts, but when I run them manually during the day I don't get this error. That might mean that this is PHP version related, I seem to remember similar problem in the past.

[4380a9cd2daef64beac8df5b] [no req]   TypeError: round(): Argument #1 ($num) must be of type int|float, string given

Backtrace:

from <mywiki>/extensions/Cargo/includes/CargoFieldDescription.php(336)
#0 <mywiki>/extensions/Cargo/includes/CargoFieldDescription.php(336): round(string)
#1 <mywiki>/extensions/Cargo/includes/parserfunctions/CargoStore.php(309): CargoFieldDescription->prepareAndValidateValue(string)
#2 <mywiki>/extensions/Cargo/includes/parserfunctions/CargoStore.php(169): CargoStore::storeAllData(MediaWiki\Title\Title, string, array, CargoTableSchema)
#3 <mywiki>/includes/parser/Parser.php(3371): CargoStore::run(Parser, PPTemplateFrame_Hash, array)
#4 <mywiki>/includes/parser/Parser.php(3056): Parser->callParserFunction(PPTemplateFrame_Hash, string, array)
#5 <mywiki>/includes/parser/PPFrame_Hash.php(274): Parser->braceSubstitution(array, PPTemplateFrame_Hash)
#6 <mywiki>/includes/parser/Parser.php(3247): PPFrame_Hash->expand(PPNode_Hash_Tree)
#7 <mywiki>/includes/parser/PPFrame_Hash.php(274): Parser->braceSubstitution(array, PPFrame_Hash)
#8 <mywiki>/includes/parser/Parser.php(2888): PPFrame_Hash->expand(PPNode_Hash_Tree, integer)
#9 <mywiki>/includes/parser/Parser.php(1544): Parser->replaceVariables(string)
#10 <mywiki>/includes/parser/Parser.php(651): Parser->internalParse(string)
#11 <mywiki>/extensions/Cargo/includes/CargoUtils.php(573): Parser->parse(string, MediaWiki\Title\Title, ParserOptions)
#12 <mywiki>/extensions/Cargo/maintenance/cargoRecreateData.php(181): CargoUtils::parsePageForStorage(MediaWiki\Title\Title, string)
#13 <mywiki>/extensions/Cargo/maintenance/cargoRecreateData.php(72): CargoRecreateData->recreateAllDataForTable(string, boolean)
#14 <mywiki>/maintenance/includes/MaintenanceRunner.php(703): CargoRecreateData->execute()
#15 <mywiki>/maintenance/run.php(51): MediaWiki\Maintenance\MaintenanceRunner->run()
#16 {main}
Yes, this is somehow related to PHP 8 - that is, it happens only with some configurations or versions of PHP 8, as far as I can tell. It's a bug, in any case - and I just checked in what I think is a fix for it here. Yaron Koren (talk) 04:51, 15 January 2024 (UTC)Reply
I have been installing Cargo via git clone https://gerrit.wikimedia.org/r/mediawiki/extensions/Cargo . Running a git pull on that doesn't seem to get me a new version today (I still get 3.5-alpha (735ab12) 2023-12-21T05:02:24) . Is the place where where you checked in the solution still that? And is that git clone still how I would best install the most current version of Cargo? Tenbergen (talk) 16:21, 15 January 2024 (UTC)Reply
That's strange - the change to 3.5-alpha only happened last week (well after 2023-12-21), so I don't know what's going on with that version timestamp. Maybe you do have the latest code. Yaron Koren (talk) 02:13, 16 January 2024 (UTC)Reply

When mywikis was getting the DDOS attacks the "solution" was to restrict Special:CargoQuery to users. However I only just realized that when I limit a query response to X and have a "more..." link at the bottom that that link is just a Special:CargoQuery link and now all the results past the initial limit I set are unavailable. AahzKarrde (talk) 13:42, 30 January 2024 (UTC)Reply

That's true... but I don't know what, if anything, can easily be done about that. Maybe it's a way to convince people to register for the wiki? Yaron Koren (talk) 16:00, 30 January 2024 (UTC)Reply
I wish that could work, but doesn't seem the greatest user experience.
One thing that's never worked properly for me is the "more results text" override. But I'm wondering if there could be something that allowed me to supply a template that could be fed the offset number and have the predefined query starting at that offset. That way the user isn't running the CargoQuery directly just like the initial page. AahzKarrde (talk) 16:12, 30 January 2024 (UTC)Reply
Well, if the "more results text" parameter isn't working for you, that's a problem (I just tried it, and it works fine for me) - but you would need to have different text depending on whether or not the user was logged in, no? Unless you were already trying to do something like that using some #if... parser function. But theoretically something like what you're asking about can already be done using Special:RunQuery, if you also have Page Forms installed. I don't know how Special:RunQuery could be connected to the "More..." link, though. Yaron Koren (talk) 16:26, 30 January 2024 (UTC)Reply

Get error message

Hello

Is this possible to show what block the creation of a Cargo Table ?

With trial and error I've found that adding a complex hierarchy block the process to create the Cargo Table, but I would like to have a better explication of what cause the error.

Produit Version
MediaWiki 1.35.2
PHP 7.4.30 (apache2handler)
MariaDB 10.1.48-MariaDB-0ubuntu0.18.04.1
Lua 5.1.5

AjaxDeshayes (talk) 15:00, 5 February 2024 (UTC)Reply

If you have access to the command line, if you call the cargoRecreateData.php script, it should give you a clearer error printout if something goes wrong. Yaron Koren (talk) 15:14, 5 February 2024 (UTC)Reply
Thank you !
There no way to print the error directly in the page for users that can't access the command line ?
On another note can you open the following pages for translation please ?
Extension:Cargo/Exporting data
Extension:Cargo/Other features
Extension:Cargo/Browsing data AjaxDeshayes (talk) 09:00, 6 February 2024 (UTC)Reply
Okay - if you have no command line access, you might be able to see a useful error message by opening the browser console, going to the "Network" tab (or whatever it's called), pressing the "Recreate" button, looking for the new "api.php" line in the Network tab, then right-clicking on it to see its contents. The error message may be contained there.
As for translation, I try not to get involved with it. You might be able to do this yourself, if you can figure out the syntax. Yaron Koren (talk) 14:10, 6 February 2024 (UTC)Reply

Display how long ago a timestamp was

I'm storing a timestamp (yyyymmddhhmmss) value of when a Cargo entry was first submitted, but would like to display how long time ago it was. Is there a way to convert the timestamp to "3 minutes ago", "8 days ago", "1 year ago", etc. when querying the table? Tahoma403 (talk) 07:53, 15 February 2024 (UTC)Reply

I'm guessing that there's no way to do that - in SQL, you can do it using a hack like this, but it requires a nested SELECT, which Cargo does not allow. What I would recommend is to do it within JavaScript - which I think would be a better approach anyway, because it would allow for smarter handling, like showing the exact date if the user hovers over the value. Yaron Koren (talk) 14:22, 15 February 2024 (UTC)Reply
Thank you, I will use JS.
Can I ask if there's a better way to order query results by date/time added than to store a timestamp for each page? I was using ‎page name=<unique number> in Page Forms, ordering query results by _pageName DESC, but if I delete a page, the next page added will take its place (lowest number) and not be at the top of the Recently Added list. Tahoma403 (talk) 15:49, 15 February 2024 (UTC)Reply
Do you know about the _pageData table, and its _creationDate field? That may or may not be what you're looking for. Yaron Koren (talk) 16:51, 15 February 2024 (UTC)Reply
Yes, I think that's the solution. I read about page data before, but ruled it out because of the need to create an additional Cargo table. I don't know much about PHP and SQL, so I'm trying to keep it as simple as possible, but I will test it and see if that's the way to go. Thanks again. Tahoma403 (talk) 07:24, 16 February 2024 (UTC)Reply

Can allowed values be a SQL Query ?

Hello

I try to make the allowed values be from a cargo table and a field, but I couldn't make it work.

I try with:

  • cargo table=mytable |cargo field=._pageName
  • cargo table=mytable ,cargo field=._pageName
  • values from query ={{#cargo_query: tables=KTD |fields=KTD._pageName }

Is the only way to restricted the entry to be from a cargo table and field is trough a form ?

But even on a from it doesn't work I try with

  • mapping cargo table=mytable| mapping cargo field=mytable._pageName
  • cargo table=mytable |cargo field=._pageName
  • cargo table=mytable ,cargo field=._pageName
  • values from query={{#cargo_query:tables=mytable%fields=mytable._pageName}

AjaxDeshayes (talk) 15:41, 16 February 2024 (UTC)Reply

That first line seems like it should work - you just need to take out the "." from the "cargo field" value. Yaron Koren (talk) 14:32, 18 February 2024 (UTC)Reply
Thank you It worked. AjaxDeshayes (talk) 15:01, 23 February 2024 (UTC)Reply

Table duplicating entries on Page save

I'm using Cargo 3.4.4 (latest), I have a #cargo_declare with 32 fields in a template. This seems to work very well. Except some times if I edit the page where we enter the data the data becomes duplicated in the underlying table.That is we start with one row for name=foo, edit the page and now we have two rows with name=foo. Repeatedly editing the page results in one new row per edit. We've not been able to figure out why some of these work correctly (the edit updates the data in the table) and others duplicate the row. Tjoneslow (talk) 01:59, 23 February 2024 (UTC)Reply

That's unfortunate - I thought this problem was fully fixed already. When you say "sometimes", do you mean randomly on any save, or on every save but only in certain pages? Yaron Koren (talk) 17:33, 23 February 2024 (UTC)Reply
As I dig further into this it becomes weirder and more intermittent. My initial discovery was it would happen only for a few pages and always happen on those pages. That is, on most pages the multiple saves would have only the one expected cargo entry. But a few pages something would go wrong (with no apparent error message) and you get a duplicate for every save. The work around I found was if I, using PhpMyAdmin to edit the database, delete the all the entries then restart saving the page/template the problem "goes away", and there are no more duplicate entries in the table on multiple saves. That tells me there is some bad data in the duplicating entries. But I'm not sure what to look for. Tjoneslow (talk) 14:50, 24 February 2024 (UTC)Reply
Are all the problematic pages part of the same Cargo table? Yaron Koren (talk) 14:07, 26 February 2024 (UTC)Reply
Yes. It's only the one table and the pages associated with it. Tjoneslow (talk) 16:18, 26 February 2024 (UTC)Reply
Could you include here, or pastebin, the #cargo_declare and #cargo_store calls? Those would be interesting to see, I think. Yaron Koren (talk) 14:37, 27 February 2024 (UTC)Reply
https://wiki.travellerrpg.com/Template:InfoboxShip -> This is the complete template in the wiki. Tjoneslow (talk) 00:36, 28 February 2024 (UTC)Reply
I did some more code reading and tracking down. I found that the pages that are duplicating are not listed in the cargo_pages table. If the page where the InfoboxShip template is used is listed in the cargo_pages table (with the table name starships) saving the page does not duplicate in the cargo table.
Looking at the code I found the code to insert to the cargo pages does not do a commit. My database is behaving weirdly, and may be loosing connections, so may be loosing the implicit commits. Might it be possible to add an explicit commit here? Tjoneslow (talk) 15:16, 17 March 2024 (UTC)Reply
That's very helpful to know, thank you. I don't think adding a commit() call (and, presumably, a corresponding begin() call) would help there, because I don't think transactions are given greater priority or anything, though I could be wrong. I do, wonder, though - after enough saves, does any specific page eventually get added to the cargo_pages table, and then duplicates go away for it? Yaron Koren (talk) 20:48, 20 March 2024 (UTC)Reply
Hello Yaron and Tjoneslow,
I have this problem currently as well. This is the only query that gives me problems. Here is my code:
{{#cargo_query:
tables=BPF,BPF__BP_Record,BP_R
|join on=BPF._ID=BPF__BP_Record._rowID,BPF__BP_Record._value=BP_R._pageName
|fields=BP_R._pageName=Business Record, BP_R.BP_Record_SME_Name =Record SME, BP_R.BP_Record_Story=Story, BP_R.BP_Record_Element=Element, BPF._pageName=Form Page Name, BPF.BP_Form_Applicability= Form Applicability, BPF.BP_Form_Contact=Form Contact
|format=table
|group by=
|limit=5000}}
The way I have been handling it is a run the recreate script from the maintenance folder in cargo.
Thanks,
Margaret 2601:447:D080:22C5:ECCA:A62D:962D:1A89 14:33, 1 April 2024 (UTC)Reply

I'll add the message here, although I'm not sure if it's the same situation.

I had long intended to write about the situation of duplicated records that I discovered. Here's what I concluded: the MediaWiki core sometimes triggers recording in Cargo tables even when a page isn't edited. Moreover, the previous entries aren't deleted! As far as I understand, Yaron addressed this by prohibiting the insertion of identical rows from a single page.

Here's how I noticed it: I corrected a spelling mistake in one of the texts stored in Cargo. Since there are many pages using this text, and the mistake was minor, I didn't immediately proceed to rewrite everything and postponed it for the future.

After some time, I noticed that some pages had duplicate sets of records — with the error and without it. Editing (or zero-editing) resolves the situation and removes the second set. --StasR (talk) 18:45, 4 April 2024 (UTC)Reply

Sorry to skip over the rest of what you wrote, but the part about "even when a page isn't edited" is interesting. Cargo data is only supposed to be stored/modified when a page is modified, or when a table is recreated. Could it be that you are seeing the latter? Or is something else happening? Yaron Koren (talk) 20:07, 4 April 2024 (UTC)Reply
Exactly! I'm confident that this is happening without overwriting the page and, moreover, without recreating the tables. StasR (talk) 06:45, 5 April 2024 (UTC)Reply
Here you can see two entries in the prizes_table. The first one (without prizeNumber) was formed when the page was saved (with the old version of the script), and the second one (with prizeNumber=1) appeared for no apparent reason based on the execution of the current version of the script. If I rewrite the page now, only the second option will remain. StasR (talk) 07:00, 5 April 2024 (UTC)Reply
What script are you talking about? Yaron Koren (talk) 13:05, 5 April 2024 (UTC)Reply
This is a Lua module (Scribunto) that is invoked on the page and writes data to the Cargo table. StasR (talk) 14:25, 5 April 2024 (UTC)Reply
Oh, interesting - perhaps there is indeed a bug in the handling of the (relatively new) Lua "store" command. Yaron Koren (talk) 21:36, 5 April 2024 (UTC)Reply
No, the recording itself is directly carried out there through ‘Template:Cargo:Prizes’ (using “{{#cargo_store:...}}”) invoked from Lua. So the issue is most likely not related to Lua. StasR (talk) 07:14, 6 April 2024 (UTC)Reply
Oh, okay. Well, the fact that it's being called indirectly, via Lua, may still be the cause of the issue (#cargo_store having an effect, when it shouldn't). Yaron Koren (talk) 17:51, 8 April 2024 (UTC)Reply
It intuitively seems to me that there is still an old problem of duplicate records manifesting here.
Furthermore, the occurrence of such duplicates is an ongoing process. So if you need any code snippets inserted to investigate the situation, I'm ready to help (preferably, these snippets shouldn't significantly affect performance since it's a live site). StasR (talk) 20:00, 8 April 2024 (UTC)Reply

In the Calendar format how to query and display a recurring_event

Hi,

I have an event table that contains a field of type list of (;) dates using the recurring_event function. I've read the documentation but I cannot find a way to display these lists of dates individually on a calendar. Drilldown's timeline displays correctly, but drilldown's calendar have multiple items on the start date.

My SQL knowledge isn't good, but I believe even with a DB you have to use a script or subqueries to display a row with a list, to individual rows.

Using just an alias didn't work:

tables=event;fields=event._pageName=name,event.ReccuringDates=start 2A02:587:1E40:9C00:0:0:0:684 00:18, 28 February 2024 (UTC)Reply

The issue may be that, because "ReccuringDates" (misspelled, but that doesn't really matter) holds a list of values, it's actually a "virtual field" - and the query is returning the full, semicolon-separated string, instead of the individual values. This might work instead:
tables=event,event__ReccuringDates|join on=event._ID=event__ReccuringDates._rowID|fields=event._pageName=name, event__ReccuringDates._value Yaron Koren (talk) 14:23, 28 February 2024 (UTC)Reply

on Dilldown filter for fields with "date" is not working

Hi,

on Special:Drilldown on any table with a date field, if I try to filter within a date range or a specific date I get:

[e3b492fe098df5d78441638e] /wiki/Spezial:Drilldown/Phelix_Artikel?_single&Bestelldatum=2000+-+2009   MWException: Error: the string "FROM" cannot be used within #cargo_query.

Backtrace:

from /srv/www/production/REL1_41/extensions/Cargo/includes/CargoSQLQuery.php(170)
#0 /srv/www/production/REL1_41/extensions/Cargo/includes/CargoSQLQuery.php(60): CargoSQLQuery::validateValues()
#1 /srv/www/production/REL1_41/extensions/Cargo/drilldown/CargoDrilldownPage.php(1876): CargoSQLQuery::newFromValues()
#2 /srv/www/production/REL1_41/includes/specialpage/QueryPage.php(564): CargoDrilldownPage->getQueryInfo()
#3 /srv/www/production/REL1_41/includes/specialpage/QueryPage.php(774): MediaWiki\SpecialPage\QueryPage->reallyDoQuery()
#4 /srv/www/production/REL1_41/extensions/Cargo/drilldown/CargoSpecialDrilldown.php(276): MediaWiki\SpecialPage\QueryPage->execute()
#5 /srv/www/production/REL1_41/includes/specialpage/SpecialPage.php(727): CargoSpecialDrilldown->execute()
#6 /srv/www/production/REL1_41/includes/specialpage/SpecialPageFactory.php(1621): MediaWiki\SpecialPage\SpecialPage->run()
#7 /srv/www/production/REL1_41/includes/MediaWiki.php(357): MediaWiki\SpecialPage\SpecialPageFactory->executePath()
#8 /srv/www/production/REL1_41/includes/MediaWiki.php(960): MediaWiki->performRequest()
#9 /srv/www/production/REL1_41/includes/MediaWiki.php(613): MediaWiki->main()
#10 /srv/www/production/REL1_41/index.php(50): MediaWiki->run()
#11 /srv/www/production/REL1_41/index.php(46): wfIndexMain()
#12 {main}

Any idea? Using MW 14.1, PostgreSQL 12.18, Cargo 3.5 (fc658e0). Filter for any other fields like Interger or String or something works as expected.

Brabi81 (talk) 15:03, 4 March 2024 (UTC)Reply

That's not good. I can't replicate this locally, so my guess is that is somehow due to a bug with PostgreSQL handling. Was this working for you before? If so, what changed - maybe a software upgrade? Yaron Koren (talk) 15:30, 4 March 2024 (UTC)Reply
ofc we use MW 1.41 ... Nevertheless. Yes I'm sure it's special on PostgreSQL, again.
No it never worked when tested through all MW versions. I reported something with drilldown and date by end '21 (MW 1.35), but the error message changed a bit. Sadly there was no solution. BTW the timeline format is showing the dates while the calendar format throws also an "from" error.
I thought to refresh the error report with this new topic. Thanks alot! Brabi81 (talk) 06:15, 5 March 2024 (UTC)Reply
Alright. Well, the problem is happening in the function CargoSQLQuery::validateValues() - one of the parameters being passed to it ($tablesStr, $fieldsStr, etc.) apparently contains the string "from". If you know any PHP coding, could you add some print statements to the top of that function, to find out which of these variables contains the "from"? And if so, could you let me know what the full value of that variable is? Yaron Koren (talk) 15:53, 5 March 2024 (UTC)Reply
In the CargoSQLQuery::validateValues() only the $whereStr has some FROM in it (call: /Spezial:Drilldown/Phelix_Artikel?_single&Bestelldatum=2009)
string(66) "(EXTRACT(YEAR FROM "Phelix_Artikel_alias"."Bestelldatum") = 2009 )"
the $noQuotesWhereStr holds string(30) "(EXTRACT(YEAR FROM .) = 2009 )"
if I just outcomment preg_match( $regexp, $noQuotesWhereStr ) || the next thorw is:
MWException: Fehler: Die SQL-Funktion „EXTRACT()“ ist nicht erlaubt.
just outcomment self::getAndValidateSQLFunctions( $noQuotesWhereStr );
it works ;D Hope this is enough and helps or need more things? Brabi81 (talk) 07:05, 6 March 2024 (UTC)Reply
Thanks - that's extremely helpful. So apparently there are two different validation issues with date filtering with PostgreSQL - which makes me think that this has never worked before! Anyway, I created a patch that I think will fix the problem, here. Could you try this out, and let me know if it works for you? Yaron Koren (talk) 14:43, 6 March 2024 (UTC)Reply
The patch works perfectly for me in Drilldown! Great and Thanks alot!
Maybe related (cuz surely PostgreSQL specific again or should I start a new topic?): format=calendar on Drilldown thows:
Error 42P01: FEHLER: fehlender Eintrag in FROM-Klausel für Tabelle »phelix_artikel_alias«
LINE 1: ...ECT /* CargoDrilldownPage::getQueryInfo */ MAX( Phelix_Art...
Function: CargoDrilldownPage::getQueryInfo
Query: SELECT MAX( Phelix_Artikel_alias.Bestelldatum ) as start_date FROM "cargo__Phelix_Artikel" "Phelix_Artikel_alias"
Backtrace:
from /srv/www/production/REL1_41/includes/libs/rdbms/database/Database.php(1236)
while it should look like (tested in only PostgreSQL):
SELECT MAX("cargo__Phelix_Artikel"."Bestelldatum") as start_date FROM "cargo__Phelix_Artikel" Brabi81 (talk) 06:44, 7 March 2024 (UTC)Reply
Great! I checked in that patch. This 2nd drilldown issue is not really related, but sure, let's talk about it here. I think this has to do with the alias not being in quotes - I just checked in what might be a fix for it here. Could you let me know if this 2nd fix works for you? Yaron Koren (talk) 14:48, 7 March 2024 (UTC)Reply
this patch didn't resolve the problem and changed the error to:
Error 42703: FEHLER: Spalte Phelix_Artikel_alias.bestelldatum existiert nicht
LINE 1: ...ECT /* CargoDrilldownPage::getQueryInfo */ MAX( "Phelix_Ar...
HINT: Vielleicht wurde beabsichtigt, auf die Spalte »Phelix_Artikel_alias.Bestelldatum« zu verweisen.
Function: CargoDrilldownPage::getQueryInfo
Query: SELECT MAX( "Phelix_Artikel_alias".Bestelldatum ) as start_date FROM "cargo__Phelix_Artikel" "Phelix_Artikel_alias"
Backtrace:
from /srv/www/production/REL1_41/includes/libs/rdbms/database/Database.php(1236)
I think the field needs to be also in quotes. Brabi81 (talk) 06:15, 8 March 2024 (UTC)Reply
That could be; please try it again now. Yaron Koren (talk) 13:26, 8 March 2024 (UTC)Reply
Yes the changes to the patch work now! Thanks! Brabi81 (talk) 09:01, 11 March 2024 (UTC)Reply
That's great to hear! Thanks for your help. This fix is now merged in. Yaron Koren (talk) 13:43, 11 March 2024 (UTC)Reply

Problem with query when fields=COUNT(...)

I've just upgraded from 1.35 to 1.39. At some point in Cargo between REL1_40 and REL1_41 something changed. A query which used to give the number of rows in a table now gives an error.

Query:

{{#cargo_query:
tables={{{1}}}
|fields=count(_pageTitle)
}}

Error:

Error 1140: In aggregated query without GROUP BY, expression #1 of SELECT list contains nonaggregated column 'xxxx.xx_cargo__xxxx._pageID'; this is incompatible with sql_mode=only_full_group_by
Function: CargoSQLQuery::run Query: SELECT `xx_cargo__xxxx`.`_pageID` AS `cargo_backlink_page_id_xxxx`,count(_pageTitle) AS `count( pageTitle)` FROM `xx_cargo__xxxx` ORDER BY `wm_cargo__xxxx`.`_pageID`,count(_pageTitle) LIMIT 100

Is there something about the query I should change? Jonathan3 (talk) 12:26, 7 March 2024 (UTC)Reply

That's a tricky one - it has to do with the "backlink_page_id" field, which should not be there if the query contains COUNT() or another aggregating function. This is a bug that needs to be fixed, but until then, you can get around it in a few ways:
  1. As the error message suggests, change the "sql_mode" setting to something other than "only_full_group_by"
  2. Add $wgCargoIgnoreBacklinks = true; to LocalSettings.php
  3. Add the following to the #cargo_query call: |group by='()'. I can't really explain why that exact syntax works, but Cargo knows to leave out the backlinks field if there's a "group by".
Yaron Koren (talk) 16:04, 7 March 2024 (UTC)Reply
Thanks. I'll likely try no.3. Is there any "for dummies" documentation about the backlinks setting? I just found https://phabricator.wikimedia.org/rECRG66952daf0329c3c16ee32892a905d2b861efa8c3 Jonathan3 (talk) 16:26, 7 March 2024 (UTC)Reply
Just whatever is in the documentation. Yaron Koren (talk) 16:47, 7 March 2024 (UTC)Reply
Thanks. Option 3 worked. I didn't find anything about backlinks in the documentation, but found this in task T308264: "Right, it's unrelated to SemanticDependencyUpdater, although this feature does for Cargo essentially does what SDU does for SMW. Anyway, I think it's a good idea to add a setting to disable the "backlinks" feature - which essentially would just mean not creating it when the admin calls update.php. (The code already works fine when the cargo_backlinks DB table doesn't exist, so admins can just delete it - the issue is just that it gets re-created whenever update.php is called.) Ideally this would not be necessary, but clearly there are still some bugs left in the implementation." Jonathan3 (talk) 21:41, 7 March 2024 (UTC)Reply
I just checked in what I think is a fix for this bug, here. Yaron Koren (talk) 19:46, 12 March 2024 (UTC)Reply

Dynamic Table Sorting

Unlike the normal table format Dynamic Table does not sort strings "naturally", as an example with the cargo query returning 11, 1 and 2. Table will sort this as 1, 2, 11 whereas Dynamic Table will give 1, 11, and 2. I think for most use cases the former behavior is more desirable. Is there any way to adjust this behavior? FGC Kaladin (talk) 19:35, 14 March 2024 (UTC)Reply

That sounds like a bug that needs to be fixed; I think it's a matter of putting the column header in the format that the DataTables JavaScript library is looking for. Yaron Koren (talk) 13:01, 15 March 2024 (UTC)Reply
I just finally tried this, a month later, and I can't reproduce the error: when I sort on the column that contains numbers, they get sorted in the right order (numeric as opposed to alphabetical). What version of Cargo are you using? And is this column for a field of type "Integer"? Yaron Koren (talk) 21:54, 15 April 2024 (UTC)Reply

"More results text" doesn't display between "intro" and "outro"

|intro=<tr><th>Heading</th><td>
|outro=</td></tr>

The "More..." appears in the main body of the page, outside the HTML table. How can I change this? Jonathan3 (talk) 23:49, 14 March 2024 (UTC)Reply

With custom JavaScript, I suppose. Yaron Koren (talk) 13:02, 15 March 2024 (UTC)Reply

Default date format display

Is there a way to set the default date display for query results? It usually is 2024-03-15, but what if I wanted it to be something like 15 Mar 24 site-wide? Jonathan3 (talk) 09:46, 15 March 2024 (UTC)Reply

I don't think there's any way to do it site-wide, other than maybe with some MySQL hack; within a specific query, the best way to do it is with a call to DATE_FORMAT() in the field. Yaron Koren (talk) 13:05, 15 March 2024 (UTC)Reply

Change titles of infoboxes called with Cargo

Is it possible to change the infobox titles that I call from within a page? I am calling several different cargo templates as infoboxes with input params from the same page. Currently, the title just shows the title of that page, so it gets confusing. For example, the page is for an address and I am calling templates for the buildings at that address with architects as separate templates, as there may be multiple buildings and architects etc. I am using Page Forms to enter these. I am new to this talk page, so please let me know if I am not providing enough info or how best to proceed Thank you! Dumpstar (talk) 20:09, 19 March 2024 (UTC)Reply

This doesn't sound like a Cargo question... by "infobox title", do you mean the page name displayed at the top of each infobox? If so, that is set within the template for that infobox. Is it being set using PAGENAME, or via #template_display, do you know? Yaron Koren (talk) 22:33, 19 March 2024 (UTC)Reply
I have yet to find the infobox template Cargo uses. Is it just the Template:Infobox? I could not make sense of this:
{{#invoke:Infobox|infobox}}<includeonly>{{template other|{{#ifeq:{{PAGENAME}}|Infobox||{{#ifeq:{{str left|{{SUBPAGENAME}}|7}}|Infobox|[[Category:Infobox templates|{{remove first word|{{SUBPAGENAME}}}}]]}}}}|}}</includeonly><noinclude> ::{{documentation}} ::<!-- Categories go in the /doc subpage, and interwikis go in Wikidata. --> ::</noinclude>
One of the cargo templates looks like this:
{{#template_params:Hausstätte|Hausstätte_Link|Baujahr|Baujahrhundert|Abbruch (label=Abbruch/Zerstörung/Aufgabe)}}
{{#cargo_declare:_table=Gebäude|Hausstätte=String|Hausstätte_Link=String|Baujahr=Date|Baujahrhundert=Integer|Abbruch=Date|_parentTables= Hausstätte(_localField=Hausstätte, _remoteField=_pageName)}}
Dumpstar (talk) 12:27, 20 March 2024 (UTC)Reply
Alright - this definitely isn't a Cargo question, because Cargo doesn't affect the display of templates, which is what you're asking about. I'm not sure I understand what's going on, in any case. Is this a public wiki? That would certainly make the problem easier to solve. Yaron Koren (talk) 12:37, 20 March 2024 (UTC)Reply
Unfortunately it only will be a public wiki sometime next month. Then let me rephrase my Cargo question: How does Cargo create the infobox and does it use the Template:Infobox (which I guess came with wiki?)? Dumpstar (talk) 12:40, 20 March 2024 (UTC)Reply
Cargo doesn't create infoboxes, it doesn't use Template:Infobox, and MediaWiki doesn't come with any built-in infoboxes (I'm guessing that you imported that one from Wikipedia). Yaron Koren (talk) 18:51, 20 March 2024 (UTC)Reply
If that is so, what happens between {{#template_display:_format=infobox}} in the Cargo template and seeing the infobox on the page where I call the template? Dumpstar (talk) 21:06, 20 March 2024 (UTC)Reply
Okay - if there are calls to #template_display with "_format=infobox", then that is almost definitely the cause of the issue you are seeing. It should be noted that #template_display is defined by the Page Forms extension, not Cargo (and the same is true for pages like Special:CreateTemplate). Anyway, #template_display could probably use a parameter like "_title=", to let users override (or remove) the title row. Yaron Koren (talk) 12:58, 21 March 2024 (UTC)Reply
I just added a "_title" parameter, here. Yaron Koren (talk) 22:05, 27 March 2024 (UTC)Reply
Cool! Thanks a lot! Dumpstar (talk) 13:38, 28 March 2024 (UTC)Reply

Display list of pages with number of occurrences in other table

I'm displaying a list of page names from Table1. In the same list, I would like to add the number of times each page name appears in Table2, like this:

Page 1 (18)

Page 2 (9)

Page 3 (32)

Do I use #cargo_compound_query and COUNT(*) to achieve this? Tahoma403 (talk) 07:56, 23 March 2024 (UTC)Reply

Problem solved, I queried both values from Table2 instead and used "group by=". Tahoma403 (talk) 12:41, 24 March 2024 (UTC)Reply

InstantCommons & Cargo

Apologise if this has already been asked.

My wiki uses InstantCommons for some images in my templates. However, these images do not display in my Cargo table or when I query them. Instead, I get redlinks. Apart from uploading all the files to my wiki, is there a solution to this?

Many thanks. Rothwell4217 (talk) 23:16, 24 March 2024 (UTC)Reply

I've noticed that it does show the images when I go to Drilldown and select gallery. Rothwell4217 (talk) 00:40, 25 March 2024 (UTC)Reply

Thanks for pointing out the problem. I just checked in a fix for this, here. Yaron Koren (talk) 16:57, 19 April 2024 (UTC)Reply
Return to "Cargo/Archive January to March 2024" page.