Extension talk:Cargo

From two tables to three (new user question)
Not a developer, very new to both Cargo and SQL (used third-party DPL for quite a while previously, all trial and error, limited actual grokking involved).

I am trying to grab parameters from a handful of tables (4 or 5), and format them all through a single template.

So far, I can get the basics to work with 2 tables (something I could not manage with DPL, so far so good):

But when I try to pull parameters from a third table, no dice.

I end up with this error:

Error: Table "DraftExtended" is not included within the join conditions.

And advice? Much appreciated. --Bgrenon (talk) 04:13, 1 April 2016 (UTC)


 * I hope I'll tell you nothing wrong, because I'm very new to Cargo, too. Try this:


 * join on=OptionCreate._pageName=DraftOption._pageName,DraftOption._pageName=DraftExtended._pageName
 * I did a test query in this style and it worked with my tables. --~o)sabine(o~ (talk) 15:30, 1 April 2016 (UTC)


 * This works. Thank you very much!  If I can bother you with a follow up - for the second join, does it matter which left table to join on?  --Bgrenon (talk) 21:09, 1 April 2016 (UTC)
 * The results can change according to the order of the joins.
 * Your tables have a hierarchical structure, don't they? I suppose OptionCreate is the parent table. Are DraftOption and DraftExtended both children or is DraftExtended a child of DraftOption? If both have the same level, they both should join to OptionCreate. If DraftExtended has a lower level it should join on DraftOption.


 * rowspan="2" |OptionCreate
 * DraftOption
 * DraftExtended
 * }
 * or
 * DraftExtended
 * }
 * or
 * or


 * OptionCreate
 * DraftOption
 * DraftExtended
 * }
 * Hopefully this explains it in a clear way. --~o)sabine(o~ (talk) 22:39, 1 April 2016 (UTC)
 * }
 * Hopefully this explains it in a clear way. --~o)sabine(o~ (talk) 22:39, 1 April 2016 (UTC)

Cargo and approvedRevs
Can Cargo coexist with approvedRevs extension? If a new page isn't approved, I think it is stored in the cargo table. --Lmorillas (talk) 18:27, 10 April 2016 (UTC)


 * As far as I know, Cargo does work with Approved Revs, though I haven't tested it in a while. Did it definitely do the wrong thing when you tried it? Yaron Koren (talk) 20:21, 10 April 2016 (UTC)


 * Yes, new pages are stored in Cargo Tables although they haven't been approbed. --Lmorillas (talk) 20:45, 10 April 2016 (UTC)


 * Do you have the "blank if unapproved" setting turned on? Otherwise, I think what you're seeing is the right behavior. Yaron Koren (talk) 22:08, 10 April 2016 (UTC)


 * Yes the "blank if unapproved" is turned on but the row with the pageName is added to the Cargo table. Maybe is a limitation of the ApprovedRevs extension and we should use other extension?. --Lmorillas (talk) 04:45, 11 April 2016 (UTC)


 * Is it possible to know the approbation status of a Page inside a Cargo query? --Lmorillas (talk) 08:13, 11 April 2016 (UTC)


 * I just tried this out, and yes - there does seem to be a problem with "blank if unapproved" and Cargo, unfortunately. I'll have to look into it. No, there's no way to query Approved Revs data in Cargo. Yaron Koren (talk) 15:24, 11 April 2016 (UTC)


 * I think I just fixed the problem with "blank if unapproved", mostly - when it's the latest revision being approved or unapproved, sometimes the change doesn't take effect. Yaron Koren (talk) 16:48, 13 April 2016 (UTC)

Auxilar tables are not cleaned when a page is deleted
When a table has fields of type "list of " the auxiliar tables are not cleaned when a page is deleted and a "recreate data" must be done by hand. --Lmorillas (talk) 08:22, 11 April 2016 (UTC)


 * I can't duplicate this error. Are you using the latest version of Cargo? Yaron Koren (talk) 15:35, 11 April 2016 (UTC)


 * Yes, I think it's the latest version (http://innovacion.educa.aragon.es/wiki/Especial:Versi%C3%B3n) I'll prepare a test site to show you the issue. --Lmorillas (talk) 21:52, 11 April 2016 (UTC)

data not updated when changing cargo_store part in a template
I save a calculation in a Cargo field, but used the wrong formula. After correcting this, every page that uses this template had to be resaved to store the new calculated data. Does Cargo care for those changes itself or do I have to use the maintenance script to push this action by hand? --~o)sabine(o~ (talk) 10:33, 12 April 2016 (UTC)


 * No, and no - besides running the script, you can also go to the "Recreate data" tab/action for that template. Yaron Koren (talk) 13:02, 12 April 2016 (UTC)


 * Well, ok. I prefer using the script and avoid getting doubled lines again. Thanks again for the fast answer. --~o)sabine(o~ (talk) 09:04, 13 April 2016 (UTC)


 * I still think you might have gotten that duplicate data only by calling "Recreate data" more than once... anyway, up to you. Yaron Koren (talk) 13:17, 13 April 2016 (UTC)

Error: 1214 The used table type doesn't support FULLTEXT indexes
When I run php setCargoPageData.php, mysql raises this error.

I'm using mysql 5.5 and I'm affraid before MySQL 5.6 Full-Text Search is supported only with MyISAM Engine.

--Lmorillas (talk) 05:33, 21 April 2016 (UTC)


 * Oh, I didn't know that; sorry. I just checked in a fix, so that tables with a "Searchtext" field will always use MyISAM. Hopefully that works. Yaron Koren (talk) 15:45, 21 April 2016 (UTC)

Row number for queries
This is a re-opening of a topic discussed in march 2016. The question here was getting a row number out of query. There were two reasons for wanting to do this. The first was to add an order number (or other similar) to the display results. The second, my use case, was to change the layout of the template based upon which row. For this case you recommended using Extension:NumerAlpha, using a template layout for the query and add the to the template. I've tried this and would like to report it works correctly for both cases. The second case using works great. Only recommendation is you must use NumerAlpha version 0.7 or later, the earlier version don't work. 64.223.164.86 04:06, 22 April 2016 (UTC)


 * That's very good to know! I should add a "Tips and tricks" section, or some such, to hold this kind of information. Yaron Koren (talk) 18:45, 22 April 2016 (UTC)

Three way join fails with Database error
I'm trying to construct a query joining three tables.

When I save the page with this query, then click on the "View Json" link I get the very unhelpful message:

A database query error has occurred. This may indicate a bug in the software.

I've looked through the logs to find either a query definition or a more detailed error message but can't find either. 70.109.135.112 12:09, 12 May 2016 (UTC)


 * Please add "$wgShowSQLErrors = true;" to your LocalSettings.php file; that should give a more useful error message. Yaron Koren (talk) 13:12, 12 May 2016 (UTC)


 * This is very clear and easy to fix. I would recommend adding this error to the list of "common" ones and ensure it gets exported to the user even without the ShowSQLErrors set. Thank you for the hint. 70.109.135.112 13:44, 12 May 2016 (UTC)

Multiple Date fields--only one has specialized date input boxes
In a template including a Cargo table declaration, I have two fields of type "Date":


 * DOB=Date
 * DOD=Date

I created a form that uses this template. When I use the form to create new records in the table, the input for the first is a simple text box, whereas that for the second is a set of three boxes (popup for month, and text boxes for date and year. Why are they not the same for both fields? (Both show in the same format; e.g., May 16, 2016, when I view the table.


 * This sounds like an error in Semantic Forms' parsing of the template; if you pastebin, or otherwise link to, the template text, I can look into it. But if you ever encounter such an error, you can get around it by hardcoding the Cargo information in the form field, using the "cargo table=" and "cargo field=" parameters. Yaron Koren (talk) 03:26, 17 May 2016 (UTC)
 * Here are the source text for the template Template:Composer and the form Form:Composer. I hard-coded the field types, but that didn't solve the problem for one field (GivenNames). Is this from coding errors or oversights?
 * The "GivenNames" one is not working because "string" is not an input type - it should be "text" (or something else). Yaron Koren (talk) 16:38, 20 May 2016 (UTC)
 * Fixed, thank you.--Egnatoff (talk) 18:25, 20 May 2016 (UTC)
 * The documentation [Extension:Cargo/Storing_data#Declaring_a_table] does show "String" as a pre-defined field type--64.118.28.179 18:03, 23 May 2016 (UTC)
 * It's a Cargo field type; it's not a Semantic Forms input type. (Both sets include a "text" type, which I know adds to the confusion.) Yaron Koren (talk) 19:00, 23 May 2016 (UTC)

Determining page title from concatenating fields at time of table data entry
I would like to be able to use a form to enter data into a table without first having to specify a name for the associated page that is created. Rather, I would like the name of that page to be determined by concatenating the values of two or more fields, and then populating that page with other data in the record (according to specifications in the associated template). Please suggest how I might do that, or propose an alternate approach.

Example 1: Category, Table, Template, Form: Composer. Fields include Surname and GivenNames and I would like the associated page to be the value of FullName:

Example 2: Concert. Fields include Series, Title, Date. Page title would be Series Title Date.

I want this capability in order to facilitate data entry and to ensure that I have unique names for the pages of a given category without having to enter the details twice.


 * This sounds like a Semantic Forms question, not Cargo; but this might be what you're looking for. Yaron Koren (talk) 17:48, 17 May 2016 (UTC)
 * Exactly the reference I needed; thank you.--Egnatoff (talk) 19:22, 17 May 2016 (UTC)
 * I was able to use the one-step process successfully, but was not able to solve the problem of specifying the page name using the input field values from two fields. Here are the source text for the template Template:Composer and the form Form:Composer. In this version of the form, I used, which gave the error message, "The specified target page  is invalid." The same thing happened when I used  . Everything, including creating a new row in the Cargo table, works properly when I specify the page name as the value of a single field for which data are entered when the form is invoked and submitted.--Egnatoff (talk) 15:47, 20 May 2016 (UTC)
 * It should be "page name=   ". Yaron Koren (talk) 16:03, 20 May 2016 (UTC)
 * Works, thank you. I now understand my mistake.--Egnatoff (talk) 18:28, 20 May 2016 (UTC)

where HOLDS LIKE "%Text%" OR IS NULL
I have a join on sql query with a HOLD LIKE in the where clause. I just discovered that entries without a contact are missing, and it turns out because the Role field is empty and doesn't match the HOLD LIKE in where.

tables=Ident,Dates,Details,Contacts |join on=Ident._pageName = Dates._pageName, Ident._pageName = Details._pageName, Ident._pageName = Contacts._pageName |where=Contacts.Role HOLDS LIKE "%Lead%"

if I add something like " OR Contacts.Role IS NULL" I get an error...

Error: operator for the virtual field 'Contacts.Role' must be 'HOLDS', 'HOLDS NOT', 'HOLDS LIKE' or 'HOLDS NOT LIKE'.

Basically I want to be able to fill in the table with name of the Lead Role Contact if it exists, but not require the field. If I remove the where clause, the left outer join works, but I get lots of rows because each item has multiple contacts. Have you encountered this limitation or thoughts on how to work around it within allowed sql syntax? --Kc5vcx (talk) 18:43, 25 May 2016 (UTC)


 * I figured out a solution with IFNULL (added to wgCargoAllowedSQLFunctions)

|where=IFNULL(Contacts.Role HOLDS LIKE "%Lead%", 1)
 * --Kc5vcx (talk) 19:35, 25 May 2016 (UTC)

Fatal Error "MWException" upon trying to invoke View table
Hi Yaron,

After not getting any further with SD (see: https://www.mediawiki.org/wiki/Extension_talk:Semantic_Drilldown#Drilldown_partially_not_working) I am trying to follow your advise and I am trying to get Cargo working. As I have another issue (cannot get access via SSH to my host), I decided to try first on my PC, installing LAMP, Mediawiki, and my DB from www.cienagagrande.co. So what I have: Ubuntu 14.04.4 LTS, Apache/2.4.7 (Ubuntu), PHP Version 5.5.9-1ubuntu4.17 (apache2handler), mysql Ver 14.14 Distrib 5.5.49, for debian-linux-gnu (x86_64) using readline 6.3, Mediawiki 1.26.3. Cargo was installed apparently fine and in the database I can see the (empty) cargo__pages and cargp__tables. Trying to start with a most simple test I made the template "CGSM-Noticia" with

created the tabel, but than get on Table view the above mentioned fatal error.

Thanks for any advise!


 * It shouldn't be "Source of Page", it should be either "List  of Page", or maybe just "Page". I don't know if that's what is causing the error, though. Yaron Koren (talk) 23:05, 25 May 2016 (UTC)
 * Thanks, I'm still struggling and still have not really understood the extension, but I think the error must be something else. I have changed the code to

being "Source" the existing property name of type Text, assuming I can use it in order to transfer the containg values to the table=News....the error is the same.


 * Did you recreate the table after changing the template? You need to do that. Yaron Koren (talk) 10:22, 26 May 2016 (UTC)
 * Yes I did...I have the feeling it has to do with the LAMP setup at my home PC because also the SMW pages produce strange errors. When I create new pages with the forms they result in -1 namespace errors which, I think, indicates that s something wrong with the MySql in general, even though the db reports fine.
 * Ah - if you're getting strange errors with SD, SMW and Cargo, there may well be something wrong with your overall setup, like with the database. Yaron Koren (talk) 11:26, 29 May 2016 (UTC)
 * Fatal exception of type "MWException" - Solved! The reason -in my case- was the table/field name, containing a "-". Thus it should be noted in https://www.mediawiki.org/wiki/Extension:Cargo/Storing_data#Declaring_a_table that not only spaces are disallowed, but also this (and possibly other) special characters. Regards, Horst, 6 June 2016
 * That's great, that you found the issue. I just checked in a fix for hyphens in field names, so now hopefully it should work... Yaron Koren (talk) 18:27, 7 June 2016 (UTC)

Fatal exception of type MWException on RunQuery Template
Hello Yaron,

I'm trying to use the RunQuery special page to create a query form on my cargo database. This is the query form definition:

Formulaire utilisé par la 'page spéciale exécute requête MagDBQueryTest'.

This is the result template : Modèle d'affichage du résultat de requête. Elle est appelée via le formulaire Form:MagDBQueryTest.

(Mot Clé "") <-- INSERT CARGO QUERY HERE -->

Without any cargo query inserted in the template or with a request with no results, it's "work", I mean, the template is correcly called with the right value for  and I have got the 'no result' sentence on my page - but when I'm supposed to get some results, I have a "Fatal exception of type MWException" even if I use a query that works on another template page ... what's wrong doc ?

Thanks for help

Guillaume Prêcheur (talk) 15:12, 30 May 2016 (UTC)


 * What happens if you call the template in some page, like setting the text to be " "? Yaron Koren (talk) 20:12, 30 May 2016 (UTC)


 * The template works well outside of the RunQuery context ! Guillaume Prêcheur (talk) 07:38, 31 May 2016 (UTC)


 * Please add the following line to LocalSettings.php:

$wgShowExceptionDetails = true;
 * That way, you'll hopefully see a more informative error message. Yaron Koren (talk) 13:21, 31 May 2016 (UTC)
 * here it is :

[d3ea54aa] /wiki/index.php/Sp%C3%A9cial:RunQuery/MagDBQueryTest Exception from line 6347 of /var/www/html/wiki/includes/parser/Parser.php: Parser state cleared while parsing. Did you call Parser::parse recursively?

Backtrace:


 * 1) 0 /var/www/html/wiki/includes/parser/Parser.php(374): Parser->lock
 * 2) 1 /var/www/html/wiki/extensions/Cargo.0.10.last/CargoUtils.php(290): Parser->parse(string, Title, ParserOptions, boolean)
 * 3) 2 /var/www/html/wiki/extensions/Cargo.0.10.last/CargoQueryDisplayer.php(181): CargoUtils::smartParse(string, Parser)
 * 4) 3 /var/www/html/wiki/extensions/Cargo.0.10.last/CargoQueryDisplayer.php(139): CargoQueryDisplayer::formatFieldValue(string, NULL, CargoFieldDescription, Parser)
 * 5) 4 /var/www/html/wiki/extensions/Cargo.0.10.last/CargoQueryDisplayer.php(245): CargoQueryDisplayer->getFormattedQueryResults(array)
 * 6) 5 /var/www/html/wiki/extensions/Cargo.0.10.last/parserfunctions/CargoQuery.php(114): CargoQueryDisplayer->displayQueryResults(CargoTableFormat, array)
 * 7) 6 [internal function]: CargoQuery::run(Parser, string, string, string, string)
 * 8) 7 /var/www/html/wiki/includes/parser/Parser.php(3753): call_user_func_array(array, array)
 * 9) 8 /var/www/html/wiki/includes/parser/Parser.php(3471): Parser->callParserFunction(PPTemplateFrame_DOM, string, array)
 * 10) 9 /var/www/html/wiki/includes/parser/Preprocessor_DOM.php(1179): Parser->braceSubstitution(array, PPTemplateFrame_DOM)
 * 11) 10 /var/www/html/wiki/includes/parser/Parser.php(3623): PPFrame_DOM->expand(PPNode_DOM)
 * 12) 11 /var/www/html/wiki/includes/parser/Preprocessor_DOM.php(1179): Parser->braceSubstitution(array, PPFrame_DOM)
 * 13) 12 /var/www/html/wiki/includes/parser/Parser.php(3281): PPFrame_DOM->expand(PPNode_DOM, integer)
 * 14) 13 /var/www/html/wiki/includes/parser/Parser.php(1239): Parser->replaceVariables(string)
 * 15) 14 /var/www/html/wiki/includes/parser/Parser.php(405): Parser->internalParse(string)
 * 16) 15 /var/www/html/wiki/extensions/SemanticForms-3.4.1/specials/SF_RunQuery.php(99): Parser->parse(string, Title, ParserOptions)
 * 17) 16 /var/www/html/wiki/extensions/SemanticForms-3.4.1/specials/SF_RunQuery.php(30): SFRunQuery->printPage(string, boolean)
 * 18) 17 /var/www/html/wiki/includes/specialpage/SpecialPage.php(363): SFRunQuery->execute(string)
 * 19) 18 /var/www/html/wiki/includes/specialpage/SpecialPageFactory.php(584): SpecialPage->run(string)
 * 20) 19 /var/www/html/wiki/includes/MediaWiki.php(275): SpecialPageFactory::executePath(Title, RequestContext)
 * 21) 20 /var/www/html/wiki/includes/MediaWiki.php(584): MediaWiki->performRequest
 * 22) 21 /var/www/html/wiki/includes/MediaWiki.php(435): MediaWiki->main
 * 23) 22 /var/www/html/wiki/index.php(46): MediaWiki->run
 * 24) 23 {main}
 * Guillaume Prêcheur (talk) 14:06, 31 May 2016 (UTC)


 * You're using old versions of Cargo and Semantic Forms - try upgrading both. Yaron Koren (talk) 14:44, 31 May 2016 (UTC)
 * I upgrade Cargo-1.0.1 and SemanticForms-3.4.1 ... same issue -
 * I'm running MediaWiki (1.24.1) and SemanticMediaWiki(2.1.1)
 * Do I need to upgrade them or to run a php update.php ??

