Chat gpt spam, faits ou fiction  


Déterminer si un projet est actif et bien entretenu est crucial, surtout lorsqu'on envisage de l'utiliser pour construire un site web ou une application. Voici quelques moyens efficaces d'évaluer le niveau d'activité d'un projet et d'identifier d'éventuels signaux d'alerte :

1. **Site Web du Projet** : Visitez le site web officiel du projet. Recherchez les mises à jour récentes, les actualités ou les publications de blog. Un projet actif maintient généralement un site web à jour avec des annonces sur les nouvelles versions, les fonctionnalités ou les événements de la communauté.
   
2. **Dépôt GitHub** : Si le projet est open source et hébergé sur GitHub ou une plateforme similaire, vérifiez l'activité du dépôt. Recherchez les commits récents, les pull requests et les problèmes. Un projet sain a généralement des contributions régulières et une activité de développement continue.
   
3. **Historique des Versions** : Examinez l'historique des versions du projet pour voir quand la dernière version a été publiée et à quelle fréquence de nouvelles versions sont publiées. Des sorties régulières avec des correctifs de bogues, des améliorations de fonctionnalités et des correctifs de sécurité indiquent une maintenance active.
   
4. **Engagement Communautaire** : Évaluez le niveau d'engagement de la communauté autour du projet. Consultez les forums, les listes de diffusion ou les canaux de médias sociaux pour les discussions, les questions et les réponses des développeurs et des utilisateurs. Les projets actifs ont généralement des communautés vibrantes et solidaires.
   
5. **Documentation** : Évaluez la qualité et la fraîcheur de la documentation du projet. Les projets actifs maintiennent une documentation complète qui est régulièrement mise à jour pour refléter les changements dans le logiciel.
   
6. **Suivi des Problèmes** : Examinez le suivi des problèmes du projet pour voir comment les bogues et les demandes de fonctionnalités sont activement traités. Un projet actif a généralement une équipe réactive qui trie et résout les problèmes de manière opportune.
   
7. **Contributeurs** : Regardez le nombre de contributeurs impliqués dans le projet et leurs niveaux d'activité. Une base de contributeurs diversifiée et active indique un écosystème de projet sain et durable.
   
8. **Feuille de Route** : Vérifiez si le projet a une feuille de route publique décrivant les fonctionnalités à venir et les plans de développement. Une feuille de route bien définie démontre la direction du projet et l'engagement envers le développement continu.
   

Signaux d'Alerte à Surveiller :

1. **Dépôt Inactif** : Un manque de commits ou de mises à jour récentes dans le dépôt du projet peut indiquer que le projet n'est plus activement maintenu.
   
2. **Problèmes Non Résolus** : Si le suivi des problèmes du projet est rempli de bogues non résolus et de demandes de fonctionnalités, cela suggère que les efforts de développement peuvent être au point mort.
   
3. **Communauté Inactive** : Un manque d'engagement communautaire ou de réponses aux questions des utilisateurs peut être le signe d'un projet en déclin.
   
4. **Documentation Obsolète** : Si la documentation du projet est obsolète ou incomplète, cela peut indiquer une négligence ou un manque d'attention à la maintenance du projet.
   
5. **Aucune Publication** : Un long intervalle entre les publications ou un manque de publications récentes peut suggérer que le projet n'est pas activement développé ou maintenu.
   
6. **Fonctionnalités Abandonnées** : Des fonctionnalités promises mais jamais livrées, ou des plans qui échouent à se concrétiser à plusieurs reprises, peuvent indiquer un manque d'engagement envers le développement du projet.
   
En évaluant soigneusement ces facteurs et en restant vigilant quant aux signaux d'alerte, vous pouvez prendre des décisions éclairées sur la viabilité d'un projet et s'il convient à vos besoins.

Je suis actuellement en train de réécrire un ancien projet PHP vers PHP 8.3.x, je partage ici mon ensemble d'outils :

# Normes de codage :
Trouver une norme de codage uniforme et basée sur les meilleures pratiques n’est pas si difficile, mettre en œuvre un style uniforme est une autre histoire.

