Mettre à jour Invision Community : sauvegarde, upgrade et migration v5

Invision Power Board, souvent abrégé IPB, a longtemps été l’un des grands classiques des forums PHP. Aujourd’hui, le produit s’appelle Invision Community, et la logique de mise à jour a bien changé.

Autrefois, on téléversait les fichiers par FTP, on lançait un script d’upgrade, puis on croisait les doigts. Aujourd’hui, on commence par l’AdminCP, on vérifie les prérequis serveur, on sauvegarde proprement, on teste en staging si possible, puis on lance l’assistant de mise à jour.

Et surtout, on évite de traiter un forum communautaire comme un vieux fichier ZIP à écraser au petit bonheur la chance. Les membres, les messages, les pièces jointes, les permissions et les thèmes méritent mieux que ça.

IPB ou Invision Community : de quoi parle-t-on ?

Le nom IPB reste encore très utilisé par habitude, mais le logiciel moderne s’appelle Invision Community. Il ne s’agit plus seulement d’un forum : la suite peut inclure forums, pages, téléchargements, événements, commerce, clubs, blogs et fonctions communautaires avancées selon la licence.

Cette évolution change la manière d’aborder une mise à jour. On ne met plus seulement à jour un “forum”. On met à jour une application communautaire complète, avec sa base de données, son système de fichiers, ses thèmes, ses extensions et ses tâches de fond.

Le bon réflexe consiste donc à penser “maintenance applicative”, pas “copie FTP vite fait avant le café”.

Faut-il mettre à jour vers Invision Community 5 ?

Oui, si votre licence, vos extensions, votre thème et votre hébergement le permettent.

Invision Community 5 est désormais la branche moderne du produit. Invision a annoncé que la version 4 ne recevra plus de mises à jour ni de support après le 31 décembre 2026. Cela ne signifie pas que tous les sites doivent migrer dans la panique, mais cela signifie qu’un forum encore en v4 doit avoir un plan.

La bonne stratégie dépend de votre situation :

• Invision Community 5 déjà installé : appliquez les mises à jour mineures rapidement, surtout les mises à jour de sécurité.
• Invision Community 4 récent : préparez la migration vers v5, vérifiez les thèmes et extensions, puis testez en staging.
• IP.Board 3.x ou plus ancien : considérez le site comme legacy. La migration demande un vrai audit.
• IP.Board 2.x : il n’existe pas de chemin direct simple vers les versions modernes. Il faut envisager une migration assistée ou une refonte.

En clair : une mise à jour mineure se planifie. Une migration majeure se prépare. Et une résurrection d’IPB antique se négocie avec les dieux du PHP ancien.

Avant la mise à jour : faites l’inventaire

Avant de cliquer sur “Upgrade”, listez ce qui compose réellement votre communauté.

• Version actuelle d’Invision Community ou IP.Board.
• Version PHP utilisée par le site.
• Version MySQL ou MariaDB.
• Extensions PHP disponibles.
• Applications tierces installées.
• Plugins ou hooks personnalisés.
• Thèmes personnalisés.
• Langues et traductions.
• Mode de stockage des fichiers et pièces jointes.
• Tâches cron ou tâches lancées via trafic web.
• Volume de la base de données.
• Taille du dossier des uploads.

Ce travail paraît scolaire, mais il évite la moitié des catastrophes. Une extension incompatible peut suffire à casser l’AdminCP. Un thème non maintenu peut exploser l’affichage. Un hébergement trop ancien peut bloquer la mise à jour avant même la première requête SQL.

Vérifier les prérequis serveur

Invision fournit un outil de vérification des prérequis. Utilisez-le avant une mise à jour importante, surtout avant une migration majeure.

Sur un serveur Linux, vérifiez déjà les versions principales :

php -v
mysql --version

Vérifiez aussi les extensions PHP chargées :

php -m | sort

Si vous utilisez PHP-FPM, contrôlez la version réellement utilisée par le site web, pas seulement celle disponible en ligne de commande. Sur un serveur avec plusieurs versions PHP, le piège est classique.

systemctl list-units --type=service | grep -Ei 'php.*fpm'Langage du code : PHP (php)

Puis vérifiez votre virtual host Nginx ou Apache pour identifier le socket PHP-FPM réellement utilisé.

Ne mettez pas à jour sans sauvegarde complète

Une sauvegarde Invision Community doit contenir deux choses : les fichiers et la base de données. L’un sans l’autre ne suffit pas.

