Skip to content
Valider 5638a2bd rédigé par eric@smellup.net's avatar eric@smellup.net
Parcourir les fichiers

Evolutions du plugin dont certaines peuvent être considérées comme des corrections:

- la page pages_tous devient pages ce qui est plus cohérent avec les autres objets.
- ajout et utilisation des autorisations classiques pour un obet 'page' : creer, modifier et voir. Ces autorisations et les suivantes sont par défaut positionnées à admin complet. Une fonction surchargeable permet de toutes les modifier d'un coup.
- ajout de l'autorisation pages_voir pour afficher la liste des pages uniques (exec=pages)
- ajout des autorisations d'affichage des menus pages et pagecreer. Ces autorisations font appel respectivement à pages_voir et page_creer.
- utilisation du pipeline pre_boucle sur la boucle ARTICLES afin de clairement séparer les listes de pages uniques et celles d'articles éditoriaux. Par exemple, les listes d'articles de la page d'acceuil et de la page articles sont exemptes de pages uniques.

Tout n'est pas parfait en particulier pour les autorisations car il est toujours possible d'accéder à une page unique en saisissant l'url même si on est pas autorisé. C'est en effet l'autorisation de l'article qui se déroule. Pour combler ce manque il faudrait surcharger l'autorisation de l'article en testant l'id de rubrique mais cela produirait des effets de bords avec d'autres plugins comme accès restreint. 
En fait, spécialiser un objet pour en créer un autre n'est pas une opération prévue dans l'api SPIP actuelle.

Autre remarque : lors de la désinstallation du plugin on supprime la colonne 'page' de la table spip_articles. On se retrouve avec des articles possédant un id_rubrique à -1. Est-ce bien de laisser cela ainsi ? Ne faudrait-il pas soit les supprimer soit les transférer dans une rubrique existante ?
parent a48d63a6
0% ou .
You are about to add 0 people to the discussion. Proceed with caution.
Terminez d'abord l'édition de ce message.
Veuillez vous inscrire ou vous pour commenter