Ich bin daran interessiert, wie andere Leute Themen und Plugins für WordPress entwickeln. Für mich schneidet der In-Browser-Editor im Admin-Bereich einfach nicht ab. Momentan verwende ich nur eine IDE mit einem PHP-Plugin (NetBeans), rufe mein Entwicklungs-Webverzeichnis von meinem Server ab, bearbeite es dort, starte es zum Testen und migriere dann zum Live.

Ich suche nach Möglichkeiten, wie andere Benutzer ihre Tools ihrer Wahl verwenden, um Workflows für das Entwickeln, Testen und Bereitstellen von Themen, Plugins und Testen der neuesten Versionen von WordPress mit diesen zu verwalten, bevor sie live gehen.

Ich habe dies zu einem Community-Wiki gemacht, damit andere Leute an diesem Entwicklungsprozess teilnehmen können. Ich erwarte nicht, dass Sie hier die einzig richtige Antwort finden - Ihr Prozess ist Ihr eigener, und ich würde nicht erwarten, dass das, was Sie tun, nur für mich selbst oder für jemanden anderen funktioniert. Ich bin nur daran interessiert, meine Fähigkeit zu verbessern, Plugins und Themen zu entwickeln, indem ich sehe, was für andere Leute funktioniert oder nicht.

In einer weiteren Frage werden spezielle Softwaretools zur Unterstützung der WordPress-Entwicklung erörtert . Hier bin ich auf der Suche nach mehr Prozessen und Methoden, die unabhängig von Werkzeugen angewendet werden können, mit Ausnahme bestimmter Aufgaben, die möglicherweise nur in einer bestimmten Familie von Werkzeugen ausgeführt werden.

Ich erstelle hauptsächlich ganze Websites und Plugins und stelle sie bereit. Mein Workflow ist sehr rubin- und gitlastig.

Um mit einem neuen Projekt zu beginnen, habe ich ein Shell-Skript, das sich um das Einrichten eines neuen vhost und das Auschecken des neuesten WordPress-Tags (aus unserem eigenen Git-Repository, das svn verfolgt) kümmert.

