oui, il faut mettre l'équivalent de la date UNIX correspondant à 0:, je sais plus exactement mais c'est 1970

le NULL est a évité en PHP, vu qu'il est amené à disparaitre.

pour un timestamp, la valeur est obligatoirement un INT compris entre 0 et xxxxxx, donc si tu laisse le champs vide, je te conseille de mettre à 0.
Toutes valeurs non INT pour un timestamp est une erreur de codage. Et PHP devient susceptible sur les types de variables avec les versions. Et ce n'est pas plus mal

Ensuite, tu peux gérer avec JS, de laisser le champs du formulaire vide si le timestamp est à 0.

Pour ma part, en 1ère idée, pour ne pas passer par les sessions et sans ce prendre la tête, je rajouterai un champs GET qui a comme valeur ASC ou DESC, avec par défaut ASC par exemple

Smarty est ton ami ;)

Par exemple :


ici, Smarty teste la valeur de la variable $xoops_isuser
si le visiteur n'est pas connecté, je choisi d'afficher le template connect.tpl et si il est connecté, dans ce cas, c'est le template home.tpl qui sera affiché.

Ensuite tu peux utiliser le gestionnaire de blocs avec la gestion des droits par groupe. Il suffit d'interdire pour les "visiteurs".

Alors, quand on touche aux templates :
- vérifier que le template est surchargé (/theme/ton_theme/modules/ton_module/blocs/ton_template_bloc_a_modifier)
- désactiver le cache smarty dans les préférences générales, mettre "controler les modifications de templates" à oui
- à chaque affichage, pensez à initialiser le cache de ton navigateur, rechargement de page : CTRL + F5 (au lieu de F5)

merci Alain

c'est la fonction : function newbbIsForumModerators

Cette fonction ajoute les modérateurs à la liste des personnes autorisées.
Regarde si les modérateurs sont déclarés dans newBB et qu'ils ont le même userID que dans la base initiale.
Selon le message, le 1er paramètre est sensé être un tableau mais le script rencontre une valeur NULL (donc inexistant)

la gestion des encodages est un peu plus complexe que ça :

il faut regarder l'encodage de la table de départ et l'encodage des données présentes dans la table.

La table d'arrivée doit être en principe de l' UTF8_General_CI au minimum.

Si la table de départ et/ou les données sont en iso_latin_machin ou autre chose que le format d'arrivé, il faut convertir les tables/données avant de les insérer dans la nouvelle BDD. J'ai fait un convertisseur ici

Ensuite, il faut que le thème soit en UTF-8 :
suffit de regarder si tu as la ligne ci-dessous présent dans le theme


Il faut aussi vérifier que les templates des blocs / templates modules etc, sans enregistré en mode utf8 sans bom

ça évite par exemple ceci
ton module Paypal ne doit pas être utf-8

Pour ton pbs de smiley, en principe, les smileys sont encodés d'une certaines façon et Xoops les traduits.

Par exemple par : - ( (sans les espaces) donc s'ils n'apparaissent pas, peut-être voir l'éditeur par défaut de Xoops dans les préférences générales ou les préférences du module si newBB permet de choisir son propre éditeur

moi, perso, j'utilise maintenant pour la BDD, l'utf8mb4_general_ci pour que les visiteurs puissent commenter en utilisant les smileys de leurs téléphones. Mais attention, ne fonctionne pas par défaut sur tous les hébergeurs. Travaillant essentiellement sur serveur, je peux modifier les paramètres de MySQL/MariaDB pour que ça fonctionne sans soucis

Oui je confirme plus ou moins ce que dit JJDai,

dans les faits, pour un site si ancien (Xoops 2.5.4), il y a au minimum une bonne journée de préparation. Vérifier le site original, voir son état global, la version des modules (à cette époque, on peut trouver des modules jaunes), l'encodage de la BDD, la branche de NewBB utilisée (à cette époque, il existait sûr 3 branches distinctes, donc pour un numéro de versions, il existe 3 modules au minimum), les hacks réalisés au fur et à mesure des années, ...

Avec de la chance, si les étoiles sont bien alignées, il faut 1 journée de migration et plus ou moins une journée de tests.

Mais souvent, ce qui rallonge les délais :
- présence de vieux modules (les jaunes)
- présence de modules qui ne sont plus suivis
- présence de modules qui ne sont plus suivis mais remplaçable par un autre (faut créer un mapping spécifique, les modules n'ont souvent pas la même structure).
- la présence de plusieurs encodages dans la BDD
- l'altération des index de certaines tables de la BDD (ça m'est encore arrivé récemment sur PrestaShop)
- très grand écarts entre les versions de PHP ou de MySQL
- présence de SEO
- présence de URL_REWRITING
- Mettre en place de l'URL_REWRITING dans la nouvelle version si pas présente dans l'ancienne.
- le nombre de pages existantes
- nombre important de hacks utilisateurs
- le theme à migrer vers les techno récentes.
- ...
Et j'ai pas tout mis.

En résumé, le temps dépend de la complexité du site initiale, de son ancienneté et de sa notoriété (plus il y a de changement à l'heure sur un site, plus il est compliqué de le migré car il faut faire un script qui reprend toutes les modifs à faire et appuyer sur le bouton, ça évitera de perdre les dernières données, donc ça implique tests avant l'heure h de migration)

Je te conseille fortement de passer, si tu peux (et que les modules que tu utilises t'autorisent) est de passer à au minimum PHP7.3 et idéalement PHP7.4, au moins pour continuer à bénéficier des MAJ de sécurité de PHP.
Surtout que depuis Xoops 2.5.9, le core est plutôt optimisé sur ces versions de PHP.
En plus tu bénéficiera de la rapidité de PHP qui est le jour et la nuit entre PHP7.0 et 7.3 (7.1 et 7.2 étaient des versions de transition)

Il se peut que lors de MAJ de core trop importante, il y a des soucis de requêtes SQL (par exemple des indexations qui ont été rajouté et qui ne le sont pas).

Pour ma part j'utilise jamais les upgrades quand je dois faire des maj de très anciennes versions Xoops à la dernière, je créé une version neuve puis importe les tables au fur et à mesure. J'en profite pour les nettoyer au passage
Une fois le core fait, je fais la même chose module par module
C'est plus long, mais ça évite bien des problèmes