¿Cómo debo estructurar un proyecto de sitio web de WP usando git y actualizando desde el tablero de WP?

13

Durante meses, he estado tratando de planificar una buena estructura de proyecto para usar el control de versiones git para el desarrollo de sitios web de WordPress que no sacrifique la capacidad de actualizar el núcleo y los complementos a través del panel de control de WP, no requiere una estructura de directorio no convencional (wp -contenido fuera de la carpeta principal de WP) y eso es fácil de administrar e implementar sitios web completos. He leído sobre submódulos, subárboles, repositorios anidados, etc., y todavía me resulta difícil adaptarlo todo y elegir la estrategia correcta.

Esto es lo que estoy pensando ahora, con mis pensamientos sobre cómo manejaría los repositorios de git entre paréntesis.

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

Esto me deja con varios problemas / preguntas;

  • Actualizaciones automáticas; Me encanta la nueva función de actualizaciones automáticas, potencialmente podría ahorrar mucho tiempo y esfuerzo para mantener mis sitios actualizados y seguros, pero parece que es un obstáculo en el seguimiento de los cambios de código con git. ¿Hay alguna forma de rastrear los cambios en mi código y al mismo tiempo permitir que el núcleo de WordPress se actualice automáticamente?

  • ¿Tener subárboles bajo el repositorio principal de WordPress me impide usar git para fusionarme en nuevas actualizaciones principales o enviar mis cambios al repositorio principal de WordPress (si alguna vez decido que me gustaría ser un contribuidor principal)?

  • Para los complementos que no tienen un repositorio público de git, ignorarlos completamente crea el problema de no poder clonar rápidamente todo el sitio en un nuevo servidor sin copiar manualmente los archivos en el servidor. También causa un problema si quiero hacer cambios en el código de ese complemento, esos cambios no se rastrean y podrían perderse fácilmente en una actualización del complemento.

Entonces, para resumir, ¿cuál es una buena configuración de git + WordPress que evita estos problemas? Agradecería sus comentarios sobre la estructura de mi proyecto propuesto. ¡Cualquier forma en que me puedan ayudar a mejorar esto sería muy apreciada!

PD: si hay un mejor foro para esta discusión, indíqueme allí.

updates automatic-updates git Josiah Sprague
fuente

Respuestas:

6

Desde mi perspectiva, hay dos problemas con su plan: Git y estructura "convencional". Así que básicamente todo. :)

  1. Git (y el control de versiones en general) es una herramienta pobre para pilas de sitios completos. He estado allí, hecho eso, me dolió mucho.

  2. Lo que usted llama una estructura "no convencional" con contenido separado del núcleo ha sido una opción muy convencional y robusta para cualquier sitio serio por un tiempo.

  3. Prácticamente no hay formas llave en mano de combinar todo el stack del sitio con actualizaciones nativas. Simplemente no funciona bien, ya que trata de lograr diferentes objetivos en proyectos de diferentes niveles (desarrollador en control frente a usuario final en control).

Si me preguntas que la mejor opción para la pila de WordPress de todo el sitio es actualmente Composer , sin embargo las opiniones pueden ser cautelosas. :)

Sobre sus preocupaciones específicas:

  1. Como anteriormente, las actualizaciones nativas (más aún, las automáticas) no funcionan bien con pilas muy controladas.

  2. El núcleo de WordPress no está desarrollado en Git y no acepta solicitudes de extracción, todas las contribuciones son (hasta ahora) a través de archivos de parche a Subversion.

  3. Es probable que tenga que comprometer dichos complementos en su repositorio. O ve con otro enfoque como Composer.

Rarst
fuente
WordPress no usa Git para el desarrollo, pero hay un espejo en github.com/WordPress/WordPress (sincronizado desde el SVN cada 15 minutos). No es para empujar parches, etc., para eso definitivamente debe usar SVN y Trac. No sé si esto será adecuado para los propósitos del OP o no, pero por completo, existe.
Pat J
@PatJ buen punto, supuse que Q significaba hacer uso de ese, pero tal vez no
Rarst
Muy buenos puntos. Tengo una pila completa de sitios configurada usando git con submódulos y es un gran dolor de cabeza. Supongo que me pregunto si hay una forma menos controlada de aprovechar Git, pero también aprovechar las actualizaciones nativas para ahorrarme algo de trabajo. Soy un equipo de un solo hombre en este momento, así que básicamente solo estoy tratando de configurar sitios de la manera más eficiente posible.
Josiah Sprague el
@JosiahSprague si su punto de dolor principal es la configuración inicial (en lugar del mantenimiento de la pila a largo plazo), podría tener sentido concentrarse en eso con una install.phprutina personalizada o algo así y usar la mecánica de actualización normal desde allí. Composer stack puede manejar las actualizaciones muy bien en abstracto, pero se basa en la calidad de los paquetes que usa y cosas como la representación de repositorios oficiales de WP porque aún no es bastante madura.
Rarst
3

Puede echar un vistazo a este problema y este problema.

También eche un vistazo a los archivos README en cada repositorio también:

