Extension talk:Cargo

From MediaWiki.org
Jump to: navigation, search
Cargo - navigation
Basics Main pageExtension:Cargo (talk) · Download and installationExtension:Cargo/Download and installation · Quick start guideExtension:Cargo/Quick start guide · Other documentationExtension:Cargo/Other documentation · SMW migration guideExtension:Cargo/SMW migration guide
Using Cargo Storing dataExtension:Cargo/Storing data · Querying dataExtension:Cargo/Querying data (Display formatsExtension:Cargo/Display formats) · Browsing dataExtension:Cargo/Browsing data · Exporting dataExtension:Cargo/Exporting data · Other featuresExtension:Cargo/Other features
Resources for help Common problemsExtension:Cargo/Common problems · Known bugs and planned featuresExtension:Cargo/Known bugs and planned features · Getting supportExtension:Cargo/Getting support
About Cargo Authors and creditsExtension:Cargo/Authors and credits · Version historyExtension:Cargo/Version history · Sites that use CargoExtension:Cargo/Sites that use Cargo · Cargo and Semantic MediaWikiExtension:Cargo/Cargo and Semantic MediaWiki · FAQExtension:Cargo/FAQ

timeline causing error[edit]

When using the following cargo query


I get the error on the page:

Caught exception: SyntaxError: expected expression, got '<'

and no timeline is displayed. Not sure what could be the problem. Using cargo version 1.6 (5a44fdc)

This doesn't seem to happen for me - I'd recommend upgrading to the latest version, 1.7 (released today!), to see if maybe that was a bug that's been fixed. Yaron Koren (talk) 19:52, 9 March 2018 (UTC)
Thanks for your reply, updated today but the issue persists. I noticed the error also occurs for me on this page from the Cargo example page: http://discoursedb.org/wiki/Virginia_United_States_Senate_election,_2006
Oh yeah, now I remember... this sometimes happens due to page caching, for reasons I can't explain. I need to look into, but I think you can get around the problem by installing the MagicNoCache extension, and adding "__NOCACHE__", on a line by itself, to any page (or better yet, template) that calls the "timeline" format. It's not an ideal solution, but it should work for now. Yaron Koren (talk) 14:04, 12 March 2018 (UTC)
I see, one of the example pages had __NOCACHE__ but I didn't know what it meant. I have updated Cargo, added the magicnocache extension and added __NOCACHE__ but now there is a different error "TypeError: v1 is NULL"

Table with more than 70 columns will not create[edit]

Hello, we're trying to work with a table that has 84 columns, but our tests are showing that if it has more than 70 columns it will not create. https://dota2.gamepedia.com/Template:User:Litzsch/Cargo_test is the test table currently. There isn't any data going in it yet, just trying to define the table. It creates super quick at 70 columns (up to buff4 in the table) but if I add just one more column to the declare it just gives a spinning wheel with no action. Any ideas? --pcj (talk) 13:22, 11 March 2018 (UTC)

I'm not sure why it's failing for you - these 70 rows appear to be all of type "String", which in Cargo translates to "VARCHAR(300)", which should be somewhere around 21,000 bytes, which is significantly less than MySQL's limit of 65,535 bytes per row.
However, it seems to me that what you're trying to do would better be accomplished with multiple-instance templates. Do you know about those, from Page Forms? Here, you're trying to store three different two-dimensional tables of data, within each row of this table. I think switching to multiple-instance templates would make for better storage, easier editing, and easier querying. Yaron Koren (talk) 14:17, 11 March 2018 (UTC)

how do I get plain numbers from aggregat functions[edit]


when I do a #cargo_query and select one integer field I get the integer back as a result – e. g. 5000 –, but when I query using MAX( integer field ) the result is a formatted number like 5,000.0. It's the same when using SUM(). I just wonder why this happens and if it's possible to suppress this formatting?

