[SPIP Zone] Tables non créées à l'installation d'un plugin

jeanmarie · Novembre 21, 2019, 2:06

Salut,

sur un hébergement en particulier, lorsque j’installe Sélections éditoriales par exemple, j'ai le message suivant sur la page ?exec=selections : https://pic.infini.fr/RsrpgjpV/IHRwgtc7.png
Et les tables ne sont effectivement pas créées. Même comportement pour GIS.

Le problème apparait sur un seul hébergement (j'en ai testé 3 + wamp en local) et je ne comprends pas d'où ça peut venir car ils ont les mêmes caractéristiques : OVH mutu avec PHP 7.2.19 (testé en 5.6.40 également) / MySQL 5.6.43

Je précise que je peux créer rubriques et articles, donc la base est accessible en écriture.

Une idée du problème ?

             jean marie

b_b · Novembre 21, 2019, 2:12

Hop,

Le 21/11/2019 à 15:06, Jean Marie Grall a écrit :

Salut,

sur un hébergement en particulier, lorsque j’installe Sélections éditoriales par exemple, j'ai le message suivant sur la page ?exec=selections : https://pic.infini.fr/RsrpgjpV/IHRwgtc7.png
Et les tables ne sont effectivement pas créées. Même comportement pour GIS.

Le problème apparait sur un seul hébergement (j'en ai testé 3 + wamp en local) et je ne comprends pas d'où ça peut venir car ils ont les mêmes caractéristiques : OVH mutu avec PHP 7.2.19 (testé en 5.6.40 également) / MySQL 5.6.43

Je précise que je peux créer rubriques et articles, donc la base est accessible en écriture.

Une idée du problème ?

Perso, sur les mutus OVH j'ai souvent des problèmes de mises à jour des tables lors de l'upgrade des plugins (bug rencontré deux ou trois fois le mois dernier). Pour contourner, je dois passer dans la table spip_meta pour réduire le n° de version en base du plugin, puis relancer l'upgrade des tables en passant par la page de gestion des plugins.

Je soupçonne grandement un problème d'opcache...

++
b_b

jeanmarie · Novembre 21, 2019, 2:27

Le 21/11/2019 à 15:12, Bruno Bergot a écrit :

Hop,

Le 21/11/2019 à 15:06, Jean Marie Grall a écrit :

Salut,

sur un hébergement en particulier, lorsque j’installe Sélections éditoriales par exemple, j'ai le message suivant sur la page ?exec=selections : https://pic.infini.fr/RsrpgjpV/IHRwgtc7.png
Et les tables ne sont effectivement pas créées. Même comportement pour GIS.

Le problème apparait sur un seul hébergement (j'en ai testé 3 + wamp en local) et je ne comprends pas d'où ça peut venir car ils ont les mêmes caractéristiques : OVH mutu avec PHP 7.2.19 (testé en 5.6.40 également) / MySQL 5.6.43

Je précise que je peux créer rubriques et articles, donc la base est accessible en écriture.

Une idée du problème ?

Perso, sur les mutus OVH j'ai souvent des problèmes de mises à jour des tables lors de l'upgrade des plugins (bug rencontré deux ou trois fois le mois dernier). Pour contourner, je dois passer dans la table spip_meta pour réduire le n° de version en base du plugin, puis relancer l'upgrade des tables en passant par la page de gestion des plugins.

Belle fourberie mais ça ne marche pas chez moi, en tout cas pour l'installation du plugin.

J'ai changé dans spip_meta :
- la version du plugin dans plugin (2 occurrences) et plugin_installes
- la version de la base dans selections_editoriales_base_version

         jean marie

jeanmarie · Novembre 21, 2019, 3:01

(Je fais suivre la réponse arrivée en direct)

Le 21/11/2019 à 15:48, Pascal JPM a écrit :

+1
Idem ici (tjrs chez OVH - Mutu perfox1), à l'installation de nouveaux plugins > tables non-installées... obligé de le faire via PhpMyAdmin...

Comment tu le fais via phpMyAdmin, avec la technique de b_b ?

jeanmarie · Novembre 21, 2019, 3:51

Le 21/11/2019 à 15:27, Jean Marie Grall a écrit :

Le 21/11/2019 à 15:12, Bruno Bergot a écrit :

Hop,

Le 21/11/2019 à 15:06, Jean Marie Grall a écrit :

Salut,

sur un hébergement en particulier, lorsque j’installe Sélections éditoriales par exemple, j'ai le message suivant sur la page ?exec=selections : https://pic.infini.fr/RsrpgjpV/IHRwgtc7.png
Et les tables ne sont effectivement pas créées. Même comportement pour GIS.

Le problème apparait sur un seul hébergement (j'en ai testé 3 + wamp en local) et je ne comprends pas d'où ça peut venir car ils ont les mêmes caractéristiques : OVH mutu avec PHP 7.2.19 (testé en 5.6.40 également) / MySQL 5.6.43

Je précise que je peux créer rubriques et articles, donc la base est accessible en écriture.

Une idée du problème ?

Perso, sur les mutus OVH j'ai souvent des problèmes de mises à jour des tables lors de l'upgrade des plugins (bug rencontré deux ou trois fois le mois dernier). Pour contourner, je dois passer dans la table spip_meta pour réduire le n° de version en base du plugin, puis relancer l'upgrade des tables en passant par la page de gestion des plugins.

Belle fourberie mais ça ne marche pas chez moi, en tout cas pour l'installation du plugin.

Suite à un échange avec b_b, la solution qui fonctionne chez moi :
- installer le plugin
- attendre plus de 2s
- faire une réparation de la base (menu Maintenance > Maintenance technique)

L'idée (confirmer) est qu'à l'installation du plugin, le cache PHP opcache (cache de 2s chez moi) empêche SPIP d'avoir les bons scripts avec les instructions de création des tables. Donc, en réparant la base, on relance les scripts d'installation mais, entre temps, le cache a été vidé et on a la nouvelle version des scripts.

Indice qui va dans ce sens : à l'installation, avec define('_LOG_FILTRE_GRAVITE', 8);, il n'y a pas d'erreurs mysql alors que les tables ne sont pas créées.

V'là, merci pour la fourberie

             jean marie

22677b9b7f977d698ae0 · Novembre 21, 2019, 7:23

Le 21/11/2019 à 15:12, Bruno Bergot a écrit :

Hop,

Le 21/11/2019 à 15:06, Jean Marie Grall a écrit :

Salut,

sur un hébergement en particulier, lorsque j’installe Sélections éditoriales par exemple, j'ai le message suivant sur la page ?exec=selections : https://pic.infini.fr/RsrpgjpV/IHRwgtc7.png
Et les tables ne sont effectivement pas créées. Même comportement pour GIS.

Le problème apparait sur un seul hébergement (j'en ai testé 3 + wamp en local) et je ne comprends pas d'où ça peut venir car ils ont les mêmes caractéristiques : OVH mutu avec PHP 7.2.19 (testé en 5.6.40 également) / MySQL 5.6.43

Je précise que je peux créer rubriques et articles, donc la base est accessible en écriture.

Une idée du problème ?

Perso, sur les mutus OVH j'ai souvent des problèmes de mises à jour des tables lors de l'upgrade des plugins (bug rencontré deux ou trois fois le mois dernier). Pour contourner, je dois passer dans la table spip_meta pour réduire le n° de version en base du plugin, puis relancer l'upgrade des tables en passant par la page de gestion des plugins.

Je soupçonne grandement un problème d'opcache...

++
b_b
----

il m'arrive parfois d'avoir le même pb, je suis sur du mutu

souvent en effectuant une réparation de base, ça fonctionne

parfois il faut desactivé et reactivé le plugin apres avoir reparé la bdd

--
spipfactory.fr

cerdic · Novembre 22, 2019, 11:09

Hello Jean-Marie,

Ce réglage opcache est vraiment chiant et pénible
Est-ce que tu peux executer le code suivant sur le serveur mutu en question et nous donner le résultat ?

<?php
echo "OPCACHE Config<br />";
echo "<li>opcache_invalidate:" . var_export(function_exists('opcache_invalidate'), true);
echo "<li>opcache_get_configuration:" . var_export(function_exists('opcache_get_configuration'), true);
echo "<li>opcache.enable:" . var_export(ini_get('opcache.enable'), true);
echo "<li>opcache.validate_timestamps:".var_export(ini_get('opcache.validate_timestamps'), true);
echo "<li>opcache.revalidate_freq:".var_export(ini_get('opcache.revalidate_freq'));

--
Cédric
Le 21 nov. 2019 à 17:57 +0100, Jean Marie Grall <jeanmarie.listes@cousumain.info>, a écrit :

Le 21/11/2019 à 15:27, Jean Marie Grall a écrit :
>
> Le 21/11/2019 à 15:12, Bruno Bergot a écrit :
> > Hop,
> >
> > Le 21/11/2019 à 15:06, Jean Marie Grall a écrit :
> > > Salut,
> > >
> > > sur un hébergement en particulier, lorsque j’installe Sélections
> > > éditoriales par exemple, j'ai le message suivant sur la page
> > > ?exec=selections : https://pic.infini.fr/RsrpgjpV/IHRwgtc7.png
> > > Et les tables ne sont effectivement pas créées. Même comportement
> > > pour GIS.
> > >
> > > Le problème apparait sur un seul hébergement (j'en ai testé 3 + wamp
> > > en local) et je ne comprends pas d'où ça peut venir car ils ont les
> > > mêmes caractéristiques : OVH mutu avec PHP 7.2.19 (testé en 5.6.40
> > > également) / MySQL 5.6.43
> > >
> > > Je précise que je peux créer rubriques et articles, donc la base est
> > > accessible en écriture.
> > >
> > > Une idée du problème ?
> > >
> >
> > Perso, sur les mutus OVH j'ai souvent des problèmes de mises à jour
> > des tables lors de l'upgrade des plugins (bug rencontré deux ou trois
> > fois le mois dernier). Pour contourner, je dois passer dans la table
> > spip_meta pour réduire le n° de version en base du plugin, puis
> > relancer l'upgrade des tables en passant par la page de gestion des
> > plugins.
>
> Belle fourberie mais ça ne marche pas chez moi, en tout cas pour
> l'installation du plugin.

Suite à un échange avec b_b, la solution qui fonctionne chez moi :
- installer le plugin
- attendre plus de 2s
- faire une réparation de la base (menu Maintenance > Maintenance technique)

L'idée (confirmer) est qu'à l'installation du plugin, le cache PHP
opcache (cache de 2s chez moi) empêche SPIP d'avoir les bons scripts
avec les instructions de création des tables. Donc, en réparant la base,
on relance les scripts d'installation mais, entre temps, le cache a été
vidé et on a la nouvelle version des scripts.

Indice qui va dans ce sens : à l'installation, avec
define('_LOG_FILTRE_GRAVITE', 8);, il n'y a pas d'erreurs mysql alors
que les tables ne sont pas créées.

V'là, merci pour la fourberie
            jean marie
----
spip-zone@rezo.net - https://listes.rezo.net/mailman/listinfo/spip-zone

JLuc · Novembre 22, 2019, 11:52

Le 22/11/2019 à 12:09, Cerdic a écrit :

Ce réglage opcache est vraiment chiant et pénible

Je rencontrais plein de fois des situations où l'opcache foirait une mise à jour du core,
l'installation d'un plugin ou même simplement une modification d'un squelette.
Je force désormais le vidage des opcaches à chaque recalcul ainsi que les autres caches non spip
Il me semble que ça évite bien des prises de tête.

if (isset($_REQUEST['var_mode']) and ($_REQUEST['var_mode'] == 'recalcul')) {

if (function_exists('spip_clear_varnish_cache'))
spip_clear_varnish_cache();

include_spip ('inc/invalideur');
suivre_invalideur('recalcul');

if (function_exists('opcache_reset'))
opcache_reset();

     if (function_exists('apc_clear_cache')) {
         apc_clear_cache();
         apc_clear_cache('user');
     }

     if (function_exists('apcu_clear_cache')) {
         apcu_clear_cache();
     }

spip_log("recalcul a vidé varnish, SPIP, opcache et apc_cache");
}

Faut il pas intégrer un vidage de cache plus radical que l'actuel
lors des installs, upgrades et recalculs ?
cf Vider l'opcache au recalcul et à l'upgrade (#4261) · Tickets · spip / spip · GitLab

Est-ce que tu peux executer le code suivant sur le serveur mutu en question et nous donner le résultat ?

Ce n'est pas moi qui ait le problème actuellement mais voici pour info :
OPCACHE Config
opcache_invalidate:true
opcache_get_configuration:true
opcache.enable:'1'
opcache.validate_timestamps:'1''30'
opcache.revalidate_freq:

JL

<?php
echo "OPCACHE Config<br />";
echo "<li>opcache_invalidate:" . var_export(function_exists('opcache_invalidate'), true);
echo "<li>opcache_get_configuration:" . var_export(function_exists('opcache_get_configuration'), true);
echo "<li>opcache.enable:" . var_export(ini_get('opcache.enable'), true);
echo "<li>opcache.validate_timestamps:".var_export(ini_get('opcache.validate_timestamps'), true);
echo "<li>opcache.revalidate_freq:".var_export(ini_get('opcache.revalidate_freq'));

--
Cédric
Le 21 nov. 2019 à 17:57 +0100, Jean Marie Grall <jeanmarie.listes@cousumain.info>, a écrit :
Le 21/11/2019 à 15:27, Jean Marie Grall a écrit :

Le 21/11/2019 à 15:12, Bruno Bergot a écrit :

Hop,

Le 21/11/2019 à 15:06, Jean Marie Grall a écrit :

Salut,

sur un hébergement en particulier, lorsque j’installe Sélections
éditoriales par exemple, j'ai le message suivant sur la page
?exec=selections : https://pic.infini.fr/RsrpgjpV/IHRwgtc7.png
Et les tables ne sont effectivement pas créées. Même comportement
pour GIS.

Le problème apparait sur un seul hébergement (j'en ai testé 3 + wamp
en local) et je ne comprends pas d'où ça peut venir car ils ont les
mêmes caractéristiques : OVH mutu avec PHP 7.2.19 (testé en 5.6.40
également) / MySQL 5.6.43

Je précise que je peux créer rubriques et articles, donc la base est
accessible en écriture.

Une idée du problème ?

Perso, sur les mutus OVH j'ai souvent des problèmes de mises à jour
des tables lors de l'upgrade des plugins (bug rencontré deux ou trois
fois le mois dernier). Pour contourner, je dois passer dans la table
spip_meta pour réduire le n° de version en base du plugin, puis
relancer l'upgrade des tables en passant par la page de gestion des
plugins.

Belle fourberie mais ça ne marche pas chez moi, en tout cas pour
l'installation du plugin.

Suite à un échange avec b_b, la solution qui fonctionne chez moi :
- installer le plugin
- attendre plus de 2s
- faire une réparation de la base (menu Maintenance > Maintenance technique)

L'idée (confirmer) est qu'à l'installation du plugin, le cache PHP
opcache (cache de 2s chez moi) empêche SPIP d'avoir les bons scripts
avec les instructions de création des tables. Donc, en réparant la base,
on relance les scripts d'installation mais, entre temps, le cache a été
vidé et on a la nouvelle version des scripts.

Indice qui va dans ce sens : à l'installation, avec
define('_LOG_FILTRE_GRAVITE', 8);, il n'y a pas d'erreurs mysql alors
que les tables ne sont pas créées.

V'là, merci pour la fourberie
            jean marie
----
spip-zone@rezo.net - https://listes.rezo.net/mailman/listinfo/spip-zone
----
spip-zone@rezo.net - https://listes.rezo.net/mailman/listinfo/spip-zone

jeanmarie · Novembre 22, 2019, 1:43

Salut,

sur le mutu qui pose problème :

OPCACHE Config

opcache_invalidate:false
opcache_get_configuration:true
opcache.enable:‹ 1 ›
opcache.validate_timestamps:‹ 1 ›‹ 2 ›
opcache.revalidate_freq:

Sur les 2 autres :

OPCACHE Config

opcache_invalidate:false
opcache_get_configuration:true
opcache.enable:‹ 1 ›
opcache.validate_timestamps:‹ 1 ›‹ 2 ›
opcache.revalidate_freq:

Entre les 2, il y a une différence de noyau (php info) :

Linux 4.14.127-ovh-vps-grsec-zfs-classid #1 SMP > pose problème
Linux 4.14.119-ovh-vps-grsec-zfs-classid #1 SMP > pas de problème

Dis-moi si besoin d’autres tests…

jeanmarie

cerdic · Novembre 22, 2019, 2:01

OK merci, je vois le bug du coup, c’est la fonction opcache_invalidate() qui n’est pas disponible
http://core.spip.org/projects/spip/repository/revisions/24431 doit corriger ça !

--
Cédric
Le 22 nov. 2019 à 14:43 +0100, Jean Marie Grall <jeanmarie.listes@cousumain.info>, a écrit :

Salut,
sur le mutu qui pose problème :
OPCACHE Config

• opcache_invalidate:false
• opcache_get_configuration:true
• opcache.enable:'1'
• opcache.validate_timestamps:'1''2'
• opcache.revalidate_freq:
Sur les 2 autres :
OPCACHE Config
• opcache_invalidate:false
• opcache_get_configuration:true
• opcache.enable:'1'
• opcache.validate_timestamps:'1''2'
• opcache.revalidate_freq:
Entre les 2, il y a une différence de noyau (php info) :
- Linux 4.14.127-ovh-vps-grsec-zfs-classid #1 SMP > pose problème
- Linux 4.14.119-ovh-vps-grsec-zfs-classid #1 SMP > pas de problème
Dis-moi si besoin d'autres tests...
jeanmarie

Le 22/11/2019 à 12:09, Cerdic a écrit :
> Hello Jean-Marie,
>
> Ce réglage opcache est vraiment chiant et pénible
> Est-ce que tu peux executer le code suivant sur le serveur mutu en question et nous donner le résultat ?
>
> <?php
> echo "OPCACHE Config<br />";
> echo "<li>opcache_invalidate:" . var_export(function_exists('opcache_invalidate'), true);
> echo "<li>opcache_get_configuration:" . var_export(function_exists('opcache_get_configuration'), true);
> echo "<li>opcache.enable:" . var_export(ini_get('opcache.enable'), true);
> echo "<li>opcache.validate_timestamps:".var_export(ini_get('opcache.validate_timestamps'), true);
> echo "<li>opcache.revalidate_freq:".var_export(ini_get('opcache.revalidate_freq'));
>
>
> --
> Cédric
> Le 21 nov. 2019 à 17:57 +0100, Jean Marie Grall <jeanmarie.listes@cousumain.info>, a écrit :

Stephane_Santon · Novembre 23, 2019, 8:45

Bonjour,

Super ! Cette solution a résolu mon pb de

https://www.mail-archive.com/spip-zone@rezo.net/msg48588.html

Y a-t-il moyen de charger un spip 3.2 dev par spip_loader ?

Merci !

Le 21/11/2019 à 16:51, Jean Marie Grall a écrit :

Suite à un échange avec b_b, la solution qui fonctionne chez moi :
- installer le plugin
- attendre plus de 2s
- faire une réparation de la base (menu Maintenance > Maintenance technique)

L'idée (confirmer) est qu'à l'installation du plugin, le cache PHP opcache (cache de 2s chez moi) empêche SPIP d'avoir les bons scripts avec les instructions de création des tables. Donc, en réparant la base, on relance les scripts d'installation mais, entre temps, le cache a été vidé et on a la nouvelle version des scripts.

Indice qui va dans ce sens : à l'installation, avec define('_LOG_FILTRE_GRAVITE', 8);, il n'y a pas d'erreurs mysql alors que les tables ne sont pas créées.

V'là, merci pour la fourberie

--
Stéphane

Les Voisins Spipeurs : http://www.voisins-spipeurs.net

Stephane_Santon · Novembre 30, 2019, 5:43

Bonjour,
Le 23/11/2019 à 21:45, Stephane Santon a écrit :

Super ! Cette solution a résolu mon pb de
https://www.mail-archive.com/spip-zone@rezo.net/msg48588.html

Y a-t-il moyen de charger un spip 3.2 dev par spip_loader ?

Faute de réponse, j'ai modifié Spip_loader en remplaçant 3.2 par dev *en comptant obtenir les dernières maj (non publiées) de 3.2.*

Donc dans l'interface j'ai sélectionné dev.

Mais j'ai récupéré une 3.3.0 dev !! Donc site un peu cassé. (j'utilise un Zpip-dist V1)

1. Comment demander donc à Spip_loader la dernière svn d'une branche ? Peut-être un travail sur l'interface de spip_loader à faire, qui au moins afficherait ici que la "dev" est une 3.3.0 et non la svn de la branche présente.

2. J'ai maintenant un message
"Compatibilité forcée
Les plugins compatibles avec SPIP 3.2.99 peuvent être activés."

Qu'est-ce que ça veut dire ??
- "C'est forcé -> c'est possible qu'ils soient actuellement activés"
- "A propos du forçage -> je peux les activer" -> mais comment ? pas de lien, pas d'info
- ...

?

Merci

Le 21/11/2019 à 16:51, Jean Marie Grall a écrit :

Suite à un échange avec b_b, la solution qui fonctionne chez moi :
- installer le plugin
- attendre plus de 2s
- faire une réparation de la base (menu Maintenance > Maintenance technique)

L'idée (confirmer) est qu'à l'installation du plugin, le cache PHP opcache (cache de 2s chez moi) empêche SPIP d'avoir les bons scripts avec les instructions de création des tables. Donc, en réparant la base, on relance les scripts d'installation mais, entre temps, le cache a été vidé et on a la nouvelle version des scripts.

Indice qui va dans ce sens : à l'installation, avec define('_LOG_FILTRE_GRAVITE', 8);, il n'y a pas d'erreurs mysql alors que les tables ne sont pas créées.

V'là, merci pour la fourberie

--
Stéphane

Les Voisins Spipeurs : http://www.voisins-spipeurs.net

Franck · Décembre 2, 2019, 8:28

Hello
Alors si pour info spip_loader permet d'avoir la 3.2_dev, il suffit de remplacer la ligne:

par:
'zip' => 'spip/dev/SPIP-branche-3.2.zip',

Mais attention, car j'avais trouver un problème à une époque et je n'ai pas prit le temps, de refaire des essais pour voir si le problème est toujours présent, donc attention...
https://core.spip.net/issues/4158

Sinon concernant le message: "Les plugins compatibles avec SPIP 3.2.99 peuvent être activés"
C'est normal, cela vient du fait que tu as installer spip 3.3 et comme cette version n'est pas encore dispo, il y a un dispositif permettant quand même de faire fonctionner les plugins qui sont normalement pour spip 3.2 max. Cela permet de faire des tests aux plugins avant la sortie de spip 3.3 et ainsi donne "un peu" plus de temps aux auteurs pour faire des corrections si besoin, et ainsi de les mettre compatible spip 3.3 dès qu'il sortira.
En plus cela a comme avantage, de permettre de voir dans le cas d'un bug, si cela vient du plug ou de spip.

Franck

-----Message d'origine-----
De : Stephane Santon <m.spiprezo@santonum.eu>
Envoyé : samedi 30 novembre 2019 18:43
À : spip-zone@rezo.net
Objet : Re: [SPIP Zone] Tables non créées à l'installation d'un plugin

Bonjour,
Le 23/11/2019 à 21:45, Stephane Santon a écrit :

Super ! Cette solution a résolu mon pb de
https://www.mail-archive.com/spip-zone@rezo.net/msg48588.html

Y a-t-il moyen de charger un spip 3.2 dev par spip_loader ?

Faute de réponse, j'ai modifié Spip_loader en remplaçant 3.2 par dev *en comptant obtenir les dernières maj (non publiées) de 3.2.*

Donc dans l'interface j'ai sélectionné dev.

Mais j'ai récupéré une 3.3.0 dev !! Donc site un peu cassé. (j'utilise un Zpip-dist V1)

1. Comment demander donc à Spip_loader la dernière svn d'une branche ?
Peut-être un travail sur l'interface de spip_loader à faire, qui au moins afficherait ici que la "dev" est une 3.3.0 et non la svn de la branche présente.

2. J'ai maintenant un message
"Compatibilité forcée
Les plugins compatibles avec SPIP 3.2.99 peuvent être activés."

Qu'est-ce que ça veut dire ??
- "C'est forcé -> c'est possible qu'ils soient actuellement activés"
- "A propos du forçage -> je peux les activer" -> mais comment ? pas de lien, pas d'info
- ...

?

Merci

Le 21/11/2019 à 16:51, Jean Marie Grall a écrit :

Suite à un échange avec b_b, la solution qui fonctionne chez moi :
- installer le plugin
- attendre plus de 2s
- faire une réparation de la base (menu Maintenance > Maintenance
technique)

L'idée (confirmer) est qu'à l'installation du plugin, le cache PHP
opcache (cache de 2s chez moi) empêche SPIP d'avoir les bons scripts
avec les instructions de création des tables. Donc, en réparant la
base, on relance les scripts d'installation mais, entre temps, le
cache a été vidé et on a la nouvelle version des scripts.

Indice qui va dans ce sens : à l'installation, avec
define('_LOG_FILTRE_GRAVITE', 8);, il n'y a pas d'erreurs mysql alors
que les tables ne sont pas créées.

V'là, merci pour la fourberie

--
Stéphane

Les Voisins Spipeurs : http://www.voisins-spipeurs.net
----
spip-zone@rezo.net - https://listes.rezo.net/mailman/listinfo/spip-zone

Stephane_Santon · Décembre 2, 2019, 8:45

Bonsoir,

Merci pour toutes ces réponses.

Le 02/12/2019 à 21:28, Franck a écrit :

Alors si pour info spip_loader permet d'avoir la 3.2_dev, il suffit de remplacer la ligne:
Connexion · GitLab
par:
'zip' => 'spip/dev/SPIP-branche-3.2.zip',

Mais attention, car j'avais trouver un problème à une époque et je n'ai pas prit le temps, de refaire des essais pour voir si le problème est toujours présent, donc attention...
https://core.spip.net/issues/4158

Dommage qu'il manque sur spip_loader cette fonctionnalité qui paraît basique !

Sinon concernant le message: "Les plugins compatibles avec SPIP 3.2.99 peuvent être activés"
C'est normal, cela vient du fait que tu as installer spip 3.3 et comme cette version n'est pas encore dispo, il y a un dispositif permettant quand même de faire fonctionner les plugins qui sont normalement pour spip 3.2 max. Cela permet de faire des tests aux plugins avant la sortie de spip 3.3 et ainsi donne "un peu" plus de temps aux auteurs pour faire des corrections si besoin, et ainsi de les mettre compatible spip 3.3 dès qu'il sortira.
En plus cela a comme avantage, de permettre de voir dans le cas d'un bug, si cela vient du plug ou de spip.

OK pour l'explication.
Donc l'info serait plus claire avec qqchose su genre :
"Les plugins définis pour SPIP 3.2.99 ont été temporairement rendus compatibles avec cette version dev"

Franck

Bonne soirée

-----Message d'origine-----
De : Stephane Santon <m.spiprezo@santonum.eu>
Envoyé : samedi 30 novembre 2019 18:43
À : spip-zone@rezo.net
Objet : Re: [SPIP Zone] Tables non créées à l'installation d'un plugin

Bonjour,
Le 23/11/2019 à 21:45, Stephane Santon a écrit :

Super ! Cette solution a résolu mon pb de
https://www.mail-archive.com/spip-zone@rezo.net/msg48588.html

Y a-t-il moyen de charger un spip 3.2 dev par spip_loader ?

Faute de réponse, j'ai modifié Spip_loader en remplaçant 3.2 par dev *en comptant obtenir les dernières maj (non publiées) de 3.2.*

Donc dans l'interface j'ai sélectionné dev.

Mais j'ai récupéré une 3.3.0 dev !! Donc site un peu cassé. (j'utilise un Zpip-dist V1)

1. Comment demander donc à Spip_loader la dernière svn d'une branche ?
Peut-être un travail sur l'interface de spip_loader à faire, qui au moins afficherait ici que la "dev" est une 3.3.0 et non la svn de la branche présente.

2. J'ai maintenant un message
"Compatibilité forcée
Les plugins compatibles avec SPIP 3.2.99 peuvent être activés."

Qu'est-ce que ça veut dire ??
- "C'est forcé -> c'est possible qu'ils soient actuellement activés"
- "A propos du forçage -> je peux les activer" -> mais comment ? pas de lien, pas d'info
- ...

?

Merci

Le 21/11/2019 à 16:51, Jean Marie Grall a écrit :

Suite à un échange avec b_b, la solution qui fonctionne chez moi :
- installer le plugin
- attendre plus de 2s
- faire une réparation de la base (menu Maintenance > Maintenance
technique)

L'idée (confirmer) est qu'à l'installation du plugin, le cache PHP
opcache (cache de 2s chez moi) empêche SPIP d'avoir les bons scripts
avec les instructions de création des tables. Donc, en réparant la
base, on relance les scripts d'installation mais, entre temps, le
cache a été vidé et on a la nouvelle version des scripts.

Indice qui va dans ce sens : à l'installation, avec
define('_LOG_FILTRE_GRAVITE', 8);, il n'y a pas d'erreurs mysql alors
que les tables ne sont pas créées.

V'là, merci pour la fourberie

--
Stéphane

Les Voisins Spipeurs : http://www.voisins-spipeurs.net
----
spip-zone@rezo.net - https://listes.rezo.net/mailman/listinfo/spip-zone

--
Stéphane

Les Voisins Spipeurs : http://www.voisins-spipeurs.net

Franck · Décembre 2, 2019, 9:15

Il faut bien comprendre qu'une version "dev" c'est toujours à risque, c'est pour cela que ce n'est pas forcément une bonne idée que cela soit "très facile" à avoir, cela évite que des gens fassent une mauvaise manip et casse leur site. Même si un passage entre une 3.2 stable vers une 3.2 dev limite les risques, il faut bien comprendre qu'ils sont toujours présents...
C'est pour cela que devoir faire un changement de ligne dans le fichier n'est pas forcément une mauvaise chose et cela reste encore "simple" à faire.
Pour le bug, cela n'a pas toujours été le cas de mémoire, donc à voir s'il est encore là ou pas.

Par contre fait attention maintenant que tu es en spip 3.3, car faire un retour en arrière en spip 3.2 n'est pas forcément possible (sauf avoir une sauvegarde...)
De plus le passage de spip 3.2 vers spip 3.3 n'est pas non plus anodin, il s'agit d'un changement de version majeur de spip, c'est pour cela qu'il est toujours bon de suivre Changer la version majeure de SPIP - SPIP
Bien comprendre aussi que quand spip 3.3 sortira, le système de compatibilité concernant les plugs sera désactivé, et donc, possible que tu auras des plugs qui ne fonctionneront plus, le temps que l'auteur change la compatibilité du plug...
Franck

-----Message d'origine-----
De : Stephane Santon <m.spiprezo@santonum.eu>
Envoyé : lundi 2 décembre 2019 21:45
À : Franck <spip.franck@lien-d-amis.net>; spip-zone@rezo.net
Objet : Re: [SPIP Zone] Tables non créées à l'installation d'un plugin

Bonsoir,

Merci pour toutes ces réponses.

Le 02/12/2019 à 21:28, Franck a écrit :

Alors si pour info spip_loader permet d'avoir la 3.2_dev, il suffit de remplacer la ligne:
Connexion · GitLab
oader/trunk/spip_loader.php#L50
par:
'zip' => 'spip/dev/SPIP-branche-3.2.zip',

Mais attention, car j'avais trouver un problème à une époque et je n'ai pas prit le temps, de refaire des essais pour voir si le problème est toujours présent, donc attention...
https://core.spip.net/issues/4158

Dommage qu'il manque sur spip_loader cette fonctionnalité qui paraît basique !

Sinon concernant le message: "Les plugins compatibles avec SPIP 3.2.99 peuvent être activés"
C'est normal, cela vient du fait que tu as installer spip 3.3 et comme cette version n'est pas encore dispo, il y a un dispositif permettant quand même de faire fonctionner les plugins qui sont normalement pour spip 3.2 max. Cela permet de faire des tests aux plugins avant la sortie de spip 3.3 et ainsi donne "un peu" plus de temps aux auteurs pour faire des corrections si besoin, et ainsi de les mettre compatible spip 3.3 dès qu'il sortira.
En plus cela a comme avantage, de permettre de voir dans le cas d'un
bug, si cela vient du plug ou de spip.

OK pour l'explication.
Donc l'info serait plus claire avec qqchose su genre :
"Les plugins définis pour SPIP 3.2.99 ont été temporairement rendus compatibles avec cette version dev"

Franck

Bonne soirée

-----Message d'origine-----
De : Stephane Santon <m.spiprezo@santonum.eu> Envoyé : samedi 30
novembre 2019 18:43 À : spip-zone@rezo.net Objet : Re: [SPIP Zone]
Tables non créées à l'installation d'un plugin

Bonjour,
Le 23/11/2019 à 21:45, Stephane Santon a écrit :

Super ! Cette solution a résolu mon pb de
https://www.mail-archive.com/spip-zone@rezo.net/msg48588.html

Y a-t-il moyen de charger un spip 3.2 dev par spip_loader ?

Faute de réponse, j'ai modifié Spip_loader en remplaçant 3.2 par dev
*en comptant obtenir les dernières maj (non publiées) de 3.2.*

Donc dans l'interface j'ai sélectionné dev.

Mais j'ai récupéré une 3.3.0 dev !! Donc site un peu cassé. (j'utilise
un Zpip-dist V1)

