Estou interessado em saber como outras pessoas desenvolvem temas e plugins para WordPress. Para mim, o editor no navegador no painel de administração simplesmente não funciona. Atualmente, estou apenas usando um IDE com um plug-in PHP (NetBeans), retirando meu diretório da Web de desenvolvimento do meu servidor, editando lá, pressionando para testar e depois migrando para o live.

Estou procurando como outras pessoas usam suas ferramentas de escolha para gerenciar fluxos de trabalho para desenvolver, testar e implantar temas, plugins e testar as versões mais recentes do WordPress em relação a eles antes de entrar no ar.

Eu criei este wiki da comunidade para que outras pessoas possam compartilhar seu processo de desenvolvimento. Não estou esperando encontrar uma resposta certa e singular aqui - seu processo é seu e não espero que o que você faça funcione apenas para mim ou para outras pessoas. Só estou interessado em melhorar minha capacidade de desenvolver plugins e temas, vendo o que funciona ou não para outras pessoas.

Outra pergunta aqui discute ferramentas de software específicas para apoiar o desenvolvimento do WordPress . Aqui, procuro mais processos e metodologias que possam ser aplicadas independentemente das ferramentas, com exceção de determinadas tarefas que só podem ser realizadas em uma determinada família de ferramentas.

Só para constar, eu faço principalmente sites e plugins, e os implanto. Meu fluxo de trabalho é muito pesado para Ruby e Git.

Para começar em um novo projeto, eu tenho um shell script que cuida de todo o negócio de configurar um novo vhost e verificar a última tag do WordPress (em nosso próprio repositório git, que rastreia svn).

