Les tables des plugins ne s'installent pas #3418

Closed
opened 8 years ago by Franck · 31 comments
Franck commented 8 years ago

Bonjour
Suite à une demande d'aide sur l'IRC hier d'une personne qui souhaite, faire la migration de sont spip 1.9.1 en 2.1.26, j'ai fait un test.
En effet, cette personne voulait faire sa migration car elle est chez ovh, donc voulant faire un changement de version de php et donc de spip en même temps

J'ai juste fait l'installation d'un spip 2.1 dev (neuf) et fait l'essai de faire l'installation de plugins via le système automatique /ecrire/?exec=charger_plugin
PHP 5.6.6
Aucun préfix particulier concernant le préfix des tables, elles sont donc sous la forme: spip_xxx
Installation en MySQL
SPIP 2.1.26 [21956] (le problème est présent également en 2.1.26 [21262])

A savoir que j'ai fait l'essai avec 2 types de plugins et via 2 installations entièrement neuve systématiquement.
J'ai fait l'essai avec le plugin "agenda" (2.4.4), mais aussi "gis" (2.4.11)
C'est d'ailleurs pour cela que je ne pense pas que le problème vient des plug. Mais plutôt de spip

A chaque fois, les tables qui devaient être présente suite à l'installation des plug étaient absente !

Bonjour Suite à une demande d'aide sur l'IRC hier d'une personne qui souhaite, faire la migration de sont spip 1.9.1 en 2.1.26, j'ai fait un test. En effet, cette personne voulait faire sa migration car elle est chez ovh, donc voulant faire un changement de version de php et donc de spip en même temps J'ai juste fait l'installation d'un spip 2.1 dev (neuf) et fait l'essai de faire l'installation de plugins via le système automatique /ecrire/?exec=charger_plugin PHP 5.6.6 Aucun préfix particulier concernant le préfix des tables, elles sont donc sous la forme: spip_xxx Installation en MySQL SPIP 2.1.26 [21956] (le problème est présent également en 2.1.26 [21262]) A savoir que j'ai fait l'essai avec 2 types de plugins et via 2 installations entièrement neuve systématiquement. J'ai fait l'essai avec le plugin "agenda" (2.4.4), mais aussi "gis" (2.4.11) C'est d'ailleurs pour cela que je ne pense pas que le problème vient des plug. Mais plutôt de spip A chaque fois, les tables qui devaient être présente suite à l'installation des plug étaient absente !
Poster

Je viens de faire un nouveau test, mais cette fois en php 5.3.29 et le problème est le même, aucune création de table concernant les plugs

Je viens de faire un nouveau test, mais cette fois en php 5.3.29 et le problème est le même, aucune création de table concernant les plugs
Poster

Nouveaux tests :-)
J'ai toujours fait les tests à partir d'un SPIP 2.1.26 [21956] (le dev) chez ovh
Les tests ont tous été fait à partir d'un spip "neuf", je supprime fichiers et bdd pour chaque test !
Aucun préfix de tables particulier.

Donc, je résume:
php 5.6.6 en mode production: cela ne fonctionne pas
php 5.3.29 en mode production: cela ne fonctionne pas

php 5.4.38 en mode production ou dev, cela fonctionne !

Voir ici, concernant le passage en mode "prod" ou "dev"

Nouveaux tests :-) J'ai toujours fait les tests à partir d'un SPIP 2.1.26 [21956] (le dev) chez ovh Les tests ont tous été fait à partir d'un spip "neuf", je supprime fichiers et bdd pour chaque test ! Aucun préfix de tables particulier. Donc, je résume: php 5.6.6 en mode production: cela ne fonctionne pas php 5.3.29 en mode production: cela ne fonctionne pas php 5.4.38 en mode production ou dev, cela fonctionne ! Voir ici, concernant le passage en mode "prod" ou "dev"
Poster

Nouvelle série de test:

SPIP 3.0.18-dev [21967]
Installation en MySQL

Le plugin était Agenda avec le Mini Calendrier
Les tables étaient bien présente à chaque fois
spip_evenements
spip_evenements_participants

https://www.ovh.com/fr/g1207.configurer-php-web
5.6.6 en mode prod = ok
5.5.22 en mode prod = ok
5.4.38 en mode prod = ok
5.3.29 en mode prod = ok

5.6.6 en mode dev = ok
5.5.22 en mode dev = ok
5.4.38 en mode dev = ok
5.3.29 en mode dev = ok

Ce qui est bizarre, c'est que b_b semble avoir eu un problème en php 5.4 et prod, j'ai peur que cela soit un bug tordu...

Nouvelle série de test: SPIP 3.0.18-dev [21967] Installation en MySQL Le plugin était Agenda avec le Mini Calendrier Les tables étaient bien présente à chaque fois spip_evenements spip_evenements_participants https://www.ovh.com/fr/g1207.configurer-php-web 5.6.6 en mode prod = ok 5.5.22 en mode prod = ok 5.4.38 en mode prod = ok 5.3.29 en mode prod = ok 5.6.6 en mode dev = ok 5.5.22 en mode dev = ok 5.4.38 en mode dev = ok 5.3.29 en mode dev = ok Ce qui est bizarre, c'est que b_b semble avoir eu un problème en php 5.4 et prod, j'ai peur que cela soit un bug tordu...
Poster

SPIP 3.1.0-alpha [21970]
Installation en MySQL
Aucun prefix de table particulier, ils sont donc sous la forme: spip_xxx
Essai d'installation du plugin "agenda" 3.14.7
L'installation est faite via SVP

Quand je parle tables, je parle des tables du plug:
spip_evenements
spip_evenements_participants