1. Comment demander donc à Spip_loader la dernière svn d'une branche ?
Peut-être un travail sur l'interface de spip_loader à faire, qui au moins afficherait ici que la "dev" est une 3.3.0 et non la svn de la branche présente.

2. J'ai maintenant un message
"Compatibilité forcée
Les plugins compatibles avec SPIP 3.2.99 peuvent être activés."

Qu'est-ce que ça veut dire ??
- "C'est forcé -> c'est possible qu'ils soient actuellement activés"
- "A propos du forçage -> je peux les activer" -> mais comment ? pas
de lien, pas d'info
- ...

?

Merci

Le 21/11/2019 à 16:51, Jean Marie Grall a écrit :

Suite à un échange avec b_b, la solution qui fonctionne chez moi :
- installer le plugin
- attendre plus de 2s
- faire une réparation de la base (menu Maintenance > Maintenance
technique)

L'idée (confirmer) est qu'à l'installation du plugin, le cache PHP
opcache (cache de 2s chez moi) empêche SPIP d'avoir les bons scripts
avec les instructions de création des tables. Donc, en réparant la
base, on relance les scripts d'installation mais, entre temps, le
cache a été vidé et on a la nouvelle version des scripts.

Indice qui va dans ce sens : à l'installation, avec
define('_LOG_FILTRE_GRAVITE', 8);, il n'y a pas d'erreurs mysql
alors que les tables ne sont pas créées.

