Je suis intéressé par la façon dont d'autres personnes développent des thèmes et des plugins pour WordPress. Pour moi, l'éditeur intégré au navigateur dans le panneau d'administration ne le coupe pas. Actuellement, j'utilise simplement un IDE avec un plugin PHP (NetBeans), en extrayant mon répertoire Web de développement de mon serveur, en le modifiant, en le testant, puis en migrant.

Je cherche comment d'autres personnes utilisent les outils de leur choix pour gérer les flux de travail afin de développer, tester et déployer des thèmes, des plug-ins et de tester les dernières versions de WordPress par rapport à ceux-ci avant de les mettre en ligne.

J'ai fait de ce wiki une communauté afin que d'autres personnes puissent partager leur processus de développement. Je ne m'attends pas à trouver une réponse juste et singulière ici - votre processus est le vôtre, et je ne m'attendrais pas à ce que vous fassiez fonctionne uniquement pour moi ou pour quelqu'un d'autre. Je suis simplement intéressé par l'amélioration de ma capacité à développer des plugins et des thèmes en voyant ce qui fonctionne ou non pour d'autres personnes.

Une autre question ici traite des outils logiciels spécifiques pour soutenir le développement WordPress . Ici, je recherche davantage de processus et de méthodes pouvant être appliqués indépendamment des outils, à l’exception de certaines tâches qui ne pourraient être accomplies que dans une certaine famille d’outils.

Pour mémoire, je réalise principalement des sites Web et des plugins entiers, et les déploie. Mon flux de travail est très lourd et très lourd.

Pour commencer un nouveau projet, j'ai un script shell qui s'occupe de la configuration d'un nouveau vhost et du dernier tag de WordPress (à partir de notre propre référentiel git, qui suit svn).

