Extension talk:Cargo

[ANSWERED] MySQL/MariaDB database user privileges required by Cargo
I know that the normal thing to do is GRANT ALL PRIVILEGES, but I'm thinking of reducing that and would like to know which privileges are required by Cargo for (a) the main database and (b) its own Cargo database. See Topic:Wnht96uupemgrsef. Thanks. Jonathan3 (talk) 11:55, 5 January 2022 (UTC)


 * For the main DB, no special privileges. For the Cargo DB, probably just the ones you listed (SELECT, INSERT, UPDATE, LOCK TABLES, DELETE), plus CREATE TABLE. Yaron Koren (talk) 21:16, 5 January 2022 (UTC)


 * Thanks. I will try this out eventually. I guess that nobody bothers with this and database rights have never been a concern. Jonathan3 (talk) 10:39, 3 February 2022 (UTC)

Datatype "Monolingual text"
Hello,

Does an equivalent to SMW Datatype "Monolingual text" exist with Cargo ?


 * No... would it be useful? Yaron Koren (talk) 15:14, 10 January 2022 (UTC)

The need is to change the field label like in This is a property of type Has type::Text.

Language labels: Has preferred property label::Role@en Has preferred property label::Rolle@de


 * Where is that "Has preferred property label" property used? Yaron Koren (talk) 20:25, 11 January 2022 (UTC)

There is a description at "www.semantic-mediawiki.org/wiki/Help:Special_property_Has_preferred_property_label#Example"


 * I've seen that page before, but I don't really understand it - it doesn't seem to explain what the actual effect on the display, or user interface, is. Where in the interface is the "preferred property label" used? Yaron Koren (talk) 18:38, 13 January 2022 (UTC)

Table created, nothing stored, no matter via calling template or directly calling parser function
The table "Level" holds no data, however, the multiple pages has already called templates that store data. Directly calling  also does not work. I tried re-creating the table, or deleting and creating the table again, neither of which can fix. -- SolidBlock (talk) 09:28, 12 January 2022 (UTC)


 * Where is the actual #cargo_store call? The one right in that template is commented out. Yaron Koren (talk) 14:47, 12 January 2022 (UTC)
 * I undid the comment in that template. Besides, this page manually calls  however the data “Level” is still empty. SolidBlock (talk) 03:35, 13 January 2022 (UTC)


 * After uncommenting #cargo_store, I think you just need to recreate the table - you can do that from Special:CargoTables. Yaron Koren (talk) 15:31, 13 January 2022 (UTC)
 * However, unfortunately, no matter how many times I recreate the table, the issue is not fixed. And pages storing that data has no data shown to be stored in the "?action=pagevalues" page. -- SolidBlock (talk) 08:27, 14 January 2022 (UTC)
 * Are you sure that #cargo_store is actually getting called? It's inside a rather complicated #ifeq statement, and I'm not sure if it ever gets called. Yaron Koren (talk) 13:43, 14 January 2022 (UTC)
 * Yes. It works normally before I initially recreate the table. Besides, I manually called  in my sandbox page. It does not work, while another table works normally. SolidBlock (talk) 06:22, 15 January 2022 (UTC)
 * Could the reason be the exception of the replace table? Zes M Young (talk) 12:06, 19 January 2022 (UTC)

and another issue related to this
The following Lua throws MW internal exceptions, which began in recent days: SolidBlock (talk) 14:42, 21 January 2022 (UTC)


 * Maybe that's related. What are the exceptions? Yaron Koren (talk) 16:56, 21 January 2022 (UTC)
 * [993445ad01d110ae8272c772] 2022-01-22 14:07:00: Fatal exception of type "TypeError" -- SolidBlock (talk) 14:07, 22 January 2022 (UTC)
 * Could you please add  to your LocalSettings.php file? That will hopefully lead to a more useful error message. Yaron Koren (talk) 16:04, 24 January 2022 (UTC)
 * I have no permission to do that and have filed a task on miraheze phab. You may refer to it. SolidBlock (talk) 10:10, 25 January 2022 (UTC)

