Sono interessato a come gli altri sviluppano temi e plugin per WordPress. Per me, l'editor nel browser nel pannello di amministrazione non lo taglia. Attualmente sto solo usando un IDE con un plugin PHP (NetBeans), tirando giù la mia directory web di sviluppo dal mio server, modificando lì, spingendo verso l'alto per testare e quindi migrando per vivere.

Sto cercando come le altre persone usano i loro strumenti preferiti per gestire i flussi di lavoro per sviluppare, testare e distribuire temi, plugin e testare le ultime versioni di WordPress rispetto a queste prima di andare in diretta.

L'ho trasformato in un wiki della comunità in modo che altre persone possano condividere il processo di sviluppo. Non mi aspetto di trovare una risposta singolare e giusta qui: il tuo processo è tuo e non mi aspetto che quello che fai funzioni solo per me o per chiunque altro. Sono solo interessato a migliorare la mia capacità di sviluppare plugin e temi vedendo cosa funziona o non funziona per altre persone.

Un'altra domanda qui discute strumenti software specifici per supportare lo sviluppo di WordPress . Qui sto cercando ulteriori processi e metodologie che possano essere applicati indipendentemente dagli strumenti, ad eccezione di alcuni compiti che potrebbero essere realizzati solo in una determinata famiglia di strumenti.

Per la cronaca, realizzo principalmente interi siti Web e plugin e li distribuisco. Il mio flusso di lavoro è molto intenso e intenso.

Per iniziare un nuovo progetto, ho uno script di shell che si occupa dell'intera attività di impostare un nuovo vhost e controllare l'ultimo tag di WordPress (dal nostro repository git, che tiene traccia di svn).

