ZwiiCMS 13.4.00

fred

Voici le descriptif des modifications https://forge.chapril.org/ZwiiCMS-Team/ZwiiCMS/releases/tag/13.4.00
Le téléchargement se fera depuis cette page.
Les tests sont les bienvenus à partir du descriptif des modifications.
Merci du retour des testeurs, publication prévue d'ici deux semaines.

fred

Cette mise à jour modifie la méthode d’authentification en supprimant le cookie contenant le hash du mot de passe.
Désormais, lors du login, une clé aléatoire est ajoutée dans les données du compte et dans un cookie d’authentification. Lorsque les deux clés correspondent, l’utilisateur est connecté. Lors de la déconnexion, la clé est effacée du compte et le cookie détruit.
Ainsi,le hash du mot dépasse n’est plus exposé.

fred

Attention, après l'installation sur un site existant, il faudra se reconnecter en ajoutant ? dans l'url.

lemimi

Bonjour,
J'ai effectué une installation neuve de la version 13.4.00 il y a quelques jours, et je n'ai encore rien trouvé qui cloche de mon côté ! Voir ici
J'ai fait aussi un transfert du tout, sauf dossier site, par FTP sur celui-ci, et rien relever d'anormal non plus.
Bonne journée... Michel

fred

Bonjour,
Merci Michel de ton retour.
J'ai également basculé tous mes sites. Le seul inconvénient de la mise à jour auto est la déconnexion, il faudrait imaginer une solution.
Bonne journée Michel

mulanee