Sort by date in Special:Drilldown
Is it possible to do this? I've tried using  to the template but to no avail. Any ideas? Thanks. Jonathan3 (talk) 11:59, 13 January 2022 (UTC)

Just to clarify, I know the table is sortable - I just wondered whether there is a way to set a default sort column. Thanks. Jonathan3 (talk) 15:55, 13 January 2022 (UTC)

Exhibit display format supported?
Creating a query with display format exhibit results in a table of rows of headers only, though with proper itemid labels (i.e. pulled from the data). I am pulling from one table, one field only, with cargo data format = page. Display and source code contains none of the query data, though the export/toolbox widget button contains the data as expected. Multiple "Error: Missing property ID at position 1" js errors.

Is the Exhibit display format still maintained, or do I have something missing in my query? --JStallings29 (talk) 20:30, 16 January 2022 (UTC)


 * That works fine for me - what versions of MediaWiki and Cargo are you running? Yaron Koren (talk) 01:36, 17 January 2022 (UTC)
 * MW 1.37.1, Cargo 3.0 JStallings29 (talk) 01:56, 21 January 2022 (UTC)

Duplicate rows again, but this time only in Special:Drilldown
I have a List of String. Most pages have one value for that field, but some have two.

On the drilldown page, when I select two values as filters, any page with those two values is listed twice. The drilldown page works correctly in other respects and Special:CargoTables doesn't show any duplicate rows.

This is on Cargo 3.0 (07f465d) and MW 1.35.5. I've not noticed the same thing on a MW 1.34.4 wiki and Cargo 3.0 (55f3f72). Jonathan3 (talk) 12:19, 17 January 2022 (UTC)


 * If it helps, a page which matches three selected values on one filter field is displayed three times (ie on three rows). I guess this would apply to any number. Jonathan3 (talk) 10:37, 3 February 2022 (UTC)


 * I've downloaded the latest code today and it's still happening. Maybe it's something simple that I've missed. Jonathan3 (talk) 22:59, 12 February 2022 (UTC)

Query File column without HTML
Hi, first of all, this extension is awesome and makes our life really easy.

I have a column with the Type File which I query for a single File. Is it now possible to get the Image without the HTML surrounding's because I'd only need the filename, like it is stored? I would really like to keep the type of the column on file because of the nice view in the table view.

Thank's for getting back to me.

EDIT: I have found a solution. If I use format=template and just output the value, it work's fine. But if there is another, better solution, I'd be happy to hear from it. --DesignerThan (talk) 23:49, 30 January 2022 (UTC)


 * That's great! One semi-hack you can do is replace FieldName in the "fields=" parameter with CONCAT(FieldName) - then it will be interpreted as type String and not File. Yaron Koren (talk) 15:55, 31 January 2022 (UTC)

Display Format: Dynamic Table with hidden fields
Hi, I have encountered another thing, I don't know how to deal with it. Just wanted to use a query with format set to dynamic table where I want to use hidden fields. The thing now is, that it seem's so that only the last column can be set to hidden... I have this query here on a public wiki.

If someone could help me with it, that would be great. --DesignerThan (talk) 02:05, 3 February 2022 (UTC)


 * Sorry for the delay. I just tried "hidden fields=", and it works fine for me. What specifically are you trying to do, that isn't working? Yaron Koren (talk) 02:30, 18 February 2022 (UTC)


 * Sorry for my delay too. I just have looked into the discussion page again and seen your answer. I am basically just testing some stuff to see what is possible, because I'll need to create an index page later on.
 * I just did test it again on the linked page, you can have a look at the code there. But it is still the same. Hidden fields is still just working for the last column. I have added the Skill Level column and that is still showing up and there is no toggle link being generated. --DesignerThan (talk) 17:01, 22 March 2022 (UTC)

