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

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.

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

Veja também os arquivos README em cada repo:

• markjaquith / WordPress-Skeleton
• davidwinter / wordpress-com-git

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:

• Atualizações automáticas do núcleo, uma atualização

  

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:

• Atualização automática do WP 3.7
• desenvolvimento do tema do submódulo GitHub?
• Instale e gerencie o WordPress com o Git

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.

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.

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?

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.