5.6.6 en mode prod = tables absente
5.5.22 en mode prod = tables absente
5.4.38 en mode prod = ok
5.3.29 en mode prod = tables absente

5.6.6 en mode dev = tables absente
5.5.22 en mode dev = tables absente
5.4.38 en mode dev = ok
5.3.29 en mode dev = tables absente

Pour une raison que j'ignore, les tables ne sont présente qu'en php 5.4 chez ovh

SPIP 3.1.0-alpha [21970] Installation en MySQL Aucun prefix de table particulier, ils sont donc sous la forme: spip_xxx Essai d'installation du plugin "agenda" 3.14.7 L'installation est faite via SVP Quand je parle tables, je parle des tables du plug: spip_evenements spip_evenements_participants 5.6.6 en mode prod = tables absente 5.5.22 en mode prod = tables absente 5.4.38 en mode prod = ok 5.3.29 en mode prod = tables absente 5.6.6 en mode dev = tables absente 5.5.22 en mode dev = tables absente 5.4.38 en mode dev = ok 5.3.29 en mode dev = tables absente Pour une raison que j'ignore, les tables ne sont présente qu'en php 5.4 chez ovh
Poster

SPIP 3.1.0-alpha [21970]
Test chez ovh sur un mutualisé, je ne sais si je suis sur ce cluster, mais de toute façon, ils doivent être tous pareil http://cluster015.ovh.net/infos

Aucun prefix des tables particulier
Les plugin était toujours agenda et Mini Calendrier

SQLite 3++

5.6.6 en mode prod = tables absente, mais présente dans une sauvegarde
5.5.22 en mode prod = tables absente, mais présente dans une sauvegarde
5.4.38 en mode prod = ok
5.3.29 en mode prod = tables absente, mais présente dans une sauvegarde

5.6.6 en mode dev = tables absente, mais présente dans une sauvegarde
5.5.22 en mode dev = tables absente, mais présente dans une sauvegarde
5.4.38 en mode dev = ok
5.3.29 en mode dev = tables absente, mais présente dans une sauvegarde

SQLite 2++
5.3.29 en mode prod = tables absente, mais présente dans une sauvegarde
Il y a une erreur qui s'affiche dans l'espace privé dès que j'y rentre:
Numero: 1, message: Array, squelette: ecrire/public/composer.php, boucle: calculer_select(){ sql_select(); }, ligne: 876

Par contre, je sais qu'elle est absente via ecrire/?exec=vertebres car quand j'essai de la lire via firefox, alors cela me sort:
SQLiteManager: Error in opening file spip.sqlite - either the file is encrypted or corrupt
Exception Name: NS_ERROR_FILE_CORRUPTED
Exception Message: Component returned failure code: 0x8052000b (NS_ERROR_FILE_CORRUPTED) [mozIStorageService.openUnsharedDatabase]

A savoir par contre que je peux parfaitement lire la sauvegarde via firefox

5.3.29 en mode dev = Installation problématique, cela me sort des:
Warning: sqlite_query() [function.sqlite-query]: near "ORDER": syntax error in /ecrire/req/sqlite_generique.php on line 2703
Http 302
Si je clique sur le lien (il a un problème d'accent) l'installation se fait quand même, mais il y beaucoup de Warning... et toujours l'erreur dans le squelette

Warning: sqlite_query() [function.sqlite-query]: near "ORDER": syntax error in /home/liendami/www/spip3/spip/ecrire/req/sqlite_generique.php on line 2703
Warning: sqlite_query() [function.sqlite-query]: no such column: auteurs.imessage in /home/liendami/www/spip3/spip/ecrire/req/sqlite_generique.php on line 2703
Après linstallation des plugins, si je vais dans exec=sauvegarder
Warning: sqlite_query() [function.sqlite-query]: no such table: spip_evenements in /home/liendami/www/spip3/spip/ecrire/req/sqlite_generique.php on line 2703
Warning: sqlite_query() [function.sqlite-query]: no such table: spip_evenements_participants in /home/liendami/www/spip3/spip/ecrire/req/sqlite_generique.php on line 2703
Cela me fait bien la sauvegarde, mais d'autres warning apparaisent pendant
Sinon, c'est identique au mode "production"

J'ai refais des 2 tests en MySQL (php 5.6.6 et php 5.4.38) en mode dev pour vérifier si les sauvegardes étaient avec ou sans les tables du plugin (je n'avais pas fait cette vérif avant)
Dans les deux cas, il y avait les tables dans les sauvegardes
Alors qu'elles étaient:
Absente dans la bdd en 5.6.6
Présente dans la bdd en 5.4.38