[PHP CodeSniffer](https://github.com/squizlabs/PHP_CodeSniffer), pour définir et appliquer des normes de codage spécifiques,
comme [PSR-12 : Style de codage étendu](https://www.php-fig.org/psr/psr-12/) et/ou [Doctrine Coding Standard](https://www.doctrine-project.org /projects/doctrine-coding-standard/en/11.0/reference/index.html)

# Analyse du codage :

Pour rechercher des erreurs dans les applications PHP -> [Psalm](https://psalm.dev/), [PHPStan](https://phpstan.org/) ou [PHP Mess Detector](https://phpmd.org /).
Pour trouver les problèmes de compatibilité entre versions PHP 5.x, 7.x, 8.x -> [PHPCompatibility](https://github.com/PHPCompatibility/PHPCompatibility)

# Refactorisation automatisée :

Pour résoudre les problèmes de normes de codage -> [PHP Coding Standards Fixer](https://github.com/PHP-CS-Fixer/PHP-CS-Fixer)
Pour obtenir une mise à niveau instantanée ou une refactorine automatisée -> [GetRector](https://getrector.com/)

Certains outils se chevauchent mais peuvent également se compléter.

Erreur bloquante dans class.usertagoperations.inc.php : j'ai trouvé une solution.

En décembre 2023, j'ai eu l'erreur suivante qui m'a bloqué CmsMadeSimple définitivement (l'erreur revenait à chaque appel de index.php) :
Parse error: syntax error, unexpected '}' in /..../..../www/cms/lib/classes/class.usertagoperations.inc.php(306) : eval()'d code on line 1399
J'ai dû réinstaller le cms (version 2.2.19) dans un dossier différent.
Mais au bout de quelques jours, le problème est revenu. J'ai bien dû réinstaller une dizaine de fois.
J'ai été tranquille pendant 3 mois, mais c'est reparti.
Je précise que cela se produit lorsque j'essaie d'enregistrer une balise utilisateur (udt) et que ça ne m'était jamais arrivé avant que je mette le php en version development au lieu de production dans www/.ovhconfig
Mais cette fois,  j'ai enfin trouvé comment supprimer l'affichage permanent de l'erreur et le blocage.
C'est pourquoi je vous expose ma méthode au cas où vous auriez les mêmes soucis. Il va quand même falloir mettre les mains dans le cambouis (le php)
Mais je me demande toujours pourquoi certaines fois, les udt sont enregistrés même s'il y a une erreur.

L'erreur est donc dans class.usertagoperations.inc.php, à la ligne 306 pour @eval($code)

    function CreateTagFunction($name)
298    {   print $name.'<br>'; //ajouté
299  $row = $this->_get_from_cache($name);
        if( !$row ) return;
        $functionname = 'cms_user_tag_'.$name;
        if( !function_exists($functionname) ) {
            if( startswith($row['code'],'<?php') ) $row['code'] = substr($row['code'],5);
            if( endswith($row['code'],'?>') ) $row['code'] = substr($row['code'],0,-2);
           $code = 'function '.$functionname.'($params,$smarty) {'.$row['code']."\n}";
306            @eval($code);
        }
        return $functionname;
    }

J'ai longtemps cru, à cause de la ligne 299, que c'était  un problème de cache, mais effacer le cache ne réglait rien.
J'ai ajouté print $name à la ligne 298 pour voir quelle balise provoquait le blocage (l'affichage de l'erreur ne le mentionne pas)
En fait, on voit que tous les udt sont vérifiés à chaque appel de index.php, et c'est donc le dernier affiché qui provoque le blocage.
Pour avoir un plus de détails sur l'erreur, et ne pas bloquer le cms, j'ai ajouté un try - catch autour de @eval($code) :
306          try { eval(@$code); }
                catch (ParseError $err) {
                    print "Erreur dans $name : <br>";
                    print "$err <br>";
                    return;
                    }
Il faut catch (ParseError $err) au lieu d'un simple catch(Exception $ex) parce que eval ne transmet pas des exceptions mais des ParseError.
On obtient alors quelque chose du style :

Erreur dans erreur2:     (erreur2 est le nom du userplugin)
ParseError: syntax error, unexpected '...' (T_ELLIPSIS) in /..../..../www/cms4/lib/classes/class.usertagoperations.inc.php(306) : eval()'d code:1    (1 est n° de ligne de l'erreur dans le userplugin)
Stack trace: #0 /www/cms4/lib/classes/internal/class.Smarty_CMS.php(82): UserTagOperations->CreateTagFunction('erreur2')
#1 ...
#2 ...

On peut faciliter la lecture en mettant à partir de la ligne 307 :
           catch (ParseError $err) {
                $p=strpos($err,'code'); $p2=strpos($err,'Stack'); $ligne=substr($err,$p+5,$p2-$p-6);
                print "<br>Erreur dans le plugin $name, ligne $ligne : <br>";
                $p= strpos($code,'{'); $code= substr($code,$p+1);
                $lignes=explode("\n", $code); print $lignes[$ligne-1].'<br>';
                print strtok($err,'#').'<br>';
                print strtok('#').'<br>';
                return;
               }
ce qui donne maintenant :

Erreur dans le plugin erreur2, ligne 1 :
print ...   (la ligne qui contient l'erreur)
ParseError: syntax error, unexpected '...' (T_ELLIPSIS) in /www/cms4/lib/classes/class.usertagoperations.inc.php(306) : eval()'d code:1 Stack trace:
0 /www/cms4/lib/classes/internal/class.Smarty_CMS.php(82): UserTagOperations->CreateTagFunction('erreur2')

On peut maintenant supprimer le print $name de la ligne 298

On a réussi à sortir de l'erreur sans bloquer le cms, mais il reste encore une erreur dans un autre fichier ; en effet, la fonction utilisant l'udt n'a toujours pas été créée :

Fatal error: Uncaught --> Smarty: Plugin 'erreur' not callable <-- thrown in /..../..../www/cms4/lib/smarty/sysplugins/smarty_internal_method_registerplugin.php on line 50

A la ligne 50 de smarty_internal_method_registerplugin.php, on trouve :      throw new SmartyException("Plugin '{$name}' not callable");
 qu'on remplace par :  print "<br>Le plugin $name est inutilisable : il faut le corriger ou le supprimer<br>";

Le blocage est terminé , plus besoin de réinstaller !!!

Bien le bonjour, tout d'abord merci à CMS Made Simple pour ouvrir ce open-source Génial

J'ai quasiment fini la conception de mon site Mais, je rencontre un petit problème lorsque que je vais dans mes sous section cela se développe sur la gauche Hors j'aimerai que les menus défilent se développe sur la droite voici un exemple

Pièces jointes

Miniature(s)
   

Un petit sondage : qui utilise un des modules usersguide ou userguide2 ?
surtout pas moi, je donne un fichier PDF qui est bien plus pratique

Note Message posté aussi sur le Forum EN

EDIT Vu le nombre de réponse je pense que ce module ne doit pas être souvent utilisé.

Est-ce que quelqu'un aurait un site Web qui entrerait dans ces caractéristiques et qui utiliserait le dernière version 2.2.19 ? (oups erreur pas 2.1.19)

Titre modifié le 08/04/24 2.2.20 ?=> Version 2.2.20 en cours
ici c'est la suite de la Version 2.2.19 enfin j'espère
- alors donc au fait y-a t-il du nouveau pour cette future année 2024 ?
car les commits sur le SVN = rien ou le futur Git qui doit voir le jour ... en attente ?

Et aussi suivre le module Microtiny

Suite à un gros blocage de cmsmadesimple (version de 2011) (peut-être dû à une erreur de syntaxe dans une balise utilisateur ),
j'ai dû le réinstaller 3 fois (version 2.2.19), (sur l'hébergeur  ovh.com) toujours pour la même raison.

Toute tentative d'accès à index.php ou admin/index.php m'affiche :
"Parse error: syntax error, unexpected ',' in /home/...../www/cms2/lib/classes/class.usertagoperations.inc.php(306) : eval()'d code on line 16".
et je ne peux rien faire d'autre avec le cms, même le lendemain.
Heureusement, j'ai quand même accès au ftp.

Une fois, j'ai vu plus de détails sur l'erreur, avec le nom de la balise utilisateur,
mais ici, dans le fichier class.usertagoperations.inc.php, les ligne 16 et 306 sont vides ; l'erreur n'est donc pas dans ce fichier.
En fait, l'affichage de l'erreur se fait dans le fichier cms2/lib/include.php qui est appelé par index.php et admin/index.php,
à la ligne contenant $modops->LoadModules(!$CMS_ADMIN_PAGE);  ou $smarty = $_app->GetSmarty(); (suivant qu'on exécute index.php ou admin/index.php)
(j'ai  mis des "print ...", un peu partout dans include.php pour localiser la ligne qui provoque l'affichage )

Il semble que la notification de l'erreur soit mémorisée quelque part.
1. Pourriez-vous m'indiquer comment la supprimer ?
2. Cmsmadesimple pourrait-il  modifier  ses programmes pour éviter qu'il bloque tout sur une simple erreur de syntaxe ?

Cordialement
Raymond

Ajout de [Résolu] dans le titre + discussion fermée - JCE

Bonjour à tous
Avec la version 2.2.18 sous php 8 je cherche vainement à afficher au format français les heures du module Kchronos ...
La variable $config['timezone'] est bien sur "Europe", dans la démo "locales.html" le choix de la locale en fr agit bien sur l'affichage, mais mes connaissances ne suffisent pas pour trouver quelle est la variable modifiée...
Auriez vous une info pour forcer l'affichage en mode français ?
Bonne soirée à tous !

Le module TinyMCE est basé sur la version TinyMCE Community et le module MicroTiny Core est également basé sur la version de TinyMCE Community
mais
TinyMCE module (V 3.3.2 28) est basé sur TinyMCE Community version 5.3.1 (2020-05-27)
MicroTiny Core(2.2.18) module (v 2.2.5) est basé sur TinyMCE Community version 4.6.4 (2017-06-13)

les versions de TinyMCE Community en cours (à la date du 22/11/23)
- version 5 Version 5.10.9 November 15, 2023
- version 6 Version 6.7.3 November 15th, 2023.

la différence entre les 2 modules et simplement "décorative" il est possible de faire exactement les même choses puisque les plugins, thèmes et skins sont les mêmes à version égale
Il suffit de bien configurer le fichier tinymce_config.js de MicroTiny pour avoir les réglages du module TinyMCE.
Nota la version 5.x ou 6.x de TinyMCE Community est plus complète que la version 4 et possède des plugins configurés par défaut supplémentaires, mais aussi des nouveautés.
La version 5.x est a atteint la fin du support ... et sera considérée en "Long Term Support (LTS)"

Ce poste fait suite à une relance sur le le forum EN pour les mises à jour de MicroTiny + module TinyMCE.
A suivre