Doing the same thing using direct sql within pma produces plain numbers for all queries. So is it a cargo or mediawiki issue? Or am I just doing something wrong? --~o)sabine(o~ (talk) 15:10, 15 March 2018 (UTC)

It's a Cargo issue - some helpful formatting around Integer and Float fields. If you want to get rid of all the formatting, the easiest way to do it is to put "CONCAT()" around the whole thing, which will turn it (in Cargo's eyes) into a String field. If, on the other hand, you just want to switch around the the "," and ".", you can use the global settings $wgCargoDigitGroupingCharacter and $wgCargoDecimalMark for that. Yaron Koren (talk) 15:54, 15 March 2018 (UTC)
Thank you for the fast answer. I have to get plain numbers for calculations with #expr. All went well until the highest number reached 1000. After that my form didn't work any longer…
I apologize for bothering you, because when I read your answer I remembered reading this somewhere or at least something similar.
And well, I wrote this earlier – maybe a year ago –, but thanks again for this great extensions, especially Cargo and PageForms make my work a lot easier :) --~o)sabine(o~ (talk) 21:00, 15 March 2018 (UTC)
I'm glad to hear it! And no problem. Yaron Koren (talk) 14:50, 18 March 2018 (UTC)

Querying a table on the same page and writing the result to a field[edit]

I've known about this limitation for a while but I figured it was too specific to ask about, but it's come up a couple other times on other wikis since, that said I don't really expect this to be possible to fix but figured I'd bring it up anyway just in case - If you have row 1 of Table 1 stored on a page, and on the same page you make a query of Table 1 row 1 and attempt to save the value to Table 2, the order in which page content is saved makes it so that you don't actually get the queried value stored. Recreating the table will make everything show up as intended, but then further edits to the page break it again.

Also, you can't store a #var_final, so this isn't an option for saving a value that depends on a template lower on the page.

Any way to get around either of these, or is the current page save order impossible to touch? --RheingoldRiver (talk) 07:21, 18 March 2018 (UTC)

If you want to use a value earlier on the page than where it's set, that's going to be tricky. Out of curiosity, why do you need to store this value in two different tables? Maybe there's an easier way to structure this? Yaron Koren (talk) 14:48, 18 March 2018 (UTC)
Actually in the case today, he wanted to store in the same table (fighting moves evolve from each other, and he wanted to input only the "to" and compute the "from"), but he ended up just doing one single input for all instances on the page in order to do the computation without Cargo, and I don't remember what the second use case was. The reason I wanted to was: In PUBG, most games are played with teams of 4 players each, and that's how teams standardly are, but sometimes there's events with 2 players. In these 2-player events there's a mix of standard teams and pick-up teams. So in some cases I will be identifying a squad of two players by their proper team name, and sometimes by a generic "unaffiliated" tag with a page-specific unique ID to refer them together. (Unique ID is manually entered by the editor and I want it to be mandatory only in the case that it's actively disambiguating.) I have one table that associates players to teams, along with the team's seed etc, which is defined in the team rosters template, and a second one for tournament placements that does team + prize + placement etc (but no rosters). Results are higher on the page than rosters. Normally in queries I just join on the team field, but this case is more complicated, so in the results template I wanted to query the rosters table to get the participants and store directly in order to avoid more complicated queries when I use the data elsewhere, but still be able to enter players only one time. I ended up just giving up on this, and I've been doing the more complicated where clauses where it looks for team if unique id isn't defined. --RheingoldRiver (talk) 15:29, 18 March 2018 (UTC)
Now that I think about it I could probably have unique ID default to just be the team variable in this case since there will be an ID iff team *isn't* unique. So that's an even easier workaround. But it would still be nice if var_final could be made to work. --RheingoldRiver (talk) 15:31, 18 March 2018 (UTC)

Multiple HOLDS checks on a single field?[edit]

Does HOLDS not work for seeing if a list has multiple specific values? Looking at _pageData._categories specifically. I want to know if the page is in two different categories but it returns no results, contrary to expected behavior. Or am I doing something wrong?

Thanks --pcj (talk) 00:06, 22 March 2018 (UTC)

Can I get the hierarchical structure as a result?[edit]


I'm doing my first steps in using a hierarchy instead of a list of allowed values and I just wondered, if it's more of a visual help when having a long list of values or if it's possible to get a part of the hierarchical structure as a result.

I have a structure of categories


and a page that's part of category C. So it should automatically be part of A and B, too. But can I get all three categories as a result in this case or do I have to handle this in the template e. g. with a case trap? --~o)sabine(o~ (talk) 13:18, 22 March 2018 (UTC)

See 'The "WITHIN" command' - is this the sort of thing you're asking about? Though it doesn't work with MediaWiki categories, unlike SMW - you have to define the hierarchy in #cargo_declare. Yaron Koren (talk) 13:29, 22 March 2018 (UTC)
No, it's not the solution I was looking for. With the WITHIN command I can get the subcategories, but I need to get the supercategories of a subcategory. --~o)sabine(o~ (talk) 17:08, 22 March 2018 (UTC)
Oh... now I get it. No, it's not possible, but this is something I've actually wanted to add to Cargo for a while - the current plan is to have a parser function called #cargo_hierarchy_values, that takes in the parameters "table", "field", "root", "level" and maybe "direction", and displays a tree. It's good to know that there's an interest in it. Yaron Koren (talk) 20:23, 22 March 2018 (UTC)
Sounds great. I'm looking forward to it. But if I could vote for a new function, it would be child tables over this. I'm using a lot of them and it would be lots more, when handling them would be easier :D
But I don't want to push you in one direction, I know almost all programmers are short on time while having too much to work on. And as far I can see you're doing a really great job and good programmers have even more to do :) --~o)sabine(o~ (talk) 21:09, 22 March 2018 (UTC)
Thanks! And both of those are good to know. I'm trying to set the priorities now for future development, so it's good timing to be discussing this kind of thing. Yaron Koren (talk) 21:40, 22 March 2018 (UTC)
So I just stumbled in at the right time :D
I'm curious, will you start a poll for the most wanted new function or decide by yourself? --~o)sabine(o~ (talk) 11:31, 23 March 2018 (UTC)
A poll might make sense - and for Page Forms too. I'll have to think about it. Yaron Koren (talk) 21:53, 23 March 2018 (UTC)

Cargo Query showing escaped HTML tags when page is saved[edit]

The issue is similar with this one. It happens every time the page is saved.
You can test this by editing and saving this page. It should look like this. Purging will fix the page.
Seems to be a Cargo issue; any help on this appreciated :) Fbcpck (talk) 00:51, 24 March 2018 (UTC)

