Como você permite que os plugins sejam atualizados usando a GUI sem quebrar seu repository de subversão?

O desenvolvimento em uma instalação do WordPress está no version control do Subversion. Não estamos usando externals para vincular nos plugins – os plugins estão sendo instalados / atualizados por não desenvolvedores responsáveis ​​pelo conteúdo.

Isso causa problemas no repository, especialmente para plugins que já estão sob version control e estão sendo atualizados para a versão mais recente, uma vez que atualizar um plugin exclui o diretório (incluindo todas as pastas .svn) e depois recriá-lo.

Aqui está um cenário típico, isso não me causa nenhum sofrimento:

  1. Coloque um site WordPress existente sob version control em um novo repo. Este site existente já possui alguns plugins. Alguns desses plugins estão desatualizados
  2. Agora, entre no administrador e atualize esses plugins
  3. execute svn st e veja o seguinte:

    ~ addthis

    ~ google-analytics-for-wordpress

    etc …

O tilde ~ é especialmente desagradável porque significa “duh, não sei o que é”, e SVN apenas cai. Mesmo copiando, excluindo, removendo, restaurando, retrocedendo, tentando cometer – não.

Muitas pessoas recomendam o uso de svn: externals ou manualmente FTPing as atualizações, que é tudo bem e dandy, mas eu gostaria de usar a UI como Deus pretendia. Pelo que posso ver no núcleo, não há gancho que possa ser usado para convencer o WP de não excluir a pasta ou a pasta .svn. Existe algo que pode ser feito?

Solutions Collecting From Web of "Como você permite que os plugins sejam atualizados usando a GUI sem quebrar seu repository de subversão?"

Resposta real, tendo em conta tudo o que precede:

Em relação aos diretórios .svn : o Subversion 1.7 foi lançado há pouco mais de um ano ( http://svn.haxx.se/dev/archive-2011-10/0152.shtml ) e as cópias de trabalho não contêm mais diretórios .svn em cada pasta. Eles contêm um único diretório .svn na raiz, juntamente com melhorias de desempenho bastante substanciais. Hoje, o SVN é compatível com a versão 1.7.7. Você deve atualizar seu cliente svn para eliminar isso como qualquer tipo de problema.

Isso responde a pergunta original, porque a WP excluindo os diretórios e recriá-los não é mais um problema. Ele não estragará uma cópia de trabalho feita pelo Subversion 1.7 ou superior. No entanto, ele não responde a questão maior do gerenciamento de repository no que se refere à implantação de produção e aos ambientes dev / testing.

Basicamente, como você gerencia suas máquinas de produção depende de você. Se você realmente tiver um ambiente de “produção” real, então você deve usar um esquema de permissions e / ou plugins para desativar a capacidade dos usuários para atualizar o sistema diretamente. Os usuários não podem alterar a produção. Essa é a forma de chamá-lo de “produção”. As mudanças em tal caso seriam feitas por desenvolvedores e roladas através de testes e / ou sistemas de controle de qualidade primeiro. Se você tem esse ambiente e realmente precisa desse tipo de nível de controle, desativar o upgrade totalmente seria o caminho preferido.

Heck, eu uso esse tipo de ambiente sozinho, embora eu controle dev, testando e produzindo todo o caminho. Todo o site está em um repo SVN. Algumas delas, de fato, usam externals (eu uso o WP trunk, alguns plugins que eu uso como versões do tronco), alguns não são e são locais para o repo. Para mim, implementar mudanças na produção significa fazer um svn up dessas checkboxs, basicamente. As alterações não podem ser feitas diretamente nos filesystems das checkboxs.

Por outro lado, alguns sites que eu corro apenas em linha reta ao vivo, com backups regulares. Se o meu site pessoal for wonky um pouco, então não me afeta. Eu uso o atualizador WP sobre aqueles que estão bem. Agora, eu não executo esses sites em um repo, eu só tenho backups regulares de tudo. Na verdade, eu uso o VaultPress em meus sites pessoais, mas qualquer método de backup é uma boa idéia. Este é um tipo diferente de gerenciamento, onde não preciso de um ambiente dev / testing.

O WordPress funciona bem com qualquer tipo de sistema que você deseja criar em torno dele, mas esse sistema é externo ao WordPress e como você o gerencia é uma questão de não de WP, mas de como você deseja gerenciá-lo, de verdade.

Ainda não testado, mas add_filter('upgrader_clear_destination', array(&$this, 'delete_old_plugin'), 10, 4); parece bom. Você vai encontrá-lo no wp-admin/includes/class-wp-upgrader.php Remova o filtro antes de atualizar seus plugins. Isso pode ser um pouco complicado porque você precisa procurar o nome da function correta para ser removido. Toscho escreveu uma postagem sobre a remoção de ganchos anônimos (alemão) .

Mas apply_filters('upgrader_pre_install', true, $hook_extra); (o mesmo arquivo acima) parece ser a melhor solução. Conecte-se a ‘upgrader_pre_install’ e salve seu diretório .svn. Também ligue a ‘upgrader_post_install’, este gancho será feito após a atualização. Depois de atualizar o plugin, basta copiar de volta seu diretório .svn.

Se você quiser gerenciar sua instalação do WordPress através do version control, não vejo como você pode fazer isso, além de atualizar apenas os plugins do painel de administração do WordPress.

O ideal seria ser assim:

  • Marque uma cópia do seu repo no local.
  • Atualize o plugin do administrador do WP.
  • Teste
  • Comprometer
  • Marque a última versão na produção (verificação que significa implantação daqueles compromissos)

E isso funciona perfeitamente com GIT. Com o SVN, pode ser um problema, já que ele possui um diretório .svn em cada diretório, mas como o Otto sugeriu o SVN 1.7 pode ajudá-lo aqui, pois haverá apenas um único diretório .svn na raiz.

Parece que um plugin foi criado para ajudar com isso.

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

Ou, basta digitar “SVN Auto Upgrade” no navegador Plugin no seu back-end WP.