Answers.Body: <p>I confirm that this is a bug in civicrm. I was able to replicate on my local running PHP 7.1.</p>
  
  <p>I've created a Gitlab issue at <a href="https://lab.civicrm.org/dev/core/issues/612" rel="nofollow noreferrer">https://lab.civicrm.org/dev/core/issues/612</a></p>
  
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2018-12-19T08:50:29.870Z
Answers.LastActivityDate: 2018-12-19T08:50:29.870Z
Answers.UserDisplayName: jitendra - fuzion
Body: <p>I am encountering this error when attempting to define a new label format, "Sorry an error occurred", "Label Format does not fit in database.".</p>
  
  <p>This is on CiviCRM 5.8.1 on Joomla 3.9.1. I can't reproduce it on dmaster.</p>
  
  <ul>
  <li>Administer > Communications > Label Formats </li>
  <li>Click Add Label Format
  button</li>
  <li>I used the format settings below:</li>
  </ul>
  
  <p><a href="https://i.sstatic.net/wgScw.png" rel="nofollow noreferrer"><img src="https://i.sstatic.net/wgScw.png" alt="Label format settings that I used"></a></p>
  
  <p>But if I entered at least some of the measurements as integer numbers only, I am able to save the new label format.</p>
  
  <p>Looking at the civicrm_option_value table in the database, value looks like:
  <code>
  {"paper-size":"a4","orientation":"portrait","font-name":"helvetica","font-size":9,"font-style":"","NX":3,"NY":11,"metric":"in","lMargin":0.25,"tMargin":0.5500000000000000444089209850062616169452667236328125,"SpaceX":0.1000000000000000055511151231257827021181583404541015625,"SpaceY":0,"width":2.520000000000000017763568394002504646778106689453125,"height":0.95999999999999996447286321199499070644378662109375,"lPadding":1,"tPadding":1}
  </code>
  The very long floating-point numbers look like the cause of the problem. The db column is a varchar(512).</p>
  
  <p>To work around this I had to finish entering the last two values directly in the database table after editing the long numbers back to 1 or 2 decimal places.</p>
  
  <p>Has anybody encountered this before?</p>
  
  <hr>
  
  <p><strong>UPDATE:</strong>
  This has arisen since PHP 7.1. See this <a href="https://stackoverflow.com/questions/42981409/php7-1-json-encode-float-issue/43056278">StackExchange question</a>: <em>"According to documentation, PHP 7.1.x started to use serialize_precision instead of precision when encoding double values."</em></p>
  
  <p>In <code>CRM_Core_BAO_LabelFormat::saveLabelFormat()</code> this line uses <code>json_encode</code>:
  <code>
  $this-&gt;value = json_encode($v);
  </code></p>
  
  <p><code>$v</code> is OK, it will contain something like:</p>
  
  <p><code>
  array(16) {
    ["paper-size"]=&gt;
    string(2) "a4"
    ["orientation"]=&gt;
    string(8) "portrait"
    ["font-name"]=&gt;
    string(9) "helvetica"
    ["font-size"]=&gt;
    int(10)
    ["font-style"]=&gt;
    string(0) ""
    ["NX"]=&gt;
    int(3)
    ["NY"]=&gt;
    int(11)
    ["metric"]=&gt;
    string(2) "in"
    ["lMargin"]=&gt;
    float(0.25)
    ["tMargin"]=&gt;
    float(0.55)
    ["SpaceX"]=&gt;
    float(0.1)
    ["SpaceY"]=&gt;
    float(0)
    ["width"]=&gt;
    float(2.52)
    ["height"]=&gt;
    float(0.96)
    ["lPadding"]=&gt;
    float(0.12)
    ["tPadding"]=&gt;
    float(0.1)
  }
  </code>
  It is only after the json_encode() that the extra-long floats are present:
  <code>
  string(546) "{"paper-size":"a4","orientation":"portrait","font-name":"helvetica","font-size":10,"font-style":"","NX":3,"NY":11,"metric":"in","lMargin":0.25,"tMargin":0.5500000000000000444089209850062616169452667236328125,"SpaceX":0.1000000000000000055511151231257827021181583404541015625,"SpaceY":0,"width":2.520000000000000017763568394002504646778106689453125,"height":0.95999999999999996447286321199499070644378662109375,"lPadding":0.11999999999999999555910790149937383830547332763671875,"tPadding":0.1000000000000000055511151231257827021181583404541015625}"
  </code></p>
  
  <p>Inserting <code>ini_set('serialize_precision', -1 );</code> into <code>CRM_Core_BAO_LabelFormat::saveLabelFormat()</code> before the <code>json_encode()</code> makes it work for me, as does adding it to php.ini but I'm not sure what the proper solution is. </p>
  
  <p>Does this affect CiviCRM elsewhere? Would this be considered a CiviCRM issue? Or something that should at least be documented (the need to set it in php.ini)?</p>
  