Scribunto : Empty fields missing in mw.ext.cargo.query results table
Hello, I am upgrading my installation from Mediawiki/Cargo 1.35.1/2.7.1 to 1.37.1/3.1.

I am using scribunto for a Cargo query. If I display the resulting table, I see that in the old version, the table has the same number of elements as fields in the Cargo query, whereas in the new version, fields with an empty value do not appear in the result table. Is there a way to get the same behaviour as before?

Best, --Ludovic Strappazon (talk) 16:39, 7 February 2022 (UTC)

Display Format: Dynamic Table with column widths
Hello, thanks for the new features in 3.1, in special "column widths" for dynamic tables. I just updated to. I always get an error when I try to set a value for the first column other than empty (i.e. before the first comma). The error seems to come of the library. Tested it on different tables with different number of columns.

And a second "error" or strange behavior I noticed: This setting for column widths acts on every cargo_query on a page and not only the one, where I added that parameter.

Brabi81 (talk) 07:38, 11 February 2022 (UTC)


 * Sorry about these problems; I believe they're both fixed now, in the latest Cargo code. Yaron Koren (talk) 14:40, 22 February 2022 (UTC)
 * Great! Just updated to the most recent version and everything I tested right now works without errors. Thank you. Brabi81 (talk) 11:58, 23 February 2022 (UTC)

Is Cargo right for this use case?
I'm hoping to use Cargo, but it's not clear to me from the docs I've read here whether or not it's appropriate for my use case. Specifically, at least in some cases, I do not want the typical user to be able to insert new records into the DB (or update or delete existing ones). From the docs, it seems like if I install Cargo and define Cargo table declarations within the wiki, then anyone with permission to edit or create a wiki page can just put cargo_attach and cargo_store calls into some random page, and voila, new database records.

Am I misunderstanding? If not, is there some way to prevent this, short of not letting users edit wiki pages, making the underlying DB read only, or things of that nature? For example, maybe there are $wg settings to define related permissions? I see there's one for create/recreate table, but I didn't see one for create/update records. -Rwv37 (talk) 04:06, 16 February 2022 (UTC)


 * I'm not sure I understand the question. Let's say that there's a template, "Person", which stores to a Cargo table called "People". If a regular user creates a new page that calls that "Person" template, should that page's data not be stored in the Cargo table? If so, when should that data get added to the table? Yaron Koren (talk) 04:28, 16 February 2022 (UTC)
 * Essentially, at least in some cases, what I want Cargo for is to pull data out of a database and easily use it in a wiki. Normal users would be able to use things like cargo_query to do whatever they want with the data, but they would not be able to use things like cargo_store to do whatever they want to the data. -Rwv37 (talk) 04:34, 16 February 2022 (UTC)
 * And to more specifically answer your actual questions: No, the typical user should not be able to insert data into the database, no matter whether through Cargo or otherwise. As for what should get data added to the table: Doesn't really matter, as long as only privileged users can do it. If there's a way to accomplish that in Cargo without allowing unprivileged users to do it too, great. But if not, regular direct DB access through SQL or whatever. -Rwv37 (talk) 04:39, 16 February 2022 (UTC)
 * Sounds like External Data Extension is what you are looking for. I use it in addition to Cargo to pull of data of external MariaDB and display it. Of course on the MariaDB is restricted access and only reads are possible with External Data. Brabi81 (talk) 06:13, 16 February 2022 (UTC)
 * Thanks! I'll check it out. -Rwv37 (talk) 06:18, 16 February 2022 (UTC)

Field type "Wikitext string" missing?
There should be field type "Wikitext string", see.

I am using latest 3.1 version & Page Forms and it seems that no such type exists. Is it bug or feature? :-) And if feature, what is an alternative for short text in wikiformat?

