grosse galère mise à jour 6.13

Information importante

En raison d'un grand nombre d'inscriptions de spammers sur notre site, polluant sans relache notre forum, nous suspendons la création de compte via le formulaire de "sign up".

Il est néanmoins toujours possible de devenir adhérent•e en faisant la demande sur cette page, rubrique "Inscription" : https://www.drupal.fr/contact


De plus, le forum est désormais "interdit en écriture". Il n'est plus autorisé d'y écrire un sujet/billet/commentaire.

Pour contacter la communauté, merci de rejoindre le slack "drupalfrance".

Si vous voulez contacter le bureau de l'association, utilisez le formulaire disponible ici, ou envoyez-nous un DM sur twitter.

Bonjour,
J'ai commencé ce matin la mise à jour (sur un multisite) de 6.12 à 6.13, je viens d'y passer 12 h…
Ça plante au moment de lancer l'update qui reste bloqué sur "run update"
J'ai déjà tout uploadé 3 fois en rechargeant une fois l'archive (avec l'install de la vf à la main répertoire par répertoire, c'est laborieux).
Rien à faire je reste planté au même endroit, ensuite plus rien n'est accessible, il ne trouve même pas la page qui annonce le site hors ligne…
Avez-vous eu ce genre de problème ?
Je commence à flipper grave, mon client a prévu une petite fête demain soir pour présenter son site dont il est très fier :***-(

Version de Drupal : 

Tu n'as pas des logs dans ton apache qui t'indiquerais où ça coince ?

EDIT: tu dois avoir un problème autre part, je viens de lancer l'update sur une 6.12 pour voir, les seules mise à jour effectuées sont :

Update #6049

    * DROP INDEX {url_alias}_src_idx
    * CREATE INDEX {url_alias}_src_language_idx ON {url_alias} (src, language)

Update #6050

    * No queries

Update #6051

    * ALTER TABLE {users} ADD COLUMN signature_format smallint NOT NULL default 0

FireFTP m'a mis un bordel gigantesque avec des bouts de fichiers dispersés n'importe où…, j'ai tout rechargé avec dream le ftp est plus chiant mais ça permet d'avoir des logs : j'ai des erreurs sur tous les fichiers settings.php en fait les répertoires de sites et les fichiers n'avaient plus les bonnes autorisations.
J'avais aussi viré une base et son utilisateur, et j'avais une erreur au redémarrage d'apache, ça commençait à faire beaucoup !
l'update #6051 est faite pas vu passer la #6049
mais ça tourne et j'ai pas d'erreur affichée.
Merci de ton coup de main, je vais pouvoir aller siffler le champagne :0)
enfin quand j'aurai recoché les ±5000 modules désactivés ;-)

Je n'ai pas l'impression d'avoir apporter grand chose mais bon champagne tout de même :)

Tu n'as pas un accès SSH sur tes machines de prod ? C'est tout de même plus simple que par FTP. Perso je suis devenu un fan des sources Drupal sur subversion. Je modifie et je teste chez moi, je commite quant c'est bon, et j'ai plus qu'à faire un update sur le serveur et c'est 100% de réussite !

Ce que tu m'as dit m'a permis de tomber sur une erreur apache. J'ai un accès SSH, mais j'ai du faire une allergie, je suis pas du tout à l'aise avec ça (je suis graphiste) mais je me soigne ;-)
Tu connais un bon bouquin ou un site pour un newbee en SSH ?
De mon côté je suis sur mac et je préfère avoir 2 x mes sites et mes bases pour tester sur le même serveur, ça évite les problèmes de plates-formes.

Ce que tu m'as dit m'a permis de tomber sur une erreur apache.
Ah ok, j'ai un peu aidé alors :)

alergie à SSH
La ligne de commande, c'est comme le Durian, tu ne peux pas le sentir jusqu'à ce que tu passes l'appréhension, et là, tu deviens un véritable fanatique :)

Tu veux dire un bouquin sur l'utilisation de Linux (car j'imagine que c'est le système d'exploitation de ton serveur). Tu as un très bon "Linux pour les nulls" qui fonctionne plutôt bien. Ceci étant dit, c'est déjà aller très loin, tu n'as pas besoin de connaître beaucoup de commandes, 10 tout au plus, pour t'en sortie dans 99% des cas.

De mon côté je suis sur mac et je préfère avoir 2 x mes sites et mes bases pour tester sur le même serveur, ça évite les problèmes de plates-formes.
L'un n'empêche pas l'autre. Le principe dont je parle est d'avoir un serveur central pour gérer les sources avec un gestionnaire de version comme subversion, puis toi et ta machine d'un côté, et ton serveur cible de l'autre.
Lors de la réalisation de ton serveur, tu stoques (ce que l'on appelle un "commit") tes sources sur le gestionnaire de version. Tu bénéfices du coup de plein de sécurités comme la possibilité de récupérer tes données en cas de crash de ta machine, revenir en arrière sur la version d'il y a une semaine, etc.
Lorsque tu veux tester sur ton serveur de production, il suffit de récupérer les sources à partir du gestionnaire de version la première fois, puis de faire un simple "svn up" les fois suivantes.

Typiquement dans le cas de ce qui t'a donné des cheveux blancs cette nuit, ce système montre sa force. Tu peux ainsi mettre à jour la nouvelle version de drupal en local (perso j'utilise des patchs pour cela, beaucoup plus sur) et tester en profondeur sur TA machine. Lorsque la version fonctionne au poile, tu commites les sources sur le gestionnaire de version. Ensuite tu n'as pas de FTP ou quoi que ce soit à refaire sur le serveur, tu vas simplement à la racine de drupal et tu tapes "svn up". Et zouh, tout est recopié à l'identique avec la versions que tu as testée. Un redémarrage du serveur apache pour vider les caches APC et il ne reste plus qu'à faire l'update de la base.

Je n'ai pas écrit de tuto qui explique la méthode à fond mais j'ai ceci qui l'approche par petit bouts :
- La mise en place d'un serveur Subversion (un gestionnaire de version simple et efficace) : http://artisan.karma-lab.net/node/29
- L'utilisation de subversion en ligne de commande (import initiaux, checkout initiaux, commit, etc.) : http://arnumeral.fr/node/96
- Mettre à jour un drupal en ligne de commande avec des patchs : http://arnumeral.fr/node/19