Interesuje mnie, w jaki sposób inne osoby opracowują motywy i wtyczki do WordPress. Dla mnie edytor w przeglądarce w panelu administracyjnym po prostu go nie wycina. Obecnie używam tylko IDE z wtyczką PHP (NetBeans), ściągam katalog programowania z mojego serwera, edytuję go, testuję, a następnie przeprowadzam migrację.

Szukam sposobu, w jaki inne osoby używają wybranych narzędzi do zarządzania przepływami pracy w celu opracowywania, testowania i wdrażania motywów, wtyczek oraz testowania najnowszych wersji WordPress przed nimi.

Zrobiłem to wiki społeczności, aby inni mogli się tam dzielić. Nie oczekuję, że znajdę tutaj jedną właściwą odpowiedź - twój proces jest twój i nie spodziewałbym się, że to, co zrobisz, będzie działało tylko dla siebie lub kogokolwiek innego. Interesuje mnie tylko poprawienie umiejętności opracowywania wtyczek i motywów poprzez sprawdzenie, co działa lub nie działa dla innych osób.

Kolejne pytanie tutaj omawia określone narzędzia programowe wspierające rozwój WordPress . Tutaj szukam więcej procesów i metodologii, które mogłyby być stosowane niezależnie od narzędzi, z wyjątkiem niektórych zadań, które można wykonać tylko w określonej rodzinie narzędzi.

Dla przypomnienia tworzę głównie witryny i wtyczki i wdrażam je. Mój obieg pracy jest bardzo ciężki i rubinowy.

Aby rozpocząć nowy projekt, mam skrypt powłoki, który zajmuje się całą działalnością związaną z konfiguracją nowego hosta vhost i sprawdzeniem najnowszego tagu WordPress (z naszego własnego repozytorium git, które śledzi svn).

