Non prise en compte de la balise `genie` d'un paquet.xml lors du vidage de cache #3860

Closed
opened 6 years ago by marcimat · 6 comments
marcimat commented 6 years ago
Owner

La balise genie dans un paquet.xml n'ajoute pas l'entrée adéquat dans tmp/charger_pipelines.php
dès lors qu'on vide le cache. Il faut repasser sur la page admin_plugins pour qu'elle soit prise en compte.

Le problème vient du code suivant :

if (charger_fonction($nom, "genie", true)) {
	$prepend_code['taches_generales_cron'] .= "\$val['$nom'] = $periode;\n";
} else {
	spip_log("Fonction genie_$nom introuvable", _LOG_ERREUR);
}

Effectivement à ce moment là, le chemin des plugins n'est pas encore pris en compte par SPIP et du coup, le charger_fonction() retourne toujours false.
Je vois deux possibilités pour corriger :
A) Ignorer ce if tout simplement, considérant que job_queue écrira un log (certes pas du niveau _LOG_ERREUR) en cas où il ne trouve pas la fonction demandée
B) Remonter le chargement des chemins des plugins : il est effectué juste avant le chargement des fichiers d'options, à la fin de la fonction.
La partie de chargement des chemins (include_once(_CACHE_PLUGINS_PATH);) pourrait être monté en tête de cette fonction, au niveau de $prepend_code = array();

Des avis ?

La balise `genie` dans un paquet.xml n'ajoute pas l'entrée adéquat dans tmp/charger_pipelines.php dès lors qu'on vide le cache. Il faut repasser sur la page admin_plugins pour qu'elle soit prise en compte. Le problème vient du code suivant : <pre> if (charger_fonction($nom, "genie", true)) { $prepend_code['taches_generales_cron'] .= "\$val['$nom'] = $periode;\n"; } else { spip_log("Fonction genie_$nom introuvable", _LOG_ERREUR); } </pre> Effectivement à ce moment là, le chemin des plugins n'est pas encore pris en compte par SPIP et du coup, le charger_fonction() retourne toujours false. Je vois deux possibilités pour corriger : A) Ignorer ce if tout simplement, considérant que job_queue écrira un log (certes pas du niveau _LOG_ERREUR) en cas où il ne trouve pas la fonction demandée B) Remonter le chargement des chemins des plugins : il est effectué juste avant le chargement des fichiers d'options, à la fin de la fonction. La partie de chargement des chemins (`include_once(_CACHE_PLUGINS_PATH);`) pourrait être monté en tête de cette fonction, au niveau de `$prepend_code = array();` Des avis ?
Poster
Owner

Pour info, le code pour la balise genie a été introduit par https://core.spip.net/projects/spip/repository/revisions/21828
Le déplacement des chargements des chemins et fichiers d'options en bas de cette fonction vient de https://core.spip.net/projects/spip/repository/revisions/15433

Pour info, le code pour la balise genie a été introduit par https://core.spip.net/projects/spip/repository/revisions/21828 Le déplacement des chargements des chemins et fichiers d'options en bas de cette fonction vient de https://core.spip.net/projects/spip/repository/revisions/15433
Poster
Owner

Dans le cas de B), on pourrait même peut être monter les 2 chargements : chemins & options.
Effectivement, les fichiers d'options peuvent aussi déclarer des chemins alors du coup…

Dans le cas de B), on pourrait même peut être monter les 2 chargements : chemins & options. Effectivement, les fichiers d'options peuvent aussi déclarer des chemins alors du coup…
Poster
Owner

