Como devo estruturar um projeto de website do WP usando git e update do painel do WP?

12

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

Aqui está o que eu estou pensando agora, com meus pensamentos de como eu lidaria com repositórios de 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 grande mudança nas alterações do código de acompanhamento com o git. Existe alguma maneira de rastrear minhas alterações de código enquanto ainda permitir 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 ou empurrar minhas alterações de volta para o repositório principal do WordPress (se eu decidir que gostaria de ser um colaborador principal? )?

  • Para plug-ins que não possuem um repositório público do git, ignorá-los completamente cria o problema de não poder clonar rapidamente todo o site 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 plugin, essas alterações não são rastreadas e podem ser facilmente perdidas em uma atualização de plugin.

Então, para resumir, o que é um bom git + configuração do WordPress que evite esses problemas? Eu apreciaria seu feedback sobre a estrutura do meu projeto proposto. 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 lá.

    
por Josiah Sprague 31.12.2013 / 21:19

5 respostas

6

Da minha perspectiva, existem dois problemas com o 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á, feito isso, doeu muito.

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

  3. Não há praticamente nenhuma maneira de combinar a pilha do site inteiro com atualizações nativas. Simplesmente não combina bem desde que tente atingir objetivos diferentes em projetos de diferentes níveis (desenvolvedor no controle versus usuário final no controle).

Se você me perguntar qual é a melhor aposta para o site inteiro, a pilha do WordPress é atualmente 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 WordPress core não é desenvolvido no Git e não aceita solicitações pull, todas as contribuições são (até agora) via arquivos de patch para o Subversion.

  3. Você provavelmente terá que enviar esses plugins para o repositório. Ou vá com outra abordagem como o Composer.

por Rarst 31.12.2013 / 21:45
3

Você pode dar uma olhada no problema e esta questão .

Veja também os arquivos README em cada repo:

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

Eu estou no mesmo barco com as atualizações automáticas ... Meu plano era atualizar manualmente o submódulo do WP quando as atualizações acontecem. Eu acho que a alternativa é, em teoria (eu ainda não ter me testado), deixar o submódulo se atualizar para pequenas atualizações (existe uma configuração WP para isso) e então fazer uma git force / reset do submódulo quando grandes atualizações sair (talvez uma das respostas aqui poderia ser de alguma ajuda ... claro, eu acho, alguém poderia querer direcionar uma tag WP específica ao atualizar para a próxima versão principal).

Uma coisa a notar é que, se o WP vir .git no (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, há 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 checkout do SVN ou do GIT, as atualizações automáticas serão desativadas
  •   
  • Se as constantes DISALLOW_FILE_MODS ou AUTOMATIC_UPDATER_DISABLED estiverem definidas, as atualizações automáticas serão desativadas
  •   
  • Se a constante WP_AUTO_UPDATE_CORE for definida como falsa, as atualizações automáticas serão desativadas
  •   
  • Sua instalação do WordPress também precisa ser capaz de entrar em contato com o WordPress.org por conexões HTTPS, portanto, sua instalação do PHP também precisa de OpenSSL instalado e funcionando
  •   
  • Wp-Cron precisa estar operacional, se por algum motivo o cron não funcionar na sua instalação, as Atualizações Automáticas também estarão indisponíveis
  •   

Outros links relacionados:

Maio de 2015 atualização

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

    
por mhulse 07.01.2014 / 21:52
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 feliz".

Eu acho subárvores, submodules ou repositórios aninhados, uma enorme dor no traseiro.

Alguns pensamentos (acompanhe tudo).

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

Método seguro via confirmações manuais + email:

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

Isso também permite que você copie / cole pastas para seus próprios repositórios à vontade, o que geralmente é como eu faço isso. Também facilita a clonagem / destruição de múltiplos servidores de teste, o git realmente entra em vigor com este método desde 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 para o servidor live. Você também pode separar repos de plugins / temas e então fazer com que o script compile / mova / qualquer que seja, e / ou use o Composer no mix.

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

A desvantagem: inflexível, leva tempo para ser criada.

O Git não deve ser usado para backups e, de um modo geral, não há necessidade de clonar o histórico de commit do WP.

    
por Wyck 01.01.2014 / 15:52
0

Depois de pensar um pouco mais, já que eu definitivamente quero aproveitar as atualizações nativas do WP para me poupar do trabalho, não faz sentido rastrear qualquer coisa 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

Claro, então eu perco a habilidade de rastrear quais plugins e temas fazem parte do projeto de dentro do VCS, mas eu realmente só preciso disso para fins de backup, e eu vou estar usando algum tipo de sistema de backup regular de qualquer maneira.

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

    
por Josiah Sprague 01.01.2014 / 14:46
0

Ok, assistindo a palestra 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, que causou problemas para mim no passado com plugins e temas mal escritos que não conseguiam encontrar o diretório de conteúdo.

    
por Josiah Sprague 01.01.2014 / 15:29