[SPIP Zone] Plugin Noizetier

Archives Zone
1

Hello,

Une petite info à partager sur une des limites du plugin Noizetier.
Pour un site particulier, l’utilisateur a créé beaucoup de compositions grâce au noizetier. Ce qui est très pratique. Ces compositions sont enregistrées dans spip_meta dans noizetier_compositions.

En soit, pas de soucis. Sauf quand on arrive, aujourd’hui, à la limite des 65000 caractères du champ « valeur » de la table spip_meta.

Est-ce qu’il ne serait pas envisageable de passer à une table dédiée à noizetier_compositions ?
C’est sûr, cela changera le fonctionnement du plugin. Mais le gain de performance et surtout ne plus avoir la limite serait parfait.

Ybbet.

2

Hello,

3

Hello,

4

Ybbet Spip a écrit :

Hello,

Le 8 juin 2017 à 20:25, Eric Lupinacci <eric@smellup.net
<mailto:eric@smellup.net>> a écrit :

    Hello,

    Le 8 juin 2017 à 17:23, Ybbet Spip <teddy.spip@gmail.com
    <mailto:teddy.spip@gmail.com>> a écrit :

        Une petite info à partager sur une des limites du plugin Noizetier.
        Pour un site particulier, l'utilisateur a créé beaucoup de
        compositions grâce au noizetier. Ce qui est très pratique. Ces
        compositions sont enregistrées dans spip_meta dans
        noizetier_compositions.

        En soit, pas de soucis. Sauf quand on arrive, aujourd'hui, à la
        limite des 65000 caractères du champ "valeur" de la table spip_meta.

    Waouh je suis impressionné.
    Il doit en avoir créé un max, tu as le nombre exact ?

Ils sont plusieurs utilisateurs. Il y a actuellement 264 pages listées,
avec une dizaine de noisettes en moyenne par page. Chaque noisette a des
options. :slight_smile:

        Est-ce qu'il ne serait pas envisageable de passer à une table
        dédiée à noizetier_compositions ?
        C'est sûr, cela changera le fonctionnement du plugin. Mais le
        gain de performance et surtout ne plus avoir la limite serait
        parfait.

    On pourrait mais ça n'arrangera en rien les performances à mon avis,
    au contraire.

C'est mon impression aussi.

En tout cas garder des configurations aussi grosses en taille dans spip_meta est très mauvais.

Je rappelle que la table meta est cachée dans le fichier tmp/meta_cache.php qui est lu et chargé à chaque hit. Il est fortement souhaitable et encouragé que ce fichier reste léger, et donc qu'on y stocke que des valeurs de configuration légères.

Son avantage est évidemment qu'il permet de récupérer les valeurs qui y sont stockées sans avoir besoin d'ouvrir une connexion sur la BDD, donc ça peut être intéressant sur des valeurs nécessaires y compris sur les hits en cache, sans calcul de squelette.

Si il faut faire une table, il vaut mieux que ce soit une table dédiée et structurée plutot qu'une autre table de meta dans laquelle les valeurs sont stockées sérializées. La serialization/unserialization est couteuse en perf.

Quand au stockage des compositions dans des fichiers xml/yaml par cohérence des compositions définies manuellement, je vois l'idée séduisante, mais ça créé une autre incohérence.
Actuellement toutes les données d'un site sont stockées en base. Stocker ces infos dans des fichiers va créer une spécificité : il ne suffira plus de migrer la base SQL pour déplacer les données d'un site, il faudra aussi penser aux fichiers des compositions, qui seront forcément en dehors du squelette (a priori leur place naturelle serait un sous dossier config/compositions)

Je pense que c'est pas top en terme de maintenabilité/portabilité et il vaut mieux en rester à :
un site = Données (SQL) + squelettes/ + IMG/
avec une certaine atomicité de chaque morceau

Cédric

5

Cédric Morin a écrit le 09/06/2017 à 09:47 :