SPIP 3.1.0-alpha [21970] Test chez ovh sur un mutualisé, je ne sais si je suis sur ce cluster, mais de toute façon, ils doivent être tous pareil http://cluster015.ovh.net/infos Aucun prefix des tables particulier Les plugin était toujours agenda et Mini Calendrier *SQLite 3*++ 5.6.6 en mode prod = tables absente, mais présente dans une sauvegarde 5.5.22 en mode prod = tables absente, mais présente dans une sauvegarde 5.4.38 en mode prod = ok 5.3.29 en mode prod = tables absente, mais présente dans une sauvegarde 5.6.6 en mode dev = tables absente, mais présente dans une sauvegarde 5.5.22 en mode dev = tables absente, mais présente dans une sauvegarde 5.4.38 en mode dev = ok 5.3.29 en mode dev = tables absente, mais présente dans une sauvegarde *SQLite 2*++ 5.3.29 en mode prod = tables absente, mais présente dans une sauvegarde Il y a une erreur qui s'affiche dans l'espace privé dès que j'y rentre: Numero: 1, message: Array, squelette: ecrire/public/composer.php, boucle: calculer_select(){ sql_select(); }, ligne: 876 Par contre, je sais qu'elle est absente via ecrire/?exec=vertebres car quand j'essai de la lire via firefox, alors cela me sort: SQLiteManager: Error in opening file spip.sqlite - either the file is encrypted or corrupt Exception Name: NS_ERROR_FILE_CORRUPTED Exception Message: Component returned failure code: 0x8052000b (NS_ERROR_FILE_CORRUPTED) [mozIStorageService.openUnsharedDatabase] A savoir par contre que je peux parfaitement lire la sauvegarde via firefox 5.3.29 en mode dev = Installation problématique, cela me sort des: Warning: sqlite_query() [function.sqlite-query]: near "ORDER": syntax error in /ecrire/req/sqlite_generique.php on line 2703 Http 302 Si je clique sur le lien (il a un problème d'accent) l'installation se fait quand même, mais il y beaucoup de Warning... et toujours l'erreur dans le squelette Warning: sqlite_query() [function.sqlite-query]: near "ORDER": syntax error in /home/liendami/www/spip3/spip/ecrire/req/sqlite_generique.php on line 2703 Warning: sqlite_query() [function.sqlite-query]: no such column: auteurs.imessage in /home/liendami/www/spip3/spip/ecrire/req/sqlite_generique.php on line 2703 Après linstallation des plugins, si je vais dans exec=sauvegarder Warning: sqlite_query() [function.sqlite-query]: no such table: spip_evenements in /home/liendami/www/spip3/spip/ecrire/req/sqlite_generique.php on line 2703 Warning: sqlite_query() [function.sqlite-query]: no such table: spip_evenements_participants in /home/liendami/www/spip3/spip/ecrire/req/sqlite_generique.php on line 2703 Cela me fait bien la sauvegarde, mais d'autres warning apparaisent pendant Sinon, c'est identique au mode "production" J'ai refais des 2 tests en MySQL (php 5.6.6 et php 5.4.38) en mode dev pour vérifier si les sauvegardes étaient avec ou sans les tables du plugin (je n'avais pas fait cette vérif avant) Dans les deux cas, il y avait les tables dans les sauvegardes Alors qu'elles étaient: Absente dans la bdd en 5.6.6 Présente dans la bdd en 5.4.38
Poster

Yop
Jluc ma fait une remarque judicieuse sur l'IRC, comme quoi, je devais être plus précis concernant la méthodologie que j'ai utilisé pour mes tests :-)

Alors les tests (spip 2.1 / 3.0 / 3.1) ont été fait chez ovh sur un mutualisé
Pour chaque test, j'ai supprimer les fichiers et les tables, pour repartir à zéro (c'est pour cela qu'il me fallait du temps pour les tests... :-( )
Si bien que systématiquement le préfix des tables était toujours spip_xxx (faudrait voir avec un prefix "particulier"
J'ai toujours installer via l'interface privé de spip le plugin "agenda" et donc le necessite qui va avec (calendriermini dans le cas de spip 3)

Concernant les tests fait pour une instal en MySQL
Pour voir si les tables du plugin étaient bien présente après l'installation d'agenda, j'ai utiliser http://phpmyadmin.ovh.net

Pour les tests fait pour une instal en SQLite 3 ou 2
J'ai télécharger le fichier sur mon ordi qui était dans "config/base/
Et j'ai regarder ce qu'il contenait via firefox et l'extension "SQLite Manager" https://addons.mozilla.org/fr/firefox/addon/sqlite-manager

Concernant les sauvegardes, elles ont toutes été faite via exec=sauvegarder
Pour vérifier ce que contenait cette sauvegarde, je me suis servi de firefox et du l'extension https://addons.mozilla.org/fr/firefox/addon/sqlite-manager

Concernant le fait qu'un sauvegarde contient plus de tables, que la bdd elle même pierretux a émis l'hypothèse comme quoi, exec=sauvegarder ne lis pas la base mais le pipelines des tables principales

Yop Jluc ma fait une remarque judicieuse sur l'IRC, comme quoi, je devais être plus précis concernant la méthodologie que j'ai utilisé pour mes tests :-) Alors les tests (spip 2.1 / 3.0 / 3.1) ont été fait chez ovh sur un mutualisé Pour chaque test, j'ai supprimer les fichiers et les tables, pour repartir à zéro (c'est pour cela qu'il me fallait du temps pour les tests... :-( ) Si bien que systématiquement le préfix des tables était toujours spip_xxx (faudrait voir avec un prefix "particulier" J'ai toujours installer via l'interface privé de spip le plugin "agenda" et donc le necessite qui va avec (calendriermini dans le cas de spip 3) Concernant les tests fait pour une instal en MySQL Pour voir si les tables du plugin étaient bien présente après l'installation d'agenda, j'ai utiliser http://phpmyadmin.ovh.net Pour les tests fait pour une instal en SQLite 3 ou 2 J'ai télécharger le fichier sur mon ordi qui était dans "config/base/ Et j'ai regarder ce qu'il contenait via firefox et l'extension "SQLite Manager" https://addons.mozilla.org/fr/firefox/addon/sqlite-manager Concernant les sauvegardes, elles ont toutes été faite via exec=sauvegarder Pour vérifier ce que contenait cette sauvegarde, je me suis servi de firefox et du l'extension https://addons.mozilla.org/fr/firefox/addon/sqlite-manager Concernant le fait qu'un sauvegarde contient plus de tables, que la bdd elle même pierretux a émis l'hypothèse comme quoi, exec=sauvegarder ne lis pas la base mais le pipelines des tables principales
b_b commented 8 years ago
Owner

On passe sur la branche 3.1 puisque ça semble la concerner (en plus de la 3.0 et la 2.1).
Version cible mise à 3.1

