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

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


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

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.