faudra aussi penser aux fichiers des compositions, qui seront forcément en dehors du squelette (a priori leur place naturelle serait un sous dossier config/compositions)

Pourquoi en dehors de squelettes/ ?
Pour moi, ça aurait été leur place évidente.

--
RealET

6

Yop,

7

Bonjour,

8

RealET a écrit :

Cédric Morin a écrit le 09/06/2017 à 09:47 :

faudra aussi penser aux fichiers des compositions, qui seront
forcément en dehors du squelette (a priori leur place naturelle serait
un sous dossier config/compositions)

Pourquoi en dehors de squelettes/ ?
Pour moi, ça aurait été leur place évidente.

Le dossier squelettes/ n'a pas vocation à être en accès en ecriture par le serveur (surtout pas !), et mélanger dans un même dossier des fichiers générés par le serveur d'une part et par l'utilisateur d'autre part me semble une très mauvaise idée pour la maintenabilité

Cédric

9

Eric Lupinacci a écrit :

Oui tu as raison, je n'avais pas pensé à ce sujet mais le dossier
config/ fait aussi partie du backup de base non?

Pas explicitement à ce jour, ce serait un point à expliciter. Mais par exemple le fichier config/connect.php est lié au serveur, pas au site, et le backuper est pas forcément une bonne idée

En fait, je me disais surtout que quitte à changer, ça serait pas idiot
d'avoir un support commun pour toutes les compositions qu'elles soient
virtuelles (noizetier) ou explicites (manuelles par fichier XML).

Je comprends l'idée, mais je ne sais pas si c'est judicieux.
Ce sont 2 modes de fonctionnement différent.

Si je développe un squelette je veux que les fichiers se suffisent à eux même, et qu'on puisse l'utiliser sans devoir aller faire des modifications/configurations en base en plus.

Donc en fait, ne serait-il pas plus judicieux de basculer toutes les
compositions dans une table dédiée ?