Related: Extension_talk:Cargo/Archive_October_to_December_2017#Links/images_sometimes_displaying_as_plaintext
Fbcpck (talk) 00:55, 24 March 2018 (UTC)
In that 2nd discussion you linked to, the people reporting the problem came to the conclusion that it was the presence of the ConfirmEdit extension that was somehow causing it to happen. It looks like you have ConfirmEdit installed - could you try temporarily disabling it and seeing if that makes the problem go away? Yaron Koren (talk) 00:40, 26 March 2018 (UTC)
Small update: a workaround for this issue is to run the cargo query within lua modules. Some examples here and here.
It's somehow faster than calling {{#cargo_query}} too!
Fbcpck (talk) 08:31, 19 April 2018 (UTC)

How to import existing data into Cargo tables?[edit]


maybe a naive question as a newcomer to MediaWiki and Cargo,

is it possible to import existing data e.g. in CSV format into a Cargo table? (in a user friendly way, i.e. without doing a SQL request or using the mediawiki API) Thanks in advance

Yes - the right approach depends on whether you want the data to "live" in the wiki or not. Do you want users to be able to modify the data in the wiki once it has been imported? If so, then the Data Transfer extension is the best approach. If you just want the wiki to display the data, but not edit it, you should use the External Data extension, and specifically the #get_web_data function, assuming the CSV comes from some outside API. In either case, you would then need to create a template that stores that data in Cargo, but the exact approach depends on which of these two approaches you take. Yaron Koren (talk) 14:27, 27 March 2018 (UTC)
Thanks a lot for the quick reply :-)

In my case it would be the Data Transfer extension, I will check it out! Patrick

Fields display as "UNIQ-item1-QINU" in queries[edit]

I have two template and tables working together, and when I try to run a query pulling data from both, the fields are displayed as 'UNIQ-item1'.

Does anybody know how to fix this? Here are my templates. The two #cargo_query are the ones that show up as 'UNIQ'.


_table = ClientBob
|writer = text
|campaign = text
|project = text

_table = ClientBob
|writer = {{{by}}}
|campaign = {{{campaign}}}
|project = {{PAGEID}}


_table = project
|invoice = text
|client = text
|date = text
|words = integer
|campaign = text
|writer = text