Guillaume Prêcheur (talk) 14:46, 31 May 2016 (UTC)
 * Your MW is fine, and SMW is probably irrelevant. But you should be using the latest SF, 3.6. No need to call update.php. Yaron Koren (talk) 16:47, 31 May 2016 (UTC)
 * Sorry I already updated to SF 3.6 as you told me (but made a mistake typing the message) - same exception :-( Guillaume Prêcheur (talk) 07:29, 1 June 2016 (UTC)
 * Oh well. What does the query look like? Yaron Koren (talk) 13:32, 1 June 2016 (UTC)
 * Here is my query included in the template. This template works well when embeded into an another page - it only faild when accessed from the RunQuery ! Guillaume Prêcheur (talk) 07:15, 2 June 2016 (UTC)

Cette page correspond au modèle d'affiche du résultat de requête de test. Elle est appelée via le formulaire Form:MagDBQueryTest. Requête : (Mots Clé "")

Is something missing here? The query itself isn't using anything that was passed in. Yaron Koren (talk) 15:28, 2 June 2016 (UTC)
 * Hello Yaron, this is actualy a fake query: to find the origin of the issue, I simplified the query code intentionnally, in the final application the "where" condition will be upgraded and will use the template's parameters, nothing missing - Guillaume Prêcheur (talk) 07:38, 3 June 2016 (UTC)
 * I found that the problem comes from the fields CONCAT and SUBSTRING parsing - If I remove these functions from the query (like following), the query works well !

|fields=MagDBCompetenceCollaborateur.Competence=Compétences,count(MagDBCompetenceCollaborateur._pageName)=
 * unfortunately, I need to use theses function to format my result ... Guillaume Prêcheur (talk) 14:06, 7 June 2016 (UTC)


 * I finally looked into this, and fortunately was able to duplicate the issue. I just checked in what I think is a fix; if you get the latest version from Git, hopefully the problem will go away. Yaron Koren (talk) 18:00, 10 June 2016 (UTC)
 * Nice - Unfortunately, I urgently had to rollback the Cargo and SemanticForms production installs repectivly to the 0.10 and 3.4.1 because of a access page error on the skill edition form - occured with the last releases. I let inform you when I get time to analyse this new issue ... Guillaume Prêcheur (talk) 09:25, 13 June 2016 (UTC)

Coordinates and precision
The Cargo documentation for storage of coordinates states:

But actually fieldName__lat and fieldName__lon are stored as standard float. This introduces a problem, as standard MySQL uses 4 digits after the decimal point, i.e. float(7,4). When using SemanticForms, coordinate inputs (and thus our data in fieldName__full) has a precision of 5 digits after the decimal point. Also Googlemaps is using 5 digits.

This results in a offset of ~3m of MapMarkers displayed via fieldName__full (e.g. #cargo_display_map ) or via fieldName__lat/fieldName__lon (e.g. #cargo_query ).

@Yaron: Could you change the fieldName__lat and fieldName__lon to float(8,5) on creating the database tables? Couldn't find it in the code myself...


 * Thanks for pointing out the error in the documentation. Do you think it would work to just change the MySQL representation from a Float to a Double? Yaron Koren (talk) 16:04, 1 June 2016 (UTC)


 * Yes, that does work, and it's exactly what I did by hand. Just couldn't find the place to change your code so it does set up the MySQL respresentation for coordinates as Double by default. Friedrich Seydel 10:55, 15 June 2016 (UTC)


 * Okay, I just checked in that change into the Cargo code. Hopefully coordinates now get their full precision, in MySQL... Yaron Koren (talk) 14:07, 15 June 2016 (UTC)

Multiple data output
Sorry for keeping on bothering....After having installed from scratch Mediawiki 1.26.2 and the latest Cargo version 1.0.1 (1d7e56f) 13:20, 6 June 2016 on http://www.zonacostera.info/CGSM and getting +/- acquainted to Cargo I initially was happy to see that my 145 pages of http://www.zonacostera.info/CGSM/Category:CGSM_-_Noticias are displayed fine, including the Drilldown. But now I see that the data pages are starting to show up double and triple...: http://www.zonacostera.info/CGSM/Special:CargoTables/CGSM_Noticias

The template code is:

This is a "CGSM en las noticias" item.

What am I doing wrong?? Thanks for any advise! Horst 7th June 2016 ....Just noticed one too many and deleted it...could that have been the reason? No, it s not...


 * Could it be that, over the course of setting up the data structure, you called "Recreate data" for the template more than once? In any case, the fix is to call "Recreate data" yet again... but make sure that all the previous recreating has completely finished. I do hope to get this working better, so that calling "Recreate data" wipes out all the pending jobs from before, but that hasn't happened yet. Yaron Koren (talk) 18:54, 7 June 2016 (UTC)
 * I certainly did...I shall try to be patient and than try again...but maybe there is a way to "hard reset"?.. or would it do any good to delete the table and than recreate?
 * You could delete everything in the "job" DB table, then recreate. Recreating already deletes the Cargo table. Yaron Koren (talk) 20:44, 7 June 2016 (UTC)

Database field to populate dropdown
I'm trying to use a database field to populate a dropdown box on a form but with no success. I've got a cargo table that holds a list of substances and want to use this list in another form to populate the values in a dropdown box.

This is the code that I'm using.

{| class="wikitable"

! Substance:

What I would expect is that the cargo query returns a comma delimited list of substances such as which it does if I just run the query directly in the page. But if I run it in the code as above I get one row in my dropdown box that contains

Is this a bug or am I doing something wrong?

Cheers.


 * That may be a bug, although thankfully there's an easier way to do this: " ". Yaron Koren (talk) 12:05, 10 June 2016 (UTC)

Brilliant, Thank you. This works a treat :)

Can't use for database results
I'm trying to add the result of a database query but get an error

I've set the field up in the database as an Integer and a Float but keep getting the same error, my code is

Any help is appreciated.


 * It's too bad that that's not working - it seems like this is the same issue as above, where nesting #cargo_query fails. Unfortunately, adding the math into the query - i.e., making the field name "Revision + 1" - will also fail, because Cargo's parsing doesn't handle that. The only solution I think of is to create a Lua module for this, using the Scribunto extension - see here. I wish there were an easier way. Yaron Koren (talk) 16:29, 10 June 2016 (UTC)

I've just tried Lua but am having trouble getting the result back. Here's my LUA script.

local p = {} local cargo = mw.ext.cargo local result = {}

function p.Rev( frame ) tables = 'Substance' fields = 'Revision' local args = { where ='Substance="Cleaner" ', limit = 1 } result = cargo.query (tables, fields, args) return result

end return (p)

and I'm calling this with..

And the result that it gives me back is 'table' instead of returning the contents of the result.


 * I'm far from a Lua/Scribunto expert, unfortunately, but I think something like "return result[1]['Revision']" (maybe also with a " + 1" at the end) would be closer to the mark than just "return result". Yaron Koren (talk) 13:24, 13 June 2016 (UTC)

Controlling separator in display of lists on pages displaying fields whose values are lists
(Note: if this question would be better placed on a different talk page, please suggest where.)

I want to display a list of field values with a separator other than the default comma (preferably a semi-colon). This example shows the relevant coding and the resultant displays both on the new page created and on the associated Cargo table.

From the template "Piece"

. ..

! Instrumentation . ..

From the form "Piece" {| class="formtable" . . . ! Instrumentation:

Entry in the "Instrumentation" field when using the form Piece (which is also the desired display on the new page): flute, piccolo; violin

Resultant display on the new page (no semi-colon): flute, piccolo, violin

Resultant display in the "Instrumentation" column on the new line in the "Pieces" Cargo table: flute, piccolo · violin

--Egnatoff (talk) 22:40, 14 June 2016 (UTC)


 * If I understand the question correctly, maybe the easiest solution is to remove the #arraymap call and replace it with just " ". Yaron Koren (talk) 11:57, 15 June 2016 (UTC)
 * Thank you; that solved the problem.--Egnatoff (talk) 17:59, 16 June 2016 (UTC)

Conditionals in "page name" parameter in Cargo data entry form
I have two problems that require conditionals in using the “page name” parameter in a Cargo table data entry form.

I currently have the following in a form “Piece” used for data entry into a Cargo table “Pieces”:

1. I only want a comma between Title and OpusNumber if the OpusNumber field is not null.

2. The Composer field (as specified in the #cargo_declare: clause) is of type “list of Page”. The field specification in the form is as follows:

! Composer:

Currently a comma is inserted in the resulting page title after the last item in the Composer list. I only want the comma between multiple entries.

For example using the form to create a new Piece with Title “With a Little Bit of Luck” and two entries in Composer “Alan Jay Lerner” and “Frederick Loewe” produces a page title “With a Little Bit of Luck, —Alan Jay Lerner, Frederick Loewe,”. In such a case, I want the page title to be “With a Little Bit of Luck—Alan Jay Lerner, Frederick Loewe”. --Egnatoff (talk) 20:44, 16 June 2016 (UTC)


 * These are both Semantic Forms questions, not Cargo questions. But I don't think either one is currently doable, unfortunately. The 2nd one could be considered a bug, and might be fixable. Yaron Koren (talk) 23:52, 16 June 2016 (UTC)
 * Thank you. I will then simplify the structure and deal with the situations in question by hand.--Egnatoff (talk) 03:44, 17 June 2016 (UTC)

Cargo not creating tables
This issue when I query:

Error: table "Testplate" not found.

Upon looking at the database, cargo_tables is empty. Clicking "Create data table" and running php cargoRecreateData.php do not remedy the issue.

I'm using the example books & author templates from the quickstart guide, copied & pasted & double checked for any errors.

Database is using the default wiki user with full permissions, it's working for the rest of the wiki and no custom db set for Cargo. PHP	5.3.3 (cgi-fcgi) MySQL	5.1.73 MediaWiki 1.24.1 (647e7c2) Semantic MediaWiki  2.2.1 Cargo	1.0.1 --Frybread (talk) 09:52, 24 June 2016 (UTC)


 * What happens when you run cargoRecreateData.php? Do you see any error messages? Does it print anything at all? Yaron Koren (talk) 13:12, 24 June 2016 (UTC)


 * It doesn't print anything at all. Tried running as root as well, nothing. --Frybread (talk) 17:44, 24 June 2016 (UTC)


 * It seems like Cargo isn't aware of any of the #cargo_declare calls. Could it be that you created those templates before installing Cargo? In any case, resaving those templates (making a slight change first) and then trying again may work. Yaron Koren (talk) 01:19, 27 June 2016 (UTC)

I'm also having a problem with Cargo not creating tables. In the noinclude section I have: In the includeonly section I have: Once I save the page I see: "This template defines the table "GiveawayItems". This table has not been created yet." I then click on More/Create data table and the process seem to start as a little turning wheel appears under the "Create data table" title. However, the process seems to get stuck in a loop and never ends.

So far I have not found any errors in the logs. Any idea how I could debug this further? Kind regards -- manu3d (talk) 23:45, 31 July 2016 (UTC)


 * Let me offer you the same advice I gave the other person: try running cargoRecreateData.php. Yaron Koren (talk) 05:10, 1 August 2016 (UTC)


 * My apologies, I should have mentioned that I did run cargoRecreateData.php and had the same issue as Frybread: no output and no resolution. Furthermore I can confirm I wrote the template after installing Cargo. Anything else I can try? Especially, it's quite important for the web-based interface to work so that other users can take advantage of Cargo. I'd love to be able to help debugging this particular problem. I can delve into PHP code but I don't know enough about how the Mediawiki-programming context to know where to begin placing logging statements to see the content of variables or simply where things get into a neverending loop. If you could provide some guidance in this context I can try and find where the problem is and in what circumstances it arises. -- manu3d (talk) 22:52, 1 August 2016 (UTC)


 * What do you see if you go to the URL "/w/api.php?action=cargorecreatetables&template=GiveawayItem" on your server, or something like that? (Assuming the name of the template is "GiveawayItem".) Yaron Koren (talk) 12:58, 2 August 2016 (UTC)


 * A-ha! I get You don't have permission to access /w/api.php on this server. That can't be good. =) I thought I read something about api.php on the Cargo pages. Something about giving permissions to interact with it, but I can't find it anymore. Am I confusing this with another extension? The other possible avenue of investigation is that it might just be an .htaccess problem, i.e. one of its rules getting in the way. Let me know if I have to do something inside MediaWiki to solve this issue please. Otherwise I'll start looking into the .htaccess file. -- manu3d (talk) 22:24, 2 August 2016 (UTC)


 * That's surprising, but it may explain the problem. Just to be sure - if you go to /w/index.php, does it take you to the wiki's main page? If so, this is the problem. It's not a MediaWiki issue; it would need to be fixed in either the file system or the web server. Yaron Koren (talk) 04:07, 3 August 2016 (UTC)


 * I just checked and you are correct /w/index.php brings me to /wiki/Hauptseite which is the (german) main page of the wiki. So, is the problem related to the use of ShortURLs perhaps? I'm going to check the documentation on ShortURLs. Perhaps that's where I saw some specific info regarding api.php. Otherwise I'll start looking into .htaccess. (10 mins later) Actually, I now seem to remember something in my .htaccess file regarding restricting execution of .php files to "index.php". So that might be it. I'll let you know in the next few days. -- manu3d (talk) 20:13, 3 August 2016 (UTC)


 * Problem solved. The line RewriteCond %{QUERY_STRING} (^|&)t(p|emplate|mpl)= [NC] in the htaccess file was preventing the request because the api.php url contained the world "template". I fixed it now and it works just fine. Thank you for helping me isolate the problem! -- manu3d (talk) 22:25, 6 August 2016 (UTC)


 * That's great! I'm curious about that line, though, and whether it's widespread on servers. I looked it up and saw that it seems to be getting used for Joomla! installations. Is that the case for you? Yaron Koren (talk) 01:23, 7 August 2016 (UTC)


 * That is the case. The starting point for the htaccess file I'm using is here and is part of Joomla's Security Checklist pages. The "offending" line originates from that file. If you find a way to change that line so that it doesn't interfere with Cargo please let me know! -- manu3d (talk) 21:59, 7 August 2016 (UTC)


 * You can just remove the "|emplate" string from that line... although I don't know if that will lead to any security vulnerabilities. Maybe the right solution is for Cargo itself to just change the name of its parameter. For now, I added a note about this to the "Common problems" page. Yaron Koren (talk) 02:27, 8 August 2016 (UTC)

Problems with list fields
Hi

I'm using cargo for some time now and I accumulated some problems with list fields:
 * 1) Recreating cargo tables produces php notices Undefined index in Cargo/parserfunctions/CargoStore.php on line 293 and 315 (not really a problem, since error reporting is only activated on my dev system where I noticed this)
 * 2) Having a field definition in Semantic Forms with cargo table and cargo field set to point to a list field produces a "Table does not exist" when accessing the form for the first time (aka: the table is emtpy). One has to remove cargo table and cargo field, create at least one entry and then they can be added again. Methinks that has to do something with type ahead suggestions (propagation of the autocomplete field).
 * 3) Most anoying: I have some list fields of type page whose *__full field exceeds the 300 characters leaving me with one of two options: I can cargo query normally for the field in the table, knowing very well that the result will be cut [0] or I can create a join and then loose the linking to the pages having to reintroduce it manully in the query [1]. Note: size in the #cargo_store definition does neither apply to page fields in generell nor to the *__full field of the list. Furthermore I have a bot gathering some data using a generic function which has no way of knowing, whether it queries a list field or a normal field making it impossible to use the join workaround.

