J'ai un problème lors de l'utilisation du "Gestionnaire de mise à jour" sur l'interface graphique. Certains répertoires sont verrouillés php-cgi.exeet le remplacement des répertoires d'origine par les nouveaux téléchargés (qui sont plus récents) échoue.
Mais je dois dire que ce n'est pas un problème d'autorisation, car les modules peuvent s'installés via « Installer à partir d' une URL » sur /admin/modules/install, et le travail sans problème.
Prenons un exemple:
Page des mises à jour disponibles (
/admin/reports/updates/update):
Maintenant, je vérifie le module Select (ou autre) à mettre à jour ( peu importe le module que je choisis , les résultats sont les mêmes !! c'est donc juste un exemple).
J'ai cliqué sur le bouton "Télécharger ces mises à jour" .
- OK, l'instance mise à jour du module est téléchargée sans problème:
" Mises à jour téléchargées avec succès ":
- Maintenant, je clique sur Continuer .
- Voici l'erreur. Le résultat:
"La mise à jour a échoué! Consultez le journal ci-dessous pour plus d'informations.
Select_or_other- Erreur d'installation / mise à jour
- Échec du transfert de fichiers, raison: impossible de copier
D:/Projects/web/drupal-7/tmp/update-extraction-6d8993ac/select_or_other/LICENSE.txtvers/Projects/web/drupal-7/htdocs/sites/all/modules/select_or_other/LICENSE.txt. "
- OK, je commence à essayer d'inspecter les raisons possibles.
- Voici ce que ma structure de répertoire Drupal ressemble à :
. J'ai défini ../tmppour être le répertoire temporaire (en/admin/config/media/file-system), les fichiers Drupal sont dedanshtdocs. C'est correct, car je peux installer des modules via l'interface graphique, comme je l'ai mentionné ci-dessus. - Lorsque j'essaie d'entrer dans le
htdocs/sites/all/modules/select_or_otherrépertoire, je ne peux pas, car j'obtiens un "Accès refusé dans le fichier......sites/all/modules/select_or_other!" lors de l' ouverture de Total Commander, et «n'est...sites/all/modules/select_or_otherpas accessible L' accès est refusé. » lors de l' ouverture dans l' Explorateur Windows:
,
- OK, je clique avec le bouton droit sur le dossier et ouvre Unlocker via son assistant dans le menu contextuel. Il dit que ce répertoire est verrouillé par
php-cgi.exe:
je clique sur "Tout déverrouiller", et le dossier peut maintenant être supprimé de lui-même (car il n'est plus verrouillé par php-cgi.exe), donc il suffit - Je peux trouver le répertoire du module select_or_other mis à jour dans
tmp:
- donc je dois le déplacer manuellement dans le
sites/all/modulesrépertoire.
- Voici ce que ma structure de répertoire Drupal ressemble à :
Quelles peuvent être les raisons possibles du blocage du répertoire par php-cgi.exe? (Peut-être que Windows Cache Extension 1.1 pour PHP 5.3 est installé via Web Platform Installer? Mais si oui, pourquoi est-ce que par exemple la suppression d'images ou similaire via l'interface graphique fonctionne correctement?)
Que puis-je faire pour éviter ce problème et laisser "Mettre à jour" gestionnaire "travail?
drush up -y, je rencontre le même problème: je dois déverrouiller ces fichiers et répertoires avec Unlocker pour le faire fonctionner, sinon je reçois le message d'erreur que ceux-ci les répertoires ne peuvent pas être écrits / supprimés et le processus de mise à jour est interrompu. Si j'utilise Unlocker AVANT d'exécuter ce processus, la mise à jour réussit.Réponses:
ce n'est pas sécurisé qui permet d'écrire des fichiers à partir de l'interface utilisateur Drupal pour la mise à jour des modules, au lieu d'utiliser ftp.
mais si vous le souhaitez, accédez au panneau plesk d'hébergement, explorez le répertoire httpdocs, cliquez avec le bouton droit de la souris, puis avec la permission, maintenant avec la permission, donnez la permission d'écriture à l'utilisateur du pool d'applications,
Merci
la source
La raison pour laquelle php-cgi a le verrou est à cause de la façon "particulière" dont Windows gère l'accès aux fichiers et php / iis gère la "mise en cache". Fondamentalement, vous venez de créer le répertoire et avez essayé d'y accéder, mais le handle qui l'a créé n'a pas été libéré (il était donc toujours verrouillé). Ce n'est pas un problème drupal, c'est un problème IIS / PHP Et il n'y a pas de solution connue que je puisse trouver.
Fondamentalement, le conseil de base de ne pas utiliser IIS est le meilleur, j'ai vu ce problème dans plus que simplement Drupal avec IIS que j'ai résolu en passant à apache HTTPD (sur win32). Rappelez-vous que c'était pour la rentrée, avec un projet où je devais utiliser Windows 2000.
la meilleure façon que je connaisse d'exécuter Drupal sur Windows est via Apache (à cause de la gestion interne de PHP).
la source
Quelques idées pour creuser dans la bonne direction:
Si vous rencontrez le même problème avec Drush, je ne suis pas sûr que ce soit un problème IIS. Drush n'exécute-t-il pas simplement PHP à partir de la ligne de commande sans IIS? Vous pouvez essayer cela en arrêtant IIS (iisreset / stop) puis en exécutant la commande de mise à jour Drush et je m'attendrais à ce que vous obteniez le même résultat.
L'autre chose (désolé, je n'ai pas assez de réputation pour commenter directement la réponse de Lawri):
Est-ce vraiment vrai? D'après l'article d'origine, il semble qu'il ait créé le dossier dans "tmp", mais le verrou se trouve sur le dossier déjà existant dans "httpdocs".
Je suppose que php-cgi essaie de copier de tmp vers httpdocs, échoue pour une raison et ne supprime pas le verrou. Donc, lorsque vous étudiez après l'échec, vous voyez un verrou sur httpdocs, mais je pense que la raison initiale de l'échec n'est pas un verrou, il peut s'agir d'un problème d'autorisation sur le dossier tmp après tout!
la source