Alors il faudrait garder le mécanisme de déclaration par fichier XML pour les squelettes, mais que le plugin les lise et les importe/update de lui même dans la table SQL (par passage dans une page de config, ou simplement sur la page d'admin des plugins)

--
Cédric

10

Yo,

11

Je rajoute deux questions au fait de passer les compositions dans une table qui ne remette pas en cause la décision:

  • pourquoi se limiter aux compositions et donc ne pas tout passer dans la même table, les pages et les compositions sachant que leur XML (ou YAML pour les pages dans la version) contiennent pratiquement les mêmes informations.
  • en supposant que l’on crée cette table, à quel moment faudrait-il la charger ou la recharger ? Il n’y a pas vraiment d’action comme celles sur les plugins pour le faire. On pourrait imaginer un recalcul sur les pages listting du noizetier ? Un var_mode propre ? autre ?
    Qu’en pensez-vous ?
12

Le 9 juin 2017 à 10:34, Eric Lupinacci a écrit :

Yop,

Je pense que c'est pas top en terme de maintenabilité/portabilité et il

vaut mieux en rester à :
un site = Données (SQL) + squelettes/ + IMG/
avec une certaine atomicité de chaque morceau

Oui tu as raison, je n'avais pas pensé à ce sujet mais le dossier config/
fait aussi partie du backup de base non?

Je me suis fait la même remarque :wink:
À moins qu'il ne fasse juste allusion à l'export SQL de la base, auquel cas
tu n'as pas forcément besoin des paramètres d'accès au SGBD ...mais si on a
défini des options...

13

Le 09/06/2017 à 11:01, Cédric Morin a écrit :

Eric Lupinacci a écrit :

Oui tu as raison, je n'avais pas pensé à ce sujet mais le dossier
config/ fait aussi partie du backup de base non?

Pas explicitement à ce jour, ce serait un point à expliciter. Mais par exemple le fichier config/connect.php est lié au serveur, pas au site, et le backuper est pas forcément une bonne idée

Dans le code la constante qui est à définir ce fichiers config/ est _NOM_PERMANENTS_INACCESSIBLES et les fichiers téléversés via Formidable y sont maintenant stockés. Donc oui, il faut le sauvegarder aussi.

Ceci dit, il faudrait peut être séparer en 2 répertoires différents si y a vraiment besoin pour différencier ce qui concerne le site de ce qui concerne le serveur, bien que la catégorisation entre l’un est l’autre n’est pas forcément évidente. Où irait le fichier mes_options.php dans ce cas ?

MM.

14

Hello,

15

Hello,

Suite des pérégrinations du noizetier.J’ai implémenté la table spip_noisettes_pages pour y accueillir les configurations des pages et compositions explicites (provenant du XML ou YAML) et virtuelles (créées par le noizetier).
J’ai mis en place un md5 pour limiter les rechargement car on peut imaginer que le nombre de changements doit être très limités en général.

Tout ça est bel et beau.
C’est pourquoi je viens de me dire que la configuration des noisettes c’est pareil voire encore plus critique vu le nombre de noisettes.

Donc je me suis dit pourquoi ne pas tout mettre en base de données ce qui simplifierait la plupart des traitements avec des boucles plutôt que les fonctions d’information actuelles.
On pourrait avoir :

  • spip_pages : contient la configuration des pages et compositions issue des fichiers XML ou YAML ou directement créées par le noizetier. C’est la table spip_noisettes_pages que je vient de créer.
  • spip_noisettes : plutôt que de contenir l’utilisation des noisettes dans les pages on y mettrait la configuration des noisettes issue des YAML.
  • spip_noisettes_pages : contiendrait cette fois l’utilisation des noisettes dans les pages c’est à dire la table spip_noisettes actuelle.

Si ce n’est le nom des tables que l’on peut discuter je trouve cette idée plutôt intéressante quitte à faire le pas non? On peut imaginer d’ailleurs plus tard le plugin compositions utiliser la premiere table même si ce n’est pas le but de cette option.

16

Hello,

17

Oui c’est noté, on peut faire ça dans la page de la… page.
Après dans la liste des pages non car ça referait calculer à chaque fois le md5 de chaque page.
Enfin, on va voir mais oui y a surement quelque chose à faire dans ce sens.

Après j’aimerais bien un avis sur les tables et leur nom svp.

18

Le 13 juin 2017 à 11:03, Eric Lupinacci <eric@smellup.net> a écrit :

Oui c'est noté, on peut faire ça dans la page de la... page.
Après dans la liste des pages non car ça referait calculer à chaque fois
le md5 de chaque page.
Enfin, on va voir mais oui y a surement quelque chose à faire dans ce sens.

Après j'aimerais bien un avis sur les tables et leur nom svp.

Il n'y a que le nom "spip_pages" qui me gêne car cela me fait penser au
plugin Pages Pages - Plugins SPIP
Mais, on est bien d'accord, ça n'a rien à voir avec le plugin cité. Bref.
ça marche pour "spip_pages" dans le noizetier.

Tu gérerais comment les héritages rubriques -> rubriques-compo ?

++
Eric

Le 13 juin 2017 à 10:13, Ybbet Spip <teddy.spip@gmail.com> a écrit :

Hello,

Le 11 juin 2017 à 13:09, Eric Lupinacci <eric@smellup.net> a écrit :

Hello,

Suite des pérégrinations du noizetier.
J'ai implémenté la table spip_noisettes_pages pour y accueillir les
configurations des pages et compositions explicites (provenant du XML ou
YAML) et virtuelles (créées par le noizetier).
J'ai mis en place un md5 pour limiter les rechargement car on peut
imaginer que le nombre de changements doit être très limités en général.

Tout ça est bel et beau.
C'est pourquoi je viens de me dire que la configuration des noisettes
c'est pareil voire encore plus critique vu le nombre de noisettes.

Donc je me suis dit pourquoi ne pas tout mettre en base de données ce
qui simplifierait la plupart des traitements avec des boucles plutôt que
les fonctions d'information actuelles.
On pourrait avoir :

- spip_pages : contient la configuration des pages et compositions issue
des fichiers XML ou YAML ou directement créées par le noizetier. C'est la
table spip_noisettes_pages que je vient de créer.
- spip_noisettes : plutôt que de contenir l'utilisation des noisettes
dans les pages on y mettrait la configuration des noisettes issue des YAML.
- spip_noisettes_pages : contiendrait cette fois l'utilisation des
noisettes dans les pages c'est à dire la table spip_noisettes actuelle.

Si ce n'est le nom des tables que l'on peut discuter je trouve cette
idée plutôt intéressante quitte à faire le pas non? On peut imaginer
d'ailleurs plus tard le plugin compositions utiliser la premiere table même
si ce n'est pas le but de cette option.

Je réponds tardivement, désolé.

Il serait intéressant en plus du var_mode=recalcul d'avoir dans une
colonne (droite ou gauche) une alerte pour dire qu'une configuration (cf.
fichier yaml) a été modifié. Pour le développeur, oui, le réflexe sera de
relancer le recalcul de la page pour avoir ce qu'il a mis en place. Mais
pour l'utilisateur lambda, c'est moins évident. Donc, un petit message pour
l'inciter à relancer le calcul de la page serait le bienvenu.