I would appreciate any input on this...

[0] Normal query

[1] Join query

On system (amongst others): MW 1.23.14 Semantic Forms 3.7 Cargo 1.0.1

Tobias (talk) 12:18, 1 July 2016 (UTC)
 * Just noticed, calling index.php?title=Group:ToManyMembers&action=pagevalues yields the same unwanted trimmed result, indicating this also accesses the *__full field. :(
 * Tobias (talk) 10:00, 5 July 2016 (UTC)


 * Hi, sorry for the delay. For #2 - what version of SF are you using? (It's not 3.7, because that hasn't come out yet.) For #3, I just checked in a small change that I think fixes this issue - I didn't fully test it. Yaron Koren (talk) 04:38, 7 July 2016 (UTC)


 * I'm sorry, you are right. I'm on SF 3.6 (0dae7d5) 16:28, 4. Mai 2016. Thanks for responding. I'll try your fix asap. Tobias (talk) 05:56, 7 July 2016 (UTC)

Not getting anything but page name
I've got queries that were working before I updated to mediawiki 1.27 and the latest version of Cargo via git, but now they only return the page name. None of the other fields in the query return anything, but when I go the page and look at the page values the values are there, and stay there after a purge.

--Cody3647 (talk) 17:00, 14 July 2016 (UTC)
 * Not working
 * Working


 * Very strange! I haven't seen this before. It looks like the issue is with the display of any field that has an alias - whether it's "Page" instead of "_pageName" or "npc permission" instead of "npc_permission", etc. Beyond that, I don't know. Could you try to narrow down whether it's due to the difference in the MediaWiki vs. the Cargo versions? Yaron Koren (talk) 18:08, 14 July 2016 (UTC)


 * I've updated Cargo on the mediawiki 1.26 installation via git and everything seems to be working, though the version listed in history hasn't updated. --Cody3647 (talk) 18:54, 14 July 2016 (UTC)


 * Okay - it must be the MediaWiki version, then. My guess is that the issue is with extension.json, which is only called for MW 1.27 and higher. Could you try commenting out the extension.json stuff, at the top of Cargo.php, in the non-working wiki, and see if that fixes the problem? Yaron Koren (talk) 20:28, 14 July 2016 (UTC)


 * I changed the version compare to 1.28, and the 1.27 install is still not working. --Cody3647 (talk) 22:11, 14 July 2016 (UTC)


 * Oh well. I guess there are three options: you can try to figure out the problem yourself, you can give me login access on your server and I can try to figure it out, or I can upgrade my own wiki to 1.27 and see what happens. (I do plan to upgrade my wiki anyway, but I didn't have any specific timeframe for that.) Yaron Koren (talk) 00:14, 15 July 2016 (UTC)


 * Looking at the sql query that is being passed in the $res object in CargoSQLQuery::run, its getting extra ` around aliases.  .  I commented out   in CargoGalleryFormat::display fixes it, but instead of adding it to the stylesheet like a normal wiki gallery does, it adds it in a style block in the head.  Only a problem because it then overwrites some changes I'd made to the gallery css through the skin. --Cody3647 (talk) 00:09, 16 July 2016 (UTC)


 * Did you really report this problem before? I don't remember hearing about it before. But yes, you're right - the 'gallery' format was only displaying correctly when there was no page caching. I just checked in a change that disables the page cache when the gallery format is called, which is my go-to fix for cases like these. Hopefully that solves this problem. Yaron Koren (talk) 01:30, 18 July 2016 (UTC)


 * I took a look again, and I'm not sure the cache needs to be disabled. The following two lines, before I was using only one, seem to work and adds it into the external stylesheet loaded on page load rather than the dynamic style block added after page load, so no jumping from list to gallery anymore whether just refreshed or purged.  Also, just FYI: Missing Gallery Module for Packed-hover gallery
 * --Cody3647 (talk) 02:27, 18 July 2016 (UTC)


 * Ah! That sounds familiar; although I didn't think it was the same issue. Anyway - isn't my solution superior, in that it doesn't overwrite any CSS? Or does it not really matter? Or does my solution not work for you? Yaron Koren (talk) 02:33, 18 July 2016 (UTC)


 * I don't think it overwrites anything, just adds the module into the stylesheet like it would if you just used the gallery tag. I'm not opposed to turning off the cache, I just know that its generally useful?  I know I have a number of pages with multiple queries, several galleries and others, and just figure that its better to have those cached rather than not.  --Cody3647 (talk) 02:37, 18 July 2016 (UTC)


 * Alright - if there's no overwriting, then yours is indeed the better solution. I just checked it in. Thanks! Yaron Koren (talk) 14:52, 18 July 2016 (UTC)

List of URL data type leads to SQL error
I have a template with a Cargo declaration of the form:

When trying to view the resulting table, I get an SQL syntax error (1064) reported in CargoSQLQuery::run. The reported query is as follows: SELECT `_pageName` AS `Page`,CONCAT('[', Field1, ' URL]') AS `Field1`,CONCAT('[', Field2, ' URL]')__full AS `Field2`,`Field3` AS `Field3`  FROM `cargo__Tests`    ORDER BY `_pageName` LIMIT 100 The problem seems to be with the concatenation of the parts of Field2 call. This is with Cargo 1.0.1 (5ed9912) on MediaWiki 1.27.0 and MariaDB 10.0.25. -- Paul T (talk) 20:28, 1 August 2016 (UTC)


 * Sorry for the delay. Yes, this was a bug - I just checked in a fix for it. Yaron Koren (talk) 17:00, 4 August 2016 (UTC)


 * Thank you. That works! Paul T (talk) 08:52, 5 August 2016 (UTC)

Undefined constants when specifying additional fields for _pageData table
Following the instructions in on the "Storing page data" part of the Storing data page, I have added $wgCargoPageDataColumns[] = CARGO_STORE_CREATION_DATE; to LocalSettings.php, below Cargo's require_once call. When trying to create the table, I get the following: $ php setCargoPageData.php PHP Notice: Use of undefined constant CARGO_STORE_CREATION_DATE - assumed 'CARGO_STORE_CREATION_DATE' in /var/www/html/w/LocalSettings.php on line NNN The same happens for the other constants. The _pageData table is successfully created, but it doesn't include any of the optional fields.

Have I missed some subtlety, or is this a bug? Many thanks! Paul T (talk) 10:52, 10 August 2016 (UTC)


 * Ah, it looks like the handling for the page data constants with extension.json - which is used with MediaWiki 1.27 and higher - doesn't work. I just changed it to a setup that's probably better in all cases. The constant names have changed - you should replace "CARGO_STORE_" with "CargoPageData::" in each of the names, so it would look like:

$wgCargoPageDataColumns[] = CargoPageData::CREATION_DATE;
 * If you get the latest code, please try this out and let me know if it works for you. Yaron Koren (talk) 13:52, 10 August 2016 (UTC)
 * Thanks. With the latest code and that change, I'm getting this: PHP Fatal error: Class 'CargoPageData' not found in /var/www/html/w/LocalSettings.php on line NNN
 * Paul T (talk) 15:16, 10 August 2016 (UTC)
 * That's not good. Are you calling Cargo in LocalSettings.php with wfLoadExtension, by any chance? Also, what version of MediaWiki are you running? Yaron Koren (talk) 02:01, 11 August 2016 (UTC)
 * No, it's: require_once( "$IP/extensions/Cargo/Cargo.php" );
 * ... which has been working fine in all other respects. The attempt to set $wgCargoPageDataColumns[] is immediately below that. This is Cargo 1.0.1 (e0dbafe) with MediaWiki 1.27.0 on PHP 5.6.24 on Debian. Paul T (talk) 08:29, 11 August 2016 (UTC)


 * Okay, I finally tested this out directly. It turns out that constants unfortunately can't be used with extension.json at all; so I had to change the settings to be strings instead. So now the relevant call is instead: $wgCargoPageDataColumns[] = 'creationDate'; ...and the other possible values are 'modificationDate', 'creator', 'fullText', 'categories' and 'numRevisions'. Sorry about all the problems; hopefully this works for you now. Yaron Koren (talk) 18:00, 12 August 2016 (UTC)