I am running into what seems an odd issue with the function to calculate an avarage value of a column: if the column contains empty cells (i.e. no value), it seems that the 'avarage' function takes the empty cell into consideration as "0. Accordingly, the reported avarage value is much lower than should be, based on the cells that actually contain a value.
E.g.: if an floating value columnwith 6 rows contain values "1","2", and "3", as well as 3 empty cells, the avarage value should be "2", but it shows "1". Oddly enough the functions Min and Max value work properly (i.e. they report min = "1" and max = "3", i.e. they do disregard the empty cells).
This seems to be an issue with how the avarage cell is calculated. Can this be solved by simply ignoring empty cells (as it seems to have been for the "Min" and "Max" functions)?
Many thanks for your response. I tried your suggestion, but it did not fix the issue.
Looking at it more closely, it seems that for some columns the system automatically puts in "0" in empty cells (i.e. on the front-end, it actually slows value "0" instead of an empty cell, and if I edit the table I see the cell in the DB is actually populated with a "0", even where I left it empty when I populated the cell), whereas other columns leave empty cells just empty. I am not sure what is causing this behaviour.
Note that this does not impact the behaviour of the 'Avarage' function; this still seems to treat both cells with actually value "0" the same as a cell that is left empty.
The best solution would seem to allow float and integer cells to be empty (or have another value, e.g. - or N/A indication there is no value). I am trying to set up a table where not every row will have a value in the integer/float column, and accordingly it is very confusing if this value is shown as "0" (which is something different than no value).
Is this something that could be implemented in the near future? For the short, term, I guess a work-around is to set the column as a "string" column, but this misses out on the (otherwise helpful) features of min/max/avarage.
So essentially (and hopefully this is a minor tweak to the plugin that can be taken up in a next update as a bug fix):
Allow string / float cells to have an option that a cell can have an empty value
Ensure that the min/max/avarage calculations all ignore the empty values when calculation the avarage (and ignore those rows when deterimining the no. of rows).
I'm sorry to say that this is anything but a minor fix; otherwise it would've already been included in the plugin. Float and Integer columns can't accept anything other than numbers, and that's not something we can easily change.
We have received a lot of feature requests about this, but unfortunately our developers haven't been able to resolve this issue. I will reach out to them, and see if they have another advice here.
Our developers will make this one of the priorities for our future updates, so I hope the issue will be fixed soon. I can't promise anything, but I hope that it will be resolved in the next month or two.
We will be dedicating the next couple of months to fixing existing issues and bugs with the plugin, and I sent it to our development team so they are reminded of the issue.
I am running into what seems an odd issue with the function to calculate an avarage value of a column: if the column contains empty cells (i.e. no value), it seems that the 'avarage' function takes the empty cell into consideration as "0. Accordingly, the reported avarage value is much lower than should be, based on the cells that actually contain a value.
E.g.: if an floating value columnwith 6 rows contain values "1","2", and "3", as well as 3 empty cells, the avarage value should be "2", but it shows "1". Oddly enough the functions Min and Max value work properly (i.e. they report min = "1" and max = "3", i.e. they do disregard the empty cells).
This seems to be an issue with how the avarage cell is calculated. Can this be solved by simply ignoring empty cells (as it seems to have been for the "Min" and "Max" functions)?
Hello Tijmen
Thank you for your purchase.
That's right, the logic of the Average function is simple - add all values from rows in a certain column, and divide them with the number of rows.
Float and integer columns do not accept empty cells, so empty cells are replaced by zeros, that's why they are included in the calculation.
Please try this:
Go to /wp-content/plugins/wpdatatables/source/class.wpdatachart.php, and around line 1631 you'll see this:
case 'int': $return_data_row[] = (float)$row[$columnKey]; break; case 'float': if ($decimalPlaces != -1){ $return_data_row[] = (float)number_format( (float)($row[$columnKey]), $decimalPlaces, '.', $thousandsSeparator ? '' : '.'); }else { $return_data_row[] = (float)$row[$columnKey]; } break;Replace it with this:
case 'int': if (is_null($row[$columnKey])){ $return_data_row[]= null; }else{ $return_data_row[] = (float)$row[$columnKey]; } break; case 'float': if ($decimalPlaces != -1) { if (is_null($row[$columnKey])) { $return_data_row[] = null; }else { $return_data_row[] = (float)number_format( (float)($row[$columnKey]), $decimalPlaces, '.', $thousandsSeparator ? '' : '.'); } } else { if (is_null($row[$columnKey])) { $return_data_row[] = null; }else { $return_data_row[] = (float)$row[$columnKey]; } } break;disable "Use minified wpDataTables Javascript" slider in main settings of wpDataTables/Custom JS and CSS:
And also clear your cookies.
Let me know if that helps.
Kind Regards,
Aleksandar Vuković
[email protected]
Rate my support
wpDataTables: FAQ | Facebook | Twitter | Instagram | Front-end and back-end demo | Docs
Amelia: FAQ | Facebook | Twitter | Instagram | Amelia demo sites | Docs | Discord Community
You can try wpDataTables add-ons before purchasing on these sandbox sites:
Powerful Filters | Gravity Forms Integration for wpDataTables | Formidable Forms Integration for wpDataTables | Master-Detail Tables
Dear Aleksandar,
Many thanks for your response. I tried your suggestion, but it did not fix the issue.
Looking at it more closely, it seems that for some columns the system automatically puts in "0" in empty cells (i.e. on the front-end, it actually slows value "0" instead of an empty cell, and if I edit the table I see the cell in the DB is actually populated with a "0", even where I left it empty when I populated the cell), whereas other columns leave empty cells just empty. I am not sure what is causing this behaviour.
Note that this does not impact the behaviour of the 'Avarage' function; this still seems to treat both cells with actually value "0" the same as a cell that is left empty.
The best solution would seem to allow float and integer cells to be empty (or have another value, e.g. - or N/A indication there is no value). I am trying to set up a table where not every row will have a value in the integer/float column, and accordingly it is very confusing if this value is shown as "0" (which is something different than no value).
Is this something that could be implemented in the near future? For the short, term, I guess a work-around is to set the column as a "string" column, but this misses out on the (otherwise helpful) features of min/max/avarage.
So essentially (and hopefully this is a minor tweak to the plugin that can be taken up in a next update as a bug fix):
Thank you.
Hi again Tijmen
I'm sorry to say that this is anything but a minor fix; otherwise it would've already been included in the plugin. Float and Integer columns can't accept anything other than numbers, and that's not something we can easily change.
We have received a lot of feature requests about this, but unfortunately our developers haven't been able to resolve this issue. I will reach out to them, and see if they have another advice here.
Kind Regards,
Aleksandar Vuković
[email protected]
Rate my support
wpDataTables: FAQ | Facebook | Twitter | Instagram | Front-end and back-end demo | Docs
Amelia: FAQ | Facebook | Twitter | Instagram | Amelia demo sites | Docs | Discord Community
You can try wpDataTables add-ons before purchasing on these sandbox sites:
Powerful Filters | Gravity Forms Integration for wpDataTables | Formidable Forms Integration for wpDataTables | Master-Detail Tables
Hello again Tijmen
Our developers will make this one of the priorities for our future updates, so I hope the issue will be fixed soon. I can't promise anything, but I hope that it will be resolved in the next month or two.
Kind Regards,
Aleksandar Vuković
[email protected]
Rate my support
wpDataTables: FAQ | Facebook | Twitter | Instagram | Front-end and back-end demo | Docs
Amelia: FAQ | Facebook | Twitter | Instagram | Amelia demo sites | Docs | Discord Community
You can try wpDataTables add-ons before purchasing on these sandbox sites:
Powerful Filters | Gravity Forms Integration for wpDataTables | Formidable Forms Integration for wpDataTables | Master-Detail Tables
I sure hope so, Tijmen
We will be dedicating the next couple of months to fixing existing issues and bugs with the plugin, and I sent it to our development team so they are reminded of the issue.
Kind Regards,
Aleksandar Vuković
[email protected]
Rate my support
wpDataTables: FAQ | Facebook | Twitter | Instagram | Front-end and back-end demo | Docs
Amelia: FAQ | Facebook | Twitter | Instagram | Amelia demo sites | Docs | Discord Community
You can try wpDataTables add-ons before purchasing on these sandbox sites:
Powerful Filters | Gravity Forms Integration for wpDataTables | Formidable Forms Integration for wpDataTables | Master-Detail Tables