Estoy interesado en cómo otras personas desarrollan temas y complementos para WordPress. Para mí, el editor en el navegador en el panel de administración simplemente no es suficiente. Actualmente, solo estoy usando un IDE con un complemento PHP (NetBeans), bajando mi directorio web de desarrollo desde mi servidor, editando allí, presionando para probar y luego migrando para vivir.

Estoy buscando cómo otras personas usan sus herramientas de elección para administrar los flujos de trabajo para desarrollar, probar e implementar temas, complementos y probar las últimas versiones de WordPress contra estos antes de lanzarse.

He hecho de esto un wiki comunitario para que otras personas puedan compartir el proceso de desarrollo. No espero encontrar una respuesta correcta singular aquí: su proceso es suyo, y no esperaría que lo que haga solo funcione para mí o para cualquier otra persona. Solo estoy interesado en mejorar mi capacidad para desarrollar complementos y temas al ver qué funciona o no para otras personas.

Otra pregunta aquí analiza herramientas de software específicas para admitir el desarrollo de WordPress . Aquí, estoy buscando más procesos y metodologías que puedan aplicarse independientemente de las herramientas, con la excepción de ciertas tareas que solo se pueden lograr en una determinada familia de herramientas.

Para el registro, principalmente hago sitios web completos y complementos, y los implemento. Mi flujo de trabajo es muy pesado con Ruby y git.

Para comenzar un nuevo proyecto, tengo un script de shell que se encarga de todo el negocio de configurar un nuevo vhost y verificar la última etiqueta de WordPress (desde nuestro propio repositorio git, que rastrea svn).

