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

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

La forma básica de todo un sitio web es un git repsotory en wp-content. Que contiene un Capfile (Makefile eqiuivalent de Capistrano) y un archivo de configuración YAML que juntos se encargan de la implementación ( enlace ). También dentro de ese repositorio, agrego el tema y los complementos como submódulos de git (sí, también mantenemos repositorios de 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 debería 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 realizar un desarrollo guiado por pruebas ( github.com/dxw/cucumber-wordpress).

Y para migrar las bases de datos de desarrollo a producción, generalmente es solo un caso de copiar el volcado (WP_SITEURL y WP_HOME están configurados por capistrano en las máquinas de producción / puesta en escena, por lo que no hay que buscar / reemplazar).

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

@Thomas Owens Esta pregunta se superpone y duplica un poco la pregunta " ¿Software para el desarrollo de temas / complementos de WordPress? ." No estoy seguro si deberíamos cerrar, pero parece ser un enfoque ligeramente diferente. Entonces ...

Mac OS X

Aquí está mi conjunto de herramientas esencial ahora mismo para Max OS X (siempre buscando algo mejor). Nota, probé NetBeans y renuncié a él. 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 (I LOVE esto)
• FileZilla - Cliente FTP
• Firefox Firebug - depuración de jQuery
• Navicat for MySQL - Cliente MySQL comercial
• Unfuddle.com - Repositorio SVN y administración de tareas para proyectos de clientes
• HTTP Scoop - Depurador de HTTP Razonable
• Fraise - Editor de texto ligero (Horquilla de Smultron )

Windows Vista

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

• FileZilla - Cliente FTP
• Firefox Firebug - jQuery Debugging
• Navicat for MySQL - Cliente comercial de MySQL
• Unfuddle.com - Repositorio SVN y administración de tareas para proyectos de clientes
• PhpED : depuración de IDE (No hay nada mejor en Windows, por ejemplo, PhpStorm + [XDEBUG] [24])
• HeidiSQL - Gran cliente MySQL de código abierto
• Notepad2 : una excelente alternativa de Notepad liviana y utilizable
• TortoiseSVN - Cliente SVN
• Fiddler 2 - Depurador de HTTP insuperable

Implementación de código / Migración de datos para cambiar dominios

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 el WP del desarrollo a la producción?

Espero que esto ayude

-Mike

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

Una solución que funciona realmente bien para el desarrollo de complementos es comenzar con un servidor web local de 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 sus copias de trabajo de wordpress plugin / theme. Cree un enlace simbólico al tronco / etiqueta / rama correspondiente 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 única base de archivos.

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

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

Una vez que esté contento de que su complemento funcione y haya realizado 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 aproximadamente 2,5 años.

Desarrollando

Realizo todo mi desarrollo sobre SSH, utilizando Vim dentro de pantalla GNU . Los complementos de Vim incluyen:

• zencoding-vim
• FuzzyFinder

Las divisiones verticales y :set hidden son esenciales. También prefiero un terminal de 256 colores ( iTerm en Mac OS X) con railscasts combinación de colores.

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

Implementación

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

Proceso de desarrollo del tema 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 a etiquetas de plantilla y funciones WP

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

• Escriba cualquier consulta personalizada y funciones que podrían ser necesarias

• Conecte el diseño CSS y agregue div {outline:1px solid red;} para ayudar ajustar la disposición 4.

• Cargar carpeta de temas en WordPress para Pruebas y desarrollo adicional

Herramientas de desarrollo de WordPress

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

• Putty

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

• Tableta Wacom Intuis 4

• Firebug con Yslow y la velocidad de la página de Google

Mi flujo de trabajo es bastante simple. Sigo 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 empujo y arrastre las diferentes ubicaciones. Utilizo unfuddle como el repositorio público / central para que otros puedan empujar y jalar.

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

Utilizo el mismo proceso para la puesta en escena. La puesta en escena se ubica en el mismo servidor que la producción; verifica dos veces el pulido y se asegura de que todas las configuraciones y los módulos estén funcionando 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 sencillo empujar y tirar cosas. Al pasar a la 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.

Le he pedido a un simliar pregunta , y voy a estudiar el uso de este complemento.

También he pensado en usar Capistrano; y la creación de un script de migración muy detallado que pasará y manejará todos los archivos y las copias de seguridad / migraciones de la base de datos, así como la actualización de las rutas de los archivos y las URL.

Herramientas

• Compañero de texto para mi editor, aunque estoy empezando a usar MacVim. Uso vim cuando estoy en linux.
• Sequel Pro para la manipulación de bases de datos. Si no puedo conectarme con él, usaré PHPMyAdmin
• Transmita 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 se trabaja en varios temas de clientes) es usar una instalación de WordPress Multisite en mi servidor dev. De esa manera, puedo tener tantos trabajos abiertos como sea necesario, y no preocuparme por el cliente A viendo el tema B del cliente. Combine esto con un paquete completo de contenido de muestra que carga cada vez que creo un sitio nuevo y tendrá un sistema de desarrollo increíble.

Lo hago desde la piratería in situ en el 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.

Al lado de eso, informo los errores al proyecto wordpress cuando los ejecuto.

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 con la creación del directorio del proyecto en cuanto recibo los requisitos y los diseños del sitio web.
• versione las carpetas Static y theme/plugin en las carpetas Dynamic usando Git.

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

  enlace

  enlace (opcionalmente)

• Por lo general, 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 herramienta build todos los días, lo que me hace sentir mal.

Pero sí uso la herramienta de construcció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 en Ubuntu, uso lo siguiente:

• Netbeans + SublimeText2 + Notepad ++
• WAMP - (PHP)
• FakeMail
• Git
• Chrome y DevTools + Firefox con Firebug y Safari + IE para pruebas
• YSlow!
• FTP integrado en Filezilla / WinSCP / NB
• indicador de comando de Cygwin +
• compositor
• NodeJS + 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