V'là, merci pour la fourberie

--
Stéphane

Les Voisins Spipeurs : http://www.voisins-spipeurs.net
----
spip-zone@rezo.net -
https://listes.rezo.net/mailman/listinfo/spip-zone

--
Stéphane

Les Voisins Spipeurs : http://www.voisins-spipeurs.net

JLuc · Décembre 3, 2019, 7:11

Le 02/12/2019 à 22:15, Franck a écrit :

Il faut bien comprendre qu'une version "dev" c'est toujours à risque, c'est pour cela que ce n'est pas forcément une bonne idée que cela soit "très facile" à avoir, cela évite que des gens fassent une mauvaise manip et casse leur site. Même si un passage entre une 3.2 stable vers une 3.2 dev limite les risques, il faut bien comprendre qu'ils sont toujours présents...

3.2 dev ? peut être veux tu dire 3.3 dev

En tout cas la sortie annoncée de la 3.3 beta est (ou sera) aussi une invitation à la tester.
Ce serait possible de le faciliter via le loader.

JL

22677b9b7f977d698ae0 · Décembre 3, 2019, 9:28

Le 03/12/2019 à 08:11, JLuc a écrit :

Le 02/12/2019 à 22:15, Franck a écrit :

Il faut bien comprendre qu'une version "dev" c'est toujours à risque, c'est pour cela que ce n'est pas forcément une bonne idée que cela soit "très facile" à avoir, cela évite que des gens fassent une mauvaise manip et casse leur site. Même si un passage entre une 3.2 stable vers une 3.2 dev limite les risques, il faut bien comprendre qu'ils sont toujours présents...

