[spip-dev] un spip sans espace privé ?

Bonjour,

a votre avis est-il possible de faire un spip sans dossier ecrire/ ?

Un travail important a été réalisé pour mettre en extensions indépendantes (modulo la gestion des mots clé) le maximum d’éléments.

Vu que SPIP peut s’installer en mode cli, j’imagine plein de cas où une interface privée n’est pas utile.

On pourrait imaginer un noyau qui ne traiterait que les squelettes (avec la gestion du cache et des sessions) et une API minimale (pour des éléments indispensables comme les pipelines par exemple). Exactement (de mon point de vue) comme un kernel unix.

L’espace privé (la GUI) serait alors une surcouche du kernel de spip.

Cela peut sembler une roadmap intéressante côté challenge pour une version 4.0, qu’en dites-vous ?

.Gilles

Ce serait en fait une sorte de moteur de template indépendant ?

Salut Gilles,

Je n'ai rien compris à ton message, mais je pense que la réponse est oui, techniquement, tout est possible et l'intérêt m'en échappe totalement :slight_smile:

Par contre, je n'arrive toujours pas à imaginer, ergonomiquement, ce que serait un « SPIP sans espace privé ». Par exemple :

- Comment changer le statut d'un article ? y associer des auteurs, mots-clefs ?
- Comment s'interfacerait l'enrichissement d'un article en documents ?
- Où s'afficheraie les panneaux de config avancée ?
- Ceux des N plugins que d'aucuns utilisent en abondance ?
- etc.

Si vous avez des idées ou plutôt des exemples concrets…

Hello,

Salut Gilles,

Je n'ai rien compris à ton message, mais je pense que la réponse est oui,
techniquement, tout est possible et l'intérêt m'en échappe totalement :slight_smile:

Quelques idées :
- pouvoir gérer les éléments de SPIP avec n'importe quoi.
- faire une installation complètement verrouillée en lecture seule d'un
site.
- gérer simplement du spip avec un backoffice sur son ordi ou sur son mobile
- Créer plusieurs API web qui pourraient être dédiées à une distrib de SPIP

Par contre, je n'arrive toujours pas à imaginer, ergonomiquement, ce que
serait un « SPIP sans espace privé ». Par exemple :

- Comment changer le statut d'un article ? y associer des auteurs,

mots-clefs ?
- Comment s'interfacerait l'enrichissement d'un article en documents ?

Ca pourrait se faire par services web - comme on en trouve dans
https://documentation.magnolia-cms.com/display/DOCS/REST+API - et du coup
la gestion des éléments pourrait se faire par n'importe quoi

- Où s'afficheraie les panneaux de config avancée ?
- Ceux des N plugins que d'aucuns utilisent en abondance ?

Pas d'idée la dessus.
Si ce n'est de séparer la partie "Vue" de la partie "Contrôleur+Modèle"
(tiens, ça me rappelle quelque chose)

Par contre, je n'arrive toujours pas à imaginer, ergonomiquement, ce que serait un « SPIP sans espace privé ». Par exemple :

En fait dans cette vision il n'y a PAS de "ergonomiquement".

Même si ce n'est pas forcément pas priorité là tout de suite, ce qui m'intéresse beaucoup dans cette conception, c'est bien d'affirmer que l'admin de SPIP (l'actuelle ou une future refonte peu importe), ce n'est QU'UNE vue possible pour éditer et gérer un site SPIP.

On peut très bien imaginer un site où les contenus viennent d'ailleurs. D'un autre site SPIP non public par exemple (celui public en production étant uniquement en lecture). Ou bien par d'autres moyens : un site dont le contenu est fourni par emails par exemple, ou uniquement par une interface totalement dédiée à ce site là, avec uniquement les choses nécessaires à ce site là.

