Page History

...

Look in the footer for "Installed Version" to confirm that the patch was applied, and the new version is recognized.

That's it!

Failed Upgrade / Errors After Upgrade

If running /admin/upgrade does not complete all the database migrations, things may not work correctly and it may be necessary to modify a migration task so that it picks back up where it failed. The first step is to determine what the last completed migration version was. To find out, run this query:

SELECT `value` FROM `settings` WHERE `key`='database_version';

As an example, let's say this returns: 4.4.0-b1 but you uploaded the files for 4.6.0. Please note that there is not a direct correlation between the database version and the version of Blesta you are running. If your database says 4.4.0-b1 you could be running 4.4.2 if there were no database changes between 4.4.0-b1 and 4.4.2.

Next, look at the migration tasks in /components/upgrades/tasks/, you'll see files like this:

...
upgrade4_3_0_b1.php
upgrade4_4_0_b1.php
upgrade4_5_0_b1.php
upgrade4_6_0_b1.php
upgrade4_6_0.php
upgrade4_7_0_b1.php
...

The version in the filename corresponds to the version in your database. If your database shows 4.4.0-b1, then the last migration task it fully completed was upgrade4_4_0_b1.php. This means that when it tried to run the next migration, upgrade4_5_0_b1.php one of the tasks in that file failed. Errors that you are getting in your logs may help identify which task failed, but lets look at upgrade4_5_0_b1.php because we know something in that file failed. Edit the file in your favorite text editor, that will not modify the file encoding (UTF-8) or line endings. Look for the function tasks() and the methods listed within.

    public function tasks()
    {
        return [
            'addProxySetting',
            'updateInvoiceTerms',
            'addPackageNames',
            'addPackageDescriptions',
            'addPackageGroupNames',
            'addPackageGroupDescriptions',
        ];
    }

In the example above, we can see that the following tasks are run in order to upgrade to 4.5.0-b1:

• addProxySetting
• updateInvoiceTerms
• addPackageNames
• addPackageDescriptions
• addPackageGroupNames
• addPackageGroupDescriptions

If addProxySetting has already ran, then we can comment it out and run /admin/upgrade again in our browser. Then, check your database version again. If it's not at least 4.5.0-b1, then we may need to comment out the next task, updateInvoiceTerms and run /admin/upgrade again and check the database version again. Continue commenting out tasks ONE at a time and running /admin/upgrade until the upgrade is able to complete and shows the version of the most recent file in /components/upgrades/tasks/

Here's an example of a commented out task:

    public function tasks()
    {
        return [
            //'addProxySetting',
            'updateInvoiceTerms',
            'addPackageNames',
            'addPackageDescriptions',
            'addPackageGroupNames',
            'addPackageGroupDescriptions',
        ];
    }

Errors During Upgrade

• I received this error during upgrade:
  PDOException: SQLSTATE[42000]: Syntax error or access violation: 1071 Specified key was too long; max key length is 767 bytes in /var/www/html/vendors/minphp/db/src/PdoConnection.php:196
• This error occurs when the collation is updated from utf8 to utf8mb4 when a varchar 255 field has more than 767 bytes. In MySQL 5.7.7 and MariaDB 10.2.2, this value was increased to 3072 bytes. We would recommend upgrading your database and re-attempting the upgrade. As an alternative, you can try running this query prior to re-attempting an upgrade:

  • SET @@global.innodb_large_prefix = 1;
    
    

• I receive an error when upgrading through 5.8.0-b1:
  SQLSTATE[22004]: Null value not allowed: 1138 Invalid use of NULL value in /vendors/minphp/db/src/PdoConnection.php:196 Stack trace: #0 /vendors/minphp/db/src/PdoConnection.php(196): PDOStatement->execute(Array) #1 /components/upgrades/tasks/upgrade5_8_1.php(87): Minphp\Db\PdoConnection->query('ALTER TABLE `co...') #2 /components/upgrades/tasks/upgrade5_8_1.php(54): Upgrade5_8_1->setContactPermissionClientId() #3
• This error may occur when running the setContactPermissionClientId task in /components/upgrades/tasks/blesta5_8_1.php to solve:
  • Comment out the setContactPermissionClientId task in the upgrade file.

  • Run the following query on your database to resolve any orphaned records (BACKUP FIRST).

    Code Block
    language sql
    DELETE contact_permissions.* from contact_permissions left join contacts on contact_permissions.contact_id = contacts.id where contacts.client_id is null;