On passe sur la branche 3.1 puisque ça semble la concerner (en plus de la 3.0 et la 2.1). **Version cible mise à 3.1**
Poster

Je viens de faire un test en SPIP 3.0.17 [21515] et php 5.6.6 cela semble être bon, les tables du plugin "agenda" sont bien présente.
Pour info, .ovhconfig contenait juste:
app.engine=php
app.engine.version=5.6

http.firewall=none
environment=production

Je viens de faire un test en SPIP 3.0.17 [21515] et php 5.6.6 cela semble être bon, les tables du plugin "agenda" sont bien présente. Pour info, .ovhconfig contenait juste: app.engine=php app.engine.version=5.6 http.firewall=none environment=production
Poster

SPIP 3.1.0-alpha [21978]
J'ai également fait des tests en modifiant .ovhconfig
J'ai fait des copies d'écran de ce qui me semble changeant dans "configure command"

php 5.3 (test1)
= ok (mais j'ai dû me reprendre à plusieurs reprise pour avoir la liste de tous les plugs compatibles)
app.engine=phpcgi
app.engine.version=5.3
http.firewall=none
environment=development

php 5.3 (test2)
= Bizarrement, cela à quand même fonctionné une fois, mais après, impossible d'avoir les tables d'agenda
app.engine=php
app.engine.version=5.3
http.firewall=none
environment=development

php 5.4 (test3)
= ok
app.engine=php
app.engine.version=5.4
http.firewall=none
environment=development

php 5.4 (test4)
= ok
app.engine=phpcgi
app.engine.version=5.4
http.firewall=none
environment=development

php 5.6 (test5)
= Les tables d'agenda ne s'installent pas
app.engine=php
app.engine.version=5.6
http.firewall=none
environment=development

php 5.6 (test6)
= ok
app.engine=phpcgi
app.engine.version=5.6
http.firewall=none
environment=development

SPIP 3.1.0-alpha [21978] J'ai également fait des tests en modifiant .ovhconfig J'ai fait des copies d'écran de ce qui me semble changeant dans "configure command" php 5.3 (test1) = ok (mais j'ai dû me reprendre à plusieurs reprise pour avoir la liste de tous les plugs compatibles) app.engine=phpcgi app.engine.version=5.3 http.firewall=none environment=development php 5.3 (test2) = Bizarrement, cela à quand même fonctionné une fois, mais après, impossible d'avoir les tables d'agenda app.engine=php app.engine.version=5.3 http.firewall=none environment=development php 5.4 (test3) = ok app.engine=php app.engine.version=5.4 http.firewall=none environment=development php 5.4 (test4) = ok app.engine=phpcgi app.engine.version=5.4 http.firewall=none environment=development php 5.6 (test5) = Les tables d'agenda ne s'installent pas app.engine=php app.engine.version=5.6 http.firewall=none environment=development php 5.6 (test6) = ok app.engine=phpcgi app.engine.version=5.6 http.firewall=none environment=development
b_b commented 8 years ago
Owner

ça commence vraiment à ressemble au bug de #3086 ...

ça commence vraiment à ressemble au bug de #3086 ...
Poster

Je viens de faire un test en SPIP 2.0.25 [21954]
Installation en Mysql

Php 5.4 = ok
app.engine=php
app.engine.version=5.4

http.firewall=none
environment=production

PHP 5.3 = Les tables du plugin agenda ne s'installent pas
app.engine=php
app.engine.version=5.3

http.firewall=none
environment=production

J'ai fait ce test, car b_b n'avait pas fait de report de https://core.spip.net/issues/3086 dans cette branche.
Le comportement semble identique à spip 3.1

Je viens de faire un test en SPIP 2.0.25 [21954] Installation en Mysql Php 5.4 = ok app.engine=php app.engine.version=5.4 http.firewall=none environment=production PHP 5.3 = Les tables du plugin agenda ne s'installent pas app.engine=php app.engine.version=5.3 http.firewall=none environment=production J'ai fait ce test, car b_b n'avait pas fait de report de https://core.spip.net/issues/3086 dans cette branche. Le comportement semble identique à spip 3.1

Je viens de aussi monter un SPIP 3.0.17 tout neuf sur un hébergement Perfox1 de chez OVH et j'ai exactement les mêmes soucis que Franck :

Si je reste en mode "optimisé OVH" (PHP-FPM) : installation des plugins agenda mais +les tables spip_evenements et spip_evenements_participants ne sont pas créées.+
C'est-à-dire : avec un .ovhconfig contenant :
app.engine=php
app.engine.version=5.5 ou 5.6
http.firewall=none
environment=production

J'ai aussi eu le souci (lors d'un deuxième test) avec les 4 plugins de la Newsletter (Mailshot, Mailsubscribers, newsletters et Facteur) : il manquait des tables à l'installation.

En repassant en mode "non-optimisé" d'OVH : aucun souci, toutes les tables s'installent bien !
soit :
app.engine=phpcgi
app.engine.version=5.5 ou 5.6
http.firewall=none
environment=development

Et information supplémentaire : cela m'était déjà arrivé en septembre 2014 (toujours sur une 3.0.x et hébergement identique), b_b et d'autres (merci à eux/elles) avaient essayé de voir pourquoi, sans trouver de cause, ni solution, sauf à réinstaller les tables manquantes via PHPMyAdmin... C'est donc un problème qui n'est pas nouveau (à priori).