La forma base di un intero sito Web è un gps repsotory su wp-content. Che contiene un Capfile (capistrano's Makefile eqiuivalent) e un file di configurazione YAML che insieme si occupano della distribuzione ( http://github.com/dxw/wp-capistrano ). Anche all'interno di quel repository aggiungo il tema e i plug-in come sottomoduli git (sì, manteniamo i repository git anche per plug-in di terze parti - ci piace usare l'ultima versione che abbiamo testato personalmente).

Per il tema, ho uno strumento / framework per la generazione di codice ( github.com/dxw/wp-generate ). Significa meno pensare a dove dovrebbe andare il codice e ha un metodo naturale di separazione tra la vista e il modello / controller.

Quando scrivo plugin uso cetriolo / webrat per lo sviluppo test-driven ( github.com/dxw/cucumber-wordpress ).

E per la migrazione dei database di sviluppo alla produzione, di solito è solo un caso di copia del dump (WP_SITEURL e WP_HOME sono impostati da capistrano sulle macchine di gestione temporanea / produzione, quindi nessuna ricerca / sostituzione).

Non riesco a immaginare quante ore ho salvato con questi script.

@Thomas Owens Questa domanda si sovrappone in qualche modo e duplica la domanda " Software per lo sviluppo di temi / plugin di WordPress?. " Non sono sicuro se dovremmo chiudere, ma sembra essere un focus leggermente diverso. Così...

Mac OS X

Ecco il mio set di strumenti essenziali in questo momento per Max OS X (sempre alla ricerca di meglio.) Nota: ho provato NetBeans e ci ho rinunciato. Funzionalità troppo lente e troppo poche.

• PhpStorm + XDEBUG - Debugging IDE (Niente di meglio sul MAC)
• VirtualHostX - Gestisce localmente gli host virtuali Apache ( ADORO questo)
• FileZilla - Client FTP
• Firefox Firebug - Debug di jQuery
• Navicat per MySQL - Client MySQL commerciale
• Unfuddle.com - Repository SVN e gestione delle attività per i progetti client
• HTTP Scoop - Debugger HTTP ragionevole
• Fraise - Editor di testo leggero (Fork of Smultron )

Windows Vista

Quando ero su Windows Vista il mio set di strumenti essenziale era:

• FileZilla - Client FTP
• Firefox Firebug - Debug di jQuery
• Navicat per MySQL - Client MySQL commerciale
• Unfuddle.com - Repository SVN e gestione delle attività per i progetti client
• PhpED - Debugging IDE (Niente di meglio su Windows, 'forse forse PhpStorm + [XDEBUG] [24])
• HeidiSQL - Ottimo client MySQL open source
• Notepad2 - Ottima alternativa a Notepad leggera e utilizzabile
• TortoiseSVN - Client SVN
• Fiddler 2 - Debugger HTTP imbattibile

Distribuzione del codice / migrazione dei dati per cambiare dominio

Non sono sicuro che sia esattamente quello che stai cercando, ma sviluppo un plugin per facilitare le migrazioni tra server di sviluppo locale, server di test e server di distribuzione. Ne ho scritto qui:

• Come posso spostare facilmente il WP dallo sviluppo alla produzione?

Spero che sia di aiuto

-Mike

Questa è una risposta al flusso di lavoro, non specifica per un IDE o un plugin.

Una soluzione che funziona davvero bene per lo sviluppo di plugin è quella di iniziare con un server web apache locale con ogni variazione di wordpress installata in una sottocartella.

In una posizione separata al di fuori della radice del server locale, archivia le copie funzionanti del plugin / tema wordpress. Crea un collegamento simbolico al trunk / tag / branch appropriato nella cartella / wp-content / plugins di ogni variazione di wordpress.

Quando modifichi il plugin nel tuo IDE, le modifiche apportate saranno ovviamente rappresentate in ogni installazione di wordpress, quindi diventa facile testare più varianti di wordpress.

In sostanza, puoi avere una scheda del browser aperta per ogni variazione di wordpress locale e testarla mentre lavori su un singolo progetto e una singola base di file.

Usando un IDE che supporti SVN e FTP tutto ciò che devi fare è modificare la tua copia di lavoro e ripristinare le modifiche nel repository.

Come IDE Coda lo fa per me, ma mi piacciono anche NetBeans ed Eclipse.

Una volta che sei felice che il tuo plug-in funzioni e hai apportato le modifiche al tuo repository, puoi quindi aprire il tuo progetto wordpress e pubblicare il plug-in modificato direttamente sul tuo sito live.

Ho una configurazione relativamente semplice che si è evoluta da quando ho iniziato il mio lavoro di oggi ~ 2,5 anni fa.

Sviluppando

Faccio tutto il mio sviluppo su SSH, usando Vim all'interno dello schermo GNU . I plugin Vim includono:

• zencoding-vim
• FuzzyFinder

Le spaccature verticali e :set hiddensono essenziali. Preferisco anche un terminale a 256 colori ( iTerm su Mac OS X) con la combinazione di colori dei railscast .

Abbiamo anche modificato lentamente dBug per soddisfare le nostre esigenze. Bello sostituto per print_r()e var_dump()quando sai che la variabile è un array o un oggetto.

Distribuzione

Al momento non lavoro su molti plugin / temi pubblici, quindi non collaudo la compatibilità dei plugin con più versioni di WordPress. Codifico sul server dev e sposto quel codice in produzione tramite Subversion.

Processo di sviluppo del tema WordPress

• Converti il ​​wire frame Mock Flow in XHTML e CSS di base

• Collega XHTML al file template master.php e convertilo in tag Template e funzioni WP

• Dividi master.php nei vari file modello, ad es. Header.php, index.php, sidebar.php e footer.php

• Scrivi eventuali domande e funzioni personalizzate che potrebbero essere necessarie

• Collegare il layout CSS e aggiungere div {outline:1px solid red;}per aiutare a modificare il layout4.

• Carica la cartella Temi su WordPress per test e ulteriore sviluppo

Strumenti di sviluppo di WordPress

• Editor di codice Aptana Studio WorkPlace con FTP integrato

• stucco

• due monitor 1920 x 1200 con browser aperto su uno e editor di codice sull'altro

• Wacom Intuis 4 tablet

• Firebug con velocità Yslow e Google Page

Il mio flusso di lavoro è piuttosto semplice. Continuo con 4 ambienti. Test, sviluppo, stadiazione e produzione.

Flusso di lavoro

Uso git per il mio controllo di revisione; Ignoro il file wp-config.php in modo che questo file non venga sovrascritto mentre spingo e tiro attraverso le diverse posizioni. Uso il disordine come archivio pubblico / centrale per gli altri da cui spingere e tirare.

Questo sembra funzionare abbastanza bene. Mi impegnerò tutte le volte che riesco a ricordare mentre sto lavorando ai test. Almeno una volta al giorno, se non di più, mi sincronizzo con unfuddle e facendo in modo che il server di sviluppo inserisca le modifiche. Cerco di non fare alcun lavoro diretto sul server, quindi prendo principalmente modifiche. Se sono state apportate modifiche significative al database (nuovi plug-in, contenuto aggiornato, ecc.), Lo scaricherò dal mio test; fare un backup dello sviluppo e importare il dump.

Uso lo stesso processo per la stadiazione. La gestione temporanea si trova sullo stesso server di produzione, quindi ricontrolla lo smalto e assicurati che tutte le impostazioni e i moduli funzionino sul server di produzione. Quando sono pronto, eseguo il backup di tutti i file di produzione e del database e copio i file e il database dalla gestione temporanea.

Poiché wp-config.php non è in git, è abbastanza semplice spingere e tirare le cose. Quando si passa alla produzione dalla stadiazione, copio i file e non uso git, quindi devo assicurarmi che wp-config.php sia corretto.

Ho fatto una domanda simliar e esaminerò l'utilizzo di questo plugin.

Ho anche pensato di usare Capistrano; e la creazione di uno script di migrazione molto dettagliato che eseguirà e gestirà tutti i file e i backup / migrazioni del database, nonché l'aggiornamento dei percorsi e degli URL dei file.

Utensili

• Compagno di testo per il mio editor, anche se sto iniziando a usare MacVim. Uso vim su linux.
• Sequel Pro per manipolazione di database. Se non riesco a collegarmi, userò PHPMyAdmin
• Trasmettere per FTP se ne ho bisogno.
• git per controllo di revisione. Principalmente dalla riga di comando, anche se ho usato un po 'il client in Textmate e GittiApp.

Una cosa che mi aiuta (specialmente quando lavoro su più temi client) è l'utilizzo di un'installazione Multisito di WordPress sul mio server di sviluppo. In questo modo, posso avere tutti i lavori aperti necessari e non preoccuparmi del tema A del cliente A. Abbinalo a un pacchetto completo di contenuti di esempio che carico ogni volta che creo un nuovo sito e hai un fantastico sistema di sviluppo.

Faccio da hacking sul posto sul server nelle viscere di un sistema vitale a sviluppo / test / fase / ciclo di vita più strutturati utilizzando sistemi di controllo della versione e test automatizzati. Dipende solo dal lavoro.

Accanto a questo, riporto i bug al progetto wordpress quando li incontro.

Per lo sviluppo di plugin cerco di non reinventare continuamente la ruota in modo da costruirne di nuovi in ​​base a principi e schemi esistenti.

Ecco il mio flusso di lavoro:

• Comincio con la creazione della directory del progetto non appena ottengo i requisiti e i design del sito Web.
• versione the Statice la theme/plugincartella in DynamicCartelle usando Git.

• creare host virtuale per il progetto. Seguo questa convenzione:

  http://project1.dev/

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

• Di solito seguo questa organizzazione di cartelle:

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

Sono consapevole che non uso ancora uno buildstrumento su base giornaliera, il che mi fa stare male.

Ma uso lo strumento di compilazione ANT per il mio progetto Sprite2CSS abbinato a un paio di script PHP per il consumo di ANT.

Utensili

Che io sia su Windows o Ubuntu, utilizzo quanto segue:

• Netbeans + SublimeText2 + Notepad ++
• WAMP - (PHP)
• FakeMail
• Idiota
• Chrome e DevTools + Firefox con Firebug e Safari + IE per i test
• YSlow!
• FTP incorporato di Filezilla / WinSCP / NB
• Cygwin + Prompt dei comandi
• Compositore
• NodoJS + NPM
• SQLYog Community Edition + PHPMyAdmin

Sono aperto a suggerimenti su come migliorare il mio flusso di lavoro.

Lavoro su Windows con Denver , FileZilla, Notepad ++, Firefox Firebug e altri ispettori (i collegamenti erano sopra), cPanel e dbForge Studio per MySQL