_table = project
|client = {{{client}}}
|date = {{{date}}}
|invoice = {{{invoice}}}
|words = {{{words}}}
|campaign = {{#cargo_query:tables=ClientBob |where=project = "{{PAGEID}}" |fields=campaign}}
|writer = {{#cargo_query:tables=ClientBob |where=project = "{{PAGEID}}" |fields=writer}}

Thanks for your help. • Supāsaru 20:28, 6 April 2018 (UTC)

Adding "|no html" to those queries may possibly fix the issue. Yaron Koren (talk) 22:27, 6 April 2018 (UTC)
That worked! Thanks! • Supāsaru 19:17, 9 April 2018 (UTC)

Find unused IDs[edit]


I'm trying to get a list of all IDs from an autoincremental field. The table holds products and in the beginning old products have been deleted leaving gaps in the sequence. Later old ones have just been replaced by other products. Now I want to do a query which shows all gaps and fill them by opportunity.

I found a working solution for this problem on this page. It works, when I do the query via phpMyAdmin, but I ran into trouble, when trying to translate it into a cargo query.

This is the example on the mentioned page:

SELECT a.id+1 AS start, MIN(b.id) - 1 AS end
    FROM testtable AS a, testtable AS b
    WHERE a.id < b.id
    GROUP BY a.id
    HAVING start < MIN(b.id)

And here's my cargo query:

{{#cargo_query:tables=Produkt=a, Produkt=b
 |fields=a.ID+1=start, MIN( b.ID ) - 1=end
 |where=a.ID < b.ID
 |group by=a.ID
 |having=start < MIN( b.ID )

When starting the query I get: Error: join conditions must be set for tables.

Did I miss something or does cargo require a join statement, when more than one table is involved – even if the two are in fact one with two different aliases? --~o)sabine(o~ (talk) 17:23, 9 April 2018 (UTC)

What a crazy query... anyway, I think in MySQL "JOIN ON" and "WHERE" are somewhat interchangeable, but in Cargo they're not, so if you just change "where=" to "join on=" in #cargo_query, the whole thing may work. I'm not sure I understand the query, though, so it might not work. Yaron Koren (talk) 17:59, 9 April 2018 (UTC)
So, if I get you right, a join on clause is required, when more than one table is involved?
I tried to convert the query, but it led to no results. I think, I will have to set up a new table to compare it with. Too bad, I found the above query very smart and elegant.
But anyways, thanks again for the fast reply --~o)sabine(o~ (talk) 08:20, 10 April 2018 (UTC)
Yes, "join on" is required if there are more than table - that's true in SQL, too, for the most part, although MySQL lets you get around it by putting the join conditions in "WHERE" instead. Looking more at the query, I think I understand it better, and actually now I'm surprised that it's not working in Cargo. Is this query on a publicly viewable wiki? Yaron Koren (talk) 14:43, 10 April 2018 (UTC)
No it isn't, atm it is a private wiki for testing purposes.
This is the query I used with pma:
SELECT a.id+1 AS start, MIN(b.id) - 1 AS END
    FROM `cargo__Produkt` AS a, `cargo__Produkt` AS b
    WHERE a.id < b.id
    GROUP BY a.id
    HAVING start < MIN(b.id)
The same results can be retrieved with:
SELECT a.id+1 AS start, MIN(b.id) - 1 AS END
    FROM `cargo__Produkt` AS a
    JOIN `cargo__Produkt` AS b ON a.id < b.id
    GROUP BY a.id
    HAVING start < MIN(b.id)
At last my translation for cargo:
{{#cargo_query:tables=Produkt=a, Produkt=b
 |join on=a.ID < b.ID
 |fields=CONCAT( a.ID + 1 )=start, CONCAT( MIN( b.ID ) - 1 )=end
 |group by=a.ID
 |having=start < MIN( b.ID )
When saving the page I get "Missing '=' in join condition (a.ID < b.ID).".
I assume the only allowed operator in cargo's ON clause is a =. --~o)sabine(o~ (talk) 09:45, 19 April 2018 (UTC)
Ah, yes - now I remember putting in that check, not that thinking that a join like that would ever be used. If possible, could you try replacing the line that throws that error (line 284 of includes/CargoSQLQuery.php) with the following line:
                                $joinParts = explode( '<', $joinString );
...and seeing if that works? Yaron Koren (talk) 12:51, 19 April 2018 (UTC)
I changed the line – after updating cargo from 1.5 to 1.7; lazy me :) – and the error vanished … or better changed into an "a.ID + 1" field unknown error when using the base version:
{{#cargo_query:tables=Produkt=a, Produkt=b
 |join on=a.ID < b.ID
 |fields=a.ID + 1=start, MIN( b.ID ) - 1=end
 |group by=a.ID
 |having=start < MIN( b.ID )
 |order by=a.ID
With a few little tweaks for plain numbers…
{{#cargo_query:tables=Produkt=a, Produkt=b
 |join on=a.ID < b.ID
 |fields=CONCAT( a.ID + 1 )=start, CONCAT( MIN( b.ID ) - 1 )=end
 |group by=a.ID
 |having=a.ID + 1 < MIN( b.ID )
 |order by=a.ID
…the query worked without throwing errors, but also without results :(
I did a counter-check of the query with pma again, but it worked as expected. --~o)sabine(o~ (talk) 16:47, 19 April 2018 (UTC)
Okay, I think I figured out the issue - adding support for '<' and '>' in joins wasn't quite as simple as that one-line change. I just checked in a change which I think actually fixes the issue; and also I think makes the handling of joins a little less hacky than it was before. Yaron Koren (talk) 13:27, 20 April 2018 (UTC)
Wow, thank you. Yes, it works!
Btw, did you think about the poll for the most wanted new features in Cargo and PageForms? --~o)sabine(o~ (talk) 06:57, 21 April 2018 (UTC)

Great. I have thought about it - the problem is just that I haven't had time to do anything more than fix bugs in all these extensions, so it might be overly optimistic to start talking about new features. Yaron Koren (talk) 01:54, 23 April 2018 (UTC)

Oh, I'm sad to read this :(
So I'll try to stay patient and bother you just in case I stumble over a world destroying bug :)
~o)sabine(o~ (talk) 12:53, 23 April 2018 (UTC)

'Create table' just stalls[edit]

I've recently added Cargo to my production server (my question above was to help me get it started on my dev server).

Now, when I create a template and click 'Create Data Table', the site just stalls. I get the 'wait' cursor, and nothing happens. I don't have root access on my server, so I used the web updater when I first installed Cargo. It appeared that the Cargo tables were added fine.

Does anybody know why the extension stalls?

Here are my server settings:

MediaWiki 1.28.2
PHP 7.0.29 (litespeed)
MySQL 5.6.38
ICU 57.1

Article path /$1
Script path /
index.php /index.php
api.php	/api.php
load.php /load.php

Current extensions:
InputBox 0.3
Cargo 1.3
A custom word-count Special page

Supāsaru 10 April 2018

You're using a very old version of Cargo - you should upgrade to the latest version. (Don't bother with branches like REL1_28.) Yaron Koren (talk) 21:36, 10 April 2018 (UTC)
I've just downloaded the latest version of Cargo, ran the web updator, and I still get the wait icon. The tables aren't created. Do you know what else could be causing this? • Supāsaru 00:32, 11 April 2018 (UTC)
Alright. If you know how, you should view the JavaScript console on that page - my guess is that there's a JS error that's preventing the code from running. Yaron Koren (talk) 02:25, 11 April 2018 (UTC)
Thanks, Yaron. I saw that Cargo was calling api.php, which I had disabled on my wiki. I enabled api.php, and that seemed to work. I took a moment to Cargo's installation instructions. • Supāsaru 15:29, 11 April 2018 (UTC)
Okay, great. I moved your note about disabling the API into the "Common problems" page, but it's helpful. Yaron Koren (talk) 16:56, 11 April 2018 (UTC)

Version compatibility policy[edit]

@Yaron Koren: Cargo doesn't use release branches does it? So I guess it has "master" compatibility policy? This should be set in the extension template. Although, I reckon we should have a 'tags' policy, for extensions that tag their releases (and maybe use semver). Sam Wilson 23:59, 10 April 2018 (UTC)

No, it doesn't use branches. I don't know what master compatibility is, but Cargo (as with all of my other extensions) tries to keep backwards compatibility with older MediaWiki versions - my general aim is to be compatible with around the last two years of versions, though most of my extensions currently support versions going back to 1.23, which is almost four years ago. If there's something that can be added in the extension templates to reflect that policy, that would be great. Yaron Koren (talk) 02:29, 11 April 2018 (UTC)
@Yaron Koren: Yeah, that fits the 'master' policy. It's only if you treat master as a development branch (and don't want people to use it in production) that it wouldn't be. But if you're not using REL branches, then it's not that. :) I've added it to the infobox. Sam Wilson 05:08, 11 April 2018 (UTC)
That's good to know. Thanks! Yaron Koren (talk) 15:04, 11 April 2018 (UTC)

Can I store an average of an array in another field?[edit]

I'm working on a wiki for a level of difficulty rating for music. My thought was to allow individual teachers to cast a "vote" in an array field of floats from 1-15, then use the average of those votes in another field. Is that doable? For example,

Field: Difficulty Vote (array, float)

Field: Average Difficulty (average of Difficulty Vote array)

In my heart of hearts, what I would really like to do is provide a Linear Analog Scale and capture the results as a one dimensional coordinate from 0-15 (click on this line your vote for level of difficulty). Then I could use proximity to coordinate in a query like map coordinates. (maybe I should just rate pieces on a level of difficulty from Los Angeles (easy) to New York (Transcendentally difficulty)

Yes, you can store it (just remember to add a "|no html" parameter to the #cargo_query call within #cargo_store), but it might be easier to just re-calculate the average every time. In either case, you'd need to use the MySQL AVERAGE() function. As for the linear scale - if you're using Page Forms, I suggest you check out the "rating" input type. It won't show cities, but maybe that's fine. :) Yaron Koren (talk) 00:51, 12 April 2018 (UTC)

Export as Excel not working[edit]

I try to export data in an Excel format, I get a fatal error. The exporting seems to work, but when I click on 'View XLS', that's when the fatal error appears. When I turned on debugging, I see \Cargo\specials\CargoExport.php: Class 'PHPExcel' not found.

Do you know how to resolve this? • Supāsaru 21:09, 12 April 2018 (UTC)

You need to install the PHPExcel PHP library for that feature to work. I know it's deprecated (in favor of the new PhpSpreadsheet), but I think it's still usable. Yaron Koren (talk) 21:43, 12 April 2018 (UTC)

PostgreSQL incompatibility in includes/parserfunctions/CargoStore.php[edit]

   $tableFieldValuesForCheck = array( '_pageID' => $pageID );

should be

   $tableFieldValuesForCheck = array( $cdb->addIdentifierQuotes( '_pageID' ) => $pageID );

otherwise you get

    ERROR:  column "_pageid" does not exist at character 93
    HINT:  Perhaps you meant to reference the column "<table>._pageID".
    STATEMENT:  SELECT /* Wikimedia\Rdbms\Database::select  */
      COUNT(*)  FROM "<table>"    WHERE _pageID = '8906' AND "Name" =

--IijimaYun (talk) 19:55, 15 April 2018 (UTC)

Thanks for pointing that out - I checked this change into the code, so hopefully now it works fully with Postgres. Yaron Koren (talk) 17:30, 16 April 2018 (UTC)

Problem with division operator[edit]

I'm having an issue with the query below. I have two tables, one with transaction history in different currencies and one with exchange rates. To create a column with USD_amounts, I join the tables and want to divide the transaction amount by an exchange rate and display this in a separate column. I haven't been able to get the syntax right. I modified Localsettings.php to include $wgCargoAllowedSQLFunctions[] = 'DIV'; Is there something I am missing? Your help is greatly appreciated.

ERROR MESSAGE:No field named "(t.Investment_amount/r.Rate)" found for any of the specified database tables.

{{#cargo_query: tables=transaction=t,fx_rates=r |join on=t.Currency=r.CurrencyID |fields=t.Investment_amount, t.Currency, r.Rate, (t.Investment_amount / r.Rate)=USD_amount |where=t.Investment_amount > 0 AND t.Investment_status='Committed' }}

Oh, that's an interesting use of Cargo. Adding to $wgCargoAllowedSQLFunctions won't have any effect because "/" is an operator, not a function. The easiest way I can think of to get this working is to change "(t.Investment_amount / r.Rate)" to "CONCAT(t.Investment_amount / r.Rate)" - CONCAT() with a single argument doesn't actually do anything, but it's useful as a hack because of the way Cargo's parsing currently works. I hope to improve the parsing code so that this sort of thing would not be necessary. Yaron Koren (talk) 13:43, 25 April 2018 (UTC)
That solved it! Thanks for the help and for your work developing all of these amazing Mediawiki extensions!! I now see what was the issue was. Another option is using ROUND(). -- 16:43, 25 April 2018 (UTC) Donovan
Great! Oh, yes - ROUND() is a much better choice, because then it would actually be serving a useful purpose. Yaron Koren (talk) 18:27, 25 April 2018 (UTC)