Xibo 2.3.9 New Install Oddities

CMS Version: 2.3.9
Installation Method: Apache2 (first with PHP7.4, then with PHP7.3)
– First tried PHP: 7.4.16
– Currently PHP: 7.3.27-9+ubuntu20.04.1+deb.sury.org+1
Operating System: Ubuntu 20.04

Immediately post-install, trying to edit settings, and when I click Save I receive the message “Unexpected Error, please contact support.”

  • No log entries are found, at all. Table is empty (verified in the database).
  • Cannot report issue through web interface, receive the same error message at the last step of the report issue wizard.
  • No log entries in apache2 error log
  • Updating user settings works fine (green success message).

I have set the log level to debug and server mode to test (via PhpMyAdmin). Same results.

Absent log entries, or more descriptive errors, what else can I try?

Welcome to the Community.

We cannot offer support for custom installs as there are just too many variables, you will need to go back and check your installation or use our recommended installation method with Docker: https://xibo.org.uk/docs/setup/xibo-for-docker

Hi Natasha,

I know you can’t fully support a non-Docker installation, just was looking for some pointers since I don’t know the software as well as you and I was not getting error/debug messages.

Also, it looks like someone else is also having this problem: Error when saving settings

I’m still troubleshooting, so capturing this here as a work in progress for me and fishing for ideas!

I had Xibo 2.3.9 running fine on:

  • Ubuntu 18.04
  • Apache 2.4.29
  • Php 7.2.24
  • MySql 5.7.33

Then I upgraded servers to:

  • Ubuntu 20.04
  • Apache 2.4.46
  • Php 7.4.16 (now 7.3.27)
  • MySql 8.0.23

On this new installation (trying it out for functionality, before moving over everything), I noticed that I could not update the settings. However, other functionality I tried seemed to work ok. I was stumped.

Initially began troubleshooting by setting the log settings to ‘debug’ and server mode to ‘Test’ in the setting DB table. Still received no error messages (even looking at the AJAX calls, etc…nothing). I poked around with some PHP versions (hence the regression to 7.3) and then investigated some issues that could be posed by the different MySql versions. Without any insight, for a while I was stuck. Then, I decided to upgrade this installation to 3.0.0-rc2…I mean, why not? And, something changed!

After the upgrade completed, I began to get the following error message when I went to update the Settings: “SQLSTATE[HY000]: General error: 1366 Incorrect integer value: ‘’ for column ‘entityId’ at row 1”; with this, I had something to go on!

Looking through the database, there’s only a couple tables with entityId field. I zeroed in on the auditlog table, located the LogService file, and discovered that the $entityId variable is empty.

To fix, I changed “lib/Service/LogService.php” as follows, starting at line 106:

            'logDate' => Carbon::now()->format('U'),
            'userId' => $this->userId,
            'entity' => $entity,
            'message' => $message,
            'entityId' => sprintf('%d',$entityId),
            'objectAfter' => $object

Now, I can update settings!

But, in the course of all this troubleshooting, I have discovered some additional errors. All seem to be caused by values that are blank/empty/false being passed as ‘’ to the DB. For example, when attempting to create a new user manually, I see this error: “SQLSTATE[HY000]: General error: 1366 Incorrect integer value: ‘’ for column ‘isPasswordChangeRequired’ at row 1”

So it seems that, when something should be 0 or FALSE, it’s being passed as empty…I’m off to Google some more but I def would appreciate input on what might be causing this condition! Is it a PHP thing? Configuration thing?


I have the same issue with a docker installation with external mysql-server (i.e. using cms_remote.yalm) on Ubuntu 18.04.3 LTS mysql Ver 14.14 Distrib 5.7.27.
I migrated th db to a docker mysql-server image, connectd to it and everythings works fine, so I think could be some mysql configuration on handling empty value.


Thanks both for your reports.

MySQL 8 isn’t tested or supported so isn’t expected to work. PHP 7.4 similarly isn’t tested or expected to work. The recommendation is PHP 7.3 and MySQL 5.6 as we distribute. MySQL 5.7 should work, and if it’s not, then I’ll ask one of our developers to take a look at the logs you have put above.

I’d recommend using the suggested configuration though in the interim.

Hi Alex,
I probably finded the problem, quoting from mysql doc:

I think that the STRICT_TRANS_TABLES param is the one that gives the isuue reported. I also removed the ONLY_FULL_GROUP_BY to make proof-of-play report working.

The sql_mode for mysql 5.6 docker image contains only NO_ENGINE_SUBSTITUTION


1 Like

There were a number of fixes added for MySQL 5.7 for that exact reason previously. I expect some new code has gone in which hasn’t been tested with it. As I say, our suggestion would be to use the versions we test on as you’ll have the least issues that way.

Hot dang, I love collaboration on the Internet, thanks, Ender!

A bit of work confirmed this was (mostly) the issue for me. Adding the below queries in Xibo3 RC2 “/lib/Storage/PdoStorageService.php” works like a champ, most aspects of my installation are now working great on PHP 7.3.27 and MySQL 8.0.23.

Line 120: $conn->query("SET SESSION sql_mode = 'NO_ENGINE_SUBSTITUTION';");
Line 144: $this->conn['default']->query("SET SESSION sql_mode = 'NO_ENGINE_SUBSTITUTION';");

However, still getting nothing recorded in the log table…trying to track this down next.

Alex, Natasha, I appreciate the work you all do on the product. You saying it shouldn’t work motivates me a little more. For various reasons, I have a box that is on Ubuntu 20.04, with MySQL 8 and can’t change that. Hopefully stumbling through this is useful to more than a couple people!


Believe all logging functions are working now. Had to add some backticks to column/field names in the SQL in two files as follows:

/lib/Helper/DatabaseLogHandler.php - Line 85 (one statement)

/lib/Factory/LogFactory.php - Lines 77 - 156 (various statement fragments)

Hopefully this helps some other folks!

This topic was automatically closed 91 days after the last reply. New replies are no longer allowed.