Como estruturar um projeto de site do WP usando git e atualizando a partir do painel do WP?

13

Por meses, eu tenho tentado planejar uma boa estrutura de projeto para usar o controle de versão git para o desenvolvimento de sites WordPress que não sacrifica a capacidade de atualizar o núcleo e os plugins através do painel do WP, não requer uma estrutura de diretório não convencional (wp conteúdo fora da pasta pai do WP) e fácil de gerenciar e implantar sites inteiros. Eu li sobre submódulos, subárvores, repositórios aninhados, etc., e ainda estou tendo dificuldades para encaixar tudo e escolher a estratégia certa.

Aqui está o que estou pensando agora, com meus pensamentos sobre como eu lidaria com repositórios git entre parênteses.

root (main project repo)
|-- wordpress (public git repo added as subtree)
|    |-- wp-content 
|    |    |-- plugins
|    |    |    |-- my-custom-plugin (git repo added as subtree)
|    |    |    |-- other-plugin-with-git-repo  (git repo added as subtree)
|    |    |    +-- other-plugin-without-git-repo (ignored/untracked)
|    |    |-- themes
|    |    |    |-- my-custom-theme (git repo added as subtree)
|    |    |    |-- other-theme-with-git-repo  (git repo added as subtree)
|    |    |    +-- other-theme-without-git-repo (ignored/untracked)
|    |    +-- uploads (ignored/untracked)
|    |-- wp-admin
|    +-- wp-includes
|-- wp-config.php (ignored/untracked)
+-- other-files.txt

Isso me deixa com vários problemas / perguntas;

  • Atualizações automáticas; Adoro o novo recurso de atualizações automáticas, que pode economizar muito tempo e esforço para manter meus sites atualizados e seguros, mas parece que isso gera uma chave no rastreamento de alterações de código com o git. Existe alguma maneira de rastrear minhas alterações de código enquanto ainda permite que o núcleo do WordPress seja atualizado automaticamente?

  • Ter subárvores sob o repositório principal do WordPress me impede de usar o git para mesclar novas atualizações principais ou enviar minhas alterações de volta ao repositório principal do WordPress (se eu decidir que gostaria de ser um colaborador principal)?

  • Para plugins que não possuem um repositório público de git, ignorá-los completamente cria o problema de não poder clonar rapidamente o site inteiro em um novo servidor sem copiar manualmente os arquivos para o servidor. Isso também causa um problema se eu quiser fazer alterações no código desse plug-in, essas alterações não são rastreadas e podem ser facilmente perdidas em uma atualização de plug-in.

Então, para resumir, o que é uma boa configuração do git + WordPress que evita esses problemas? Agradecemos o seu feedback sobre minha estrutura de projeto proposta. De qualquer maneira que você possa me ajudar a melhorar isso, seria muito apreciado!

PS, se houver um fórum melhor para esta discussão, por favor me aponte para lá.

updates automatic-updates git Josiah Sprague
fonte

Respostas:

6

Na minha perspectiva, há dois problemas com seu plano - Git e estrutura "convencional". Então basicamente tudo. :)

  1. Git (e controle de versão em geral) é uma ferramenta ruim para pilhas de sites inteiros. Estive lá, fiz isso, doeu muito.

  2. O que você chama de estrutura "não convencional" com conteúdo separado do núcleo tem sido uma opção muito convencional e robusta para qualquer site sério por um tempo.

  3. Não há maneiras prontas de combinar a pilha inteira de sites com atualizações nativas. Apenas não funciona bem, uma vez que tenta atingir objetivos diferentes em projetos de diferentes níveis (desenvolvedor no controle versus usuário final no controle).

Se você me perguntar, a melhor aposta para toda a pilha do WordPress atualmente é o Composer , no entanto, as opiniões podem ser cautelosas. :)

Sobre suas preocupações específicas:

  1. Como acima - as atualizações nativas (mais automáticas) não funcionam bem com pilhas rigidamente controladas.

  2. O núcleo do WordPress não foi desenvolvido no Git e não aceita solicitações pull, todas as contribuições são (até o momento) via arquivos de patch para o Subversion.

  3. Você provavelmente precisará comprometer esses plugins em seu repositório. Ou siga outra abordagem como o Composer.