La forma básica de un sitio web completo es un repositorio git en wp-content. Contiene un Capfile (el equivalente del Makefile del Capistrano) y un archivo de configuración YAML que juntos se encargan de la implementación ( http://github.com/dxw/wp-capistrano ). También dentro de ese repositorio agrego el tema y los complementos como submódulos git (sí, también mantenemos repositorios git para complementos de terceros; nos gusta usar la última versión que hemos probado personalmente).

Para el tema, tengo una herramienta / marco de generación de código ( github.com/dxw/wp-generate ). Significa menos pensar en dónde debe ir el código, y tiene un método natural de separación entre la Vista y el Modelo / Controlador.

Cuando escribo complementos, uso cucumber / webrat para hacer un desarrollo basado en pruebas ( github.com/dxw/cucumber-wordpress ).

Y para migrar bases de datos de desarrollo a producción, generalmente solo se trata de copiar el volcado (WP_SITEURL y WP_HOME son configurados por capistrano en las máquinas de producción / preparación, por lo que no es necesario buscar / reemplazar).

No puedo imaginar cuántas horas he ahorrado con estos scripts.

@Thomas Owens Esta pregunta se superpone y duplica la pregunta "¿ Software para desarrollo de tema / plugin de WordPress? ". No estoy seguro de si deberíamos cerrar, pero parece un enfoque ligeramente diferente. Asi que...

Mac OS X

Aquí está mi conjunto de herramientas esencial en este momento para Max OS X (siempre buscando algo mejor). Tenga en cuenta que probé NetBeans y me di por vencido. Demasiado lento y muy pocas características.

• PhpStorm + XDEBUG - Depuración de IDE (Nada mejor en el MAC)
• VirtualHostX : administra los hosts virtuales de Apache localmente ( ME ENCANTA )
• FileZilla - Cliente FTP
• Firefox Firebug - Depuración de jQuery
• Navicat para MySQL - Cliente comercial MySQL
• Unfuddle.com - SVN Repository and Task Management para proyectos de clientes
• HTTP Scoop : depurador HTTP razonable
• Fraise - Editor de texto ligero (Tenedor de Smultron )

Windows Vista

Cuando estaba en Windows Vista, mi conjunto de herramientas esencial era:

• FileZilla - Cliente FTP
• Firefox Firebug - Depuración de jQuery
• Navicat para MySQL - Cliente comercial MySQL
• Unfuddle.com - SVN Repository and Task Management para proyectos de clientes
• PhpED - Depuración de IDE (Nada mejor en Windows, excepto quizás PhpStorm + [XDEBUG] [24])
• HeidiSQL - Gran cliente MySQL de código abierto
• Notepad2 - Gran alternativa de Notepad ligera y utilizable
• TortoiseSVN - Cliente SVN
• Fiddler 2 : depurador HTTP inmejorable

Implementación de código / migración de datos para cambiar de dominio

No estoy seguro de si esto es exactamente lo que está buscando, pero desarrollo un complemento para facilitar las migraciones entre el servidor de desarrollo local, el servidor de prueba y el servidor de implementación. Escribí sobre esto aquí:

• ¿Cómo puedo mover fácilmente WP del desarrollo a la producción?

Espero que esto ayude

-Micro

Esta es una respuesta de flujo de trabajo, no específica de un IDE o complemento.

Una solución que funciona realmente bien para el desarrollo de complementos es comenzar con un servidor web local apache con cada variación de wordpress instalada en una subcarpeta.

En una ubicación separada fuera de la raíz del servidor local, almacene su complemento de WordPress / copias de trabajo del tema. Cree un enlace simbólico a la troncal / etiqueta / rama apropiada en la carpeta / wp-content / plugins de cada variación de wordpress.

Al editar el complemento en su IDE, los cambios que realice, obviamente estarán representados en cada instalación de WordPress, por lo que es fácil probar múltiples variaciones de WordPress.

Esencialmente, puede tener una pestaña del navegador abierta para cada variación de wordpress local y probar cada una mientras trabaja en un solo proyecto y una base de archivos única.

Utilizando un IDE que admita SVN y FTP, todo lo que necesita hacer es editar su copia de trabajo y confirmar sus cambios en el repositorio.

Como IDE, Coda lo hace por mí, pero también me gustan NetBeans y Eclipse.

Una vez que esté satisfecho de que su complemento funcione y haya confirmado esos cambios en su repositorio, puede abrir su proyecto de WordPress y publicar el complemento modificado directamente en su sitio en vivo.

Tengo una configuración relativamente sencilla que ha evolucionado desde que comencé mi trabajo actual hace ~ 2.5 años.

Desarrollando

Hago todo mi desarrollo sobre SSH, usando Vim dentro de la pantalla GNU . Los complementos de Vim incluyen:

• zencoding-vim
• FuzzyFinder

Las divisiones verticales y :set hiddenson esenciales. También prefiero un terminal de 256 colores ( iTerm en Mac OS X) con el esquema de color de railscasts .

También hemos estado modificando lentamente dBug para satisfacer nuestras necesidades. Un buen reemplazo para print_r()y var_dump()cuando sabes que la variable es una matriz u objeto.

Desplegando

Actualmente no trabajo en muchos plugins / temas públicos, por lo que no pruebo la compatibilidad de plugins con múltiples versiones de WordPress. Codifico en el servidor de desarrollo y muevo ese código a producción a través de Subversion.

Proceso de desarrollo de temas de WordPress

• Convierta el marco de alambre de Mock Flow en XHTML y CSS básicos

• Conecte XHTML en el archivo de plantilla master.php y conviértalo en etiquetas de plantilla y funciones WP

• Divida master.php en varios archivos de plantilla, es decir: header.php, index.php, sidebar.php y footer.php

• Escriba las consultas y funciones personalizadas que puedan ser necesarias.

• Conecte el diseño CSS y agréguelo div {outline:1px solid red;}para ayudar a ajustar el diseño4.

• Cargue la carpeta de temas en WordPress para probar y seguir desarrollando

Herramientas de desarrollo de WordPress

• Editor de código Aptana Studio WorkPlace con FTP incorporado

• Masilla

• monitores duales de 1920 x 1200 con navegador abierto en uno y editor de código en el otro

• Tableta Wacom Intuis 4

• Firebug con velocidad de Yslow y Google Page

Mi flujo de trabajo es bastante simple. Me mantengo al día con 4 ambientes. Pruebas, desarrollo, puesta en escena y producción.

Flujo de trabajo

Yo uso git para mi control de revisión; Ignoro el archivo wp-config.php para que este archivo no se sobrescriba cuando presiono y jalo a través de las diferentes ubicaciones. Utilizo Unuddle como repositorio público / central para que otros puedan empujar y tirar.

Esto parece funcionar bastante bien. Me comprometeré con la frecuencia que pueda recordar mientras estoy trabajando en las Pruebas. Al menos una vez al día, si no más, me sincronizo con Unuddledle y haciendo que el servidor de Desarrollo introduzca los cambios. Intento no hacer ningún trabajo directo en el servidor, por lo que principalmente estoy haciendo cambios. Si se realizaron cambios significativos en la base de datos (nuevos complementos, contenido actualizado, etc.), lo volcaré de mis Pruebas; haga una copia de seguridad del desarrollo e importe el volcado.

Yo uso el mismo proceso para la puesta en escena. La puesta en escena se encuentra en el mismo servidor que la producción; verifique dos veces el pulido y asegúrese de que todas las configuraciones y módulos funcionen en el servidor de producción. Cuando estoy listo, hago una copia de seguridad de todos los archivos de producción y la base de datos, y copio los archivos y la base de datos desde la puesta en escena.

Dado que wp-config.php no está en git, hace que sea bastante simple empujar y tirar cosas. Cuando paso a producción desde la puesta en escena, copio los archivos y no uso git, así que tengo que asegurarme de que wp-config.php sea correcto.

He hecho una pregunta similar y voy a analizar el uso de este complemento.

También he pensado en usar Capistrano; y creando una secuencia de comandos de migración muy detallada que pasará y manejará todos los archivos y las copias de seguridad / migraciones de la base de datos, así como actualizará las rutas de los archivos y las URL.

Herramientas

• Textmate para mi editor, aunque estoy empezando a usar MacVim. Yo uso vim cuando en Linux.
• Sequel Pro para la manipulación de bases de datos. Si no puedo conectarme con él, usaré PHPMyAdmin
• Transmitir por FTP si lo necesito.
• Git para el control de revisión. Principalmente por línea de comandos, aunque he estado usando el cliente en Textmate y GittiApp un poco.

Una cosa que me ayuda (especialmente cuando trabajo en múltiples temas de clientes) es usar una instalación de WordPress Multisite en mi servidor de desarrollo. De esa manera, puedo tener tantos trabajos abiertos como sea necesario, y no preocuparme de que el cliente A vea el tema del cliente B. Combine esto con un paquete integral de contenido de muestra que cargo cada vez que creo un nuevo sitio, y tiene un sistema de desarrollo increíble.

Lo hago desde el pirateo en el lugar del servidor en las entrañas de un sistema de vida hasta un desarrollo / prueba / etapa / ciclo de vida más estructurado utilizando sistemas de control de versiones y pruebas automatizadas. Solo depende del trabajo.

Además de eso, reporto errores al proyecto de WordPress cuando los atropello.

Para el desarrollo de complementos, trato de no reinventar la rueda todo el tiempo para construir nuevos basados ​​en los principios y patrones existentes.

Aquí está mi flujo de trabajo:

• Comienzo a crear el directorio del proyecto tan pronto como obtengo los requisitos y diseños del sitio web.
• versión Staticy la theme/plugincarpeta en DynamicCarpetas usando Git.

• crear host virtual para el proyecto. Sigo esta convención:

  http://project1.dev/

  http://project1.static.dev (opcionalmente)

• Normalmente sigo esta organización de carpetas:

  Projects
         Project1Name
                     Docs //Requirements docs, emails, other related documents. 
                          //This directory may contain directories with  names as dates
                          //(e.g 2014-01-01) to stay super organized :)    
                     Designs //All PSDs go here  
                     Data  //Database backup for the project,
                     Site
                         Dynamic //WordPress generally
                         Static //I don't always create a static version. I did a couple  
                                //of times in the past. I use the same structure inside
                                //the theme or plugin I'm developing
                               js
                               css
                               img
  
         Project2Name and so on ...

Soy consciente de que todavía no uso una buildherramienta en el día a día, lo que me hace sentir mal.

Pero sí uso la herramienta de compilación ANT para mi proyecto Sprite2CSS junto con un par de scripts PHP para el consumo de ANT.

Herramientas

Ya sea que esté en Windows o Ubuntu, uso lo siguiente:

• Netbeans + SublimeText2 + Notepad ++
• WAMP - (PHP)
• FakeMail
• Git
• Chrome y DevTools + Firefox con Firebug y Safari + IE para probar
• YSlow!
• FTP integrado en Filezilla / WinSCP / NB
• Indicador de comando de Cygwin +
• Compositor
• NodoJS + NPM
• SQLYog Community Edition + PHPMyAdmin

Estoy abierto a sugerencias para mejorar mi flujo de trabajo.

Trabajo en Windows con Denver , FileZilla, Notepad ++, Firefox Firebug y otros inspectores (los enlaces estaban arriba), cPanel y dbForge Studio para MySQL