Basado en los repositorios anteriores, como otro ejemplo de una configuración de Git / WP, creé esto . Opté por usar enlaces simbólicos para los temas (trato de cubrir eso en mi README ).

Sin embargo, estoy un poco en el mismo barco con las actualizaciones automáticas ... Mi plan era actualizar manualmente el submódulo WP cuando ocurrieran las actualizaciones. Creo que la alternativa es, en teoría (todavía no me he probado), dejar que el submódulo se actualice solo para actualizaciones menores (hay una configuración de WP para esto) y luego hacer un gitforzado / reinicio del submódulo cuando salen actualizaciones importantes ( tal vez una de las respuestas aquí podría ser de alguna ayuda ... por supuesto, creo, uno querría apuntar a una etiqueta WP específica al actualizar a la próxima versión principal).

Una cosa a tener en cuenta es que si WP ve .giten la (s) ruta (s), desactivará automáticamente las actualizaciones automáticas. Para más información, ver:

Para que se habiliten las Actualizaciones automáticas, hay algunos requisitos simples:

  • Si la instalación usa FTP para actualizaciones (y solicita credenciales), las actualizaciones automáticas están deshabilitadas
  • Si la instalación se ejecuta como un pago SVN o GIT, las actualizaciones automáticas se deshabilitan
  • Si las constantes DISALLOW_FILE_MODSo AUTOMATIC_UPDATER_DISABLEDestán definidas, las actualizaciones automáticas están deshabilitadas
  • Si la constante WP_AUTO_UPDATE_COREse define como falsa, las actualizaciones automáticas se deshabilitan
  • Su instalación de WordPress también debe poder comunicarse con WordPress.org a través de conexiones HTTPS, por lo que su instalación de PHP también necesita estar OpenSSLinstalada y funcionando
  • Wp-Cron debe estar operativo, si por alguna razón cron no funciona para su instalación, las actualizaciones automáticas tampoco estarán disponibles

Otros enlaces relacionados:

Actualización de mayo de 2015

He creado esta cesión temporal , que es una forma rápida para que empiece a proyectos de WordPress. Mi último enfoque es solo controlar la versión de los temas. En otras palabras, instalo WP localmente (usando la configuración en el repositorio mencionado anteriormente) y en producción, luego modifico el archivo de configuración en cada sistema y gitextraigo mis temas para obtener un sitio funcional.

mhulse
fuente
2

Este tipo de desarrollo cae en "no es tan fácil y requiere un flujo de trabajo personalizado que podría llevar mucho tiempo".

Encuentro subárboles, submódulos o repositorios anidados, un gran dolor en el culo.

Algunos pensamientos (rastrear todo).

  1. Habilite las actualizaciones automáticas con git / svn usando:
    add_filter( 'auto_upgrade_ignore_checkout_status', '__return_true' );

Método seguro a través de confirmaciones manuales + correo electrónico:

Puede usar un servidor de ensayo y notificaciones de actualización por correo electrónico para usted, confirmar las actualizaciones y enviar al servidor en vivo que tiene las actualizaciones automáticas desactivadas.

Esto también le permite copiar / pegar carpetas para sus propios repositorios a voluntad, que a menudo es como lo hago. También facilita la clonación / destrucción de múltiples servidores de ensayo, git realmente entra en vigor con este método ya que se distribuye.

La desventaja: copiar / pegar carpetas, administración.

Método automático

Configure un script de compilación (Phing, Ant, Bash, Capistrano, etc.) y algún código personalizado que haga un git add + commit cuando se aplique una actualización y la envíe al servidor en vivo. También puede separar complementos / repositorios de temas y luego hacer que el script compile / mueva / lo que sea, y / o use Composer en la mezcla.

Automatizar un flujo de trabajo como este también tiende a ser inflexible y solo vale la pena si ve una necesidad real del tiempo invertido.

La desventaja: inflexible, lleva tiempo crear.

Git no debe usarse para copias de seguridad y, en general, no es necesario que clones el historial de confirmación de WP.

Wyck
fuente
0

Después de pensarlo un poco más, ya que definitivamente quiero aprovechar las actualizaciones nativas de WP para ahorrarme trabajo de campo, no tiene sentido rastrear nada de lo que WP actualizará usando git. Aquí hay una idea 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

Por supuesto, luego pierdo la capacidad de rastrear qué complementos y temas son parte del proyecto desde el VCS, pero realmente solo lo necesito para propósitos de respaldo, y de todos modos usaré algún tipo de sistema de respaldo regular.

Por lo tanto, lo único que realmente me falta es la capacidad de implementar fácilmente toda la pila en diferentes servidores sin usar FTP para copiar manualmente todo. Alguien tiene alguna idea sobre eso?

Josiah Sprague
fuente
0

Ok, viendo la charla de Mark Jaquith aquí , tal vez estoy en el camino equivocado. Aquí hay otra puñalada que rastrea todo.

   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

Supongo que el principal inconveniente de esto es tener un directorio de contenido personalizado, lo que me ha causado problemas en el pasado con complementos y temas mal escritos que no pueden encontrar el directorio de contenido.

Josiah Sprague
fuente