Passage à Drupal 8.4.0 sur un VPS

Je me suis heurté à plusieurs types de complications depuis l'installation de Drupal 8 sur mon "serveur privé virtuel" ou VPS, allant du manque de capacité serveur à des problèmes liés au core Drupal, en passant par des erreurs en utilisant les célèbres outils Drush et Drupal Console. 

Cet article traite de quelques difficultés que vous pourriez rencontrer avec dans mon cas bien précis leur solution, mais également le passage à la version 8.4.0 de Drupal, dernière version stable à ce jour.


Un problème mysql récurrent

Le moteur de stockage de MySQL InnoDB stocke tout dans un seul et même fichier ibdata1 (bases, tables, indexes, etc), généralement situé dans le répertoire /var/lib/mysql/ du serveur.

Ce fichier est ce qu'on appelle "auto-extensible", c'est-à-dire qu'il grossit automatiquement et peut vite dépasser le Go, puis plusieurs. C'est précisément ce qui m'est arrivé, ce qui pose un réel problème lorsqu'on a peu d'espace disponible sur son serveur, ce qui est le cas pour mon modeste VPS. Pour vous dire à quel point cela peut être bloquant, la commande suivante qui permet de vider les logs — pour justement libérer de l'espace disque — renvoyait un message d'erreur... par manque de place !

$ service rsyslog restart

En regardant les logs :

$ nano /var/log/syslog
[...] /etc/init.d/mysql[1996]: ERROR: The partition with /var/lib/mysql is too full!

En effet, j'avais bien un répertoire mysql supérieur à 5 Go, car ibdata1 avait dépassé les 5 Go.

Je vous passe les recherches, et vous cite la procédure qui m'a sauvé la mise :

