Thread

Thanks for the clarification, and agreed for the majority of sites this likely isn’t an important issue which is why I mentioned this vent isn’t purely about my bug (although I have another bug related to this project which isn’t resolved either) it’s more about bugs like this: https://support.ellislab.com/bugs/detail/14821/ which effect the large majority of us.

Thanks again for you time and I’ll leave this thread now.

Ben

I understand, Ben, and I’ve just emailed our Product Owners regarding our handling of critical bugs.  This is important to us as well, and I want you to know that we do take this seriously.

Thank you for all of your feedback!

I’m sorry this has delayed things for you, Ben.

There’s a short term fix and a long term fix.  The long term fix is adding some display options to the field to handle the number of decimals to show.

Without getting into the pros/cons of float fields vs. real/decimal fields, what I’d suggest doing in the short term is changing the relevant field type to a decimal field.  In the long term, I am leaning toward using decimal(30, 10) - which gives us a possible 10 decimal places.  And is fairly arbitrary, but validation can pick up on preventing input that exceeds the max.  That will also give 30 characters total.

The glitch with doing this now- you will end up with 10 decimal places.  So for the short term and given the particular needs of the site?  I’d go with decimal(30,2).

So- backup your exp_channel_data table and make sure you have a good copy.  Find the field id of the field(s) that needs changing.  Then in phpmyadmin or something similar run:

ALTER TABLE exp_channel_data CHANGE field_id_x field_id_8 decimal(30, 2)

Note- replace the ‘x’ in field_id_x with the correct field id number.

There’s one more change you may/may not want to make.  In order for numbers to go in as null rather than 0- in Api_channel_entries around line 1790:

elseif ($field->type == 'int' && isset($cust_fields[$field->name]) && $cust_fields[$field->name] === '')

change to

elseif (($field->type == 'int' OR $field->type == 'real') && isset($cust_fields[$field->name]) && $cust_fields[$field->name] === '')

Again- I apologize this has jammed up the progress of your site.  The fix for a single instance is fairly easy, but a longer term fix has proved more daunting.  And is truthfully, still not firm.  But switching to a decimal won’t interfere with upgrades at all.

Let me allow to hijack this thread.

I’m in real trouble, after finding out that most of my entries phone numbers aren’t stored properly.

Entering something like “xxx444588” (where xxx are actually digits), get stored as xxx445000, I’ve found out that after clicking the save button and you get this overview page, I see the input showed as 445e+08. It didn’t go wrong on all entries, but still…

Any help what to do is really appreciated as I’ve probably hundreds(!—in the best case) of wrong entries now!

Eelco- what version are you running?  PHP is showing the number as scientific notation, which shouldn’t be happening in the latest release.

Looks I’m on an older version. v2.2.2 - Build: date 20110801

So, all(!) the information is wrongly saved in my DB now? Is that the case? Cause that would mean checking/changing almost 1500 entries.

What I would do- backup your database and then explicitly backup your exp_channel_data table- as long as the number is correctly stored (be it scientific notation or otherwise) it can be converted.  Update to the latest 2.3.1.  If there is still an issue with the number display, we have the backup to convert from.  I can’t replicate an issue with 2.3.1, so the update itself may resolve the problem.  And if it doesn’t, we have the backup to work a conversion from.

Robin, I’m not understanding it completely. I’ve checked the data in Phpmyadmin and the phone numbers are like “5.82449e+08”, where they should be like “0582449323”. Also every entry ends with “e+08”—really doesn’t look good to me!

Scientific notation is a kind of shorthand for large numbers (see converter)- so 0582449323 = 5.82449323E8.  PHP was converting your large numbers into scientific notation.  So those two numbers?  Are the same, just written in different format.

Thanks Robin, I will have to give it a try coming weekend. Hope I don’t need to come back then.

Eelco,

Have you resolved your issue?

Sean