Tags: <address-labels><php7>
Title: Label Format does not fit in database - PHP 7.1 json_encode() and serialize_precision
ThreadText: # Label Format does not fit in database - PHP 7.1 json_encode() and serialize_precision
  
  (Asked by: username_0 on 2018-12-18)
  
  I am encountering this error when attempting to define a new label format, "Sorry an error occurred", "Label Format does not fit in database.".
  
  This is on CiviCRM 5.8.1 on Joomla 3.9.1. I can't reproduce it on dmaster.
  
  * Administer > Communications > Label Formats
  * Click Add Label Format
    button
  * I used the format settings below:
  
  [![Label format settings that I used](https://i.sstatic.net/wgScw.png)](https://i.sstatic.net/wgScw.png)
  
  But if I entered at least some of the measurements as integer numbers only, I am able to save the new label format.
  
  Looking at the civicrm\_option\_value table in the database, value looks like:
  `{"paper-size":"a4","orientation":"portrait","font-name":"helvetica","font-size":9,"font-style":"","NX":3,"NY":11,"metric":"in","lMargin":0.25,"tMargin":0.5500000000000000444089209850062616169452667236328125,"SpaceX":0.1000000000000000055511151231257827021181583404541015625,"SpaceY":0,"width":2.520000000000000017763568394002504646778106689453125,"height":0.95999999999999996447286321199499070644378662109375,"lPadding":1,"tPadding":1}`
  The very long floating-point numbers look like the cause of the problem. The db column is a varchar(512).
  
  To work around this I had to finish entering the last two values directly in the database table after editing the long numbers back to 1 or 2 decimal places.
  
  Has anybody encountered this before?
  
  ---
  
  **UPDATE:**
  This has arisen since PHP 7.1. See this [StackExchange question](https://stackoverflow.com/questions/42981409/php7-1-json-encode-float-issue/43056278): *"According to documentation, PHP 7.1.x started to use serialize\_precision instead of precision when encoding double values."*
  
  In `CRM_Core_BAO_LabelFormat::saveLabelFormat()` this line uses `json_encode`:
  `$this->value = json_encode($v);`
  
  `$v` is OK, it will contain something like:
  
  `array(16) {
  ["paper-size"]=>
  string(2) "a4"
  ["orientation"]=>
  string(8) "portrait"
  ["font-name"]=>
  string(9) "helvetica"
  ["font-size"]=>
  int(10)
  ["font-style"]=>
  string(0) ""
  ["NX"]=>
  int(3)
  ["NY"]=>
  int(11)
  ["metric"]=>
  string(2) "in"
  ["lMargin"]=>
  float(0.25)
  ["tMargin"]=>
  float(0.55)
  ["SpaceX"]=>
  float(0.1)
  ["SpaceY"]=>
  float(0)
  ["width"]=>
  float(2.52)
  ["height"]=>
  float(0.96)
  ["lPadding"]=>
  float(0.12)
  ["tPadding"]=>
  float(0.1)
  }`
  It is only after the json\_encode() that the extra-long floats are present:
  `string(546) "{"paper-size":"a4","orientation":"portrait","font-name":"helvetica","font-size":10,"font-style":"","NX":3,"NY":11,"metric":"in","lMargin":0.25,"tMargin":0.5500000000000000444089209850062616169452667236328125,"SpaceX":0.1000000000000000055511151231257827021181583404541015625,"SpaceY":0,"width":2.520000000000000017763568394002504646778106689453125,"height":0.95999999999999996447286321199499070644378662109375,"lPadding":0.11999999999999999555910790149937383830547332763671875,"tPadding":0.1000000000000000055511151231257827021181583404541015625}"`
  
  Inserting `ini_set('serialize_precision', -1 );` into `CRM_Core_BAO_LabelFormat::saveLabelFormat()` before the `json_encode()` makes it work for me, as does adding it to php.ini but I'm not sure what the proper solution is.
  
  Does this affect CiviCRM elsewhere? Would this be considered a CiviCRM issue? Or something that should at least be documented (the need to set it in php.ini)?
  
  **Tags:** address-labels, php7
  
  
  ---
  
  ## 1 answers
  
  ### Answer by username_1 on 2018-12-19. Score: 2 | Accepted answer
  
  I confirm that this is a bug in civicrm. I was able to replicate on my local running PHP 7.1.
  
  I've created a Gitlab issue at <https://lab.civicrm.org/dev/core/issues/612>
  
  
  ---
  
  