Bonjour,
Pourquoi je ne fais plus de MAJ auto via le site.
A chaque fois je me dis "toujours par FTP", je tente malgré tout et ça foire :(

fred

Bonjour @mulanee
Cette erreur est presque normale, la session change pour mieux isoler les sites sur le même site dans la même navigateur. Changement de session dit variable indéfinie.
~~Une copie de vos traces d'erreur me serait utile, il faut corriger ce comportement avant de lâcher la version en public.
Ce ne peut pas être la cause, la modification de session n'affecte pas ce changement de version.

mulanee

@fred
Bonjour, MP

fred

Bonjour @mulanee
Le sujet de discussion concerne la version 13.4, suite à ton MP, je pense que le VPN peut être la cause de l'échec.

fred

Bonjour tout le monde,

Je ne suis pas complétement satisfait de la persistance des cookies pour une connexion réellement permanente, de plus, je voudrais transférer quelques cookies dans la session php. Je proposerai bientôt un correctif identifié 13.4.00.1

Thispy

Bonjour,

Je n'ai pas rencontré de problème avec la version 13.4.00

Bonne journée,

fred

Bonsoir tout le monde,
@Thispy RFM signifie Responsive File Manager, un gestionnaire de contenu en ligne qui n'a pas évolué depuis un moment et qu'il faut adapter au fil des sorties de versions de php.
Pour déclencher des scripts à heure ou date fixes, j'utilise https://console.cron-job.org/
Phpblocnotes utilise un framework, symphony. Zwii n'utilise pas de framework, il dispose de son propre outil ce qui évite les installations de dépendances.
@lemimi
Ton erreur est due à une classe non instanciée, tu dois passer par le routeur et suivre cette adresse http://SITE_ADRESSE/?config/autoupdate
L'url que j'avais donnée et pour les curieux qui veulent comprendre le code.

Thispy

Bonjour,

Merci de l'info @fred

Bonne fin de soirée,

Cordialement,

fred

Bonjour,
Pour éviter l'erreur mentionnée par @mulanee lors de la mise à jour, une version intermédiaire de ZwiiCMS est déjà disponible en mise à jour automatique.
L'intérêt de cette mise à jour est de modifier le script en charge de la mise à jour afin de traiter correctement la déconnexion après l'étape 3. En effet, le système d'authentification de la 13.4 ne stocke plus le mot de passe dans un cookie, il utilise désormais une clé d'authentification.

Thispy

Bonjour,

Afin de procéder à la mise à jour vers la version 13.4.00, il est nécessaire d'accéder à l'URL suivante et de saisir la commande suivante : http://SITE_ADRESSE/?config/autoupdate ?

Cordialement,

fred

Bonjour,

Pas du tout @Thispy, il y a une confusion avec un sujet connexe que je vais diviser. La mise à jour s'effectue d'une manière standard, soit en FTP soit par l'auto-update.

TipO

Bonjour,
j'ai procédé successivement aux mises à jour par auto-update vers 13.3.08 puis 13.4.00. J'ai eu droit au même message d'erreur que @mulanee, puis tout s'est affiché normalement.

fred

Bonjour tout le monde,

Cette version est téléchargeable à l'aide de la mise à jour automatique ou depuis la forge.

Voici la liste des éditions :

Versions 13.4.00

** Améliorations :**

• Change le mode d'authentification, le hash du mot de passe n'est plus stocké dans un cookie.
• Améliore les performances des opérations d'écriture.
• Le sélecteur de fichier affiche le chemin d'accès du fichier présent dans le champ dans le gestionnaire de fichier.
• Connexion persistante renforcée.
• Script Datatables.net filtrage des éléments, nombre d'éléments et position sur l'écran.
• Slider 7.2, le dossier sélectionné est affiché par défaut dans la page update.
• Augmente la dimension des miniatures après le transfert dans RFM.
• Search 3.3 n'effectue qu'une seule lecture du fichier module.json en prévention des bots agressifs.
• Modification du contenu de robots.txt afin de n'autoriser que les moteurs de recherche et d'interdire les bots.
• Suppression des cookies mémorisant le dernier onglet affiché dans l'édition de la page et dans la configuration du site. Cette information est désormais stockée dans la fiche de l'utilisateur connecté.

**Corrections : **

• Change les paramètres du cookie de consentement.
• Isole la session dans l'onglet actif.
• Edition de page, delete et duplicate renvoyant vers une mauvaise page.
• Supprime un warning à la création d'une page.
• Bouton de génération du site inopérant.
• Affichage intempestif des boutons de navigation de pages dans les vues des modules.

Je précise que @Rémi a contribué à l'optimisation des performances en détectant des répétitions d'écriture de données. Tout a été corrigé ce week-end.
Bientôt une nouvelle mise à jour améliorant encore les performances.

fred

@TipO , le cache n'ayant pas été vidé, le script jquery est toujours chargé en RAM. Je ne peux pas y faire grand chose.

FM69

Bonjour,

La mise à jour est passée comme sur des roulettes et pas de problème majeur sur mon player radio. J'ai constaté que je n'ai pas eu à ajouter de "?". Je pense que les sites ayant activé les "Apache URL intelligentes". D'ailleurs, il m'est impossible de décocher l'option !

Aussi, sur Firefox, j'ai un avertissement de Cookie :

"Le cookie « ZWII_UI » n’a pas de valeur d’attribut « SameSite » appropriée. Bientôt, les cookies dont l’attribut « SameSite » est manquant ou défini avec une valeur invalide seront traités comme « Lax ». Cela signifie que le cookie ne sera plus envoyé dans des contextes tiers. Si votre application dépend de la disponibilité de ce cookie dans de tels contextes, veuillez lui ajouter l’attribut « SameSite=None ». Pour en savoir plus sur l’attribut « SameSite », consultez https://developer.mozilla.org/docs/Web/HTTP/Headers/Set-Cookie/SameSite"

Et un avertissement sur le "content-type" :

"Le « Content-Type » HTTP « text/html » n’est pas géré. Le chargement de la ressource média https://lesitedeflo.floinfo38.com/# a échoué."

Contexte : Je suis dans l'obligation de mettre un lien # sur mon player afin de recevoir un flux radio défini.

Je ne vois pas la ligne <meta http-equiv="content-type" content="text/html; charset=UTF-8"> sur mes autres sites. Je pense que cette ligne n'a pas lieu d'exister encore. D'autant plus qu'il me semble y avoir une redondance sur le charset=UTF-8 :

<head>
 <meta charset="UTF-8">
 <meta http-equiv="content-type" content="text/html; charset=UTF-8">
 ...

Des avertissements Firefox très mineurs, du reste !

Merci

fred

Bonjour @FM69
Merci du retour. ZWII_UI détermine la langue du site, je pense que bientôt, il passera en session.
J'ai ouvert ton site qui est très bien fait d'ailleurs, je n'ai pas eu d'erreur avec ou sans # (lié à une ancre) sauf

rblsdf.js:81 Uncaught (in promise) NotSupportedError: The element has no supported sources.

Erreur qui a disparu après un rechargement.
Oui il y a une redondance que j'ai évitée.

mulanee

Bonjour,

Installé par FTP sans problème, j'ai bien accès au store des modules également
Je ne comprends pas la signification des symboles mais ce n'est pas nouveau, un clic sur l'icône rouge ne change pas sa couleur..

fred

Bonne nouvelle @mulanee
Les icônes rouges correspondent à des modules attachés à des pages, ce qui peut éveiller l'attention en cas de problème de mise à jour.

FM69

Bonjour @fred,
Je te remercie pour le compliment sur mon site
Depuis lors, j'ai un réel léger problème. Très léger, car c'est un site Single-Page côté visiteur.
Autant l'option "Apache URL intelligentes" n'était pas "décochable", il y a cinq jours, autant je n'arrive plus à l'activer aujourd'hui. Au clic, la coche ne se met pas en bleu. Elle est désactivée en permanence.
J'ai déjà "remis" le .htaccess par défaut, mais rien ne change. Mon hébergement est bien en Apache.
Si, c'est juste embêtant pour la page de connexion, il faut ajouter un "?". Mais bon, sans plus quoi !
Au mieux, pour que je l'ajoute manuellement au fichier .htaccess, aurais-tu le code que Zwii met automatiquement lorsqu'on coche cette option ? Entre les lignes suivantes :

# ne pas supprimer la ligne URL rewriting !
# URL rewriting

Je te remercie !

FM69

Pour le code, <meta http-equiv="content-type" content="text/html; charset=UTF-8">, voici ce que dit l'IA Copilot :

"Le code HTML que vous mentionnez :

<meta http-equiv="content-type" content="text/html; charset=UTF-8">
est en effet considéré comme obsolète dans les versions modernes de HTML. Depuis HTML5, il est recommandé d’utiliser simplement :

<meta charset="UTF-8">
Cette méthode est plus concise et largement supportée par les navigateurs."

En fait, même si l'erreur reste un simple avertissement sans conséquences, je me demandais si cette ligne était encore nécessaire, tout simplement. D'où l'objet de ma question, puis de ma recherche aujourd'hui, vois-tu !

fred

Bonjour @FM69 ,

Voici les lignes ajoutées pour une URL LOCALHOST, il faudra adapter la ligne RewriteBase, / à la racine

`# ne pas supprimer la ligne URL rewriting !

URL rewriting

RewriteEngine on
RewriteBase /ZwiiCMS/
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule ^(.*)$ index.php?$1 [L]

URL rewriting`

La case à cocher s'active selon ces deux conditions :
stripos($_SERVER["SERVER_SOFTWARE"], 'Apache') === false and $module->isModRewriteEnabled()

Le serveur est "vue" comme Apache et le module de réécriture est activé. Il se peut que cela ne soit pas le cas sur ton hébergement.

Sinon, avec l'inspecteur du navigateur, il est possible de supprimer l'attribut readonly.

Quelle que soit la méthode, si tout fonctionne, il faudra corriger les conditions dans Zwii.

fred

Concernant la META, il est peut-être bon de conserver une assiette de compatibilité plus large, dans tous les cas, cela ne change pas grand-chose.

TipO

@fred, la 13.5.00 installée via FTP fonctionne bien. J'ai commencé à faire des essais.

Merci mille fois !

fred

Bonsoir tout le monde,
Je viens de me rendre compte que cette version de Zwii n'a pas eu sa mise à jour en ligne ! C'est corrigé.

FM69

salut @fred,

Bon, j'ai fait des investigations avec ChatGPT concernant URL Rewriting Apache. D'après les tests effectués, mon serveur web est passé de Apache à Litespeed. Ainsi, la coche est grisée.

Voici la discussion :

"La valeur LiteSpeed pour SERVER_SOFTWARE explique pourquoi la condition échoue, car elle recherche spécifiquement Apache. Bien que LiteSpeed soit compatible avec les fichiers .htaccess et mod_rewrite, il n'est pas explicitement détecté comme Apache dans ce contexte.

Solution temporaire pour tester :
Modifie directement la condition dans le CMS Zwii pour inclure LiteSpeed comme serveur valide. Trouve le fichier où cette condition est définie (probablement dans une classe ou un contrôleur) et ajuste ainsi :

Code à chercher et modifier :

if (stripos($_SERVER["SERVER_SOFTWARE"], 'Apache') === false && $module->isModRewriteEnabled()) {
    // Code existant
}

Remplace par :

if ((stripos($_SERVER["SERVER_SOFTWARE"], 'Apache') !== false || stripos($_SERVER["SERVER_SOFTWARE"], 'LiteSpeed') !== false) && $module->isModRewriteEnabled()) {
    // La case à cocher devient activable
}

Étapes :
Reproduis cette modification dans le fichier concerné.
Recharge la page du CMS.
Vérifie si la case à cocher devient active et si tu peux utiliser l'option de réécriture d'URL.
Si cela fonctionne :
Tu pourras inclure cette modification de manière permanente dans ton installation Zwii. LiteSpeed étant largement utilisé, cette correction pourrait également être partagée avec la communauté ou les développeurs du CMS pour qu'ils l'intègrent officiellement.

Dis-moi si cela débloque la situation ! 😊"

J'ai aussi un problème de génération des fichiers robots.txt et sitemap.xml avec l'erreur "Échec de l'écriture, vérifiez les permissions". J'ai vérifié les permissions des dossiers et fichiers, c'est OK. Mais est-ce que cela vient aussi du serveur Litespeed ?? C'est probable !

PS 1 : Je précise que mon hébergeur a migré de serveur et qu'avant tout fonctionnait. J'en conclus que l'ancien devait donc être sous Apache.
PS 2 : Je pense que tu as compris pourquoi j'ai partagé la discussion avec l'AI (car il te cite indirectement). Si cela pose un problème, je supprimerai ce message.
PS 3 : J'ai installé la version 13.5.00 via FTP. Le core est tout neuf. Cela m'a permis d'isoler une possibilité.

Merci beaucoup !

Florian @FM69

fred

Salut @Florian,

Tu peux conserver ton post tel qu'il est.
Je reprends dans 13.5.00 dans la branche (doubleauth) qui n'est pas encore publiée cette modification qui prend en charge LiteSpeed. D'après les renseignements que j'ai trouvés, ce serveur est beaucoup plus rapide qu'Apache.
En revanche, j'ai préféré ajouter une fonction spécifique dans ce commit :

    /**
     * Check le statut de l'URL rewriting
     * @return bool
     */
    public static function checkRewrite()
    {
        // N'interroge que le serveur Apache
        if ((helper::checkServerSoftware() === false)) {
            self::$rewriteStatus = false;
        } else {
            // Ouvre et scinde le fichier .htaccess
            $htaccess = explode('# URL rewriting', file_get_contents('.htaccess'));
            // Retourne un boolean en fonction du contenu de la partie réservée à l'URL rewriting
            self::$rewriteStatus = (strpos($htaccess[1], 'RewriteEngine on') !== false);
        }
        return self::$rewriteStatus;
    }

    /**
     * Retourne vrai ou faux selon que le serveur est comptatible avec htaccess
     * @return bool
     */
    public static function checkServerSoftware() {
        return (stripos($_SERVER['SERVER_SOFTWARE'], 'Apache') !== false || stripos($_SERVER['SERVER_SOFTWARE'], 'LiteSpeed')  !== false);
    }

Concernant les deux fichiers de la racine, je ne peux pas tester, mais peut-être que le journal de ton serveur aura plus d'informations.