No Branch/Tag Specified
1.8
1.9.1
1.9.2
2.0
2.1
3.0
3.1
3.2
4.0
4.1
4.2
boutons-danger
coquille_doc
debug_ecrire_fichier
dev-sortable
dev/autoloader
dev/hasard_fixe
dev/instituer_ergo
dev/issue_5447_exporter_csv
dev_infos_image
fix/valider_url_distante
fix_issue_5454
fix_modifier_login
issue_4101
issue_4678
issue_4705
issue_4717
issue_4836
issue_4946
issue_5258
issue_5344
issue_5427_bis
master
v1.8.3+b
v1.9.1+i
v1.9.2+f
v1.9.2+g
v1.9.2+h
v1.9.2+i
v1.9.2+j
v1.9.2+k
v1.9.2+m
v1.9.2+n
v1.9.2+o
v1.9.2+p
v2.0.0
v2.0.1
v2.0.10
v2.0.11
v2.0.12
v2.0.13
v2.0.14
v2.0.15
v2.0.16
v2.0.17
v2.0.18
v2.0.19
v2.0.2
v2.0.20
v2.0.21
v2.0.22
v2.0.23
v2.0.24
v2.0.25
v2.0.26
v2.0.3
v2.0.5
v2.0.6
v2.0.7
v2.0.8
v2.0.9
v2.1.0
v2.1.1
v2.1.10
v2.1.11
v2.1.12
v2.1.13
v2.1.14
v2.1.15
v2.1.16
v2.1.17
v2.1.18
v2.1.19
v2.1.2
v2.1.20
v2.1.21
v2.1.22
v2.1.23
v2.1.24
v2.1.25
v2.1.26
v2.1.27
v2.1.28
v2.1.29
v2.1.3
v2.1.30
v2.1.4
v2.1.5
v2.1.6
v2.1.7
v2.1.8
v2.1.9
v3.0.0
v3.0.0-alpha.1
v3.0.0-beta
v3.0.0-beta.2
v3.0.0-rc
v3.0.1
v3.0.10
v3.0.11
v3.0.12
v3.0.13
v3.0.14
v3.0.15
v3.0.16
v3.0.17
v3.0.18
v3.0.19
v3.0.2
v3.0.20
v3.0.21
v3.0.22
v3.0.23
v3.0.24
v3.0.25
v3.0.26
v3.0.27
v3.0.28
v3.0.3
v3.0.4
v3.0.5
v3.0.6
v3.0.7
v3.0.8
v3.0.9
v3.1.0
v3.1.0-alpha
v3.1.0-beta
v3.1.0-rc
v3.1.0-rc.2
v3.1.0-rc.3
v3.1.1
v3.1.10
v3.1.11
v3.1.12
v3.1.13
v3.1.14
v3.1.15
v3.1.2
v3.1.3
v3.1.4
v3.1.5
v3.1.6
v3.1.7
v3.1.8
v3.1.9
v3.2-alpha.1
v3.2.0
v3.2.0-alpha.1
v3.2.0-beta
v3.2.0-beta.2
v3.2.0-beta.3
v3.2.1
v3.2.10
v3.2.11
v3.2.12
v3.2.13
v3.2.14
v3.2.15
v3.2.16
v3.2.17
v3.2.2
v3.2.3
v3.2.4
v3.2.5
v3.2.6
v3.2.7
v3.2.8
v3.2.9
v4.0.0
v4.0.0-alpha
v4.0.0-beta
v4.0.1
v4.0.2
v4.0.3
v4.0.4
v4.0.5
v4.0.6
v4.0.7
v4.0.8
v4.0.9
v4.1.0
v4.1.0-alpha
v4.1.0-beta
v4.1.0-rc
v4.1.1
v4.1.2
v4.1.3
v4.1.4
v4.1.5
v4.1.6
v4.1.7
v4.2.0-alpha
v4.2.0-alpha2
Labels
Amélioration, nouvelle fonctionnalité APIs authentification base de données bug
Ca ne fonctionne pas code généré compilo css divers documentation doublon
Ce ticket est un doublon ergonomie espace privé filtres et balises formulaires Inscription installation invalide
Ticket invalide javascript langues LDAP plugin PostgreSQL refusé
Ignoré, c'est comme Ca... sécurité traduction
Apply labels
Clear labels
accessibilité
amélioration
Amélioration, nouvelle fonctionnalité APIs authentification base de données bug
Ca ne fonctionne pas code généré compilo css divers documentation doublon
Ce ticket est un doublon ergonomie espace privé filtres et balises formulaires Inscription installation invalide
Ticket invalide javascript langues LDAP plugin PostgreSQL refusé
Ignoré, c'est comme Ca... sécurité traduction
No Label
accessibilité
amélioration
APIs
authentification
base de données
bug
code généré
compilo
css
divers
documentation
doublon
ergonomie
espace privé
filtres et balises
formulaires
Inscription
installation
invalide
javascript
langues
LDAP
plugin
PostgreSQL
refusé
sécurité
traduction
Milestone
Set milestone
Clear milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Assign users
Clear assignees
No Assignees
7 Participants
Notifications
Due Date
The due date is invalid or out of range. Please use the format 'yyyy-mm-dd'.
No due date set.
Dependencies
This issue currently doesn't have any dependencies.
Reference in new issue
There is no content yet.
Delete Branch '%!s(MISSING)'
Deleting a branch is permanent. It CANNOT be undone. Continue?
No
Yes
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 !
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
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"
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...
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]
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
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
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
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
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
ça commence vraiment à ressemble au bug de #3086 ...
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).
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
notons que sur la même install local en 3.0.17 je n'ai pas de souci.
Devrait être corrigé chez OVH par https://core.spip.net/projects/spip/repository/revisions/22116
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
Correctif reporté en 3.0 (r22122 r22123 r22124), 2.1 (r22126) et 2.0 (r22127)
Statut changé à Fermé
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
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...
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. :-)
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 :
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 ?
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
Qui ne dit mot consent ? J'envoie le report dans la soirée...
Appliqué par commit r22208.
Statut changé à Fermé
Je reporte ici le commentaire de fil sur #3523 que j'ai effacé par erreur (désolé) :
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.
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
"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
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é
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 fonctionspip_clear_opcode_cache()
.Quelque chose comme
Bonne idée, à tester :)
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.
Ça vaudrait peut-être le coup d'ouvrir le ticket non ?