Pour sauvegarder les fichiers :

cd /var/www
tar -czf /root/invision-files-$(date +%F).tar.gz community.example.com/Langage du code : JavaScript (javascript)

Pour sauvegarder la base MySQL ou MariaDB :

mysqldump \
  --single-transaction \
  --quick \
  --routines \
  --triggers \
  --events \
  --default-character-set=utf8mb4 \
  -u database_user \
  -p database_name \
  | gzip > /root/invision-db-$(date +%F).sql.gzLangage du code : JavaScript (javascript)

Si votre forum contient beaucoup de pièces jointes, vérifiez la taille réelle du dossier :

du -sh /var/www/community.example.com
du -sh /var/www/community.example.com/uploadsLangage du code : JavaScript (javascript)

Ensuite, vérifiez que les sauvegardes existent et ne font pas zéro octet. Oui, ça arrive. Non, ce n’est jamais drôle.

ls -lh /root/invision-files-*.tar.gz
ls -lh /root/invision-db-*.sql.gz

Tester la restauration avant de continuer

Une sauvegarde non testée est une promesse, pas une assurance. Pour une petite communauté, vous pouvez restaurer sur un sous-domaine de staging. Pour une grosse communauté, préparez au moins une restauration locale ou sur une machine temporaire.

Le staging permet de vérifier :

• la compatibilité PHP ;
• la compatibilité MySQL ou MariaDB ;
• les erreurs de thème ;
• les extensions incompatibles ;
• les migrations de base de données ;
• les tâches de fond ;
• les permissions fichiers ;
• les problèmes de chemins absolus.

Pour une migration vers Invision Community 5, le staging n’est pas un luxe. C’est le filet de sécurité.

Méthode recommandée : mise à jour automatique depuis l’AdminCP

Pour une installation self-hosted récente, commencez par la méthode automatique.

Dans l’AdminCP, Invision affiche une alerte lorsqu’une mise à jour est disponible. Le processus vous demande généralement les identifiants liés à l’espace client Invision, pas votre mot de passe administrateur local.

Le système récupère ensuite les fichiers nécessaires, scanne l’installation, vérifie les problèmes éventuels, puis lance l’assistant d’upgrade. Pendant ce temps, la communauté affiche un message hors ligne indiquant qu’une mise à jour est en cours.

La séquence propre ressemble à ceci :

1. Lire les notes de version.
2. Faire une sauvegarde complète.
3. Vérifier les prérequis serveur.
4. Désactiver ou auditer les extensions tierces sensibles.
5. Lancer la mise à jour depuis l’AdminCP.
6. Suivre les étapes de l’assistant.
7. Vider les caches.
8. Vérifier le front, l’AdminCP et les tâches de fond.

Si le serveur ne peut pas écrire les fichiers, l’outil peut demander des identifiants FTP ou SCP. Si cette étape échoue, passez à la mise à jour manuelle.

Méthode manuelle : remplacer les fichiers puis lancer /admin/upgrade

La mise à jour manuelle reste utile si l’upgrade automatique échoue, si les permissions fichiers sont strictes, ou si vous gérez vous-même le déploiement.

La logique officielle est simple : télécharger le paquet complet depuis l’espace client Invision, extraire l’archive, puis envoyer le contenu du dossier extrait dans le répertoire principal du forum, en écrasant les fichiers existants.

Ensuite, ouvrez l’URL d’upgrade :

https://community.example.com/admin/upgradeLangage du code : JavaScript (javascript)

Connectez-vous avec un compte administrateur, puis suivez l’assistant. L’upgrader scanne les fichiers et signale ceux qui ne correspondent pas à la version attendue. Si des fichiers sont manquants ou incorrects, recommencez l’envoi avant de poursuivre.

En SSH, vous pouvez déployer plus proprement qu’en FTP avec rsync. Exemple :

rsync -avh --progress /tmp/ips_package/ /var/www/community.example.com/Langage du code : JavaScript (javascript)

Attention : adaptez le chemin source. Il faut envoyer le contenu du dossier du paquet, pas le dossier parent lui-même. Sinon, vous créez un joli sous-dossier inutile, et l’upgrader vous regardera de travers.

Passer une communauté hors ligne

Lors d’une mise à jour importante, mettez la communauté hors ligne depuis l’AdminCP. Cela évite les écritures concurrentes pendant les migrations de base de données.