Je viens de aussi monter un SPIP 3.0.17 tout neuf sur un hébergement Perfox1 de chez OVH et j'ai exactement les mêmes soucis que Franck : Si je reste en mode "optimisé OVH" (PHP-FPM) : installation des plugins agenda mais +les tables spip_evenements et spip_evenements_participants ne sont pas créées.+ C'est-à-dire : avec un .ovhconfig contenant : app.engine=php app.engine.version=5.5 ou 5.6 http.firewall=none environment=production J'ai aussi eu le souci (lors d'un deuxième test) avec les 4 plugins de la Newsletter (Mailshot, Mailsubscribers, newsletters et Facteur) : il manquait des tables à l'installation. *En repassant en mode "non-optimisé" d'OVH : aucun souci, toutes les tables s'installent bien !* soit : app.engine=phpcgi app.engine.version=5.5 ou 5.6 http.firewall=none environment=development Et information supplémentaire : cela m'était déjà arrivé en septembre 2014 (toujours sur une 3.0.x et hébergement identique), b_b et d'autres (merci à eux/elles) avaient essayé de voir pourquoi, sans trouver de cause, ni solution, sauf à réinstaller les tables manquantes via PHPMyAdmin... C'est donc un problème qui n'est pas nouveau (à priori).
Collaborator

Ma config local

PHP Version 5.2.17

System Darwin FTSR22998 12.6.0 Darwin Kernel Version 12.6.0: Wed Mar 18 16:23:48 PDT 2015; root:xnu-2050.48.19~1/RELEASE_X86_64 x86_64
Build Date Sep 18 2013 13:58:06
Configure Command './configure' '--with-mysql=/Applications/MAMP/Library' '--with-apxs2=/Applications/MAMP/Library/bin/apxs' '--with-gd' '--with-jpeg-dir=/Applications/MAMP/Library' '--with-png-dir=/Applications/MAMP/Library' '--with-zlib' '--with-freetype-dir=/Applications/MAMP/Library' '--prefix=/Applications/MAMP/bin/php/php5.2.17' '--exec-prefix=/Applications/MAMP/bin/php/php5.2.17' '--sysconfdir=/Applications/MAMP/bin/php/php5.2.17/conf' '--with-soap' '--with-config-file-path=/Applications/MAMP/bin/php/php5.2.17/conf' '--enable-track-vars' '--enable-bcmath' '--enable-ftp' '--enable-gd-native-ttf' '--with-bz2=/usr' '--with-ldap' '--with-mysqli=/Applications/MAMP/Library/bin/mysql_config' '--with-sqlite' '--with-ttf' '--with-t1lib=/Applications/MAMP/Library' '--enable-mbstring=all' '--with-curl=/Applications/MAMP/Library' '--enable-dbx' '--enable-sockets' '--enable-bcmath' '--with-imap=shared,/Applications/MAMP/Library/lib/imap-2007f' '--enable-soap' '--with-kerberos' '--enable-calendar' '--with-pgsql=shared,/Applications/MAMP/Library/pg' '--enable-dbase' '--enable-exif' '--with-libxml-dir=/Applications/MAMP/Library' '--with-gettext=shared,/Applications/MAMP/Library' '--with-xsl=/Applications/MAMP/Library' '--with-pdo-mysql=shared,/Applications/MAMP/Library' '--with-pdo-pgsql=shared,/Applications/MAMP/Library/pg' '--with-mcrypt=shared,/Applications/MAMP/Library' '--with-openssl' '--enable-zip' '--with-iconv=/Applications/MAMP/Library'
Server API Apache 2.0 Handler
Virtual Directory Support disabled
Configuration File (php.ini) Path /Applications/MAMP/bin/php/php5.2.17/conf
Loaded Configuration File /Applications/MAMP/bin/php/php5.2.17/conf/php.ini
Scan this dir for additional .ini files (none)
additional .ini files parsed (none)
PHP API 20041225
PHP Extension 20060613
Zend Extension 220060519
Debug Build no
Thread Safety disabled
Zend Memory Manager enabled
IPv6 Support enabled
Registered PHP Streams https, ftps, compress.zlib, compress.bzip2, php, file, data, http, ftp, zip
Registered Stream Socket Transports tcp, udp, unix, udg, ssl, sslv3, sslv2, tls
Registered Stream Filters zlib., bzip2., convert.iconv., string.rot13, string.toupper, string.tolower, string.strip_tags, convert., consumed

Mon test

  1. spip 3.1 svn 22109
  2. pas de plugins/auto mais le flux déclaré
  3. plugin tickets mis manuellement dans plugins
  4. j'active le plugin. Il se "préactive" en entendance les dépendances
  5. lorsque j'installe saisies, le plugin tickets peut bien s'activer
  6. mais les tables n'ont pas été installées