--Radouch (talk) 16:40, 19 February 2022 (UTC)


 * I only ever use Text and String (maybe I should use their wikitext alternatives). Their contents are displayed properly (e.g. bold text) in content pages/queries, but displayed as raw wikitext (e.g. bold text ) on the Special:CargoTables page. Jonathan3 (talk) 00:17, 20 February 2022 (UTC)


 * The "Wikitext string" type has existed for a long time, but it wasn't showing up in Page Forms' Special:CreateTemplate and Special:CreateClass (I assume that's what you are referring to) due to a bug in Cargo - I just checked in a fix for it. Yaron Koren (talk) 04:36, 21 February 2022 (UTC)

Use MATCHES in query and template format
When I use the table format, it shows a relevant extract.

When I use the template format, the  field displays the WHOLE page!

Is there something I need to do to fix this? Thanks. Jonathan3 (talk) 22:38, 24 February 2022 (UTC)

Display internal Cargo errors when invoking #cargo_store?
There are some bugs lurking somewhere in my chain of templates that eventually lead to a call to #cargo_store. However, these are always very tedious to debug because the errors don't seem to be displayed anywhere and are silently swallowed; the only symptom being that the row declared in an article isn't being added to the database.

I seem to vaguely recall that back when I was first setting up Cargo on our wiki, I could run rebuilds of cargo databases from the command line using cargoRecreateData.php and would get errors there that were helpful for debugging, but by now rebuilding the tables takes hours and that's not really an option.

1- is there a way to display the errors that show up on command line from #cargo_store in the wiki UI anywhere? Turning on the following flags didn't include anything useful (lots and lots of junk output, but nothing *useful*): wgShowSQLErrors, wgDebugDumpSql, wgDebugToolbar, wgShowDebug, wgShowExceptionDetails, wgShowSQLErrors

2- Failing that, is there any php script that can be ran on the command line that recreates a single article's data, so that any associated errors can easily be seen?

Thanks! Teltura01 (talk) 19:10, 5 March 2022 (UTC)

Why aren't my calls to working anymore?
I'm working on a query template that will allow entries to any one of 7 fields. In the past, I had this working with a parser call inside the cargo_query call. Now all I get is DB query errors. Here's what I'm doing:

The if parser was only including the where clause if the user had entered something into that field in the query form. The final -pageID>0 was a hack to close any trailing ANDs. This worked like a charm before (and I had to look this solution up on your Talk Archive from 2018 - and it was my solution!) Any reason why the parser if isn't working inside of cargo-query now? May214 (talk) 20:49, 17 March 2022 (UTC)


 * What are the DB error messages you're getting? Yaron Koren (talk) 21:43, 17 March 2022 (UTC)
 * Getting this: [YjPdaeMDSgi5VaCf-l8MpwABDQE] 2022-03-18 01:16:25: Fatal exception of type "Wikimedia\Rdbms\DBQueryError"
 * I've set $wgDebugDumpSql = true; in LocalSettings, but I'm not sure where to find the log of the SQL errors. May214 (talk) 01:29, 18 March 2022 (UTC)
 * Please add "$wgShowExceptionDetails = true;" and "$wgShowSQLErrors = true;" to LocalSettings.php. Yaron Koren (talk) 03:06, 18 March 2022 (UTC)
 * Thank you

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 '{#if:\x0A 4\x0A |Level >= '4' AND\x0A}}\x0A{{#if:\x0A 6\x0A |Level <= '6' ' at line 1 (localhost) Function: CargoSQLQuery::run Query: SELECT `mwhi_cargo__Repertoire`.`_pageID` AS `cargo_backlink_page_id_Repertoire`,`_pageName` AS `RepertoirePage`,`Level` AS `Level`,`_pageID` AS `_pageID` FROM `mwhi_cargo__Repertoire` WHERE {{#if: 4 }} {{#if: 6 }} {{#if:
 * Level >= '4' AND
 * Level <= '6' AND

}} {{#if:
 * Tonic= '' AND

}} {{#if:
 * Mode= '' AND

}} {{#if:
 * Tempo= '' AND

}} {{#if:
 * Period = '' AND

}} _pageID > 0 ORDER BY `mwhi_cargo__Repertoire`.`_pageID`,`_pageName`,`Level`,`_pageID` LIMIT 100 Backtrace:
 * Mood= '' AND

from /home4/pianoiki/public_html/wiki/includes/libs/rdbms/database/Database.php(1809)
 * 1) 0 /home4/pianoiki/public_html/wiki/includes/libs/rdbms/database/Database.php(1793): Wikimedia\Rdbms\Database->getQueryException(string, integer, string, string)
 * 2) 1 /home4/pianoiki/public_html/wiki/includes/libs/rdbms/database/Database.php(1768): Wikimedia\Rdbms\Database->getQueryExceptionAndLog(string, integer, string, string)
 * 3) 2 /home4/pianoiki/public_html/wiki/includes/libs/rdbms/database/Database.php(1327): Wikimedia\Rdbms\Database->reportQueryError(string, integer, string, string, boolean)
 * 4) 3 /home4/pianoiki/public_html/wiki/includes/libs/rdbms/database/Database.php(2012): Wikimedia\Rdbms\Database->query(string, string, integer)
 * 5) 4 /home4/pianoiki/public_html/wiki/extensions/Cargo/includes/CargoSQLQuery.php(1588): Wikimedia\Rdbms\Database->select(array, array, string, string, array, NULL)
 * 6) 5 /home4/pianoiki/public_html/wiki/extensions/Cargo/includes/parserfunctions/CargoQuery.php(102): CargoSQLQuery->run
 * 7) 6 /home4/pianoiki/public_html/wiki/includes/parser/Parser.php(3407): CargoQuery::run(Parser, string, string, string, string)
 * 8) 7 /home4/pianoiki/public_html/wiki/includes/parser/Parser.php(3092): Parser->callParserFunction(PPTemplateFrame_Hash, string, array)
 * 9) 8 /home4/pianoiki/public_html/wiki/includes/parser/PPFrame_Hash.php(273): Parser->braceSubstitution(array, PPTemplateFrame_Hash)
 * 10) 9 /home4/pianoiki/public_html/wiki/includes/parser/Parser.php(3281): PPFrame_Hash->expand(PPNode_Hash_Tree)
 * 11) 10 /home4/pianoiki/public_html/wiki/includes/parser/PPFrame_Hash.php(273): Parser->braceSubstitution(array, PPFrame_Hash)
 * 12) 11 /home4/pianoiki/public_html/wiki/includes/parser/Parser.php(2930): PPFrame_Hash->expand(PPNode_Hash_Tree, integer)
 * 13) 12 /home4/pianoiki/public_html/wiki/includes/parser/Parser.php(1598): Parser->replaceVariables(string)
 * 14) 13 /home4/pianoiki/public_html/wiki/includes/parser/Parser.php(656): Parser->internalParse(string)
 * 15) 14 /home4/pianoiki/public_html/wiki/extensions/PageForms/specials/PF_RunQuery.php(110): Parser->parse(string, Title, ParserOptions, boolean, boolean)
 * 16) 15 /home4/pianoiki/public_html/wiki/extensions/PageForms/specials/PF_RunQuery.php(28): PFRunQuery->printPage(string, boolean)
 * 17) 16 /home4/pianoiki/public_html/wiki/includes/specialpage/SpecialPage.php(647): PFRunQuery->execute(string)
 * 18) 17 /home4/pianoiki/public_html/wiki/includes/specialpage/SpecialPageFactory.php(1366): SpecialPage->run(string)
 * 19) 18 /home4/pianoiki/public_html/wiki/includes/MediaWiki.php(314): MediaWiki\SpecialPage\SpecialPageFactory->executePath(string, RequestContext)
 * 20) 19 /home4/pianoiki/public_html/wiki/includes/MediaWiki.php(930): MediaWiki->performRequest
 * 21) 20 /home4/pianoiki/public_html/wiki/includes/MediaWiki.php(564): MediaWiki->main
 * 22) 21 /home4/pianoiki/public_html/wiki/index.php(53): MediaWiki->run
 * 23) 22 /home4/pianoiki/public_html/wiki/index.php(46): wfIndexMain
 * 24) 23 {main}
 * This is the error log after entering a 4 for LevelLow and a 6 for LevelHi. Looks like template passed the #if parser to the query without parsing. Is there something I could wrap around the mutliple #ifs to get them to parse first before passing it on to the query? May214 (talk) 13:18, 18 March 2022 (UTC)
 * That's strange - I have no idea why those #if calls are not being parsed before #cargo_query is. What changed in your setup, do you know? Yaron Koren (talk) 13:12, 21 March 2022 (UTC)
 * The last time I had this working was in 2018. I took a new job and the project went off my radar, and when I returned to it, it had been completely spam-vandalized - I couldn't even roll back changes.  I'm bringing the project back starting earlier this month.  New version of Mediawiki?  Cargo updates?
 * I tried the #if statements outside of the Cargo Query, and it looks like #if isn't parsing anywhere. (See here:  Has #if been deprecated?  May214 (talk) 14:40, 21 March 2022 (UTC)
 * So, apparently if you want parser functions to work, you have to enable the ParserFunction extension. Who knew!?!
 * I had scanned the extensions included with my MediaWiki install, and the ParserFunctions folder was there, and I had assumed it was active. I checked my localsettings.php, and it wasn't.  I have since enabled, and the #if is parsing beautifully. My apologies for the time suck this caused.  My bad....    May214 (talk) 16:19, 21 March 2022 (UTC)
 * That would certainly explain the problem. :) I'm glad you figured it out. Yaron Koren (talk) 01:16, 22 March 2022 (UTC)