Pour une petite mise à jour mineure, l’assistant gère souvent l’indisponibilité temporaire. Pour une migration majeure, je préfère annoncer une fenêtre de maintenance claire aux membres.

Message simple :

La communauté est temporairement hors ligne pour maintenance. Nous appliquons une mise à jour technique et serons de retour prochainement.

Évitez les messages vagues du type “Erreur technique”. Les utilisateurs pardonnent beaucoup plus facilement une maintenance annoncée qu’un écran cassé sans explication.

Désactiver ou auditer les extensions tierces

Les applications, plugins, thèmes et hooks tiers sont les grands suspects d’une mise à jour ratée. Avant une migration majeure, vérifiez chaque élément :

• est-il compatible avec la version cible ?
• est-il encore maintenu ?
• existe-t-il une version compatible Invision Community 5 ?
• modifie-t-il les templates, l’éditeur ou le login ?
• touche-t-il aux permissions, au paiement ou aux membres ?

Pour les vieux forums IPB, les skins, hooks, traductions et applications tierces peuvent bloquer la migration. Invision indique d’ailleurs que les skins, hooks, applications tierces et langues d’IP.Board 3.x ne sont pas compatibles tels quels avec les versions modernes.

Le bon réflexe : désactiver ce qui n’est pas indispensable avant la migration, puis réactiver progressivement après validation.

Vérifier les permissions fichiers

Après l’envoi des fichiers, vérifiez les droits. Les fichiers doivent être lisibles par le serveur web, et certains répertoires doivent rester inscriptibles par PHP selon la configuration : uploads, datastore, cache ou stockage local selon votre installation.

Exemple générique pour une installation servie par www-data :

chown -R www-data:www-data /var/www/community.example.com
find /var/www/community.example.com -type d -exec chmod 755 {} \;
find /var/www/community.example.com -type f -exec chmod 644 {} \;Langage du code : JavaScript (javascript)

Ce n’est pas une règle universelle. Certains hébergements utilisent un utilisateur par site, et il vaut mieux éviter de tout donner à www-data sur un serveur mutualisé ou multi-sites. Adaptez aux pratiques de votre serveur.

Cas particulier : IP.Board 3.x

Si votre communauté tourne encore sous IP.Board 3.x, ne parlez pas de simple mise à jour. Parlez de migration legacy.

La base des membres, forums, sujets et messages peut être conservée lors d’un chemin de migration prévu vers Invision Community 4. En revanche, plusieurs éléments ne suivent pas proprement :

• skins ;
• images de skins ;
• hooks tiers ;
• applications tierces ;
• langues ;
• templates IP.Content ;
• certains comportements de modération ;
• anciens chemins de stockage.

Avant de migrer, il faut donc faire un inventaire fonctionnel : ce qui doit être gardé, ce qui peut disparaître, ce qui doit être reconstruit, et ce qui peut être remplacé par une fonction native récente.

Sur une vieille communauté, ce tri est souvent plus important que l’upgrade lui-même. Les vieux plugins finissent toujours par raconter leur petite histoire au pire moment.

Cas particulier : IP.Board 2.x et versions plus anciennes

Si vous partez d’IP.Board 2.x, il n’y a pas de chemin direct confortable vers les versions actuelles. Il faut généralement passer par une prestation spécialisée, une migration intermédiaire, ou une stratégie d’export/import selon l’état des données.

Dans ce cas, posez d’abord ces questions :

• le forum contient-il encore une communauté active ?
• les comptes utilisateurs doivent-ils être conservés ?
• les anciens messages doivent-ils rester indexables ?
• les pièces jointes sont-elles encore utiles ?
• le SEO des anciennes URLs compte-t-il encore ?
• faut-il migrer vers Invision Community, WordPress, Discourse ou une archive statique ?

Parfois, le meilleur upgrade d’un très vieux forum n’est pas une mise à jour. C’est une archive propre, consultable, sécurisée et bien redirigée.

Après l’upgrade : les contrôles indispensables

Une fois l’assistant terminé, ne rouvrez pas immédiatement la communauté sans vérifier les points essentiels.

• La page d’accueil charge correctement.
• Les forums, sujets et messages s’affichent.
• La connexion membre fonctionne.
• L’AdminCP fonctionne.
• Les permissions de groupes sont cohérentes.
• Les pièces jointes et images s’affichent.
• La recherche fonctionne.
• Les e-mails transactionnels partent correctement.
• Les tâches de fond s’exécutent.
• Les thèmes ne génèrent pas d’erreurs.
• Les extensions tierces critiques fonctionnent.
• Les logs PHP et serveur web ne hurlent pas.