La forme de base de tout un site Web est une représentation git sur wp-content. Cela contient un fichier Capfile (l'équivalent Makefile de capistrano) et un fichier de configuration YAML qui, ensemble, se chargent du déploiement ( http://github.com/dxw/wp-capistrano ). Également à l'intérieur de ce référentiel, j'ajoute le thème et les plugins en tant que sous-modules git (oui, nous gérons des référentiels git pour les plugins tiers - nous aimons utiliser la dernière version que nous avons testée personnellement).

Pour le thème, j'ai un outil / framework de génération de code ( github.com/dxw/wp-generate ). Cela signifie moins de réflexion sur l'endroit où le code devrait aller, et il a une méthode naturelle de séparation entre la vue et le modèle / contrôleur.

Lorsque j'écris des plugins, j'utilise concombre / webrat pour effectuer un développement piloté par les tests ( github.com/dxw/cucumber-wordpress ).

Et pour migrer les bases de développement vers la production, il s’agit généralement de copier le dump sur (WP_SITEURL et WP_HOME sont définis par capistrano sur les machines de transfert / production, donc aucune recherche / remplacement).

Je ne peux pas imaginer combien d'heures j'ai économisé avec ces scripts.

@Thomas Owens Cette question recoupe quelque peu la question " Logiciel pour le développement de thèmes / plugins pour WordPress? ". Je ne sais pas si nous devrions fermer mais cela semble être un objectif légèrement différent. Alors...

Mac OS X

Voici mon ensemble d’outils essentiels en ce moment pour Max OS X (toujours à la recherche de meilleurs). Remarque: j’ai essayé NetBeans et j’ai abandonné. Trop lent et trop peu de fonctionnalités.

• PhpStorm + XDEBUG - Débogage IDE (Rien de mieux sur le MAC)
• VirtualHostX - Gère localement les hôtes virtuels Apache ( J'AIME ça)
• FileZilla - Client FTP
• Firefox Firebug - Débogage jQuery
• Navicat for MySQL - Client commercial MySQL
• Unfuddle.com - Référentiel SVN et gestion des tâches pour les projets clients
• HTTP Scoop - Débogueur HTTP raisonnable
• Fraise - Éditeur de texte léger (Fork of Smultron )

Windows Vista

Lorsque j'étais sous Windows Vista, mon ensemble d'outils essentiels était le suivant:

• FileZilla - Client FTP
• Firefox Firebug - Débogage jQuery
• Navicat for MySQL - Client commercial MySQL
• Unfuddle.com - Référentiel SVN et gestion des tâches pour les projets clients
• PhpED - Débogage IDE (Rien de mieux sous Windows, mais peut-être PhpStorm + [XDEBUG] [24])
• HeidiSQL - Excellent client MySQL open-source
• Notepad2 - Une excellente alternative au Bloc-notes, léger et utilisable
• TortoiseSVN - Client SVN
• Fiddler 2 - Débogueur HTTP imbattable

Déploiement de code / migration de données pour changer de domaine

Vous ne savez pas si c'est exactement ce que vous recherchez, mais je développe un plug-in pour faciliter les migrations entre un serveur de développement local, un serveur de test et un serveur de déploiement. J'ai écrit à propos de cela ici:

• Comment puis-je déplacer facilement WP du développement à la production?

J'espère que cela t'aides

-Mike

C'est une réponse de workflow, non spécifique à un IDE ou à un plugin.

Une solution qui fonctionne vraiment bien pour le développement de plugins consiste à démarrer avec un serveur Web Apache local avec chaque variante de wordpress installée dans un sous-dossier.

Dans un emplacement séparé en dehors de la racine du serveur local, stockez vos copies de travail pour le plugin / thème wordpress. Créez un lien symbolique vers le trunk / tag / branch approprié dans le dossier / wp-content / plugins de chaque variante wordpress.

Lors de l’édition du plugin dans votre IDE, les modifications que vous apportez seront bien évidemment représentées à chaque installation de wordpress, il sera donc facile de tester plusieurs variantes de wordpress.

Pour l’essentiel, vous pouvez ouvrir un onglet de navigateur pour chaque variante wordpress locale et les tester tout en travaillant sur un seul projet et une seule base de fichiers.

En utilisant un environnement de développement prenant en charge SVN & FTP, il vous suffit de modifier votre copie de travail et de valider vos modifications dans le référentiel.

En tant qu'IDE, Coda le fait pour moi, mais j'aime aussi NetBeans et Eclipse.

Une fois que vous êtes satisfait du fonctionnement de votre plug-in et que vous avez engagé ces modifications dans votre référentiel, vous pouvez ensuite ouvrir votre projet wordpress et publier le plug-in modifié directement sur votre site actif.

J'ai une configuration relativement simple qui a évolué depuis le début de mon travail actuel, il y a environ 2,5 ans.

Développement

Je fais tout mon développement sur SSH, en utilisant Vim dans l’ écran GNU . Les plugins Vim incluent:

• zencoding-vim
• FuzzyFinder

Les fractionnements verticaux :set hiddensont essentiels. Je préfère également un terminal de 256 couleurs ( iTerm sur Mac OS X) avec le schéma de couleurs Railcasts .

Nous avons également lentement modifié dBug pour répondre à nos besoins. Joli remplacement pour print_r()et var_dump()quand vous savez que la variable est un tableau ou un objet.

Déploiement

À l'heure actuelle, je ne travaille pas sur beaucoup de plugins / thèmes publics, je ne teste donc pas la compatibilité des plugins avec plusieurs versions de WordPress. Je code sur le serveur de développement et déplace ce code en production via Subversion.

Processus de développement de thèmes WordPress

• Convertir le fil de fer Mock Flow en XHTML et CSS de base

• Branchez XHTML dans le fichier de modèle master.php et convertissez-le en balises de modèle et en fonctions WP

• Divisez le fichier master.php dans les différents fichiers de modèles, à savoir: header.php, index.php, sidebar.php et footer.php

• Écrivez toutes les requêtes et fonctions personnalisées qui pourraient être nécessaires

• Branchez la mise en page CSS et ajoutez-la div {outline:1px solid red;}pour aider à peaufiner la mise en page4.

• Téléchargez le dossier du thème sur WordPress pour le tester et le développer

Outils de développement WordPress

• Aptana Studio WorkPlace éditeur de code avec FTP intégré

• Mastic

• deux moniteurs 1920 x 1200 avec navigateur ouvert sur l'un et éditeur de code sur l'autre

• Wacom Intuis 4 comprimé

• Firebug avec Yslow et Google Page vitesse

Mon flux de travail est assez simple. Je continue avec 4 environnements. Essais, développement, mise en scène et production.

Flux de travail

J'utilise git pour mon contrôle de révision; J'ignore le fichier wp-config.php afin que ce fichier ne soit pas écrasé lorsque je pousse et tire à travers les différents emplacements. J'utilise unduddle en tant que référentiel public / central pour que les autres puissent en tirer parti.

Cela semble fonctionner assez bien. Je vais commettre aussi souvent que je peux me souvenir pendant que je travaille sur les tests. Au moins une fois par jour, sinon plus, je synchronise avec unfuddle et demande au serveur de développement de prendre en compte les modifications. J'essaie de ne pas faire de travail direct sur le serveur, donc je ne fais qu'apporter des modifications. Si des modifications significatives ont été apportées à la base de données (nouveaux plugins, contenu mis à jour, etc.), je le viderai de mes tests; faire une sauvegarde du développement et importer le dump.

J'utilise le même processus pour Staging. Le transfert est installé sur le même serveur que celui de la production, vérifiez bien le polissage et assurez-vous que tous les paramètres et modules fonctionnent sur le serveur de production. Lorsque je suis prêt, je sauvegarde tous les fichiers de production et la base de données, puis je copie les fichiers et la base de données de staging.

Wp-config.php n'étant pas dans git, il est assez simple de pousser et de tirer les choses. Lorsque je passe de la mise en production à la production, je copie les fichiers sans utiliser git. Je dois donc m'assurer que le fichier wp-config.php est correct.

J'ai posé une question similaire et je vais examiner l'utilisation de ce plugin.

J'ai aussi pensé à utiliser Capistrano; et créer un script de migration très détaillé qui traitera et gérera toutes les sauvegardes / migrations de fichiers et de bases de données, ainsi que la mise à jour des chemins de fichiers et des URL.

Outils

• Textmate pour mon éditeur, bien que je commence à utiliser MacVim. J'utilise vim sur linux.
• Sequel Pro pour la manipulation de base de données. Si je ne parviens pas à me connecter, j'utilise PHPMyAdmin.
• Transmettez pour FTP si j'en ai besoin.
• git pour le contrôle de révision. Principalement par ligne de commande, bien que j'utilise un peu le client dans Textmate et GittiApp.

Une chose qui m'aide (surtout lorsque je travaille sur plusieurs thèmes de clients) est d'utiliser une installation WordPress Multisite sur mon serveur de développement. De cette façon, je peux avoir autant de jobs ouverts que nécessaire, sans me soucier du thème du client B. Ajoutez à cela un ensemble complet d'exemples de contenu que je charge chaque fois que je crée un nouveau site et vous obtenez un système de développement impressionnant.

Je fais du piratage sur place sur le serveur dans les entrailles d'un système de vie à plus structuré développement / test / étape / cycle de vie en utilisant des systèmes de contrôle de version et des tests automatisés. Cela dépend du travail.

À côté de cela, je signale les bogues au projet wordpress lorsque je les écris.

Pour le développement de plugins, j'essaie de ne pas réinventer la roue tout le temps, donc d'en construire de nouvelles sur la base des principes et des modèles existants.

Voici mon flux de travail:

• Je commence par créer le répertoire du projet dès que je connais les exigences et les conceptions du site.
• version the Staticet le theme/plugindossier dans DynamicDossiers utilisant Git.

• créer un hôte virtuel pour le projet. Je suis cette convention:

  http://project1.dev/

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

• Je suis généralement cette organisation de dossier:

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

Je suis conscient que je n'utilise pas encore un buildoutil au jour le jour, ce qui me fait me sentir mal.

Mais j’utilise l’outil de construction ANT pour mon projet Sprite2CSS associé à quelques scripts PHP pour la consommation d’ANT.

Outils

Que je sois sous Windows ou Ubuntu, j'utilise les éléments suivants:

• Netbeans + SublimeText2 + Notepad ++
• WAMP - (PHP)
• FakeMail
• Git
• Chrome et DevTools + Firefox avec Firebug et Safari + IE pour les tests
• YSlow!
• FTP intégré de Filezilla / WinSCP / NB
• Cygwin + Invite de commande
• Compositeur
• NodeJS + NPM
• SQLYog Community Edition + PHPMyAdmin

Je suis ouvert aux suggestions pour améliorer mon flux de travail.

Je travaille sur Windows avec Denver , FileZilla, Notepad ++, Firefox Firebug et d’autres inspecteurs (les liens étaient précédents), cPanel et dbForge Studio for MySQL.