3.2 dev ? peut être veux tu dire 3.3 dev

En tout cas la sortie annoncée de la 3.3 beta est (ou sera) aussi une invitation à la tester.
Ce serait possible de le faciliter via le loader.

JL

*SPIP 3.2.6-dev SVN [24421 <http://core.spip.net/projects/spip/repository/revisions/24421>\]*

--
spipfactory.fr

Franck · Décembre 3, 2019, 9:18

Hello
Non, je parlais bien de la futur 3.2.6, car ce qu'il voulait, c'était pouvoir faire l'installation de la futur 3.2.6 qui est donc en "dev" pour avoir dès le départ ce patch Fix opcache invalidation sur les mutus qui n'ont pas la fonction opcache_invalidate() (Jean Marie) (f3cfdb19) · Validations · spip / spip · GitLab

Pas de bol, il à fait l'installation d'un spip 3.3 qui lui aussi, même s'il est proche de la sortie, est également au stade de "dev"
Spip_loader permet déjà de faire une installation du futur spip 3.3 Connexion · GitLab
Par contre, faut que je prenne le temps de changer via git la version mini de php Faire l'ajout de la config mini dans le paquet.xml d'ecrire (#4350) · Tickets · spip / spip · GitLab

Franck

-----Message d'origine-----
De : JLuc <jluc@no-log.org>
Envoyé : mardi 3 décembre 2019 08:11
À : spip-zone@rezo.net
Objet : Re: [SPIP Zone] Tables non créées à l'installation d'un plugin

Le 02/12/2019 à 22:15, Franck a écrit :

Il faut bien comprendre qu'une version "dev" c'est toujours à risque, c'est pour cela que ce n'est pas forcément une bonne idée que cela soit "très facile" à avoir, cela évite que des gens fassent une mauvaise manip et casse leur site. Même si un passage entre une 3.2 stable vers une 3.2 dev limite les risques, il faut bien comprendre qu'ils sont toujours présents...

3.2 dev ? peut être veux tu dire 3.3 dev

En tout cas la sortie annoncée de la 3.3 beta est (ou sera) aussi une invitation à la tester.
Ce serait possible de le faciliter via le loader.

JL

----
spip-zone@rezo.net - https://listes.rezo.net/mailman/listinfo/spip-zone