Qu'en pensez-vous ?

Ybbet.

++
Eric

Le 10 juin 2017 à 15:42, Eric Lupinacci <eric@smellup.net> a écrit :

Hello,

Le 9 juin 2017 à 16:13, Eric Lupinacci <eric@smellup.net> a écrit :

Je rajoute deux questions au fait de passer les compositions dans une
table qui ne remette pas en cause la décision:
- pourquoi se limiter aux compositions et donc ne pas tout passer dans
la même table, les pages et les compositions sachant que leur XML (ou YAML
pour les pages dans la version) contiennent pratiquement les mêmes
informations.
- en supposant que l'on crée cette table, à quel moment faudrait-il la
charger ou la recharger ? Il n'y a pas vraiment d'action comme celles sur
les plugins pour le faire. On pourrait imaginer un recalcul sur les pages
listting du noizetier ? Un var_mode propre ? autre ?
Qu'en pensez-vous ?

Auto-réponse et nouvelle question :

- je vais tout mettre, les pages, les compositions et les compositions
explicites dans une table spip_noisettes_pages.
- Pour les mise à jour je vais essayer d'optimiser les lectures de
fichier et j'utiliserais le var_mode=recalcul sur les pages listant les
pages du noizetier pour resynchroniser si besoin. Peut-être qu'un bouton
serait aussi approprié ?

Maintenant j'ai une question pour définir le contenu de la table.
En lisant le code de Compositions, j'ai vu qu'il y avait des
informations que je ne connaissais pas pour une composition à savoir:
- image_exemple, class et configuration.
Quelqu'un peut-il m'éclairer ? Pour l'instant j'ai mis des varchar(255)
pour chacun de ces champs.

Je vous joins une DTD des XML page et composition pour information.
L'idée est plus de définir la liste des champs plutôt qu'une quelconque
validation (la DTD n'est pas verbeuse à contrario des XML actuels).
J'avoue que tout XML devrait avoir une DTD pour savoir au moins ce
qu'on autorise dedans.

++
Eric

19

Il me semble aussi que spip_pages est trop générique, le terme « page » est utilisé par au moins 3 plugins avec des sens différents (noizetier, pages uniques, urls pages).
Je n’ai pas d’alternative en tête tout de suite, mais je pense qu’il faudrait trouver autre chose.

20

Le 13/06/2017 à 11:03, Eric Lupinacci a écrit :

Après j'aimerais bien un avis sur les tables et leur nom svp.

Ben moi tu sais ce que j'en pense hein, j'aime pas le terme "noisettes", ça fait un peu kitsch et ça parle pas vraiment...

--
nicod_