Sur un serveur Linux, surveillez les logs pendant les premières minutes :

tail -f /var/log/nginx/error.log
tail -f /var/log/php*-fpm.logLangage du code : JavaScript (javascript)

Sur Apache :

tail -f /var/log/apache2/error.logLangage du code : JavaScript (javascript)

Adaptez les chemins selon votre distribution, votre panneau d’hébergement ou votre stack.

Relancer les tâches de fond

Invision Community s’appuie sur des tâches de fond pour traiter plusieurs opérations : notifications, indexation, nettoyage, files d’attente et tâches applicatives. Après une mise à jour, vérifiez qu’elles s’exécutent correctement.

Dans l’AdminCP, contrôlez la section dédiée aux tâches. Si votre installation utilise une tâche cron serveur, vérifiez qu’elle existe toujours et pointe vers le bon PHP.

crontab -l -u www-data

Si vous avez changé de version PHP pendant la mise à jour, assurez-vous que la tâche cron n’appelle pas une ancienne version. C’est un classique : le site tourne en PHP récent, mais la cron continue de lancer un vieux binaire dans un coin sombre du serveur.

Vider les caches et reconstruire ce qui doit l’être

Après l’upgrade, videz les caches applicatifs depuis l’AdminCP. Si vous utilisez un cache serveur, un CDN ou un reverse proxy, purgez aussi ces couches.

• cache Invision ;
• cache PHP OPcache ;
• cache Nginx ou Apache si configuré ;
• cache CDN ;
• cache navigateur pendant les tests ;
• index de recherche si nécessaire.

Pour redémarrer PHP-FPM :

systemctl restart php8.3-fpmLangage du code : CSS (css)

Adaptez évidemment la version PHP. Sur certains serveurs, vous aurez php8.2-fpm, php8.4-fpm ou un nom personnalisé fourni par l’hébergeur.

Surveiller les performances après migration

Une mise à jour majeure peut modifier les performances : nouvelles requêtes SQL, nouveaux templates, nouveau JavaScript, nouveaux caches, nouvelles tâches de fond. Surveillez donc le site pendant quelques heures, puis pendant les jours suivants.

Quelques commandes utiles :

top
htop
df -h
free -m
ss -s

Pour MySQL ou MariaDB, surveillez les requêtes lentes si le slow log est actif :

tail -f /var/log/mysql/mysql-slow.logLangage du code : JavaScript (javascript)

Une communauté active peut générer beaucoup de charge après réouverture : membres qui se reconnectent, notifications, robots d’indexation, caches froids, reconstructions internes. Ne jugez pas les performances sur les trente premières secondes.

Checklist rapide avant de rouvrir le forum

• Sauvegarde fichiers vérifiée.
• Sauvegarde base de données vérifiée.
• Version PHP compatible.
• Version MySQL ou MariaDB compatible.
• Extensions PHP nécessaires présentes.
• Thème compatible ou thème par défaut prêt.
• Extensions tierces auditées.
• Upgrade terminé sans erreur.
• AdminCP accessible.
• Connexion membre testée.
• Publication de sujet testée.
• Upload de fichier testé si utilisé.
• Envoi d’e-mail testé.
• Tâches de fond opérationnelles.
• Logs serveur propres.
• Cache vidé.
• Plan de retour arrière disponible.

Plan de retour arrière

Le plan de retour arrière doit être prêt avant l’upgrade, pas improvisé après l’échec.

Pour restaurer les fichiers :

cd /var/www
tar -xzf /root/invision-files-YYYY-MM-DD.tar.gzLangage du code : JavaScript (javascript)

Pour restaurer la base :

gunzip -c /root/invision-db-YYYY-MM-DD.sql.gz | mysql -u database_user -p database_name

Si vous avez un snapshot serveur ou VM, c’est encore mieux. Mais ne remplacez pas les sauvegardes applicatives par un seul snapshot opaque. Les deux approches se complètent.

Erreurs fréquentes pendant une mise à jour Invision Community

Page blanche après l’upgrade

Vérifiez d’abord les logs PHP et serveur web. Une page blanche signale souvent une erreur fatale PHP, une extension manquante, un fichier mal téléversé ou une incompatibilité de thème.

Fichiers signalés comme incorrects