Je pensais bien déplacer plus haut le chargement des chemins et options (le point B que j'indiquais).
Mais. Cela pourrait potentiellement impacter des plugins qui attendent d'avoir dans leur fichier d'option un 'spip_pipeline' un peu rempli.

Mais je vois 1 plugin (1 seul sur la zone il me semble) que ma pourrait impacter : Fastcache. (En fait non car Mutualisation déclare son pipeline dans son fichier d'option aussi donc, ça ne s'applique pas pour lui) mais je le mets pour l'exemple : si je remonte un peu le chargement des fichiers d'options, la globale 'spip_pipeline' ne sera pas remplie par les pipelines déclarés dans les plugin.xml ou paquet.xml des plugins à activer.
Or, dans Fastcache on a cette écriture :

# s'inserer au *debut* du pipeline affichage_final pour etre avant f_surligne etc
# mais de preference apres mutualisation_url_img_courtes pour qu'il s'applique
$GLOBALS['spip_pipeline']['affichage_final'] = preg_replace(
    ',\|mutualisation_url_img_courtes|^,
    ','\0|Fastcache_affichage_final', 
    $GLOBALS['spip_pipeline']['affichage_final']
);

On peut peut être du coup supposer que d'autres plugins dans la nature font de même ?
Ça se mord un peu la queue tout de même, vu que le fichier de chargement des pipelines (tmp/cache/charger_pipelines) pourrait aussi avoir besoin d'infos qui sont chargées dans les fichiers d'options de plugins. En tout cas là pour cette balise <genie> tel que c'est codé il en a besoin (des chemins au moins).

Cependant je serai d'avis tout de même de recharger les chemins et options plus tôt (spip_pipeline sera presque vide dans les fichiers d'options), en considérant que le fichier d'option sert à remplir justement ce fichier de pipeline, pas à modifier des fonctions qu'ont demandé d'autres plugins.

Voici un patch, pour voir ce que j'indique en B donc, en pièce jointe.

Je pensais bien déplacer plus haut le chargement des chemins et options (le point B que j'indiquais). Mais. Cela pourrait potentiellement impacter des plugins qui attendent d'avoir dans leur fichier d'option un 'spip_pipeline' un peu rempli. Mais je vois 1 plugin (1 seul sur la zone il me semble) que ma pourrait impacter : Fastcache. (En fait non car Mutualisation déclare son pipeline dans son fichier d'option aussi donc, ça ne s'applique pas pour lui) mais je le mets pour l'exemple : si je remonte un peu le chargement des fichiers d'options, la globale 'spip_pipeline' ne sera pas remplie par les pipelines déclarés dans les plugin.xml ou paquet.xml des plugins à activer. Or, dans Fastcache on a cette écriture : <pre> # s'inserer au *debut* du pipeline affichage_final pour etre avant f_surligne etc # mais de preference apres mutualisation_url_img_courtes pour qu'il s'applique $GLOBALS['spip_pipeline']['affichage_final'] = preg_replace( ',\|mutualisation_url_img_courtes|^, ','\0|Fastcache_affichage_final', $GLOBALS['spip_pipeline']['affichage_final'] ); </pre> On peut peut être du coup supposer que d'autres plugins dans la nature font de même ? Ça se mord un peu la queue tout de même, vu que le fichier de chargement des pipelines (tmp/cache/charger_pipelines) pourrait aussi avoir besoin d'infos qui sont chargées dans les fichiers d'options de plugins. En tout cas là pour cette balise `<genie>` tel que c'est codé il en a besoin (des chemins au moins). Cependant je serai d'avis tout de même de recharger les chemins et options plus tôt (spip_pipeline sera presque vide dans les fichiers d'options), en considérant que le fichier d'option sert à remplir justement ce fichier de pipeline, pas à modifier des fonctions qu'ont demandé d'autres plugins. Voici un patch, pour voir ce que j'indique en B donc, en pièce jointe.
b_b commented 6 years ago
Owner

Voir r23258 donc. De ce que je comprends l'effet de bord du patch ne me semble pas problématique, on devrait pouvoir reporter le patch en 3.1, merci marcimat :)

Voir r23258 donc. De ce que je comprends l'effet de bord du patch ne me semble pas problématique, on devrait pouvoir reporter le patch en 3.1, merci marcimat :)
Poster
Owner

Reporté par r23304 dans la branche 3.1.
Faudra vérifier que ça ne casse rien :)

Statut changé à Résolu

Reporté par r23304 dans la branche 3.1. Faudra vérifier que ça ne casse rien :) **Statut changé à Résolu**
b_b commented 6 years ago
Owner

Merci mignon :) (on ferme)
Statut changé à Fermé

Merci mignon :) (on ferme) **Statut changé à Fermé**
Sign in to join this conversation.
No Milestone
No project
No Assignees
2 Participants
Notifications
Due Date

No due date set.

Dependencies

This issue currently doesn't have any dependencies.

Loading…
There is no content yet.