web-dev-qa-db-fra.com

Comment autorisez-vous la mise à jour des plugins à l'aide de l'interface graphique sans casser votre référentiel Subversion?

Le développement sur une installation WordPress est sous contrôle de version Subversion. Nous n'utilisons pas d'externaux pour créer des liens dans les plugins - les plugins sont installés/mis à jour par des non-développeurs en charge du contenu.

Cela pose des problèmes au sein du référentiel, en particulier pour les plug-ins déjà sous contrôle de version et en cours de mise à jour vers la dernière version, car la mise à jour d'un plugin supprime le répertoire (y compris tous les dossiers .svn), puis le recrée.

Voici un scénario typique, qui me cause énormément de chagrin:

  1. Mettez un site WordPress existant sous contrôle de version dans un nouveau dépôt. Ce site existant a déjà quelques plugins. Certains de ces plugins sont obsolètes
  2. Maintenant, allez dans l'admin et mettez à jour ces plugins

  3. lancez svn st et vous verrez ce qui suit:

    ~ ajouter

    ~ google-analytics-for-wordpress

    etc...

Le tilde ~ est particulièrement méchant, car il signifie "duh, je ne sais pas ce qui est heureux", et SVN vient de chialer. Même copier, supprimer, supprimer, restaurer, revenir en arrière, tenter de commettre une erreur.

Beaucoup de gens recommandent d’utiliser svn: externals ou d’envoyer manuellement par FTP les mises à jour, ce qui est très bien, mais je voudrais simplement pouvoir utiliser l’UI à la volonté de Dieu. D'après ce que je peux voir dans le noyau, aucun crochet ne peut être utilisé pour convaincre WP de ne pas supprimer le dossier ou le dossier .svn. Y a-t-il quelque chose qui peut être fait?

pluginssvn
6
Tom Auger

Réelle réponse, en tenant compte de tout ce qui précède:

En ce qui concerne les répertoires .svn: Subversion 1.7 est sorti il ​​y a un peu plus d'un an ( http://svn.haxx.se/dev/archive-2011-10/0152.shtml ) et les copies de travail ne contiennent plus de répertoires .svn dans chaque dossier. Ils contiennent un seul répertoire .svn à la racine, ainsi que des améliorations de performances assez substantielles. Aujourd'hui, SVN est à la version 1.7.7. Vous devriez mettre à jour votre client svn pour éliminer ceci comme n'importe quel problème.

Cela répond à la question initiale, car WP supprimer les répertoires et les recréer n'est plus vraiment un problème. Cela ne gâchera pas une copie de travail créée par Subversion 1.7 ou une version ultérieure. Cependant, cela ne répond pas à la question plus vaste de la gestion des référentiels en ce qui concerne le déploiement en production et les environnements de développement et de test.

En gros, c'est à vous de décider comment gérer vos machines de production. Si vous avez réellement un véritable environnement de "production", vous devez utiliser un schéma d'autorisations et/ou des plugins pour désactiver la possibilité pour les utilisateurs de mettre à niveau le système directement. Les utilisateurs ne peuvent pas changer de production. C'est en quelque sorte le point de l'appeler "production". Les modifications dans un tel cas seraient effectuées par les développeurs et passées en revue d'abord par les systèmes de test et/ou d'assurance qualité. Si vous avez un tel environnement et avez vraiment besoin de ce type de contrôle, alors la désactivation complète de l'usine de traitement serait la meilleure façon de procéder.

Heck, j'utilise juste ce genre d'environnement moi-même, même si je contrôle tout le développement, les tests et la production. L'ensemble du site est dans un dépôt SVN. Certains d’entre eux utilisent en effet des externes (j’utilise WP trunk, quelques plugins que j’utilise en tant que versions de trunk), d’autres non et sont locaux au référentiel. Pour moi, déployer des changements en production signifie faire un svn up sur ces cases, en gros. Les modifications ne peuvent pas être effectuées directement sur ces systèmes de fichiers.

D’autre part, certains sites que je lance directement, avec des sauvegardes régulières. Si mon site personnel est un peu pervers, cela ne me touche pas vraiment. J'utilise le WP Updater sur ceux-ci très bien. Maintenant, je n'exécute pas ces sites dans un dépôt, mais des sauvegardes régulières de l'ensemble. En fait, j'utilise VaultPress sur mes sites personnels, mais toute méthode de sauvegarde est une bonne idée. Il s'agit d'un type de gestion différent, pour lequel je n'ai pas besoin d'un environnement de développement/test.

WordPress fonctionne bien avec tout type de système que vous souhaitez créer autour de celui-ci, mais ce système est externe à WordPress, et la façon dont vous le gérez est une question de non pas de WP mais de la façon dont vous voulez le gérer, vraiment.

7
Otto

Pas encore testé, mais add_filter('upgrader_clear_destination', array(&$this, 'delete_old_plugin'), 10, 4); a l'air bien. Vous le trouverez dans wp-admin/includes/class-wp-upgrader.php Supprimez le filtre avant de mettre à jour vos plugins. Cela pourrait être un peu délicat, car vous devez rechercher le nom de la fonction à supprimer. Toscho a écrit un article sur la suppression des hooks anonymes (allemand) .

Mais apply_filters('upgrader_pre_install', true, $hook_extra); (même fichier que ci-dessus) semble être la meilleure solution. Accrochez-vous dans 'upgrader_pre_install' et sauvegardez votre répertoire .svn. Accrochez-vous également à 'upgrader_post_install', ce raccordement sera effectué après la mise à jour. Après la mise à jour du plugin, copiez simplement votre répertoire .svn.

2
Ralf912

Si vous souhaitez gérer votre installation WordPress via le contrôle de version, je ne vois pas comment vous pouvez le faire en mettant à jour les plugins à partir du panneau d'administration WordPress uniquement.

Idéalement, cela devrait être comme ça:

  • Commander une copie de votre repo sur local.
  • Mettez à jour le plug-in à partir de WP admin.
  • Tester
  • Commettre
  • Commander la dernière version en production (checkout signifie le déploiement de ces commits)

Et cela fonctionne parfaitement avec GIT. Avec SVN, cela peut poser un problème car il contient un répertoire .svn dans chaque répertoire, mais comme Otto l’a suggéré, SVN 1.7 peut vous aider car il n’y aura qu’un seul répertoire .svn à la racine.

1
Ashfame

On dirait qu'un plugin a été créé pour aider avec ceci.

http://plugins.svn.wordpress.org/svn-auto-upgrade/trunk/

Ou bien, tapez simplement "SVN Auto Upgrade" dans le navigateur de plug-ins de votre back-end WP.

0
Tom Auger