L’upgrader peut refuser d’aller plus loin si certains fichiers ne correspondent pas. Réenvoyez le paquet complet, vérifiez que l’upload n’a pas échoué, puis relancez l’assistant.

Erreur de connexion à la base

Vérifiez le fichier de configuration, les identifiants MySQL, les droits de l’utilisateur, le nom de la base et le service MariaDB/MySQL. Si vous avez déplacé le site en staging, vérifiez aussi les hôtes autorisés.

Thème cassé après migration

Revenez temporairement au thème par défaut, puis corrigez le thème personnalisé. Les migrations majeures cassent souvent les templates très modifiés.

Extensions incompatibles

Désactivez les extensions tierces, puis réactivez-les une par une. Si une extension n’est plus maintenue, remplacez-la. Garder une extension morte dans une communauté active, c’est inviter un gremlin dans la salle serveur.

Faut-il migrer vers une autre plateforme ?

La mise à jour n’est pas toujours la meilleure décision. Si votre forum est peu actif, très ancien ou trop personnalisé, posez la question franchement : faut-il vraiment rester sur Invision Community ?

Quelques options existent :

• rester sur Invision Community, si la communauté est active et la licence justifiée ;
• migrer vers Discourse, si vous voulez une plateforme moderne centrée discussion ;
• intégrer une partie dans WordPress, si le forum sert surtout de contenu éditorial ou support ;
• créer une archive statique, si l’objectif est de conserver les anciennes discussions sans maintenir un forum complet.

Pour une communauté active, Invision reste une solution solide. Pour un vieux forum abandonné, l’archive propre peut être plus raisonnable qu’une grosse migration logicielle.

FAQ

Peut-on encore parler d’IPB ?

Oui, par habitude, mais le nom actuel est Invision Community. Pour un article moderne, il vaut mieux utiliser “Invision Community” dans le titre et garder “IPB” dans le texte pour les anciennes recherches.

Faut-il utiliser FTP pour mettre à jour Invision Community ?

Pas en priorité. Utilisez d’abord l’upgrade automatique depuis l’AdminCP. Si l’écriture automatique échoue, passez à la méthode manuelle avec SFTP, SCP ou rsync plutôt qu’un FTP non sécurisé.

Puis-je mettre à jour directement depuis IP.Board 3.x vers Invision Community 5 ?

Ne partez pas du principe que ce sera direct. Les anciennes versions demandent souvent une migration intermédiaire, un audit des données et la suppression des éléments incompatibles. Testez toujours sur une copie.

Que faire si le thème est incompatible ?

Activez un thème compatible ou le thème par défaut, puis reconstruisez les personnalisations. Les migrations majeures sont souvent l’occasion de repartir sur un thème propre plutôt que de patcher un vieux skin à bout de souffle.

Faut-il sauvegarder les pièces jointes ?

Oui. Les pièces jointes, avatars, images et fichiers uploadés font partie du site. Une sauvegarde de base de données seule ne permet pas de restaurer une communauté complète.

Invision Community 4 est-il encore maintenu ?

Invision a annoncé que la version 4 ne recevra plus de mises à jour ni de support après le 31 décembre 2026. Si vous êtes encore en v4, préparez la migration vers v5.

Conclusion

Mettre à jour Invision Community ne consiste pas seulement à écraser des fichiers. Il faut vérifier les prérequis, sauvegarder les fichiers et la base, tester si possible en staging, lancer l’upgrade proprement, puis contrôler les thèmes, extensions, tâches et logs.

Pour une installation récente, l’AdminCP reste la méthode la plus simple. Pour une migration majeure, surtout depuis IP.Board ou Invision Community 4 vers v5, prenez le temps de préparer le terrain.

Une communauté contient souvent des années de discussions, de liens, de comptes et de contenus. Elle mérite une mise à jour chirurgicale, pas un coup de pelle numérique.

À lire aussi sur SkyMinds

• Mettre à jour Ubuntu vers la dernière version disponible
• Installer PHP 8.5 sur Ubuntu Server
• Installer Nginx avec HTTP/2, TLS, PHP et MariaDB sur un serveur dédié
• Sécuriser Apache avec ModSecurity sur un serveur dédié

Sources

• Invision Community — Install and Upgrade
• Invision Community — fin de cycle annoncée pour la version 4
• Invision Community — sortie d’Invision Community 5.0.0
• Invision Community — notes de version v5

Report a typo