une autre piste probable :
Vérifier si serveur BDD est en fonctionnement, ça m'est arrivée, quand je démarre easyPHP, le serveur Apache et Mysql sont arrêtés par défaut, suffisait de les démarrer.

je m'en souvient plus, je sais que je l'ai essayé à une époque, car j'ai une copie d'une module dans mes archives.

@jjday, envoyer un pixel permet surtout de vérifier si le mail a été lu,
le plus simple est d'utiliser une API comme préciser ci-dessus.

Sinon moi, je vérifie avec la fonction checkdnsrr la présence d'un MX (existence du nom de domaine et présence d'un serveur de mail)[/a], sa limite déjà les envois inutiles.

A tout les coups, ça ressemble un problème de librairies PHP (voir Version PHP)
Sinon, dans l'ordre
- une fonction ou une class qui existent déjà (souvent PEAR ou conflit de modules) présent sur le neuf et pas l'ancien
- manque un fichier (parfois possible avec le FTP)
- possibilité faible de pbs de chemin

Voici les possibilités pour les erreurs critiques quand un module fonctionne sur hébergement et pas sur l'autre

merci @JJday, je vais regarder ça

Oui Backpack est dans la liste ;)

Niveau module :
- TCPDF_for_Xoops
- WideImage_for_xoops
- Backpack
- CHGminiboutique
- CHGmentions
- CHGalbums (petit nouveau)
- CHGpush (petit nouveau)

Après faut que je vois pour xo_rewrite

OK je le note, c'est facilement faisable, je suis occupé à préparer la mise à jour de tous les modules et frameworks que j'ai écrit.

Je vide les caches avant le basculement, donc j'ai jamais fait attention.
Normalement, les fichiers du cache sont inaccessibles via l'URL (répertoire xoops_data/cache en dehors de la racine du site), donc a priori, peu de danger.
De ce que j'ai regardé chez moi, il n'y a aucun rapport entre le préfixe des tables et le préfixe des fichiers caches.
J'ai pas regardé mais en général, le préfixe des fichiers caches est généré en fonction de l'URL, si tu modifie l'URL de http à https, il doit changer.
Après par mesure de sécurité, tu peux vider entièrement les répertoires des caches (sauf le fichier index.html).

non non l'UTF (8,16,32) ne rajoute pas de caractère d'échappement, il encode sur plusieurs octets certains caractères, il faut faire attention quand on coupe, si on coupe un caractère encodé sur plusieurs octets, on a un caractère bizarre (souvent un losange ou un carré avec du texte à l'intérieur).

ça va déconné avec abscon