web-dev-qa-db-fra.com

Quel processus utilisez-vous pour le développement WordPress?

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), puis je retire mon répertoire Web de développement depuis mon serveur, je l'édite, je passe à tester, puis migrer pour vivre.

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 leur mise 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 souhaite simplement améliorer ma capacité à développer des plugins et des thèmes en voyant ce qui fonctionne ou non pour d'autres personnes.

Une autre question concerne des outils logiciels spécifiques pour = -/pour 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.

plugin-developmenttheme-development
37
Thomas Owens

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 de la vérification de la dernière balise 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 doit 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 over (WP_SITEURL et WP_HOME sont définis par capistrano sur les machines de transfert/production, donc pas de recherche/remplacement).

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

20
tomdxw

@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 jeu d’outils essentiel en ce moment pour Max OS X (toujours à la recherche de meilleurs résultats.) Remarque: j’ai essayé NetBeans et j’ai abandonné. Trop lent et trop peu de fonctionnalités.

Windows Vista

Quand j'étais sous Windows Vista, mon jeu d’outils essentiel était:

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 ça ici:

J'espère que cela t'aides

-Mike

6
MikeSchinkel

Il s'agit d'une réponse de flux de travail, 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.

Lorsque vous modifiez le plug-in dans votre IDE, les modifications que vous apportez seront évidemment représentées dans chaque installation de wordpress, de sorte qu'il devient 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 IDE qui prend en charge SVN & FTP, vous devez simplement modifier votre copie de travail et enregistrer vos modifications dans le référentiel.

En tant que 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.

5
leetagg

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 inside GNU screen . Les plugins Vim incluent:

Les fractionnements verticaux et :set hidden sont essentiels. Je préfère également un terminal de 256 couleurs ( iTerm sur Mac OS X) avec les railscasts palette de couleurs.

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

Déploiement

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

3
Annika Backstrom

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èle, à 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 le modèle CSS et ajoutez div {outline:1px solid red;} pour aider à modifier le modèle4.

  • 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

3
Chris_O

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 récupère les différents emplacements. J'utilise unduddle en tant que référentiel public/central pour que d'autres puissent pousser et en tirer.

Cela semble fonctionner assez bien. Je vais m'engager 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 importantes ont été apportées à la base de données (nouveaux plug-ins, 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, cela simplifie la tâche 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 simple et je vais étudier 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 quand 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.
3
Ryan Gibbons

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 disposez d'un système de développement impressionnant.

1
Keith S.

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.

0
hakre

Voici mon flux de travail:

  • Je commence par créer le répertoire du projet dès que je reçois les spécifications et les conceptions du site Web.
  • version le dossier Static et le dossier theme/plugin dans les dossiers Dynamic utilisant Git.

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

    http://project1.dev/

    http://project1.static.dev (éventuellement)

  • 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 outil build au jour le jour, ce qui me rend mal à l'aise.

Mais j’utilise l’outil de compilation ANT pour mon projet Sprite2CSS couplé à 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.

0
Junaid Qadir

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

0
Michael Pozdnakov