Ma config local PHP Version 5.2.17 System Darwin FTSR22998 12.6.0 Darwin Kernel Version 12.6.0: Wed Mar 18 16:23:48 PDT 2015; root:xnu-2050.48.19~1/RELEASE_X86_64 x86_64 Build Date Sep 18 2013 13:58:06 Configure Command './configure' '--with-mysql=/Applications/MAMP/Library' '--with-apxs2=/Applications/MAMP/Library/bin/apxs' '--with-gd' '--with-jpeg-dir=/Applications/MAMP/Library' '--with-png-dir=/Applications/MAMP/Library' '--with-zlib' '--with-freetype-dir=/Applications/MAMP/Library' '--prefix=/Applications/MAMP/bin/php/php5.2.17' '--exec-prefix=/Applications/MAMP/bin/php/php5.2.17' '--sysconfdir=/Applications/MAMP/bin/php/php5.2.17/conf' '--with-soap' '--with-config-file-path=/Applications/MAMP/bin/php/php5.2.17/conf' '--enable-track-vars' '--enable-bcmath' '--enable-ftp' '--enable-gd-native-ttf' '--with-bz2=/usr' '--with-ldap' '--with-mysqli=/Applications/MAMP/Library/bin/mysql_config' '--with-sqlite' '--with-ttf' '--with-t1lib=/Applications/MAMP/Library' '--enable-mbstring=all' '--with-curl=/Applications/MAMP/Library' '--enable-dbx' '--enable-sockets' '--enable-bcmath' '--with-imap=shared,/Applications/MAMP/Library/lib/imap-2007f' '--enable-soap' '--with-kerberos' '--enable-calendar' '--with-pgsql=shared,/Applications/MAMP/Library/pg' '--enable-dbase' '--enable-exif' '--with-libxml-dir=/Applications/MAMP/Library' '--with-gettext=shared,/Applications/MAMP/Library' '--with-xsl=/Applications/MAMP/Library' '--with-pdo-mysql=shared,/Applications/MAMP/Library' '--with-pdo-pgsql=shared,/Applications/MAMP/Library/pg' '--with-mcrypt=shared,/Applications/MAMP/Library' '--with-openssl' '--enable-zip' '--with-iconv=/Applications/MAMP/Library' Server API Apache 2.0 Handler Virtual Directory Support disabled Configuration File (php.ini) Path /Applications/MAMP/bin/php/php5.2.17/conf Loaded Configuration File /Applications/MAMP/bin/php/php5.2.17/conf/php.ini Scan this dir for additional .ini files (none) additional .ini files parsed (none) PHP API 20041225 PHP Extension 20060613 Zend Extension 220060519 Debug Build no Thread Safety disabled Zend Memory Manager enabled IPv6 Support enabled Registered PHP Streams https, ftps, compress.zlib, compress.bzip2, php, file, data, http, ftp, zip Registered Stream Socket Transports tcp, udp, unix, udg, ssl, sslv3, sslv2, tls Registered Stream Filters zlib.*, bzip2.*, convert.iconv.*, string.rot13, string.toupper, string.tolower, string.strip_tags, convert.*, consumed Mon test 1) spip 3.1 svn 22109 2) pas de plugins/auto mais le flux déclaré 3) plugin tickets mis manuellement dans plugins 4) j'active le plugin. Il se "préactive" en entendance les dépendances 5) lorsque j'installe saisies, le plugin tickets peut bien s'activer 6) mais les tables n'ont pas été installées
Collaborator

notons que sur la même install local en 3.0.17 je n'ai pas de souci.

notons que sur la même install local en 3.0.17 je n'ai pas de souci.
Owner
Devrait être corrigé chez OVH par https://core.spip.net/projects/spip/repository/revisions/22116
Poster

Je confirme, cela semble être bon en 3.1 chez ovh en php 5.6, je ferais plus de tests demain :-)
Par contre, faut faire le report dans toutes les versions de spip car même en 2.0 le problème est présent
Franck

Je confirme, cela semble être bon en 3.1 chez ovh en php 5.6, je ferais plus de tests demain :-) Par contre, faut faire le report dans toutes les versions de spip car même en 2.0 le problème est présent Franck
Owner

Correctif reporté en 3.0 (r22122 r22123 r22124), 2.1 (r22126) et 2.0 (r22127)

Statut changé à Fermé

Correctif reporté en 3.0 (r22122 r22123 r22124), 2.1 (r22126) et 2.0 (r22127) **Statut changé à Fermé**
Poster

Bon alors mauvaise nouvelle, après plusieurs tests, il semble que cela ne fonctionne pas systématiquement !
Parfois oui, parfois non, c'est aléatoire

Bon alors mauvaise nouvelle, après plusieurs tests, il semble que cela ne fonctionne pas systématiquement ! Parfois oui, parfois non, c'est aléatoire
Collaborator

pour ma part en svn 3.1 22135, toujours le même souci. Mais je me demande si on parle bien du même bug...

pour ma part en svn 3.1 22135, toujours le même souci. Mais je me demande si on parle bien du même bug...
Poster

Je le mets là, car il y a des chance que cela soit oublier :-D
Juste pour dire que cerdic avait proposer un patch sur l'irc qui semble vraiment résoudre le problème chez ovh cette fois, j'ai fais pas mal de tests en spip 2.0 / 2.1 / 3.0 / 3.1 et cela semble fonctionner systématiquement. Peut importe la version de php
A savoir que concernant spip 3.1 j'ai fait les tests à l'époque en SPIP 3.1.0-beta [22129]
Maieul, avait le problème en local et par contre, cela n'avait pas résolut le problème le concernant.
Eric l'avait aussi en local mais, je me souviens plus si le concernant c'était bon avec ce patch

Par contre, j'ai fait des tests uniquement avec le plug "agenda"
Il faudrait donc remplacer:
https://core.spip.net/projects/spip/repository/entry/spip/ecrire/inc/flock.php#L479
Par:
sleep($duree+1);

Pour le moment cerdic n'a pas fait le commit, c'est pour cela que je fais cet ajout, car sans quoi, il y a de grande chance d'un oubli. :-)

Je le mets là, car il y a des chance que cela soit oublier :-D Juste pour dire que cerdic avait proposer un patch sur l'irc qui semble vraiment résoudre le problème chez ovh cette fois, j'ai fais pas mal de tests en spip 2.0 / 2.1 / 3.0 / 3.1 et cela semble fonctionner systématiquement. Peut importe la version de php A savoir que concernant spip 3.1 j'ai fait les tests à l'époque en SPIP 3.1.0-beta [22129] Maieul, avait le problème en local et par contre, cela n'avait pas résolut le problème le concernant. Eric l'avait aussi en local mais, je me souviens plus si le concernant c'était bon avec ce patch Par contre, j'ai fait des tests uniquement avec le plug "agenda" Il faudrait donc remplacer: https://core.spip.net/projects/spip/repository/entry/spip/ecrire/inc/flock.php#L479 Par: `sleep($duree+1);` Pour le moment cerdic n'a pas fait le commit, c'est pour cela que je fais cet ajout, car sans quoi, il y a de grande chance d'un oubli. :-)
b_b commented 8 years ago
Owner