To shrink ibdata1 once and for all you must do the following:

  1. Dump (e.g., with mysqldump) all databases into a .sql text file (SQLData.sql is used below)

  2. Drop all databases (except for mysql and information_schemaCAVEAT : As a precaution, please run this script to make absolutely sure you have all user grants in place:

    mkdir /var/lib/mysql_grants
    cp /var/lib/mysql/mysql/* /var/lib/mysql_grants/.
    chown -R mysql:mysql /var/lib/mysql_grants
  3. Login to mysql and run SET GLOBAL innodb_fast_shutdown = 0; (This will completely flush all remaining transactional changes from ib_logfile0 and ib_logfile1)

  4. Shutdown MySQL

  5. Add the following lines to /etc/my.cnf (or my.ini on Windows)

    [mysqld]
    innodb_file_per_table
    innodb_flush_method=O_DIRECT
    innodb_log_file_size=1G
    innodb_buffer_pool_size=4G

    (Sidenote: Whatever your set for innodb_buffer_pool_size, make sure innodb_log_file_size is 25% of innodb_buffer_pool_size.

    Also: innodb_flush_method=O_DIRECT is not available on Windows)

  6. Delete ibdata* and ib_logfile*, Optionally, you can remove all folders in /var/lib/mysql, except /var/lib/mysql/mysql.

  7. Start MySQL (This will recreate ibdata1 [10MB by default] and ib_logfile0 and ib_logfile1 at 1G each).

  8. Import SQLData.sql

Now, ibdata1 will still grow but only contain table metadata because each InnoDB table will exist outside of ibdata1ibdata1 will no longer contain InnoDB data and indexes for other tables.

Source : stackoverflow.com

 

Drush FAIL

Quand vous rencontrez cette erreur en tapant une commande Drush :

PHP Fatal error: Class 'Drupal\Core\StringTranslation\PluralTranslatableMarkup' not found in core [...]

C'est probablement que vous avez une version incompatible avec votre version Drupal. En l'occurrence, une mise à jour Drush de 5.4 à 8.1.14 (à ce jour la dernière version 8 stable) a réglé mon problème.

Pour information, la documentation Drush officielle avec le tableau des compatibilités Drupal : http://www.drush.org/en/master/install/#drupal-compatibility

 

Drupal console FAIL

En tapant des commandes Drupal Console, par exemple celle qui permet de vider les caches :

$ drupal cr

console.dotenv_init - You have requested a non-existent service "console.dotenv_init_generator"

[ERROR] Command "cr", is not a valid command name. 

Et la solution en une commande : 

$ composer update drupal/console --with-dependencies --optimize-autoloader

Source : https://github.com/hechoendrupal/drupal-console/issues/3485#issuecomment-330245842

 

Le passage de Drupal 8.3.7 à 8.4.0

Pour commencer, une erreur de swap

...en utilisant composer, vite réglée grâce au lien indiqué dans l'erreur, à savoir :

https://getcomposer.org/doc/articles/troubleshooting.md#proc-open-fork-failed-errors

Une mise à jour mal sourcée

En voulant mettre à jour Drupal via composer, après avoir lancé les commandes classiques :

$ composer update drupal/console --with-dependencies

The "https://packagist.drupal-composer.org/packages.json" file could not be downloaded

La solution est à trouver dans la documentation officielle de Drupal, plus précisément l'article Using packages.drupal.org. Il indique la chose suivante :

Your composer.json repository section should end up looking like this:

{
    "repositories": [
        {
            "type": "composer",
            "url": "https://packages.drupal.org/8"
        }
    ]
}

Le changement dans le fichier composer.json à la racine du projet permet de régler cette erreur.

Par la suite

Une autre erreur bloquante après avoir lancé la même commande composer indiquée dans le paragraphe précédent :

Installation request for symfony/class-loader (locked at v2.8.18, required as ~2.8) -> satisfiable by symfony/class-loader[v2.8.18].
So as I mentioned above, you're stuck in dependency hell. You can't update to 8.4 because Symfony 2.8.28 is incompatible with 8.4. You can't update to Symfony 3.2 because it's incompatible with 8.3.7.

Suite à moultes recherches, voilà la procédure décrite sur le forum officiel de drupal.org qui m'a permis de mener à bien cette fameuse mise à jour :

1.
edit composer.json
change drupal version to ^8.4
if any change drush version ~9.0

2.
rename /vendor to /_vendor
rename /core to /_core
rename composer.lock to _composer.lock
- - available for easy rollback if problems occur

3.
run composer update drupal/core

4.
from browser run {site}/update.php

5. clear the cache from either admin GUI or drush

6. check basics from admin GUI, such as status report

7.
delete /_vendor
delete /_core
delete _composer.lock

8. proceed to Drupal 8.4.0 - test carefully
- this update causes various known problems, such as breaking existing site features that use jquery

Source : https://www.drupal.org/forum/support/upgrading-drupal/2017-10-06/update-to-84-with-composer#comment-12294335

 

 

Des configurations récalcitrantes

En voulant activer des modules et mon thème, l'erreur suivante est apparue :

Unable to install XXXX, XXXX.settings already exists in active configuration.

Drush me retournait le message suivant :

Configuration objects (...) already exists in active configuration

La solution : supprimer les lignes concernées de la table config.

Autre alternative : installer le module Easy Install (à ce jour en version alpha) qui permet de supprimer via le backoffice les configurations des modules installés.

 

Erreur remontée par le core Drupal

Peu après la mise à jour, je suis tombé sur cette erreur : 

The URI is invalid. You must use a valid URI scheme Drupal\Core\Utility\UnroutedUrlAssembler core/lib/Drupal/Core/Utility/UnroutedUrlAssembler.php

Le problème provient probablement d'un oubli ou erreur dans le fichier services.yml situé dans le dossier /sites/default/, c'est lui qui indique les protocoles autorisés comme http ou https par exemple. A retrouver à la fin du fichier après la ligne filter_protocols.

Un article intéressant à ce propos : Change list of valid URI schemes in Drupal 8

 

Pour terminer ce billet, un article qui détaille le passage à Drupal 8.4.0, découvert récemment après la mise à jour mais ça peut toujours servir !

Le lien : Update to Drupal core 8.4, a step by step guide