Modification plugin Users

NemStudio18

Salut,

je viens de cloner le dépôt au cas ou, ce serait dommage qu'un jour le travail de max disparaisse.

du coup j'ai commencé a regarder un peut le fonctionnement en interne de 299ko.

je me suis donné pour tâche d'intégrer une gestion des membres plus graduelle dans le système.

Je vous tiens au courant plus tard !
remotivons les troupes !

edit 1:
ce qui est fait et fonctionne:
-ajout des roles
-page d'enregistrement (accessible depuis users/register)
-possibilité de modifier les roles depuis l'administration.
-l'enregistrement est fonctionnel
-la connexion aussi.

reste a restreindre les accès en fonction du/des rôle(s).

pour ceux que ça intéresse vous pouvez accéder au github ici:
github 299nem branch
---

edit 2:

mise en place de la protection par role des pages d'administration , pour le moment si pas rôle admin, impossible d'accéder au pages de gestion.

Edit3: mise en place de certaines parties publiques sous condition d'inscription (ex: poster un commentaire sur un article de blog)

Max

NemStudio18 Salut l'ami,

Félicitations pour tout ça. Je regarderai plus en profondeur avec un PC mais ça a l'air très propre.

En revanche, je ne comprends pas le filesystem report. Je comprends ce que ça fait, mais pas le besoin. Est-ce quelque chose dont tu as besoin ?

NemStudio18

Max
Merci de ton retour parmis nous Max !
non les files_system.php ou .md ce sont mes petit prog pour analyser rapidement le code source de tout ton CMS et trouver ce que je cherche !

Désolé j'ai oublié de supprimer avant de pousser, il y en a plusieurs d'ailleurs (dans un plugin je crois) et d'autres qui sont spécifiques aux commentaires.

oubli de ma part faut que je les mettent en githignor.

le principal de la gestion des groupes est mis en place maintenant il faut modifier tout le reste du CMS / plugins afin d'intégré la possibilité de restreindre les partie du CMS a la demande et en fonction des groupes.

honnêtement je pense que j'utilise pas bien ton core à certains moment mais pour le moment chez moi ça a l'air de fonctionner.

j'ai mis de coté depuis cette nuit. je me suis mis en tète de dev une API afin de séparer complètement tes plugins du core , afin de simplifier le développement de plugins/mods sans aller toucher au core.
J'ai développé et mis en place une bonne partie de l'API , intégré cela au core, une gestions des dépendances et conflits mais pour le moment je lutte afin d'avoir un rendu.

je vais aller mettre a jour la branche Users afin de supprimer mes fichier perso , encore désolé, et si j'arrive a quelque chose coté API dans la journée je ferai créerai une nouvelle branche.

