Extension talk:Cargo/Archive April to June 2016

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

{{#cargo_query:
tables=OptionCreate,DraftOption
|join on=OptionCreate._pageName=DraftOption._pageName
|fields=OptionCreate._pageName,parameter,valid,defaultvalue,takeseffect,shortdesc
|format=template
|template=DraftOptionPrint
}}

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

{{#cargo_query:
tables=OptionCreate,DraftOption,DraftExtended
|join on=OptionCreate._pageName=DraftOption._pageName=DraftExtended._pageName
|fields=OptionCreate._pageName,parameter,valid,defaultvalue,takeseffect,shortdesc,moredesc
|format=template
|template=DraftOptionPrint
}}

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.

OptionCreate	-->	DraftOption
	-->	DraftExtended

or

OptionCreate

-->

DraftOption

-->

DraftExtended

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 {{#counter: }} to the template. I've tried this and would like to report it works correctly for both cases. The second case using {{#ifeq: {{#counter: foo}}|1|first layout | second and following layout}} 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.

  {{#cargo_query:
    tables = StellarData,AllegianceCode,SubsectorData
   |join on = AllegianceCode.code=StellarData.allegiance, StellarData.subsector=SubsectorData.name
   |fields=StellarData.name, AllegianceCode.description, SubsectorData.name
   |where=sector='Spinward Marches' and era='New Era'
   |format=json
  }}

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)

    Query:
    SELECT `mw_cargo__SubsectorData`.`name` AS `name`,`mw_cargo__AllegianceCode`.`description` AS `description` FROM `mw_cargo__AllegianceCode` LEFT OUTER JOIN `mw_cargo__StellarData` ON ((`mw_cargo__AllegianceCode`.code=`mw_cargo__StellarData`.allegiance)) LEFT OUTER JOIN `mw_cargo__SubsectorData` ON ((`mw_cargo__StellarData`.subsector=`mw_cargo__SubsectorData`.name)) WHERE sector='Spinward Marches' and era='New Era' ORDER BY `mw_cargo__SubsectorData`.`name` LIMIT 100
    Function: CargoSQLQuery::run
    Error: 1052 Column 'sector' in where clause is ambiguous (localhost)

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 {{{info|page name=<Composer[GivenNames_Surname]>}}}, which gave the error message, "The specified target page <Composer[GivenNames_Surname]> is invalid." The same thing happened when I used {{{info|page name=<Composer[FullName]>}}}. 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=<Composer[GivenNames]> <Composer[Surname]>". 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

{{#cargo_declare:_table=News|CGSM-NoticiaFuente=Source (,) of Page}}
{{#cargo_store:_table=News|CGSM-NoticiaFuente={{{CGSM-NoticiaFuente|}}} }}
[[Categoría:La CGSM en las noticias]]

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

{{#cargo_declare:_table=News|Source=List (,) of Text}}
{{#cargo_store:_table=News|Source={{{Source|}}} }}

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:

 <noinclude>
  Formulaire utilisé par la [[Special:RunQuery/MagDBQueryTest|'page spéciale exécute requête MagDBQueryTest']].
  [[category:MagDB]]
 </noinclude>
 <includeonly>
  {{{info|query form at top}}}
  {{{for template|MagDBQueryTest}}}
  {| class="formtable"
  ! Mot clé:
  | {{{field|mot_cle}}}
  |}
  {{{end template}}}
 </includeonly>
 

This is the result template :

 <noinclude>
 Modèle d'affichage du résultat de requête. Elle est appelée via le formulaire [[Form:MagDBQueryTest]].
 [[category:MagDB]]
 </noinclude>
 <includeonly>

  (Mot Clé "{{{mot_cle|}}}")
  <-- INSERT CARGO QUERY HERE -->
 
 </includeonly>
 

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 {{{mot_cle}}} 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 "{{MagDBQueryTest|mot_cle=XXX}}"? 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:

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

 <noinclude>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]].
 [[category:MagDB]]
 </noinclude><includeonly>
 Requête : (Mots Clé "{{{mot_cle|}}}")
 
 {{#cargo_query:
 tables=MagDBCompetenceCollaborateur
 |fields=CONCAT('[[Competence:',MagDBCompetenceCollaborateur.Competence,'|',
    SUBSTRING_INDEX(MagDBCompetenceCollaborateur.Competence,'/',-1),']]')=Compétences,
    count(MagDBCompetenceCollaborateur._pageName)=
 |group by=MagDBCompetenceCollaborateur.Competence
 |where=MagDBCompetenceCollaborateur.Competence != "TOTO"
 }}
 
 </includeonly>
 

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:

fieldName__full - holds the coordinates as written in the page

fieldName__lat - holds the latitude from the coordinates, as an integer

fieldName__lon - holds the longitude from the coordinates, as an integer

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:

<noinclude>
{{#cargo_declare:_table=CGSM_Noticias
|Fecha=Date
|Fuente=List (,) of Page
|Enlace=URL
|Tipo=List (,) of Page
|Palabras_clave=List (,) of Page}}
</noinclude><includeonly>

This is a "CGSM en las noticias" item. 
{{#cargo_store:_table=CGSM_Noticias
|Fecha={{{Fecha|}}}
|Fuente={{{Fuente|}}}
|Enlace={{{Enlace|}}}
|Tipo={{{Tipo|}}}
|Palabras_clave={{{Palabras clave|}}}
}}

<includeonly>{| class="wikitable" style="text-align: left;"
! style="text-align: left;"| Fecha
| {{{Fecha|}}}
|-
! style="text-align: left;"| Fuente
| {{#arraymap:{{{Fuente|}}}|,|x|[[x]]}}
|-
! style="text-align: left;"| Enlace
| {{{Enlace|}}}
|-
! style="text-align: left;"| Tipo
| {{#arraymap:{{{Tipo|}}}|,|x|[[x]]}}
|-
! style="text-align: left;"| Palabras clave
| {{#arraymap:{{{Palabras clave|}}}|,|x|[[x]]}}
|}

[[Category:CGSM - Noticias]]
</includeonly>

What am I doing wrong?? Thanks for any advise! Horst 7th June 2016

....Just noticed one

<includeonly>

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.

{{{for template|Assessment}}}
{| class="wikitable"

! Substance: 
| {{{field|Substance|mandatory |input type = dropdown |size = 25 | values = {{#cargo_query: tables=Substance |fields=Substance |format = list | delimiter = ,}}  }}}
|-

What I would expect is that the cargo query returns a comma delimited list of substances such as Glue, Paint, Solvent, Cleaner 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 UNIQ15d70afa77549........

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: "{{{field|Substance|mandatory |input type = dropdown |cargo table=Substance |cargo field=Substance}}}". Yaron Koren (talk) 12:05, 10 June 2016 (UTC)

Brilliant, Thank you. This works a treat :)

Can't use {{#expr:}} for database results

I'm trying to add the result of a database query but get an error expression error: Unrecognized punctuation character "?".

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

{{#expr: {{#cargo_query: tables=Substance|fields=Revision|where= Substance = 'Cleaner'}} + 1 }}

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..

{{#invoke:LuaTest|Rev}} 

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"

{{#cargo_declare:_table=Pieces
. . .
|Instrumentation=List ( ;) of Text
}}
. . .
{{#cargo_store:_table=Pieces
. . .
|Instrumentation={{{Instrumentation|}}}
. . .
}}
! Instrumentation
| {{#arraymap:{{{Instrumentation|}}}| ; |x|x}}
. . .

From the form "Piece"

{| class="formtable"
. . .
! Instrumentation: 
| {{{field|Instrumentation|cargo table=Pieces|cargo field=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 "{{{Instrumentation|}}}". 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”:

{{{info|page name=<Piece[Title]>, <Piece[OpusNumber]>--<Piece[Composer]>}}}

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: | {{{field|Composer|cargo table=Pieces|cargo field=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:

{{#cargo_declare:_table=GiveawayItems|image=Text|owner=Text|name=Text|description=Text|availableUntil=Date}}

In the includeonly section I have:

{{#cargo_store:_table=GiveawayItems|image={{{image|}}}|owner={{{owner|}}}|name={{{name|}}}|description={{{description|}}}|availableUntil={{{availableUntil|}}} }}

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)