Bon, j'ai une mauvaise nouvelle, je confirme ce qu'annonce Franck.

Installation de SPIP 3.1.0-beta [22198] sur un mutu ovh avec la config suivante :

app.engine=php
app.engine.version=5.4
http.firewall=none
environment=production

Après l'installation du plugin Agenda, j'ai l'erreur suivante quand je tente d'accéder à l'exec des événements :

Erreur SQL HY000 / 1
no such table: spip_evenements
SELECT evenements.date_debut FROM spip_evenements AS 'evenements' ORDER BY evenements.date_debut LIMIT 0,1

La bonne nouvelle, c'est que si on ajoute +1 à la $duree comme le suggère Franck, ça fixe le bug. L'explication pourrait être que comme on fait un sleep de la durée de la fréquence d'invalidation du cache, et bien on retombe dedans. Non ?

Bon, j'ai une mauvaise nouvelle, je confirme ce qu'annonce Franck. Installation de SPIP 3.1.0-beta [22198] sur un mutu ovh avec la config suivante : <pre> app.engine=php app.engine.version=5.4 http.firewall=none environment=production </pre> Après l'installation du plugin Agenda, j'ai l'erreur suivante quand je tente d'accéder à l'exec des événements : Erreur SQL HY000 / 1 no such table: spip_evenements SELECT evenements.date_debut FROM spip_evenements AS 'evenements' ORDER BY evenements.date_debut LIMIT 0,1 La bonne nouvelle, c'est que si on ajoute +1 à la $duree comme le suggère Franck, ça fixe le bug. L'explication pourrait être que comme on fait un sleep de la durée de la fréquence d'invalidation du cache, et bien on retombe dedans. Non ?
b_b commented 8 years ago
Owner

Et hop, +1 intégré dans la 3.1 par r22201. J'attends vos avis pour faire le report en 3.0, 2.1 et 2.0.
Statut changé à En cours

Et hop, +1 intégré dans la 3.1 par r22201. J'attends vos avis pour faire le report en 3.0, 2.1 et 2.0. **Statut changé à En cours**
b_b commented 8 years ago
Owner

Qui ne dit mot consent ? J'envoie le report dans la soirée...

Qui ne dit mot consent ? J'envoie le report dans la soirée...
b_b commented 8 years ago
Owner

Appliqué par commit r22208.
Statut changé à Fermé

Appliqué par commit r22208. **Statut changé à Fermé**
b_b commented 5 years ago
Owner

Je reporte ici le commentaire de fil sur #3523 que j'ai effacé par erreur (désolé) :

Si la valeur est 300 (comme j'avais chez moi suite à une installation standard Debian) il faut absolument trouver un moyen d'informer le webmestre que ça ne va pas, et se contenter de partir en timeout (301s c'est très long ! et le bug est vachement dur à traquer.)

Donc je dirais : avant d'envoyer le sleep(), ajouter un message dans les alertes, et dans les logs. Par ailleurs peut-être limiter le sleep() à 10s max ?

Auquel je répondais :

Voilà déjà le patch pour le log :)

Qu'entends-tu par "ajouter un message dans les alertes" ? Afficher un message dans le bloc de retour de l'interface des plugins ? Ça risque d'être chaud de s'insérer là dedans, et en plus ça se passe dans inc/plugin ou svp suivant le type d'installation.

Par ailleurs peut-être limiter le sleep() à 10s max ?

J'ai un doute sur ce point, car cela annulerait le correctif et pourrait générer des erreurs d'installation des tables de plugin par exemple. Qu'est-ce qui est pire/mieux : attendre 300s et avoir un truc fonctionnel ou ne pas attendre et avoir des erreurs d'installation de plugin ?
Statut changé à En cours

Je reporte ici le commentaire de fil sur #3523 que j'ai effacé par erreur (désolé) : > Si la valeur est 300 (comme j'avais chez moi suite à une installation standard Debian) il faut absolument trouver un moyen d'informer le webmestre que ça ne va pas, et se contenter de partir en timeout (301s c'est très long ! et le bug est vachement dur à traquer.) > > Donc je dirais : avant d'envoyer le sleep(), ajouter un message dans les alertes, et dans les logs. Par ailleurs peut-être limiter le sleep() à 10s max ? Auquel je répondais : Voilà déjà le patch pour le log :) Qu'entends-tu par "ajouter un message dans les alertes" ? Afficher un message dans le bloc de retour de l'interface des plugins ? Ça risque d'être chaud de s'insérer là dedans, et en plus ça se passe dans inc/plugin ou svp suivant le type d'installation. > Par ailleurs peut-être limiter le sleep() à 10s max ? J'ai un doute sur ce point, car cela annulerait le correctif et pourrait générer des erreurs d'installation des tables de plugin par exemple. Qu'est-ce qui est pire/mieux : attendre 300s et avoir un truc fonctionnel ou ne pas attendre et avoir des erreurs d'installation de plugin ? **Statut changé à En cours**
Fil commented 5 years ago
Owner

"attendre 300s et avoir un truc fonctionnel" => non chez moi ça finissait en timeout sur varnish, et ça ne donnait rien de fonctionnel jamais : en gros la page admin_plugins était morte.

Mais ok pour ne pas causer d'erreur en raccourcissant le temps.

Pour ce qui est d'informer la webmestre il y a une API (avertir_auteurs je crois ?) que personne n'utilise :-)
Mais spip_log serait déjà pas mal

