Que processo você usa para o desenvolvimento do WordPress? [fechadas]

37

Estou interessado em saber como outras pessoas desenvolvem temas e plugins para o WordPress. Para mim, o editor do navegador no painel de administração simplesmente não o corta. Atualmente, estou usando apenas um IDE com um plug-in do PHP (NetBeans), removendo meu diretório da web de desenvolvimento do meu servidor, editando lá, testando e 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, plug-ins e testar as versões mais recentes do WordPress em relação a elas antes de serem publicadas.

Eu criei um wiki da comunidade para que outras pessoas possam compartilhar o processo de desenvolvimento. Eu não estou esperando encontrar uma resposta correta aqui - seu processo é o seu, e eu não esperaria que o que você fizesse funcionasse para mim ou para qualquer outra pessoa. Estou interessado apenas em melhorar minha capacidade de desenvolver plug-ins e temas, vendo o que funciona ou não para outras pessoas.

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

    
por Thomas Owens 13.04.2017 / 14:37
fonte

10 respostas

20

Para o registro, eu principalmente faço sites e plugins inteiros, e os implanto. Meu fluxo de trabalho é muito pesado e pesado.

Para começar um novo projeto, eu tenho um script de shell que cuida de todo o negócio de configurar um novo vhost e verificar a tag mais recente do WordPress (do nosso próprio repositório git, que controla o svn). / p>

A forma básica de um site inteiro é um repositório do wp-content. Que contém um Capfile (arquivo Makefile eqiuivalent do capistrano) e um arquivo de configuração YAML que juntos cuidam da implantação ( enlace ). Também dentro desse repositório eu adiciono o tema e plugins como git sub-modules (sim, nós também mantemos repositórios git para plugins de terceiros - nós gostamos de usar a última versão 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 tem um método natural de separação entre o View e o Model / Controller.

Quando escrevo plugins eu uso o cucumber / webrat para fazer desenvolvimento orientado a testes ( github.com/dxw/cucumber-wordpress).

E para migrar bancos de dados de desenvolvimento para produção, normalmente é apenas um caso de copiar o dump (WP_SITEURL e WP_HOME são definidos pelo capistrano nas máquinas de teste / produção, portanto, não procure / substitua).

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

    
por holizz 08.07.2011 / 06:44
fonte
6

@ Thomas Owens Essa pergunta sobrepõe e duplica a pergunta " Software para desenvolvimento de tema / plugin WordPress? ." Não tenho certeza se devemos fechar, mas parece um foco ligeiramente diferente. Então ...

Mac OS X

Aqui está meu conjunto de ferramentas essencial agora para Max OS X (sempre procurando por melhor.) Note que eu tentei o NetBeans e desisti dele. Muito lento e com poucos recursos.

Windows Vista

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

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

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

Espero que isso ajude

-Mike

    
por MikeSchinkel 13.04.2017 / 14:37
fonte
5

Esta é uma resposta de fluxo de trabalho, não específica para um IDE ou plug-in.

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

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

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

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

Usando um IDE que suporte SVN & FTP tudo que você precisa fazer é editar sua cópia de trabalho e enviar suas alterações de volta ao repositório.

Como um IDE, a Coda faz isso para mim, mas também gosto do NetBeans e do Eclipse.

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

    
por leetagg 20.08.2010 / 03:53
fonte
3

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

Desenvolvendo

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

Os divisões verticais e :set hidden são essenciais. Eu também prefiro um terminal de 256 cores ( iTerm no Mac OS X) com o railscasts .

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

Implantando

Atualmente não trabalho em muitos plug-ins / 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.

    
por Annika Backstrom 20.08.2010 / 04:23
fonte
3

Processo de desenvolvimento de temas para WordPress

  • Converter quadro 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 do WP

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

  • Escreva qualquer consulta personalizada e funções que podem ser necessárias

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

  • Carregue a pasta Tema para o WordPress para teste e desenvolvimento adicional

Ferramentas de desenvolvimento para WordPress

  • Editor de códigos do Aptana Studio WorkPlace com construído em FTP

  • Massa de vidraceiro

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

  • Wacom Intuis 4 tablet

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

por Chris_O 20.08.2010 / 05:06
fonte
3

Meu fluxo de trabalho é bem simples. Eu continuo com 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 este arquivo não seja sobrescrito enquanto eu pressiono e puxo os diferentes locais. Eu uso unfuddle como o repositório público / central para os outros empurrarem e puxarem.

Isso parece funcionar razoavelmente bem. Vou me comprometer tantas vezes quanto me lembro enquanto estou trabalhando no teste. Pelo menos uma vez por dia, se não mais, eu sincronizo com unfuddle e tendo o servidor de Desenvolvimento puxando as mudanças. Eu tento não fazer nenhum trabalho direto no servidor, então estou apenas fazendo alterações. Se houve mudanças significativas no banco de dados (novos plugins, conteúdo atualizado, etc), então eu vou fazer o dump do meu teste; faça um backup do Development e importe o dump.

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

Como o wp-config.php não está no git, ele simplifica muito o push e o pull das coisas. Ao mover para a produção a partir do staging, eu copio os arquivos, e não uso o git, então eu tenho que ter certeza que o wp-config.php está correto.

Eu perguntei a um pergunta , e eu vou olhar para usar este plugin.

Eu também pensei em usar o Capistrano; e criar um script de migração muito detalhado que passará por 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 vim quando no linux.
  • Sequel Pro para manipulação de banco de dados. Se eu não conseguir me conectar com ele, usarei o PHPMyAdmin
  • Transmitir para FTP se eu precisar.
  • git para controle de revisão. Principalmente pela linha de comando, embora eu tenha usado o cliente no Textmate e GittiApp um pouco.
por Ryan Gibbons 13.04.2017 / 14:37
fonte
1

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

    
por Keith S. 21.08.2010 / 21:24
fonte
0

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

Além disso, eu relato bugs de volta ao projeto wordpress quando os atropelo.

Para o desenvolvimento de plugins, tento não reinventar a roda o tempo todo, para construir novos baseados nos princípios e padrões existentes.

    
por hakre 24.08.2010 / 14:39
fonte
0

Este é o meu fluxo de trabalho:

  • Eu começo a criar o diretório do projeto assim que obtenho os requisitos e designs do site.
  • versão da pasta Static e theme/plugin em Dynamic pastas usando o Git.
  • crie um host virtual para o projeto. Eu sigo esta convenção:

    enlace

    enlace (opcionalmente)

  • 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 ferramenta build 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

Se estou no Windows ou no Ubuntu, uso o seguinte:

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

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

    
por JeyKeu 10.02.2015 / 13:59
fonte
0

Eu trabalho no Windows com o Denver , o FileZilla, o Notepad ++, o Firefox Firebug e outros inspetores (os links estavam acima), cPanel e dbForge Studio para MySQL

    
por Michael Pozdnakov 05.01.2017 / 09:13
fonte