Creation error with huge data tables
I'm trying to create a cargo table with the following definition:

However, table creation always fails. When I delete half of the declaration above my system succeeds with creating the table. I'm running a mediawiki 1.37.1 installation on an Ubuntu 20.04 server and running Cargo 3.1. Holger Most (talk) 22:57, 18 March 2022 (UTC)


 * That is a large table indeed! From a data structure perspective, it may be better to change this into a table (and template) that only has six fields: one for the country (if that's what it is), and the other five for the five values being stored for each country or such. That would give you more flexibility, if you wanted to change either the set of countries, or the set of data being stored for each one. If, however, you want to keep the current structure, my guess is that you can do it by changing the MySQL settings to allow for more storage per table row. Another option is to change the field declarations from something like "Std_INT=String" to "Std_INT=String (size=10)", assuming there can be some limit set on them, to decrease the amount of storage for each String field. Yaron Koren (talk) 13:22, 21 March 2022 (UTC)
 * Thanks Yaron, for the feedback. You are right that it would be a better idea to store the country data in separate tables. The funny thing is, that I was able to create the table above on hte same server, however, with mediawiki 1.35.3 and Cargo 3.0 Holger Most (talk) 08:35, 28 March 2022 (UTC)

cargoRecreateData.php switch in replacement
Hi Yaron, first of all, thanks for the amazing extension and your support. So I have a table that has about 150000 entries and I had an issue where I wanted to switch in the replacement in the web interface and the wiki was showing some error's at first and then, that the DB is offline. So I restarted it and then it worked again. Do you think it is possible that was just to much for the DB? Are there any limitations in size of tables? I don't want to miss use the extension. So now I did recreate the table again on my development wiki with the cargoRecreateData.php-Script and the replacement option activated. Is there a way to switch in the table with this script, or just with the web interface? Thanks for you help. DesignerThan (talk) 17:17, 22 March 2022 (UTC)


 * A table of that size shouldn't cause problems, I think... I don't know why your DB went offline. Hopefully it won't happen if you try it again. There's no way yet to do a switch from the command line, I don't think, unfortunately. Yaron Koren (talk) 19:42, 25 March 2022 (UTC)

CargoQuery help: Why does it work "sometimes"
Working on a cargo query that works "most of the time." I'm wondering if someone can help me figure out what is going on with the few cases where it doesn't work.

Relevant Tables: Repertoire (individual pieces of music) and Books (containing those pieces). I have my Books table set with a repertoire field holding a list of pages from category Repertoire. I would like my Repertoire template page to display the list of books in which that repertoire can be found. On the Repertoire template page I've added this cargo query.

I set up some test books, and it works beautifully....71% of the time. In the first test case, I had Book A, Book B, and Book C. I chose 7 repertoire and assigned them (A) (AB) (ABC) (AC) (B) (BC) (C). Five of the Seven worked perfectly, showing one, two or (three) links to the books that contained them. Two of them showed "no results" in the query area (ABC) and (B).

I tried again with Books E, F, and G - all different repertoire. Again, five of seven worked beautifully except for (EF) and (F).

I'm okay with complete failure, or mostly failure because then I know I have something conceptually wrong. I'm not sure what to do with almost 75% success. I'm thinking the fail has to be somewhere in the pagename. Is there a way to get around that using pageID?

Here's the Cargo Table for Books

The offenders are the Mozart Menuetto (ABC), the Bach, JS, Aria  (B), Bartok Village girls (EF), and Gretchaninoff Woodland Glade (F)

A couple that work nicely: Clementi  (EFG), and Heller Etude  (AC)

Any ideas? May214 (talk) 16:06, 25 March 2022 (UTC)


 * That's very strange - I don't see anything unusual in the page names. Yes, you could try it with _pageID and the PAGEID variable. Another option is to simplify the query, to something like:


 * You might need something more complex from the query, though. Yaron Koren (talk) 19:48, 25 March 2022 (UTC)
 * Perfect. This query is functioning perfectly.  Thanks for the more elegant and efficient query!!!  May214 (talk) 13:54, 28 March 2022 (UTC)

"_pageID" in GROUP BY clause makes grouping of identical columns with different _pageIDs impossible
Since Cargo V3 "_pageID" must appear in the GROUP BY clause. However, this makes it impossible to group by columns that have the same values but different _pageIDs. GROUP BY is thus significantly restricted! Many old query codes are no longer functional.

--Barpfotenbaer (talk) 12:37, 1 April 2022 (UTC)


 * I don't think that is true. Do you have "_pageID" as one of the fields in the "fields=" parameter? If so, that is the cause of the problem. Yaron Koren (talk) 13:16, 1 April 2022 (UTC)
 * Only one single field parameter is set
 * The _pageID isn't referred anywhere. This string is completely missing in my code. I reduced the former complex query to these very simple lines (only identifiers were changed a little in this posting):
 * that's the answer:
 * Barpfotenbaer (talk) 13:38, 1 April 2022 (UTC)
 * Barpfotenbaer (talk) 13:38, 1 April 2022 (UTC)


 * Okay, I did a web search on "muss in der GROUP-BY-Klausel" and found that this is a (German-language) PostgreSQL error message. So, you are probably using PostgreSQL. That makes it hard for me to test, unfortunately. I have no idea why this is happening. What exact Cargo version are you using? Yaron Koren (talk) 14:00, 1 April 2022 (UTC)
 * Cargo 3.1 (0f06913) 08:42, 25. Feb. 2022
 * MediaWiki 1.37.1
 * PHP 8.0.14 (apache2handler)
 * PostgreSQL 13.4
 * Perhaps it is interesting for you to know, that the problem was introduced with Version 3
 * Thanks for your help!
 * Barpfotenbaer (talk) 19:06, 1 April 2022 (UTC)
 * I think the issue is caused somewhere in file includes/parserfunctions/CargoQuery.php line 79-101. The behaviour is described there not as bug, but as feature :-)
 * Barpfotenbaer (talk) 19:45, 1 April 2022 (UTC)
 * Barpfotenbaer (talk) 19:45, 1 April 2022 (UTC)