Podstawowym kształtem całej witryny jest repozytorium git na wp-content. Zawiera plik Capfile (eqiuivalent Makefile Capistrano) i plik konfiguracyjny YAML, który razem zajmuje się wdrożeniem ( http://github.com/dxw/wp-capistrano ). Również wewnątrz tego repozytorium dodaję motyw i wtyczki jako podmoduły git (tak, utrzymujemy repozytoria git również dla wtyczek stron trzecich - lubimy korzystać z najnowszej wersji, którą osobiście przetestowaliśmy).

Do motywu mam narzędzie / platformę do generowania kodu ( github.com/dxw/wp-generate ). Oznacza to mniej myślenia o tym, dokąd powinien iść kod, i ma naturalną metodę oddzielania widoku od modelu / kontrolera.

Pisząc wtyczki używam cucumber / webrat do programowania opartego na testach ( github.com/dxw/cucumber-wordpress ).

W przypadku migracji programistycznych baz danych do produkcji zwykle jest to tylko przypadek skopiowania zrzutu (WP_SITEURL i WP_HOME są ustawiane przez capistrano na maszynach pomostowych / produkcyjnych, więc nie można wyszukiwać / zamieniać).

Nie mogę sobie wyobrazić, ile godzin zaoszczędziłem na tych skryptach.

@Thomas Owens To pytanie w pewnym stopniu pokrywa się i powiela pytanie „ Oprogramowanie do tworzenia motywów / wtyczek WordPress? ”. Nie jestem pewien, czy powinniśmy zamknąć, ale wydaje się nieco inny cel. Więc...

Mac OS X

Oto mój niezbędny zestaw narzędzi dla Max OS X (zawsze szukam lepszego.) Uwaga: wypróbowałem NetBeans i zrezygnowałem z niego. Zbyt powolny i zbyt mało funkcji.

• PhpStorm + XDEBUG - Debugowanie IDE (nic lepszego na MAC)
• VirtualHostX - lokalnie zarządza wirtualnymi hostami Apache ( UWIELBIAM to)
• FileZilla - klient FTP
• Firefox Firebug - debugowanie jQuery
• Navicat dla MySQL - komercyjny klient MySQL
• Unfuddle.com - repozytorium SVN i zarządzanie zadaniami dla projektów klienckich
• Scoop HTTP - Rozsądny debugger HTTP
• Fraise - lekki edytor tekstu (Fork of Smultron )

Windows Vista

Gdy byłem w systemie Windows Vista, moim podstawowym zestawem narzędzi był:

• FileZilla - klient FTP
• Firefox Firebug - debugowanie jQuery
• Navicat dla MySQL - komercyjny klient MySQL
• Unfuddle.com - repozytorium SVN i zarządzanie zadaniami dla projektów klienckich
• PhpED - debugowanie IDE (nic lepszego w systemie Windows, może nie PhpStorm + [XDEBUG] [24])
• HeidiSQL - Świetny klient MySQL typu open source
• Notepad2 - Świetna lekka i użyteczna alternatywa dla Notatnika
• TortoiseSVN - klient SVN
• Fiddler 2 - Bezkonkurencyjny debugger HTTP

Wdrażanie kodu / migracja danych do przełączania domen

Nie jestem pewien, czy jest to dokładnie to, czego szukasz, ale opracowuję wtyczkę, aby ułatwić migrację między lokalnym serwerem deweloperskim, serwerem testowym i serwerem wdrażania. Pisałem o tym tutaj:

• Jak mogę łatwo przenieść WP z działu rozwoju do produkcji?

Mam nadzieję że to pomoże

-Mikrofon

To jest odpowiedź na przepływ pracy, a nie specyficzna dla IDE lub wtyczki.

Rozwiązaniem, które naprawdę dobrze sprawdza się przy opracowywaniu wtyczek, jest uruchomienie lokalnego serwera WWW Apache z każdą odmianą WordPress zainstalowaną w podfolderze.

W oddzielnej lokalizacji poza lokalnym katalogiem głównym serwera przechowuj kopie robocze wtyczki / motywu Wordpress. Utwórz dowiązanie symboliczne do odpowiedniego trunk / tag / branch w folderze / wp-content / plugins każdej odmiany wordpress.

Podczas edycji wtyczki w twoim IDE zmiany, które wprowadzisz, będą oczywiście reprezentowane w każdej instalacji wordpress, więc łatwo jest przetestować wiele odmian wordpress.

Zasadniczo możesz mieć otwartą kartę przeglądarki dla każdej lokalnej wersji WordPressa i przetestować każdą z nich podczas pracy nad jednym projektem i jedną bazą plików.

Używając IDE, które obsługuje SVN i FTP, wystarczy edytować kopię roboczą i zatwierdzić zmiany z powrotem do repozytorium.

Jako IDE Coda robi to za mnie, ale lubię także NetBeans i Eclipse.

Gdy będziesz zadowolony, że wtyczka działa, a zmiany zostały wprowadzone w repozytorium, możesz otworzyć projekt Wordpress i opublikować zmienioną wtyczkę bezpośrednio na swojej stronie.

Mam stosunkowo nieskomplikowaną konfigurację, która ewoluowała od momentu rozpoczęcia mojej obecnej pracy ~ 2,5 roku temu.

Rozwijający się

Cały swój rozwój robię nad SSH, używając Vima na ekranie GNU . Wtyczki Vima obejmują:

• zencoding-vim
• FuzzyFinder

Podziały pionowe :set hiddensą niezbędne. Wolę także terminal 256-kolorowy ( iTerm w systemie Mac OS X) ze schematem kolorów emisji rails .

Powoli modyfikujemy dBug, aby dostosować go do naszych potrzeb. Niezła zamiana na print_r()i var_dump()kiedy wiesz, że zmienna jest tablicą lub obiektem.

Wdrażanie

Obecnie nie pracuję na wielu publicznych wtyczkach / motywach, więc nie testuję kompatybilności wtyczek z wieloma wersjami WordPress. Piszę kod na serwerze deweloperskim i przenoszę ten kod do produkcji za pomocą Subversion.

Proces tworzenia motywów WordPress

• Konwertuj ramkę Mock Flow na podstawowy XHTML i CSS

• Podłącz XHTML do pliku szablonu master.php i przekonwertuj na tagi szablonów i funkcje WP

• Podziel master.php na różne pliki szablonów, np .: header.php, index.php, sidebar.php i footer.php

• Napisz wszelkie niestandardowe zapytania i funkcje, które mogą być potrzebne

• Podłącz układ CSS i dodaj, div {outline:1px solid red;}aby ulepszyć układ 4.

• Prześlij folder motywów do WordPressa w celu przetestowania i dalszego rozwoju

Narzędzia programistyczne WordPress

• Edytor kodu Aptana Studio WorkPlace z wbudowanym FTP

• Kit

• dwa monitory 1920 x 1200 z przeglądarką otwartą na jednym i edytorem kodu na drugim

• Tablet Wacom Intuis 4

• Firebug z Yslow i Google Page speed

Mój obieg pracy jest dość prosty. Nadążam z 4 środowiskami. Testowanie, rozwój, inscenizacja i produkcja.

Przepływ pracy

Używam git do kontroli wersji; Ignoruję plik wp-config.php, aby ten plik nie został nadpisany, gdy popycham i przeciągam różne lokalizacje. Używam unfuddle jako publicznego / centralnego repozytorium, z którego inni mogą pchać i wyciągać.

To wydaje się działać całkiem dobrze. Będę angażować się tak często, jak pamiętam, kiedy pracuję nad testowaniem. Przynajmniej raz dziennie, jeśli nie więcej, synchronizuję się z unfuddle i nakazuję serwerowi zmian wprowadzanie zmian. Staram się nie wykonywać żadnej bezpośredniej pracy na serwerze, więc głównie wprowadzam zmiany. Jeśli dokonano znaczących zmian w bazie danych (nowe wtyczki, zaktualizowana zawartość itp.), To zrzucę to z moich testów; wykonaj kopię zapasową Rozwoju i zaimportuj zrzut.

Korzystam z tego samego procesu do inscenizacji. Inscenizacja znajduje się na tym samym serwerze co produkcja, dokładnie sprawdź poprawność i upewnij się, że wszystkie ustawienia i moduły działają na serwerze produkcyjnym. Kiedy jestem gotowy, tworzę kopie zapasowe wszystkich plików produkcyjnych i bazy danych oraz kopiuję pliki i bazę danych ze środowiska tymczasowego.

Ponieważ wp-config.php nie jest w git, to sprawia, że ​​bardzo łatwo jest popychać i ciągnąć rzeczy. Przechodząc do produkcji ze sceny, kopiuję pliki i nie używam git, więc muszę się upewnić, że wp-config.php jest poprawny.

Zadałem proste pytanie i zamierzam skorzystać z tej wtyczki.

Myślałem też o użyciu Capistrano; oraz tworzenie bardzo szczegółowego skryptu migracji, który przejdzie i obsłuży wszystkie pliki i kopie zapasowe / migracje bazy danych, a także zaktualizuje ścieżki plików i adresy URL.

Przybory

• Textmate dla mojego edytora, chociaż zaczynam używać MacVima. Używam vima na Linuksie.
• Sequel Pro do manipulacji bazą danych. Jeśli nie mogę się z nim połączyć, użyję PHPMyAdmin
• Prześlij na FTP, jeśli go potrzebuję.
• git do kontroli wersji. Głównie z wiersza poleceń, chociaż trochę korzystałem z klienta w Textmate i GittiApp.

Jedną z rzeczy, która pomaga mi (szczególnie podczas pracy z wieloma motywami klienta), jest instalacja WordPress Multisite na moim serwerze deweloperskim. W ten sposób mogę mieć tyle otwartych zadań, ile potrzeba i nie martwić się o klienta A, widząc motyw klienta B. Połącz to z kompleksowym pakietem przykładowej zawartości, którą ładuję za każdym razem, gdy tworzę nową witrynę, a masz niesamowity system deweloperów.

Robię to od hakowania na miejscu w trzewiach systemu życiowego do bardziej ustrukturyzowanego tworzenia / testowania / etapu / cyklu życia za pomocą systemów kontroli wersji i automatycznych testów. To zależy tylko od pracy.

Oprócz tego zgłaszam błędy z powrotem do projektu wordpress, gdy je przejdę.

Przy opracowywaniu wtyczek staram się cały czas nie wymyślać koła, aby budować nowe w oparciu o istniejące zasady i wzorce.

Oto mój przepływ pracy:

• Zaczynam od utworzenia katalogu projektu, gdy tylko otrzymam wymagania i projekty strony.
• wersja Statici theme/pluginfolder w folderze Dynamicza pomocą Git.

• utwórz wirtualny host dla projektu. Przestrzegam tej konwencji:

  http://project1.dev/

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

• Zazwyczaj śledzę tę organizację folderów:

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

Wiem, że nie używam jeszcze buildnarzędzia na co dzień, co sprawia, że ​​czuję się źle.

Ale używam narzędzia do budowania ANT do mojego projektu Sprite2CSS w połączeniu z kilkoma skryptami PHP do konsumpcji ANT.

Przybory

Bez względu na to, czy korzystam z systemu Windows, czy Ubuntu, używam:

• Netbeans + SublimeText2 + Notepad ++
• WAMP - (PHP)
• FakeMail
• Git
• Chrome i DevTools + Firefox z Firebug i Safari + IE do testowania
• YSlow!
• Filezilla / WinSCP / NB ma wbudowany FTP
• Cygwin + wiersz polecenia
• Kompozytor
• NodeJS + NPM
• SQLYog Community Edition + PHPMyAdmin

Jestem otwarty na sugestie dotyczące ulepszenia mojego przepływu pracy.

Pracuję w systemie Windows z Denver , FileZilla, Notepad ++, Firefox Firebug i innymi inspektorami (linki były powyżej), cPanel i dbForge Studio dla MySQL