"attendre 300s et avoir un truc fonctionnel" => non chez moi ça finissait en timeout sur varnish, et ça ne donnait rien de fonctionnel *jamais* : en gros la page admin_plugins était morte. Mais ok pour ne pas causer d'erreur en raccourcissant le temps. Pour ce qui est d'informer la webmestre il y a une API (avertir_auteurs je crois ?) que personne n'utilise :-) Mais spip_log serait déjà pas mal
b_b commented 5 years ago
Owner

Et hop, le log est commité dans le trunk et reporté en 3.2 & 3.1, je ferme le ticket, hésitez pas à commenter si vous pensez que c'est améliorable.
Statut changé à Fermé

Et hop, le log est commité dans le trunk et reporté en 3.2 & 3.1, je ferme le ticket, hésitez pas à commenter si vous pensez que c'est améliorable. **Statut changé à Fermé**
Owner

Ah bah je viens de me rendre compte que c’est aussi le comportement de Mamp Pro par défaut lorsqu’on active l’opcache.
Dans le php.ini il y a opcache.revalidate_freq=60.

Le truc c’est que je suis pas certain que le log «Probleme de configuration ...» convienne vraiment.
Cette configuration de l’opcache a l’air courante quand même.

Je me demande si on ne pourrait pas plutôt lancer l’invalidation des fichiers modifiés. J’imagine que ce sont tous les fichiers tmp/cache/charger_*.php qui viennent d’être générés.
Ça pourrait peut être être fait même dans la fonction clear_path_cache() ou à la place de l’appel à spip_attend_invalidation_opcode_cache(), en utilisant notre fonction spip_clear_opcode_cache().

Quelque chose comme

	// invalidation du cache opcode
	spip_clear_opcode_cache(realpath(_CACHE_PLUGINS_PATH));
	spip_clear_opcode_cache(realpath(_CACHE_PLUGINS_OPT));
	spip_clear_opcode_cache(realpath(_CACHE_PLUGINS_FCT));
	spip_clear_opcode_cache(realpath(_CACHE_PIPELINES));
Ah bah je viens de me rendre compte que c’est aussi le comportement de Mamp Pro par défaut lorsqu’on active l’opcache. Dans le php.ini il y a `opcache.revalidate_freq=60`. Le truc c’est que je suis pas certain que le log «Probleme de configuration ...» convienne vraiment. Cette configuration de l’opcache a l’air courante quand même. Je me demande si on ne pourrait pas plutôt lancer l’invalidation des fichiers modifiés. J’imagine que ce sont tous les fichiers tmp/cache/charger_*.php qui viennent d’être générés. Ça pourrait peut être être fait même dans la fonction `clear_path_cache()` ou à la place de l’appel à `spip_attend_invalidation_opcode_cache()`, en utilisant notre fonction `spip_clear_opcode_cache()`. Quelque chose comme <pre> // invalidation du cache opcode spip_clear_opcode_cache(realpath(_CACHE_PLUGINS_PATH)); spip_clear_opcode_cache(realpath(_CACHE_PLUGINS_OPT)); spip_clear_opcode_cache(realpath(_CACHE_PLUGINS_FCT)); spip_clear_opcode_cache(realpath(_CACHE_PIPELINES)); </pre>
b_b commented 5 years ago
Owner

Bonne idée, à tester :)

Bonne idée, à tester :)
Owner

Bon, en fait mon patch est incorrect.

En fait, après quelques tests, et comme le souligne fa_b également, si je remets ma conf par défaut de Mamp (opcache.revalidate_freq=60), ma page admin_plugin est lente.
Si j’enlève l’appel à spip_attend_invalidation_opcode_cache() simplement, la page redevient rapide… ET l’installation / désinstallation de plugins fonctionne parfaitement,
notamment car lorsqu’on écrit un fichier PHP, on invalide le cache opcode dans la foulée dans ecrire_fichier(). C’est ce que fait en doublon le patch du dessus, qui est donc inutile.

Donc on est plusieurs à avoir un problème avec spip_attend_invalidation_opcode_cache() qui plombe la page des plugins à tord dans nos configurations.
Mais je ne vois absolument pas ce qui distingue notre configuration (qui fonctionne très bien sans) des configurations qui sont ou étaient foireuses réellement.

Bon, en fait mon patch est incorrect. En fait, après quelques tests, et comme le souligne fa_b également, si je remets ma conf par défaut de Mamp (`opcache.revalidate_freq=60`), ma page admin_plugin est lente. Si j’enlève l’appel à `spip_attend_invalidation_opcode_cache()` simplement, la page redevient rapide… ET l’installation / désinstallation de plugins fonctionne parfaitement, notamment car lorsqu’on écrit un fichier PHP, on invalide le cache opcode dans la foulée dans `ecrire_fichier()`. C’est ce que fait en doublon le patch du dessus, qui est donc inutile. Donc on est plusieurs à avoir un problème avec `spip_attend_invalidation_opcode_cache()` qui plombe la page des plugins à tord dans nos configurations. Mais je ne vois absolument pas ce qui distingue notre configuration (qui fonctionne très bien sans) des configurations qui sont ou étaient foireuses réellement.
b_b commented 5 years ago
Owner

Ça vaudrait peut-être le coup d'ouvrir le ticket non ?

Ça vaudrait peut-être le coup d'ouvrir le ticket non ?
Sign in to join this conversation.
No Milestone
No project
No Assignees
7 Participants
Notifications
Due Date

No due date set.

Dependencies

This issue currently doesn't have any dependencies.

Loading…
There is no content yet.