A forma básica de um site inteiro é um repositório git no wp-content. Ele contém um Capfile (Makefile eqiuivalent do capistrano) e um arquivo de configuração YAML que juntos cuidam da implantação ( http://github.com/dxw/wp-capistrano ). Também dentro desse repositório, adiciono o tema e os plugins como submódulos do git (sim, também mantemos repositórios git para plugins de terceiros - gostamos de usar a versão mais recente que testamos pessoalmente).

Para o tema, eu tenho uma ferramenta / estrutura de geração de código ( github.com/dxw/wp-generate ). Significa menos pensar sobre onde o código deve ir e possui um método natural de separação entre a View e o Model / Controller.

Ao escrever plugins, eu uso o pepino / webrat para fazer desenvolvimento orientado a testes ( github.com/dxw/cucumber-wordpress ).

E para migrar bancos de dados de desenvolvimento para produção, geralmente é apenas um caso de copiar o dump over (WP_SITEURL e WP_HOME são definidos por capistrano nas máquinas de preparo / produção, portanto, não é necessário pesquisar / substituir).

Não consigo imaginar quantas horas economizei com esses scripts.

@ Thomas Owens Esta pergunta se sobrepõe e duplica de algum modo a pergunta " Software para WordPress tema / desenvolvimento de plugins?. " Não tenho certeza se devemos fechar, mas parece um foco um pouco diferente. Tão...

Mac OS X

Aqui está o meu conjunto de ferramentas essenciais agora para o Max OS X (sempre procurando por melhores). Nota: eu tentei o NetBeans e desisti dele. Recursos muito lentos e muito poucos.

• PhpStorm + XDEBUG - IDE de depuração (nada melhor no MAC)
• VirtualHostX - Gerencia os hosts virtuais do Apache localmente (eu amo isso)
• FileZilla - Cliente FTP
• Firefox Firebug - Depuração do jQuery
• Navicat for MySQL - cliente MySQL comercial
• Unfuddle.com - Repositório SVN e gerenciamento de tarefas para projetos de clientes
• Colher HTTP - Depurador HTTP razoável
• Fraise - Editor de texto leve (Fork of Smultron )

Windows Vista

Quando eu estava no Windows Vista, meu conjunto de ferramentas essencial era:

• FileZilla - Cliente FTP
• Firefox Firebug - Depuração do jQuery
• Navicat for MySQL - cliente MySQL comercial
• Unfuddle.com - Repositório SVN e gerenciamento de tarefas para projetos de clientes
• PhpED - IDE de depuração (nada melhor no Windows, exceto PhpStorm + [XDEBUG] [24])
• HeidiSQL - Ótimo cliente MySQL de código aberto
• Notepad2 - Ótima alternativa leve e útil para o Notepad
• TortoiseSVN - Cliente SVN
• Fiddler 2 - Depurador HTTP imbatível

Implantação de código / migração de dados para alternar domínios

Não tenho certeza se é exatamente isso que você está procurando, mas desenvolvo um plug-in para facilitar as migrações entre o servidor dev local, o servidor de teste e o servidor de implantação. Eu escrevi sobre isso aqui:

• Como posso mover facilmente o WP do desenvolvimento para a produção?

Espero que isto ajude

-Mike

Esta é uma resposta do fluxo de trabalho, não específica para um IDE ou plugin.

Uma solução que funciona muito bem para o desenvolvimento de plugins é começar com um servidor web apache local com cada variação do wordpress instalada em uma subpasta.

Em um local separado, fora da raiz do servidor local, armazene suas cópias de trabalho do plugin / tema do wordpress. Crie um link simbólico para o trunk / tag / branch apropriado na pasta / wp-content / plugins de cada variação do wordpress.

Ao editar o plugin no seu IDE, as alterações que você fizer serão obviamente representadas em cada instalação do wordpress, tornando-se fácil testar várias variações do wordpress.

Essencialmente, você pode ter uma guia do navegador aberta para cada variação local do wordpress e testar cada uma delas enquanto trabalha em um único projeto e uma única base de arquivos.

Usando um IDE que suporte SVN e FTP, tudo o que você precisa fazer é editar sua cópia de trabalho e confirmar suas alterações no repositório.

Como IDE, o Coda faz isso por mim, mas também gosto do NetBeans e Eclipse.

Quando estiver satisfeito com o funcionamento do seu plug-in e confirmar essas alterações no seu repositório, você poderá abrir o seu projeto wordpress e publicar o plug-in alterado diretamente no seu site ao vivo.

Eu tenho uma configuração relativamente simples que evoluiu desde o início do meu trabalho atual ~ há 2,5 anos.

Em desenvolvimento

Eu faço todo o meu desenvolvimento em SSH, usando o Vim dentro da tela GNU . Os plugins do Vim incluem:

• zencoding-vim
• FuzzyFinder

Divisões verticais e :set hiddensão essenciais. Também prefiro um terminal de 256 cores ( iTerm no Mac OS X) com o esquema de cores do railscasts .

Também modificamos lentamente o dBug para atender às nossas necessidades. Um bom substituto para print_r()e var_dump()quando você sabe que a variável é uma matriz ou objeto.

Implantando

No momento, não trabalho em muitos plugins / temas públicos, por isso não testo a compatibilidade de plugins com várias versões do WordPress. Eu codifico no servidor dev e movo esse código para produção via Subversion.

Processo de Desenvolvimento de Temas WordPress

• Converter armação de arame Mock Flow em XHTML e CSS básico

• Conecte o XHTML ao arquivo de modelo master.php e converta-o em tags de modelo e funções WP

• Divida master.php nos vários arquivos de modelo, por exemplo: header.php, index.php, sidebar.php e footer.php

• Escreva quaisquer consultas e funções personalizadas que possam ser necessárias

• Conecte o layout CSS e adicione div {outline:1px solid red;}para ajudar a ajustar o layout4.

• Faça o upload da pasta Theme para WordPress para teste e desenvolvimento

Ferramentas de desenvolvimento WordPress

• Editor de código do Aptana Studio WorkPlace com FTP embutido

• Putty

• monitores duplos de 1920 x 1200 com navegador aberto em um e editor de código no outro

• Wacom Intuis 4 comprimido

• Firebug com Yslow e velocidade da página do Google

Meu fluxo de trabalho é bem simples. Eu acompanho 4 ambientes. Teste, Desenvolvimento, Preparação e Produção.

Fluxo de trabalho

Eu uso o git para meu controle de revisão; Eu ignoro o arquivo wp-config.php para que ele não seja sobrescrito à medida que empurro e puxo os diferentes locais. Eu uso unfuddle como repositório público / central para que outros possam empurrar e puxar.

Isso parece funcionar bastante bem. Comprometerei sempre que me lembro enquanto estiver trabalhando no teste. Pelo menos uma vez por dia, se não mais, sincronizo com o desembrulhar e com o servidor de Desenvolvimento para fazer as alterações. Eu tento não fazer nenhum trabalho direto no servidor, por isso estou apenas efetuando alterações. Se foram feitas alterações significativas no banco de dados (novos plug-ins, conteúdo atualizado etc.), eu o despejo do meu Teste; faça um backup do Development e importe o dump.

Eu uso o mesmo processo para teste. O armazenamento temporário fica no mesmo servidor que a produção. Verifique novamente o polimento e verifique se todas as configurações e módulos estão funcionando no servidor de produção. Quando estou pronto, faço backup de todos os arquivos e banco de dados de produção e copio os arquivos e o banco de dados da preparação.

Como o wp-config.php não está no git, torna bastante simples empurrar e puxar as coisas. Ao passar para a produção do preparo, copio os arquivos e não uso o git, portanto, tenho que garantir que o wp-config.php esteja correto.

Fiz uma pergunta semelhante e vou examinar o uso deste plugin.

Também pensei em usar o Capistrano; e criar um script de migração muito detalhado que examinará e manipulará todos os arquivos e backups / migrações de banco de dados, além de atualizar os caminhos e URLs dos arquivos.

Ferramentas

• Textmate para o meu editor, embora eu esteja começando a usar o MacVim. Eu uso o vim quando no linux.
• Sequel Pro para manipulação de banco de dados. Se não conseguir me conectar, usarei o PHPMyAdmin
• Transmitir para FTP, se eu precisar.
• git para controle de revisão. Principalmente por linha de comando, embora eu esteja usando o cliente no Textmate e no GittiApp um pouco.

Uma coisa que me ajuda (especialmente ao trabalhar com vários temas de clientes) é usar uma instalação Multisite do WordPress no meu servidor de desenvolvimento. Dessa forma, eu posso ter tantos empregos abertos quanto necessário e não me preocupar com o cliente A vendo o tema do cliente B. Junte isso a um pacote abrangente de conteúdo de amostra que eu carrego toda vez que crio um novo site, e você tem um sistema de desenvolvimento incrível.

Eu faço desde o hacking no local no servidor nas entranhas de um sistema de vida até um desenvolvimento / teste / estágio / ciclo de vida mais estruturado usando sistemas de controle de versão e testes automatizados. Depende apenas do trabalho.

Depois disso, relato bugs de volta ao projeto wordpress quando os atropelo.

Para o desenvolvimento de plugins, tento não reinventar a roda o tempo todo, de modo a criar novos com base nos princípios e padrões existentes.

Aqui está o meu fluxo de trabalho:

• Começo com a criação do diretório do projeto assim que recebo os requisitos e os designs do site.
• versão Statice theme/pluginpasta nas Dynamicpastas usando o Git.

• crie um host virtual para o projeto. Eu sigo esta convenção:

  http://project1.dev/

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

• Eu costumo seguir esta organização de pastas:

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

Estou ciente de que ainda não uso uma buildferramenta no dia a dia, o que me faz sentir mal.

Mas eu uso a ferramenta de construção ANT para o meu projeto Sprite2CSS, juntamente com alguns scripts PHP para o consumo da ANT.

Ferramentas

Seja no Windows ou no Ubuntu, uso o seguinte:

• Netbeans + SublimeText2 + Bloco de notas ++
• WAMP - (PHP)
• FakeMail
• Git
• Chrome e DevTools + Firefox com Firebug e Safari + IE para teste
• YSlow!
• FTP embutido no Filezilla / WinSCP / NB
• Prompt de comando Cygwin +
• Compositor
• NodeJS + NPM
• SQLYog Community Edition + PHPMyAdmin

Estou aberto a sugestões para melhorar meu fluxo de trabalho.

Trabalho no Windows com Denver , FileZilla, Notepad ++, Firefox Firebug e outros inspetores (links acima), cPanel e dbForge Studio for MySQL