Mais pour cela il faut bien s'assurer que le noyau du SPIP a tout ce qu'il faut pour modifier *tous* les contenus ET configurations, sans l'admin habituelle. C'est-à-dire qu'il existe bien des fonctions, des API, qui permettent de modifier la config, les objets éditoriaux de toute sorte, etc. C'est à peu près le cas, mais pas tout à fait me semble-t-il. Il reste des choses trop liées aux interfaces (notamment dans les placements des tests d'autorisation, mais pas que ça).

Ya 2 ans j'avais noté un truc séparant les CMS en trois grandes fonctions : Publication / Édition / Gestion.
http://rastapopoulos.artizanal.info/notes/reflexions-sur-spip-cms-gestion-de-contenu

Dans la partie Édition, je disais :

Mon propos est de dire qu’il faudrait en premier lieu des API très solides et très complètes, que ce soit ça un des gros morceaux du noyau. Et que l’interface d’édition (pas juste ecrire/ mais tous les CVT aussi) ne soit qu’une couche par dessus, pour ceux qui éditent en mode web/HTML/navigateur.

En quoi ce n’est pas centré développeur ? Parce que le but est de fournir plus facilement DES moyens d’éditer le contenu. Soit par l’interface d’administration officielle, soit par email, soit dans un éditeur local, soit depuis d’autres applications distantes, etc. Et cela, sans devoir bidouiller soi-même chacun dans son coin. L’interface "ecrire/" ne serait qu’un seul des moyens, et non plus le point de passage obligé.

J’ajoute à ce gros point précédent, que je pense aussi qu’il faudrait une refonte ergonomique assez importante de l’interface web d’administration fournie par défaut. C’est encore un autre chantier donc, totalement différent, et qui ne porte que sur une seule des interfaces possibles.

Donc Attention : cela n'empêche pas que la distribution par défaut DOIT continuer de comporter une interface d'admin (et que celle-ci peut grandement être améliorée voire refondue). Mais cela signifie que cette interface serait un module séparé, fourni en "dist". Et non plus fusionné dans le noyau.

Au passage cela permettrait de renforcer la cohérence à mon avis, de "prouver" que tout est bien séparé, bien rangé, etc.

Rien que pour l'installation, actuellement ya encore trop de choses uniquement en interface (@gilles et au passage la commande spip-cli pour installer, justement elle ne marche pas encore à cause de ça).

Bref, ya du boulot, ce n'est pas quelque chose de "cool" et "montrable" qui fait envie à plein d'utilisateurices, mais même si ce n'est pas en haut de la pile des priorités, pour moi aussi ça me semble un truc important.

Il y a aussi la possibilité de déposer des fichiers textes dans des répertoires pour alimenter le site SPIP… :slight_smile:

Je voulais faire un plugin pour permettre l'ajout de documents à des articles, des rubriques, etc. Par dépôt dans un répertoire précis…

Hello,

peut-être que plutôt que se focaliser sur le "comment" faire un spip sans espace privé, il faut plutot s'intéresser et explorer le "pourquoi" et les usages.

Fonctionnellement, il est déjà possible de faire un SPIP sans espace privé utilisable avec un
function autoriser_ecrire(){return false;}
donc rien ne bloque les usages que chacun peut imaginer.

Il me semble que quand il y aura ces usages il sera toujours temps de consacrer du temps et de l'énergie à permettre d'enlever les fichiers qui servent à générer l'espace privé.

peut-être que plutôt que se focaliser sur le "comment" faire un spip
sans espace privé, il faut plutot s'intéresser et explorer le "pourquoi"
et les usages.

Ben on a déjà donné des exemples précédemment. Et il y en a d'autres.

donc rien ne bloque les usages que chacun peut imaginer.

Si. Car justement il y a encore plein de logiques fonctionnelles directement inscrites à l'intérieur de certains formulaires CVT (et ce n'est qu'un exemple). Les diverses API seules ne suffisent pas encore à modifier et gérer un site SPIP complètement.

Il me semble que quand il y aura ces usages il sera toujours temps de
consacrer du temps et de l'énergie à permettre d'enlever les fichiers
qui servent à générer l'espace privé.

Personne n'a parlé de les enlever réellement. Il me semble qu'on parle de les séparer proprement du noyau, mais seulement si ce dernier a ce qu'il faut pour fonctionner sans. Et d'avoir ces fichiers en plugins-dist, et non plus mélangé au reste.

Comme je le disais, faire cela n'est pas que cosmétique, car ça force à bien vérifier la cohérence de notre code, la propreté et la complétude des API, etc. À mon avis ça ne peut qu'être bénéfique pour y voir plus clair.

Car sinon on aurait pu dire exactement la même chose pour les autres fonctionnalités qu'on a enlevé ! Ce n'est pas parce que là il ne s'agit pas d'un objet éditorial que ce n'est pas le même principe : pourquoi enlever les statistiques du noyau ? pourquoi enlever les mots-clés du noyau ? pourquoi enlever les fonctions d'images ? etc etc : et bien parce que c'est plus propre et que ça oblige à bien rendre générique notre code, et avoir le moins d'exceptions "en dur" à l'intérieur (si possible aucune).

Ce n'est que la suite logique de tout ce qu'on a enlevé avant. Ce n'est pas un chantier qui est fini.

Par contre je suis d'accord qu'après avoir dit ça de manière *abstraite*, il faut créer des vrais tickets concrets du genre "Enlever tel traitement de ce formulaire CVT pour le mettre dans une fonction plus générique". Et cela pour chaque scorie identifié. Ce n'est qu'après avoir résolu tous ces tickets qu'on l'on pourra voir si l'admin peut se déplacer dans un plugin dist.

Allez Gilles, fouilles le code et balances du ticket ! :smiley:

Pas tout à fait, la particularité des squelettes SPIP est de proposer "vue + contrôleur" dans les squelettes.
Il y a un accès aux données et toute une partie logique dans les squelettes.
C'est justement ce qui les différencie de moteurs de templates comme Smarty ou Twig, qui ne font que recevoir des données.

Si ce n'est de séparer la partie "Vue" de la partie "Contrôleur+Modèle"

(tiens, ça me rappelle quelque chose)

Pas tout à fait, la particularité des squelettes SPIP est de proposer "vue
+ contrôleur" dans les squelettes.
Il y a un accès aux données et toute une partie logique dans les
squelettes.

Je pensais plutôt aux nombreux appels directs à la fonction "echo" partout
dans le code.
Un affichage direct simplifie peut-être les chose mais ne devrait être
réalisé que dans une vue (afin de pouvoir être détourné et/ou complété par
un pipeline)

C'est justement ce qui les différencie de moteurs de templates comme
Smarty ou Twig, qui ne font que recevoir des données.

oui pour cette partie je suis d'accord

Bonjour

Parmi les usages, de mon coté j'ai une ferme à SPIP environ 400 sites
sans espace privé. On a un SPIP maitre qui fournit ses propres
squelettes d'administrations et pilote indifféremment l'un des 400
sous sites. Les utilisateurs n'ont pas conscience de cette
distinction. Ils ont tous le même point d'entrée et leurs propres
contenus.

Pour info on l'a fait avec du spip 2.0/2.1, donc cela fait un petit
moment qu'on peut se passer d'un /ecrire/ :slight_smile:

Km