Submitted by eloriaux on
Comment le processus d'update.php fonctionne-t-il en interne ?
Avant tout, si vous connaissez un quelconque document important qui pourrait m'aider pour ce problème, je suis tout prêt à lire le f...antastique manuel, j'ai juste besoin du lien.
Si pas...
Ce post suit bien entendu mon précédent (merci Lapalisse) mais j'ai sans doute posté des détails qui ont jeté la confusion.
Autant présenter le problème simplement donc : je suis supposé avoir des updates database à appliquer si j'en crois le status report mais mon update.php est "gelé" au moment du "Starting updates" et je ne sais pas comment m'en sortir pour en serait-ce que trouver la raison du pourquoi.
Est-ce que quelqu'un peut me dire comment fonctionne update.php ?
Je veux dire... Franchement je me pose des questions aussi simples que :
"Où sont stockées les updates de databases" (je suppose que ces mises à jours sont des fichiers contenant des commandes sql du genre CREATE / ALTER / DROP...) ?
Comment update.php sait-il au départ que de telles mises à jour sont nécessaires ?
S'agit-il du contenu d'une table (laquelle contient alors peut-être des crasses) ou bien la présence de fichiers dans certains répertoires ?
Je suis actuellement aussi gelé que mon update.php car je n'ai pas connaissance d'un moyen (log ?) qui me permettrait de savoir ce qui coince.
Je me doute que normalement le processus de update.php devrait se terminer par un rapport mais je n'arrive bien entendu pas jusque là et n'ai donc pas le bonheur de voir ne serait-ce que des messages d'erreur.
J'ai aussi noté que pendant l'update : j'ai les accès suivant sur ces fichiers / répertoires
sites/default/setting.php is r-- r-- r--
site/default/ is r-x r-x r-x
Quand bien même je remets w pour l'owner après l'essai, l'essai suivant de update.php le remet -w
Est-ce normal ?
Pour rappel, si vous connaissez la partie de la doc qui devrait me permettre de tout comprendre, ce serait déjà un pas en avant.
Merci d'avance,
Eric
Je pense qu'il se pourrait
Permalien Soumis par eloriaux le 20 Octobre, 2015 - 16:22
Je pense qu'il se pourrait fort bien que mon problème de Drupal soit causé par des tables devenues énormes par manque de maintenance de ma part.
Par exemple, des tas de users jamais validés qui trainent... Inscrits par des robots de spam, manifestement.
Ils ne sont pas validés, mais à mon avis ils encombrent. Et si jamais un upgrade de table est nécessaire sur une table dont la taille dépend du nombre d'utilisateurs alors forcément je n'y arriverai jamais.
C'est sans doute la première chose à faire.
Vous en pensez quoi ?
Les updates sont des les
Permalien Soumis par Mixalis44 le 20 Octobre, 2015 - 17:14
Les updates sont des les .install des modules.
Elles ont un numéro de version 7100,7101,7102 inscrit sur le hook (ex: mymodule_update_7125())
Quand la MàJ est réussi, Drupal met à jour l'entrée du hook ( dans la table system) en précisent le numéro de l'update actuel. Pour ne pas repasser X fois.
La table system contient plein de chose mais surtout les infos générales des modules, emplacement, activé, version update ...
Le systeme de MàJ BDD est utilisé pour les mises à jour de version des modules.
Lorsqu'un module est installé et activé, Drupal va chercher le numéro de version le plus élévé et le met dans sa table.
C'est pour interdire la mise à niveau d'un module qui s'installe car il doit etre propre pour l'installation.
Si il y à un saut dans la numérotation 7102 puis 7121 et que la 7121 est passé, Drupal ne passera jamais sur les éventuelles futures 7103-7104-7105...
Pour pouvoir revenir en arrière il faut aller dans la table system, trouver la ligne du module et modifier l'entrée du numéro de MàJ à la main.
Merci beaucoup pour ces infos
Permalien Soumis par eloriaux le 21 Octobre, 2015 - 13:08
Merci beaucoup pour ces infos.
Actuellement je suis en train de nettoyer mes user "fantômes" (ceux faits par des spammers mais jamais validés)...
En gros j'avais près de 200000 (400*50 pages sur la page d'admin).
Bien entendu j'ai changé le module pour afficher par 500 users à la fois à la place de 50.
Je pourrais passer une requête MySQL sur la base users mais bon je préfère laisser les modules drupal faire ça proprement...
J'ai déjà assez de b... :)
NB: est-il besoin de le dire... Il s'agit d'un site dont je m'étais fort occupé à un moment... Et puis j'ai laissé aller les choses... Bref, de la maintenance à faire avant tout... Et ensuite j'imagine qu'une réorganisation par backup/reload des dbs ne sera pas du luxe ? ;)
Ce qui m'inquiète c'est que
Permalien Soumis par eloriaux le 23 Octobre, 2015 - 12:42
Ce qui m'inquiète c'est que quand je tente de faire un browse sur la table system vie phpmyadmin...
phpadmin ne me montre rien là où il devrait afficher mes rows.
D'un autre côté je fais ça en même temps que j'ai lancé une nouvelle tentative d'update.php ... Il y a un peu plus de deux heures.
Alors la question est : est-ce normal ?
Je n'ai pas d'accès ssh ici mais ce soit je comptais dumper la table, voir ce qu'il y a dedans si j'y arrive...
Faut-il la reloader ? Eventuellement la nettoyer avant ? Si oui, selon quel critère supprimer des rows ?
D'un autre côté, si la table
Permalien Soumis par eloriaux le 23 Octobre, 2015 - 12:54
D'un autre côté, si la table system n'est plus fonctionnelle, comment update.php a-t-il pu me donner une liste de numéros d'updates à faire ? L'update.php semble toujours tourner et bien entendu je le laisse faire même si je ne suis pas spécialement optimiste à ce stade...
Question subsidiaire :
Permalien Soumis par eloriaux le 23 Octobre, 2015 - 13:54
Question subsidiaire :
Y a-t-il un endroit (en espérant que ce ne soit pas dans table system si jamais elle est bousillée) qui contienne le niveau d'update chaque database ?
Là où je veux en venir c'est que dans le pire des cas bien entendu je referais une installation complète d'un drupal et je m'efforcerait de migrer mes données avant basculement.
Il est clair que certaines données sont plus importantes que d'autres en fonction de l'usage que je fais de mon site.
Il y a des choses dont je me fiche complètement, d'autres sont cruxiales.
En admettant que je réinstalle un drupal from scratch il faudrait bien entendu un coup de bol extraordinaire pour que mes databases à migrer de l'ancien site soient au bon niveau.
Je suppose donc qu'il me faudrait loader un backup puis mettre à niveau manuellement tel base depuis le niveau n vers le niveau m. Comment fait-on ça ?