Max
Bonjour ,
Je t'ai envoyé un pull request sur ton dépôt Github qui corrige le bug pour le bouton-burger de la sidebar.
Il y a d'autres correctifs aussi.
Je vais explorer le code de ton CMS.
Il y a une doc pour les plugins quelque part ou il faut explorer le code et jouer avec xdebug et vscode ?
Version 2 is here
bazooka07 Salut ! Tu es le même bazooka07 que PluXml ?
Pour le moment il y a aucunes documentations sur les plugins. Max étant tout seul sur le projet je suis venu lui apporter mon aide sur les thèmes et la futur écriture du wiki et documentations.
Alors pour l'instant il faut explorer un peu mais c'est vite fait !
Bonjour et bienvenue,
J'ai vu ton PR passer, je regarderai ça demain après midi.
Pour la Doc, comme écrit récemment sur le forum, il faut que j'en fasse. Ce n'était pas une priorité car aucun dev ni utilisateur ne m'avait donné de retour sur la v2, aussi j'ai préféré continuer à faire du code et faire les travaux chez moi ^^
Tu souhaite de la Doc sur quelque chose en particulier ?
8 days later
- Edited
Bonjour @Max ,
Merci pour ce travail fort appréciable et fort apprécié ! 
J'ai passé la mise à jour pour mon site sur lequel j'utilise le plugin stats et comme @philazerty je constate que le bouton n'apparait plus dans le menu. Du coup impossible de visualiser les stats. Je n'ai pas regardé sur le filesystem si elles continuaient bien à s'enregistrer en revanche... Je vérifierai. Mais ce problème n'est pas bloquant.
Plus embêtant, j'utilise aussi la fonctionnalité de l'accès restreint sur certaines pages pour lesquelles j'avais défini un mot de passe. Or depuis la mise à jour, j'ai bien la mire de login ou je rentre mon mot de passe. Mais lorsque je valide, je reviens sur la mire de login indéfiniment... J'ai bien sûr vérifié que le mot de passe était bon, je l'ai même re-défini pour être sûr, mais rien à faire... Peut-être un effet de bord du travail sur les utilisateurs ??? As-tu constaté ce problème également ?
- Edited
qla
Accès restreint à certaines pages
Dans le fichier plugin/page/controllers/PageController.php, remplacer $_SERVER['HTTP_REFERER'] par $_SERVER['REQUEST_URI'] dans la fonction renderPage()
Merci @bazooka07 , effectivement ça marche nickel ! Du coup sais-tu si ce sera intégré dans une future mise à jour ?
23 days later
qla Le souci est qu'il a très peu d'activité et donc de mise à jour ! @Max intervient de moins en moins on dirait et pas de collaboration en place. @bazooka07 à fait un PR et il n'y a aucune réaction.
Dommage j'aime bien le produit mais vie très limitée dans ces conditions.
@+
6 months later
Je viens de fixer l'histoire du burger.
J'en ai profité pour commiter des modifs que j'avais en cours. Il s'agit de passer sous la dernière version de TinyMCE 6 (6.6), d'ajouter 4 formats de bloc et de pouvoir insérer facilement des icônes Font-Awesome (avec possibilité de choisir la taille et la couleur) dans vos contenus :
Entre temps, j'ai développé une librairie qui permet de faire des "Ping" comme les blogs Wordpress si ça vous parle. Il faut que je l'implémente dans 299Ko, et que j'intègre les modifs du plugin Users de @NemStudio18 concernant les droits et les rôles.
4 days later
Max
Pour info, le tag "<?=" pour remplacer le tag "<?php echo" est un tag tout à fait normal.
Lire la doc !
https://www.php.net/manual/en/language.basic-syntax.phptags.php
4 days later
8 days later
salut,
j'ai continué un peut en local la doc et je me suis apercu que je dois tout reprendre a cause des url mais ça va aller vite !
j'ai eu des soucis avec mon serveur perso qui ont eu la priorité je m'en excuse.
j'ai vue la maj que tu a poussé de bazeooka , pour essayé la nouvelle installation de mon serveur j'ai voulu tester l'installation de 299Ko.
première installation il y a un soucis , BASE_PATH est deja defini dans common.
ensuite au moment de s'enregistrer. Le loader ne charge pas UsersManager qui se tyrouve dans le dossier plugins, car il ne charge que common.
j'ai pas encore été plus loin je ne parviens pas a atteindre login une fois avoir réparé UsersManager.
je vais travailler cette nuit sur la complétion de la doc.
Salut !
NemStudio18 j'ai eu des soucis avec mon serveur perso qui ont eu la priorité je m'en excuse.
Ne t'inquiètes pas, je n'ai pas trop de temps en ce moment également avec les week-end chargés.
Je vais regarder tout ça, merci !
- Edited
Salut,
J'ai public une release de 299ko, avec les modifications proposées dans mon dernier Pull Request, sur mon dépôt Github
https://github.com/bazooka07/299ko/releases.
J'ai fait une installation neuve sur un serveur Nginx couplé à 2 serveurs php-fpm avec PHP 7.4 et PHP 8.3. Et aucun message d'erreur.
Il n'est pas à la racine du site mais dans le dossier 299ko du DocumentRoot
Pour gérer les redirections de 299ko, il faut ajouter les lignes suivantes dans la config de Nginx
location ~ ^/299ko/(?!index.php) {
try_files $uri /299ko/index.php;
}L'intérêt des serveurs est de pouvoir faire des tests sous différentes versions de PHP simplement avec des noms d'otes virtuels différents. Avec un serveur Apache, c'est plus compliqué.
Et j'obtiens bien une erreur avec PHP5.6 ( pas de type pour les fonctions avec cette version) Normal !
@Max,
Peux-tu régler ton éditeur de code pour supprimer les espaces en fin de ligne (trailing spaces) ?
Il y a peut-être une option dans git pour régler ce problème dans tes prochains commits.
Sinon la commande sed sous Linux est aussi une solution.
- Edited
Salut bazooka.
d'abord, merci de ta contribution et du temps passé dessus.
ce qui suit n'engage que moi et d'ailleurs j'ai le même défaut dans le sens inverse et je vais devoir m'installer une machine sous Nginx.
je m'explique j'ai tendance a oublier les autres serveurs existant Apache n'étant pas le seul donc quand je programme je ne m'attarde pas sur les différences potentielles avec les autres.
il me semble que Max développe sous Apache et s'il est comme moi cela demande un peut de recherche afin de faire côtoyer ngnix et apache (et j'avoue que je trouve ça chiant ^^). d'ailleurs même si la documentation n'est pas complète cette partie est bien spécifiée, "un serveur tournant sous Apache"
Du coup j'imagine que tu fais comme moi mais dans l'autre sens avec ngnix first.
J'ai fait une installation neuve sur un serveur Nginx couplé à 2 serveurs php-fpm avec PHP 7.4 et PHP 8.3. Et aucun message d'erreur.
Il n'est pas à la racine du site mais dans le dossier 299ko du DocumentRoot
Pour gérer les redirections de 299ko, il faut ajouter les lignes suivantes dans la config de Nginx
location ~ ^/299ko/(?!index.php) { try_files $uri /299ko/index.php; }L'intérêt des serveurs est de pouvoir faire des tests sous différentes versions de PHP simplement avec des noms d'otes virtuels différents. Avec un serveur Apache, c'est plus compliqué.
Alors en soit je trouve pas ça plus compliqué sous Apache, en général si tu te fais héberger c'est pas ton soucis, si tu es en dev, sous linux plus compliqué car rien de vraiment automatisé a ma connaissance mais sous windows le travail d'Otomatic (un peut plus de 80 ans le Monsieur ^^) comme mainteneur de WAMP Serveur fait des miracle et permet la même chose. je dois avoir une install de 299ko sous différentes versions de php gérés grâce aux vhost.
En ce qui concerne le font du problème, dans common.php
define('BASE_PATH', rtrim(dirname($_SERVER['SCRIPT_NAME']), '/'));
renvoi une chaine vide ce que Apache ne gère pas si j'ai bien compris d'après mes recherche.
malgré que l'installation fonctionne ( bonne configuration dans le fichier config.json lors de la création du dossier data/ a la racine) .
je pense que ça ne gène pas (et c'est pour cela que j'ai une double définition de BASE_PATH suite a ton commit car install.php est a la racine du site et pas common.php.
il faudrait donc essayer de modifier la définition de BASE_PATH dans ta version de common.php en la remplaçant par celle-ci:
$basePath = dirname($_SERVER['SCRIPT_NAME']);
if ($basePath === "\\" || $basePath === "/") {
$basePath = ''; // On évite d'avoir un caractère seul inutile
}
define('BASE_PATH', rtrim($basePath, `'/'));`après avoir fais cette modification chez moi, le retour a la normal sur Apache, donc a voir si sur Ngnix ça passe... (à toi de nous faire le retour)
cependant ton travail permettrai d'avoir une version qui tourne sur les deux et ce serait honnêtement plus cool, afin de toucher un public plus large.
a bientôt 
Hello !
Merci de tes recherches et ton aide.
Comme le dit @NemStudio18 , 299Ko est développé pour Apache, parce que c'est le serveur le plus courant sur les mutualisés (cible nette du CMS).
Nginx est clairement une piste à prendre, ça m'arrangerait même pour l'hébergement de ce serveur. Je vais essayer de regarder, mais il faut pouvoir guider l'utilisateur pour qu'il puisse installer 299Ko sous Nginx.
bazooka07 Peux-tu régler ton éditeur de code pour supprimer les espaces en fin de ligne (trailing spaces) ?
C'est fait, désolé du dérangement ^^
NemStudio18 il me semble que Max développe sous Apache et s'il est comme moi cela demande un peut de recherche afin de faire côtoyer ngnix et apache (et j'avoue que je trouve ça chiant ^^). d'ailleurs même si la documentation n'est pas complète cette partie est bien spécifiée, "un serveur tournant sous Apache"
J'ai clairement continué le projet dans la voie prise par Jon, sous Apache donc. L'avantage du routeur mis en place récemment c'est que normalement il n'y a aucune règle d'écriture et que tout passe par le index.php (et de façon propre). Normalement il n'y a rien à faire pour faire tourner 299Ko sous Nginx si on sait paramétrer le serveur.
@NemStudio18 : Ton problème rencontré c'est quand tu mets 299Ko à la racine du site ?
Merci à vous.
Je vais vérifier mais il me semble que racine ou non c'est pareil pour moi.
Pour le BASE_PATH, inutile de le définir dans install.php puisqu'il est déjà defini dans common.php. Il y a un "include_once ROOT . 'common/common.php' dans install.php.
Je trouve aberrant de développer des sites Internet sous Windows alors que la très grande majorité des serveurs sur Internet tournent sous Linux. Même dans les ministères et la Gendarmerie se sont mis à Linux. Mais bon Microsoft a bien formaté les esprits.
Je développe principalement avec un serveur Apache. le souci avec lui,c'est basculé d'une version de PHP à l'autre est compliqué. Et la version 8.0 de PHP a rendu incompatible beaucoup de scripts PHP incompatibles.
C'est plus facile de basculer d'une version à l'autre de PHP lorsqu'il y a 2 ou 3 serveurs PHP-FPM derrière un serveur NGINX si on crée plusieurs hôtes virtuels qui partagent le même DocumentRoot.
Le serveur Nginx est installé sur une SBC ( Single Board Computer ) connecté à mon réseau domestique. la carte est une Rock64 avec stockage en mémoire EMMC ( les cartes SD sont lentes et surtout pas très fiables) https://pine64.org/devices/rock64/
Récemment pour déboguer un script sous Windows pour un utilisateur lambda, j'ai utilisé Laragon qui permet de changer plus facilement de version de PHP.
bazooka07 Pour le BASE_PATH, inutile de le définir dans install.php puisqu'il est déjà defini dans common.php. Il y a un "include_once ROOT . 'common/common.php' dans install.php.
ça a mon avis c'est une coquille restée inaperçu un moment qui n'a rien a voir avec ton push d'après mes recherches.
bazooka07 Je trouve aberrant de développer des sites Internet sous Windows alors que la très grande majorité des serveurs sur Internet tournent sous Linux. Même dans les ministères et la Gendarmerie se sont mis à Linux. Mais bon Microsoft a bien formaté les esprits.
Ce qui est aberrant pour les uns ne l'est pas forcément pour d'autres, il en faut pour tout le monde! j'ai deux serveurs sur linux et malheureusement, les IDE sur linux sont pas ouf de mon point de vue.
malgré le fait que beaucoup de serveurs tournent sous linux ... a se que je sache , tu développes rarement sur un serveur de production donc derrière que ce soit développé sous la fenêtre ou sur un pingouin ça change pas grand chose non?
Pour info j'ai vue des pc du ministère comme tu le dis encore tourner sur du windows 7 donc pas au top encore de ce côté la
bazooka07 Je développe principalement avec un serveur Apache. le souci avec lui, c'est basculé d'une version de PHP à l'autre est compliqué. Et la version 8.0 de PHP a rendu incompatible beaucoup de scripts PHP incompatibles.
j'ai pas bien compris la phrase mais bon, tout comme le soucis de write_acces qui en l'état n'est pas bon pour fonctionner avec Apache 2.4, il y a un moment ou c'est au développeur de faire les vérifications nécessaires ET s'il le souhaite pour la compatibilité des versions et Pas seulement de PHP, mais aussi des différents serveurs existants. Dans un monde parfait tout le monde serait hébergé de la même manière et il n'y aurait pas de soucis mais ce n'est pas moi qui fais les règles...
bazooka07 C'est plus facile de basculer d'une version à l'autre de PHP lorsqu'il y a 2 ou 3 serveurs PHP-FPM derrière un serveur NGINX si on crée plusieurs hôtes virtuels qui partagent le même DocumentRoot.Le serveur Nginx est installé sur une SBC ( Single Board Computer ) connecté à mon réseau domestique. la carte est une Rock64 avec stockage en mémoire EMMC ( les cartes SD sont lentes et surtout pas très fiables) https://pine64.org/devices/rock64/
vue les capacités de ton serveur le choix peut se comprendre de travailler Nginx ça évite de dupliquer tes fichiers ce que je peux comprendre tu ne peux pas le faire avec Apache mais un fois tes vhost et tes installations faites tu peux faire tourner plusieurs versions de php différentes quand même , alors oui effectivement pas dans le même dossier...
PS: le PR envoyé ce matin ne fonctionne pas chez moi... un problème de l'autoloader ( ce n'est pas la parenthèse qu'il y avait en trop et que tu as déjà corrigé).
Pour mon dernier PR il faut merger les 2 commits, il y a 2erreurs typo sur le 1er commit.
J'ai essayé ce matin de faire tourner 299ko sur Laragon/Windows avec en parallèle Apache sur le port 80 et Nginx sur le port 8080.
Premier souci : core::makeSiteUrl() ne prend pas en compte le port
2ème souci : j'ai arrêté Apache et basculé Nginx sur le port 80. Et ça bugue car la racine du site est enregistré dans le fichier config.json. Mauvaise idée ! Si on déménage le site sur un autre domaine, il faut corriger à la main. Pas évident pour un newbie.
Je vais continuer d'explorer pour faire tourner 299ko sur le port 8080 de Nginx et vérifie que le changement de port se fasse sans souci.
Il vaut mieux utiliser preg_replace() au lieu de str_replace() dans core::makeSiteUrl().