(bon je cache pas que je suis en pleins test afin de customiser 299ko ce que je fais ou dis n'engage que moi hein ^^ pour le moment je me concentre sur ces deux point mais j'aimerai bien faire une branche sqlite une sorte de version "pro" ca reste léger avec les avantages du relationnel même si sur le principe c'est plus vraiment du fichier plat)

Edit: Nettoyage du dépôt branche users fait.

Edit 2:
note a moi même, peut être pour la gestions des rôles s'appuyer sur le système de restriction des pages par mdp

Max

Pour l'API, c'était en cours mais ce n'est pas finalisé ni utilisable en l'état de mémoire. Je te laisse regarder du coté du fichier common\responses\ApiResponse.php

Pour garder un fonctionnement homogène et que ce soit plus facile d'intégrer des évolutions, comme un système de cache, il faut absolument que tous les plugins et controllers fonctionnement de la même façon. Un controller ne doit rien afficher, seulement retourner une instance d'une classe enfant de Response.

Que veux-tu faire avec ton API ?

Il faut d'ailleurs que je refasse le plugin FilesManager dans ce sens.

(bon je cache pas que je suis en pleins test afin de customiser 299ko ce que je fais ou dis n'engage que moi hein ^^ pour le moment je me concentre sur ces deux point mais j'aimerai bien faire une branche sqlite une sorte de version "pro" ca reste léger avec les avantages du relationnel même si sur le principe c'est plus vraiment du fichier plat)

J'y ai déjà pensé, mais le fait de garder des fichiers plats me semble plus simple à gérer pour un futur plugin de backup ou même de la maintenance. Je ne sais pas ce qu'en pensent les autres.

NemStudio18

Max
L'idée de l'API (enfin que j'en ai) est de découpler les plugins de ton core, les règles de construction de plugins afin qu'ils soient unifiés (comme tu le dis qu'ils fonctionnent de la même façon) devra être expliqué dans la doc "développeur" .
Cela permettra de garder un noyau avec ce qu'on pourrais appeler un plugin de base (page par exemple) et juste avoir a ajouter un dossier plugin (autonome) dans le dossier source des plugins (blog, gallerie etc...) tu vois ce que je veux dire ?
Comme ça pack de base du CMS (site vitrine) et pour étendre le CMS juste a download les sources du plugin et mes envoyer sur le FTP.
Je suis même presque sûre qu'on peut gérer le téléchargement et la décompression directement depuis l'administration.

Car si j'ai bien compris en l'état un plugin fait partie intégrante du core. On peut juste l'activer ou non
(D'ailleurs un plugin qon ne peut pas désactiver via plugin manager pour moi fait partie du core donc on ne devrait pas le voir dans le tableau si ?)

Désolé si je pose beaucoup de questions.

Tu pourrais m'expliquer le fonctionnement et l'intérêt aussi dans pluginmanager de la priorité des plugins ?

Edit: Je me suis dit du coup que l'ajout d'un pseudo pourrait être plus user friendly, donc j'ai commencé a l'implémenté en même temps vue que ça se passe au même endroit.

j'ai laisser dans userAdminController.php une partie de code avec des commentaires afin qu'on puisse retravailler le système. j'avais pas envie de chercher ou il fallait appeler un nouveau fichier json donc j'ai fonctionné comme ça pour tester .

Poussé sur Github.

Max

NemStudio18 L'idée de l'API (enfin que j'en ai) est de découpler les plugins de ton core, les règles de construction de plugins afin qu'ils soient unifiés (comme tu le dis qu'ils fonctionnent de la même façon) devra être expliqué dans la doc "développeur" .
Cela permettra de garder un noyau avec ce qu'on pourrais appeler un plugin de base (page par exemple) et juste avoir a ajouter un dossier plugin (autonome) dans le dossier source des plugins (blog, gallerie etc...) tu vois ce que je veux dire ?
Comme ça pack de base du CMS (site vitrine) et pour étendre le CMS juste a download les sources du plugin et mes envoyer sur le FTP.
Je suis même presque sûre qu'on peut gérer le téléchargement et la décompression directement depuis l'administration.

Car si j'ai bien compris en l'état un plugin fait partie intégrante du core. On peut juste l'activer ou non

Hello !

C'est déjà le cas. Certains plugins sont totalement indépendants du core, et on peut donc en supprimer les fichiers sans que ça ne gêne en rien le reste.

Après oui, il y a des plugins qui servent au coeur, comme Users, parce qu'ils sont appelés dans l'administration pour se connecter par exemple. TinyMCE est un plugin qui peut être supprimé sans aucun soucis si l'on veut taper le contenu en HTML directement.

(D'ailleurs un plugin qon ne peut pas désactiver via plugin manager pour moi fait partie du core donc on ne devrait pas le voir dans le tableau si ?)

Le fonctionnement est celui-là car c'est plus simple à gérer. Mais oui, on pourrait très bien virer des plugins tout ce qui est essentiel pour le mettre dans le coeur du CMS.

Tu pourrais m'expliquer le fonctionnement et l'intérêt aussi dans pluginmanager de la priorité des plugins ?

Un plugin avec une priorité à 1 sera appelé avant les plugins qui ont une priorité à 2. Car même si tu lances le plugin blog, tous les plugins sont "appelés". Enfin, tous les hooks de tous les plugins sont enregistrés et seront lancés dans l'ordre de priorité, 1 étant la plus grande priorité. C'est surtout envisagé dans le cas de modifications successives de contenu.

Edit: Je me suis dit du coup que l'ajout d'un pseudo pourrait être plus user friendly, donc j'ai commencé a l'implémenté en même temps vue que ça se passe au même endroit.
Pseudo utilisé à quel endroit ?

j'ai laisser dans userAdminController.php une partie de code avec des commentaires afin qu'on puisse retravailler le système. j'avais pas envie de chercher ou il fallait appeler un nouveau fichier json donc j'ai fonctionné comme ça pour tester .

L'idée est bonne, mais les permissions des plugins doivent être incluses dans le plugin respectif. Il faut modifier le core pour ça. Pareil pour les permissions, les rôles sont biens mais si on veut un vrai système de permissions, il faut utiliser des bytes, par exemple READ = 0x01, WRITE = 0x02, DELETE = 0x04 etc, et l'utilisateur en fonction du rôle hérite des bytes de permissions.
Dans le cas simple, un visiteur pour le plugin blog aura la permission 0x01, un auteur aura 0x03 et l'admin 0x07 pour pouvoir effectuer toute ces actions.

C'est plus compliqué (un peu) à mettre en place mais bien plus efficace, personnalisable et rapide à l'usage après.