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

Question

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

#1 de Rarst (6 votos)
#2 de mhulse (3 votos)
#3 de Wyck (2 votos)
#4 de Josiah Sprague (0 votos)
#5 de Josiah Sprague (0 votos)

12

Durante meses he estado tratando de planificar una buena estructura de proyecto para usar el control de versiones de 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 un directorio no convencional Estructura (wp-contenido fuera de la carpeta principal de WP) y que es fácil de administrar y desplegar sitios web completos. He leído acerca de los submódulos, subárboles, repositorios anidados, etc., y todavía me resulta difícil compaginarlo 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 arroja una llave en el seguimiento de cambios de código con git. ¿Hay alguna forma de hacer un seguimiento de los cambios en mi código y al mismo tiempo permitir que el núcleo de WordPress se actualice automáticamente?
¿Tener subárboles en el repositorio central de WordPress me impide usar git para fusionar las nuevas actualizaciones del núcleo o devolver mis cambios al repositorio del núcleo de WordPress (si alguna vez decido que me gustaría ser un colaborador principal )?
Para los complementos que no tienen un repositorio git público, 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 realizar 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, ¿qué es una buena configuración de git + WordPress que evite estos problemas? Agradecería sus comentarios sobre la estructura de mi proyecto propuesto. Cualquier forma en que pueda ayudarme a mejorar esto, sería muy apreciada!

PD, si hay un foro mejor para esta discusión, por favor, apúntame allí.

updates git auto-update

pregunta Josiah Sprague 31.12.2013 - 21:19

5 respuestas

Lea otras preguntas en las etiquetas updates git auto-update

dbDelta no está creando tablas Publicaciones con al menos 3 etiquetas de una lista de etiquetas

score 6 · Answer 1

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

Git (y el control de versiones en general) es una herramienta pobre para las pilas de todo el sitio. He estado allí, hecho eso, me dolió mucho.
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.
No hay prácticamente ninguna forma llave en mano para combinar la pila completa del sitio con las actualizaciones nativas. Simplemente no va bien juntos ya que trata de lograr diferentes objetivos en proyectos de diferentes niveles (desarrollador en control frente a usuario final en control).

Si me preguntas cuál es la mejor apuesta para WordPress Stack de todo el sitio actualmente es Compositor , sin embargo, las opiniones pueden ser cautelosas. :)

Sobre sus preocupaciones específicas:

Como se mencionó anteriormente, las actualizaciones nativas (más que las automáticas) no funcionan bien con las pilas controladas de forma estricta.
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 parches a Subversion.
Es probable que tengas que ingresar dichos complementos en tu repositorio. O vaya con otro enfoque como Composer.

score 3 · Answer 2

Puede consultar 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 ).

Estoy un poco en el mismo barco con las actualizaciones automáticas, aunque ... Mi plan era actualizar manualmente el submódulo WP cuando las actualizaciones ocurren. Creo que la alternativa es, en teoría (todavía tengo que probarme), dejar que el submódulo se actualice para las actualizaciones menores (hay una configuración de WP para esto) y luego hacer un git force / reset del submódulo cuando las actualizaciones importantes salir (tal vez una de las respuestas aquí podría ser de algo de ayuda ... por supuesto, creo que uno querría apuntar a una etiqueta WP específica cuando se actualice a la próxima versión importante).

Una cosa a tener en cuenta es que si WP ve .git en las rutas, automáticamente apagará las actualizaciones automáticas. Para más información, vea:

Actualizaciones automáticas del núcleo, una actualización

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 están deshabilitadas

Si se definen las constantes DISALLOW_FILE_MODS o AUTOMATIC_UPDATER_DISABLED , las actualizaciones automáticas están deshabilitadas

Si la constante WP_AUTO_UPDATE_CORE se define como falso, las actualizaciones automáticas están deshabilitadas

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 OpenSSL instalado y funcionando

Wp-Cron debe estar operativo, si por alguna razón el cron no funciona para su instalación, las Actualizaciones automáticas tampoco estarán disponibles

Otros enlaces relacionados:

Actualización de mayo de 2015

Creé este repositorio , que es una manera rápida para comenzar proyectos de WordPress. Mi último enfoque es controlar únicamente 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 git extrae mis temas para obtener un sitio funcional.

score 2 · Answer 3

Este tipo de desarrollo cae en el "no es tan fácil y requiere un flujo de trabajo personalizado que puede tardar mucho tiempo en estar contento con".

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

Algunos pensamientos (rastrear todo).

Habilita 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 prueba y notificaciones de actualización por correo electrónico para usted mismo, confirmar las actualizaciones y enviar al servidor activo que tiene desactivadas las actualizaciones automáticas.

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

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

Método automático

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

La automatización de 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, toma tiempo para crear.

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

score 0 · Answer 4

Después de pensar un poco más, ya que definitivamente quiero aprovechar las actualizaciones nativas de WP para ahorrarme el trabajo, no tiene sentido rastrear cualquier cosa 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 forman parte del proyecto desde el VCS, pero realmente solo necesito eso para fines de respaldo, y usaré algún tipo de sistema de respaldo regular de todos modos.

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 el contenido. ¿Alguien tiene alguna idea sobre eso?

score 0 · Answer 5

Bien, 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.