Rarst
fonte
O WordPress não usa o Git para desenvolvimento, mas há um espelho em github.com/WordPress/WordPress (sincronizado a partir do SVN a cada 15 minutos). Não é para empurrar patches, etc - para isso você definitivamente precisa usar o SVN & Trac. Não sei se isso será adequado para os propósitos do OP ou não, mas, por uma questão de exaustividade, existe.
Pat J
@PatJ ponto bom, eu assumi meio Q significa fazer uso do que um, mas talvez não
Rarst
Muito bons pontos. Eu tenho uma pilha de sites inteira configurada usando git com submódulos e é uma grande dor de cabeça. Acho que estou me perguntando se existe uma maneira menos rigorosa de aproveitar o Git, mas também aproveitar as atualizações nativas para me poupar algum trabalho. Sou uma equipe de um só homem no momento, então estou basicamente tentando configurar sites da maneira mais eficiente possível.
Josiah Sprague
@JosiahSprague se o seu principal problema é a configuração inicial (em vez da manutenção de pilha de longo prazo), pode fazer sentido focar nisso com install.phprotina personalizada ou algo assim e usar a mecânica de atualização normal a partir daí. A pilha do compositor pode lidar com as atualizações muito bem em resumo, mas depende da qualidade dos pacotes que você usa e coisas como proxy de repositórios oficiais do WP, pois ainda não está maduro.
Rarst
3

Você pode dar uma olhada neste problema e neste problema.

Veja também os arquivos LEIA-ME em cada repositório:

Com base nos repositórios acima, como outro exemplo de configuração do Git / WP, criei isso . Optei por usar links simbólicos para temas (eu tento cobrir isso no meu README ).

Mas estou no mesmo barco com as atualizações automáticas ... Meu plano era atualizar manualmente o submódulo WP quando as atualizações acontecessem. Eu acho que a alternativa é, em teoria (eu ainda tenho que me testar), permitir que o submódulo se atualize para atualizações menores (há uma configuração de WP para isso) e faça uma gitforça / redefinição do submódulo quando surgirem atualizações importantes ( talvez uma das respostas aqui possa ser de alguma ajuda ... é claro, acho que alguém desejaria direcionar uma tag WP específica ao atualizar para a próxima versão principal).

Uma coisa a observar é que, se o WP vir .gitno (s) caminho (s), ele desativará automaticamente as atualizações automáticas. Para mais informações, consulte:

Para que as Atualizações Automáticas sejam ativadas, existem alguns requisitos simples:

  • Se a instalação usar o FTP para atualizações (e solicitar credenciais), as atualizações automáticas serão desativadas
  • Se a instalação estiver sendo executada como um check-out SVN ou GIT, as atualizações automáticas serão desativadas
  • Se as constantes DISALLOW_FILE_MODSou AUTOMATIC_UPDATER_DISABLEDestiverem definidas, as atualizações automáticas serão desativadas
  • Se a constante WP_AUTO_UPDATE_COREfor definida como falsa, as atualizações automáticas serão desativadas
  • Sua instalação do WordPress também precisa poder entrar em contato com o WordPress.org através de conexões HTTPS, portanto, a instalação do PHP também precisa estar OpenSSLinstalada e funcionando
  • Wp-Cron precisa estar operacional, se por algum motivo o cron falhar em sua instalação, as Atualizações Automáticas também estarão indisponíveis

Outros links relacionados:

Atualização de maio de 2015

Criei este repositório, que é uma maneira rápida de iniciar projetos WordPress. Minha abordagem mais recente é controlar apenas a versão do (s) tema (s). Em outras palavras, eu instalo o WP localmente (usando a configuração no repositório mencionado acima) e na produção, modifico o arquivo de configuração em cada sistema e gitpuxo meu (s) tema (s) para obter um site funcional.

mhulse
fonte
2