Die Grundform einer ganzen Website ist ein Git-Repository bei wp-content. Das enthält ein Capfile (das Makefile-Äquivalent von capistrano) und eine YAML-Konfigurationsdatei, die zusammen für die Bereitstellung sorgen ( http://github.com/dxw/wp-capistrano ). Außerdem füge ich in diesem Repository das Theme und die Plugins als Git-Submodule hinzu (ja, wir pflegen Git-Repositories auch für Plugins von Drittanbietern - wir verwenden gerne die neueste Version, die wir persönlich getestet haben).

Für das Thema habe ich ein Tool / Framework zur Codegenerierung ( github.com/dxw/wp-generate ). Es bedeutet weniger darüber nachzudenken, wohin der Code gehen soll, und es gibt eine natürliche Methode zur Trennung zwischen der Ansicht und dem Modell / Controller.

Beim Schreiben von Plugins verwende ich cucumber / webrat, um eine testgetriebene Entwicklung durchzuführen ( github.com/dxw/cucumber-wordpress ).

Und für die Migration von Entwicklungsdatenbanken in die Produktion muss normalerweise nur der Speicherauszug kopiert werden (WP_SITEURL und WP_HOME werden von capistrano auf den Staging- / Produktionsmaschinen festgelegt, sodass kein Suchen / Ersetzen erforderlich ist).

Ich kann mir nicht vorstellen, wie viele Stunden ich mit diesen Skripten gespart habe.

@Thomas Owens Diese Frage überschneidet sich etwas und dupliziert die Frage " Software für WordPress Theme / Plugin Entwicklung? " Nicht sicher, ob wir schließen sollen, aber es scheint ein etwas anderer Fokus. So...

Mac OS X

Hier ist mein unverzichtbares Toolset für Max OS X (immer auf der Suche nach besserem). Hinweis: Ich habe NetBeans ausprobiert und aufgegeben. Zu träge und zu wenige Funktionen.

• PhpStorm + XDEBUG - IDE debuggen (nichts besseres auf dem MAC)
• VirtualHostX - Verwaltet virtuelle Apache-Hosts lokal (ich liebe dies)
• FileZilla - FTP-Client
• Firefox Firebug - jQuery Debugging
• Navicat für MySQL - Kommerzieller MySQL-Client
• Unfuddle.com - SVN-Repository und Aufgabenverwaltung für Kundenprojekte
• HTTP Scoop - Angemessener HTTP-Debugger
• Fraise - Leichter Texteditor (Fork of Smultron )

Windows Vista

Als ich unter Windows Vista war, war mein wesentliches Toolset :

• FileZilla - FTP-Client
• Firefox Firebug - jQuery Debugging
• Navicat für MySQL - Kommerzieller MySQL-Client
• Unfuddle.com - SVN-Repository und Aufgabenverwaltung für Kundenprojekte
• PhpED - Debugging IDE (Nichts besseres unter Windows, außer vielleicht PhpStorm + [XDEBUG] [24])
• HeidiSQL - Großartiger Open-Source-MySQL-Client
• Notepad2 - Tolle, leichte und benutzerfreundliche Notepad-Alternative
• TortoiseSVN - SVN-Client
• Fiddler 2 - Unschlagbarer HTTP-Debugger

Codebereitstellung / Datenmigration zum Wechseln von Domänen

Ich bin mir nicht sicher, ob dies genau das ist, wonach Sie suchen, aber ich entwickle ein Plugin, um Migrationen zwischen lokalem Entwicklungsserver, Testserver und Bereitstellungsserver zu vereinfachen. Ich habe hier darüber geschrieben:

• Wie kann ich WP einfach von der Entwicklung in die Produktion verlagern?

Hoffe das hilft

-Mike

Dies ist eine Workflow-Antwort, die weder für eine IDE noch für ein Plugin spezifisch ist.

Eine sehr gute Lösung für die Plugin-Entwicklung ist, mit einem lokalen Apache-Webserver zu beginnen, auf dem jede WordPress-Variante in einem Unterordner installiert ist.

Speichern Sie die Arbeitskopien Ihres WordPress-Plugins / Themes an einem separaten Ort außerhalb des lokalen Server-Stammverzeichnisses. Erstellen Sie einen Symlink zum entsprechenden Trunk / Tag / Zweig im Ordner / wp-content / plugins jeder WordPress-Variante.

Wenn Sie das Plugin in Ihrer IDE bearbeiten, werden die Änderungen, die Sie vornehmen, natürlich in jeder WordPress-Installation dargestellt, so dass es einfach wird, mehrere Variationen von WordPress zu testen.

Grundsätzlich können Sie eine Browserregisterkarte für jede lokale WordPress-Variante öffnen und jede einzelne testen, während Sie an einem einzelnen Projekt und einer einzelnen Dateibasis arbeiten.

Mit einer IDE, die SVN und FTP unterstützt, müssen Sie lediglich Ihre Arbeitskopie bearbeiten und Ihre Änderungen wieder in das Repository übertragen.

Als IDE macht Coda das für mich, aber ich mag NetBeans und Eclipse auch.

Sobald Sie zufrieden sind, dass Ihr Plugin funktioniert und Sie diese Änderungen in Ihr Repository übernommen haben, können Sie Ihr WordPress-Projekt öffnen und das geänderte Plugin direkt auf Ihrer Live-Site veröffentlichen.

Ich habe ein relativ unkompliziertes Setup, das sich seit Beginn meines heutigen Jobs vor ca. 2,5 Jahren entwickelt hat.

Entwicklung

Ich entwickle alles über SSH mit Vim im GNU-Bildschirm . Vim Plugins beinhalten:

• zencoding-vim
• FuzzyFinder

Vertikale Teilungen und :set hiddensind unerlässlich. Ich bevorzuge auch ein 256-Farben-Terminal ( iTerm unter Mac OS X) mit dem Railscasts- Farbschema.

Wir haben dBug auch langsam an unsere Bedürfnisse angepasst. Schöner Ersatz für print_r()und var_dump()wenn Sie wissen, dass die Variable ein Array oder ein Objekt ist.

Bereitstellen

Gegenwärtig arbeite ich nicht an vielen öffentlichen Plugins / Themes, daher teste ich die Pluginkompatibilität mit mehreren Versionen von WordPress nicht. Ich codiere auf dem Entwickler-Server und verschiebe diesen Code über Subversion in die Produktion.

WordPress Theme Entwicklungsprozess

• Konvertieren Sie Mock Flow-Drahtrahmen in einfaches XHTML und CSS

• Stecken Sie XHTML in die Vorlagendatei master.php und konvertieren Sie sie in Template-Tags und WP-Funktionen

• Teilen Sie master.php in die verschiedenen Template-Dateien auf, zB: header.php, index.php, sidebar.php und footer.php

• Schreiben Sie alle benutzerdefinierten Abfragen und Funktionen, die möglicherweise benötigt werden

• div {outline:1px solid red;}Schließen Sie das CSS-Layout an und fügen Sie es hinzu , um das Layout zu optimieren4.

• Laden Sie den Theme-Ordner zu Test- und Entwicklungszwecken in WordPress hoch

WordPress-Entwicklungstools

• Aptana Studio WorkPlace-Code-Editor mit integriertem FTP

• Kitt

• Doppelmonitore 1920 x 1200 mit offenem Browser auf dem einen und Code-Editor auf dem anderen

• Wacom Intuis 4 Tablette

• Firebug mit Yslow- und Google Page-Geschwindigkeit

Mein Arbeitsablauf ist ziemlich einfach. Ich halte mit 4 Umgebungen Schritt. Testen, Entwickeln, Inszenieren und Produzieren.

Arbeitsablauf

Ich benutze git für meine Versionskontrolle. Ich ignoriere die Datei wp-config.php, damit diese Datei nicht überschrieben wird, wenn ich über die verschiedenen Speicherorte schiebe und ziehe. Ich benutze unfuddle als öffentliches / zentrales Repository für andere, um zu schieben und zu ziehen.

Dies scheint ziemlich gut zu funktionieren. Ich werde mich so oft wie möglich verpflichten, während ich am Testen arbeite. Mindestens einmal am Tag, wenn nicht sogar mehr, synchronisiere ich mich mit unfuddle und lasse den Entwicklungsserver die Änderungen einspielen. Ich versuche, keine direkte Arbeit auf dem Server zu erledigen, daher nehme ich hauptsächlich Änderungen vor. Wenn bedeutende Datenbankänderungen vorgenommen wurden (neue Plugins, aktualisierte Inhalte usw.), werde ich diese aus meinen Tests entfernen. Erstellen Sie eine Sicherungskopie der Entwicklung und importieren Sie den Speicherauszug.

Ich benutze den gleichen Prozess für die Inszenierung. Das Staging befindet sich auf demselben Server wie die Produktion. Überprüfen Sie den Poliervorgang und stellen Sie sicher, dass alle Einstellungen und Module auf dem Produktionsserver funktionieren. Wenn ich bereit bin, sichere ich alle Produktionsdateien und die Datenbank und kopiere die Dateien und die Datenbank aus dem Staging.

Da wp-config.php nicht in git enthalten ist, ist es ziemlich einfach, Dinge zu verschieben und zu verschieben. Wenn ich vom Staging in die Produktion wechsle, kopiere ich die Dateien und verwende kein Git. Daher muss ich sicherstellen, dass die Datei wp-config.php korrekt ist.

Ich habe eine ähnliche Frage gestellt und werde mich mit der Verwendung dieses Plugins befassen .

Ich habe auch darüber nachgedacht, Capistrano zu verwenden. Erstellen eines sehr detaillierten Migrationsskripts, das alle Dateien und Datenbanksicherungen / -migrationen durchläuft und verarbeitet sowie die Dateipfade und URLs aktualisiert.

Werkzeuge

• Textmate für meinen Editor, obwohl ich anfange, MacVim zu verwenden. Ich benutze vim unter Linux.
• Sequel Pro zur Datenbankmanipulation. Wenn ich keine Verbindung herstellen kann, verwende ich PHPMyAdmin
• Übertragen Sie für FTP, wenn ich es brauche.
• Git für die Revisionskontrolle. Meistens über die Befehlszeile, obwohl ich den Client in Textmate und GittiApp ein bisschen verwendet habe.

Eine Sache, die mir hilft (besonders wenn ich an mehreren Client-Themen arbeite), ist die Verwendung einer WordPress Multisite-Installation auf meinem Entwickler-Server. Auf diese Weise habe ich so viele offene Jobs wie nötig und mache mir keine Sorgen, dass Kunde A das Thema von Kunde B sieht. Kombinieren Sie dies mit einem umfassenden Paket mit Beispielinhalten, das ich jedes Mal lade, wenn ich eine neue Site erstelle, und Sie haben ein fantastisches Entwicklungssystem.

Ich verwende Versionskontrollsysteme und automatisierte Tests, um von In-Place-Hacking auf dem Server in die Eingeweide eines Lebenssystems zu strukturierteren Entwicklern / Tests / Phasen / Lebenszyklen zu gelangen. Es kommt nur auf den Job an.

Außerdem melde ich Fehler zurück an das WordPress-Projekt, wenn ich sie überfliege.

Für die Plugin-Entwicklung versuche ich, das Rad nicht ständig neu zu erfinden, um auf der Grundlage bestehender Prinzipien und Muster neue zu bauen.

Hier ist mein Workflow:

• Ich beginne mit der Erstellung des Projektverzeichnisses, sobald ich die Anforderungen und das Design der Website erhalte.
• versioniere das Staticund den theme/pluginOrdner in DynamicFolders mit Git.

• Erstellen Sie einen virtuellen Host für das Projekt. Ich folge dieser Konvention:

  http://project1.dev/

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

• Normalerweise folge ich dieser Ordnerorganisation:

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

Mir ist bewusst, dass ich noch kein buildtägliches Tool benutze , was mir ein schlechtes Gefühl gibt.

Aber ich verwendet ANT - Build - Werkzeug für mein Projekt Sprite2CSS gekoppelt mit ein paar PHP - Skripte für ANT Verbrauch.

Werkzeuge

Egal, ob ich unter Windows oder Ubuntu arbeite, ich verwende Folgendes:

• Netbeans + SublimeText2 + Notepad ++
• WAMP - (PHP)
• FakeMail
• Git
• Chrome und DevTools + Firefox mit Firebug und Safari + IE zum Testen
• YSlow!
• Das in Filezilla / WinSCP / NB integrierte FTP
• Cygwin + Eingabeaufforderung
• Komponist
• NodeJS + NPM
• SQLYog Community Edition + PHPMyAdmin

Ich bin offen für Vorschläge zur Verbesserung meines Workflows.

Ich arbeite unter Windows mit Denver , FileZilla, Notepad ++, Firefox Firebug und anderen Inspektoren (Links oben), cPanel und dbForge Studio für MySQL