Esse tipo de desenvolvimento se enquadra no "não é tão fácil e requer um fluxo de trabalho personalizado que pode levar muito tempo para ser satisfeito".

Acho Subárvores, submódulos ou repositórios aninhados, uma enorme dor na bunda.

Alguns pensamentos (acompanhem tudo).

  1. Ative as atualizações automáticas com o git / svn usando:
    add_filter( 'auto_upgrade_ignore_checkout_status', '__return_true' );

Método seguro via confirmação manual + email:

Você pode usar um servidor de armazenamento temporário e notificações por atualização por e-mail, confirmar as atualizações e enviar para o servidor ativo com as atualizações automáticas desativadas.

Isso também permite que você copie / cole pastas para seus próprios repositórios à vontade, o que geralmente é o que faço. Também facilita a clonagem / destruição de vários servidores de armazenamento temporário, o git realmente entra em vigor com esse método, uma vez que é distribuído.

A desvantagem: copiar / colar pastas, gerenciamento.

Método automático

Configure um script de construção (Phing, Ant, Bash, Capistrano, etc) e algum código personalizado que faça um git add + commit quando uma atualização for aplicada e envie-a para o servidor ativo. Você também pode separar os plugins / repositórios de temas e, em seguida, solicitar que o script compile / mova / o que quer que seja e / ou use o Composer na mistura.

Automatizar um fluxo de trabalho como esse também tende a ser inflexível e só vale a pena se você observar uma necessidade real do tempo investido.

A desvantagem: inflexível, leva tempo para criar.

O Git não deve ser usado para backups e, em geral, não é necessário clonar o histórico de consolidação do WP.

Wyck
fonte
0

Depois de pensar um pouco mais, como eu definitivamente quero tirar proveito das atualizações nativas do WP para me poupar trabalho, não faz sentido rastrear nada que o WP atualize usando o git. Aqui está uma ideia revisada.

root (main project repo)
|-- wordpress (ignored/untracked)
|    |-- wp-content 
|    |    |-- plugins
|    |    |    |-- my-custom-plugin (git repo not connected to parent)
|    |    |    |-- other-plugin (ignored/untracked)
|    |    |    +-- modified-plugin (unignored, added to main project repo)
|    |    |-- themes
|    |    |    |-- my-custom-theme (git repo not connected to parent)
|    |    |    |-- other-theme (ignored/untracked)
|    |    |    +-- modified-theme (unignored, added to main project repo)
|    |    +-- uploads (ignored/untracked)
|    |-- wp-admin
|    +-- wp-includes
|-- wp-config.php (ignored/untracked)
+-- other-files.txt

Obviamente, perco a capacidade de rastrear quais plug-ins e temas fazem parte do projeto no VCS, mas eu realmente só preciso disso para fins de backup e, de qualquer maneira, usarei algum tipo de sistema de backup regular.

Portanto, a única coisa que realmente falta é a capacidade de implantar facilmente a pilha inteira em diferentes servidores sem usar o FTP para copiar manualmente a coisa toda. Alguém tem alguma ideia sobre isso?

Josiah Sprague
fonte
0

Ok, assistindo a conversa de Mark Jaquith aqui , talvez eu esteja no caminho errado. Aqui está outra facada que rastreia tudo.

   root (main project repo)
    |-- wordpress (repo as subtree)
    |-- wp-config.php (ignored/untracked)
    |-- wp-content 
    |    |-- plugins
    |    |    |-- my-custom-plugin (repo as subtree)
    |    |    |-- other-plugin-with-git-repo (repo as subtree)
    |    |    +-- plugin-without-git-repo
    |    |-- themes
    |    |    |-- my-custom-theme (repo as subtree)
    |    |    |-- other-theme-with-git-repo (repo as subtree)
    |    |    +-- theme-without-git-repo
    |    +-- uploads (ignored/untracked)
    +-- other-files.txt

Eu acho que a principal desvantagem disso é ter um diretório de conteúdo personalizado, o que causou problemas para mim no passado, com plugins e temas mal escritos e não sendo possível encontrar o diretório de conteúdo.

Josiah Sprague
fonte