Мене цікавить, як інші люди розробляють теми та плагіни для WordPress. Для мене редактор в браузері на панелі адміністратора просто не вирізає. В даний час я просто використовую IDE з плагіном PHP (NetBeans), витягую веб-каталог свого розвитку з мого сервера, редагую там, підштовхуючись до тестування, а потім переходжуся до живого.

Я шукаю, як інші люди використовують свої інструменти за вибором для управління робочими процесами для розробки, тестування та розгортання тем, плагінів та тестування останніх версій WordPress проти цих, перш ніж виходити наживо.

Я зробив це вікі спільноти, щоб інші люди могли поділитися там процесом розвитку. Я не сподіваюся, що тут знайду єдину правильну відповідь - ваш процес ваш, і я не сподівався б, що ви робите, щоб просто працювали на себе чи когось іншого. Мені просто цікаво вдосконалити свою здатність розробляти плагіни та теми, бачачи, що працює або що не працює для інших людей.

Ще одне питання тут обговорює конкретні програмні засоби для підтримки розвитку WordPress . Тут я шукаю більше процесу та методології, які можна застосовувати незалежно від інструментів, за винятком певних завдань, які можуть бути виконані лише у певній родині інструментів.

Для запису я в основному роблю цілі веб-сайти та плагіни та розгортаю їх. Мій робочий процес дуже Ruby- та git-важкий.

Для початку нового проекту у мене є сценарій оболонки, який піклується про весь бізнес щодо створення нового vhost та перевірки останнього тегу WordPress (з нашого власного сховища git, який відстежує svn).

Основна форма всього веб-сайту - це git-резонанс на wp-content. Він містить Capfile (Makefile eqiuivalent Capistrano) та файл конфігурації YAML, який разом береться за розгортання ( http://github.com/dxw/wp-capistrano ). Також всередині цього сховища я додаю тему та плагіни як підмодулі git (так, ми також зберігаємо git-сховища для сторонніх плагінів - ми любимо використовувати останню версію, яку ми особисто перевірили).

Для теми у мене є інструмент / рамка для генерації коду ( github.com/dxw/wp-generate ). Це означає менше замислюватися над тим, куди повинен піти код, і він має природний метод розділення між Поглядом та Моделлю / Контролером.

Під час написання плагінів я використовую огірок / вебрат для тестового розвитку ( github.com/dxw/cucumber-wordpress ).

А для міграції баз даних про розвиток у виробництво, як правило, це лише випадок копіювання дампа (WP_SITEURL і WP_HOME встановлюються capistrano на постановочних / виробничих машинах, тому не потрібно шукати / замінювати).

Я не уявляю, скільки годин я заощадив за допомогою цих сценаріїв.

@Thomas Owens Це питання дещо перекриває і дублює питання " Програмне забезпечення для теми / розробки плагінів WordPress? ". Не впевнений, чи варто закривати, але це здається трохи іншим фокусом. Так...

Mac OS X

Ось мій найважливіший набір інструментів зараз для Max OS X (завжди шукаю кращого.) Примітка. Я спробував NetBeans і відмовився від нього. Занадто млявий і занадто мало функцій.

• PhpStorm + XDEBUG - Налагодження IDE (нічого кращого на MAC)
• VirtualHostX - Керує віртуальними хостами Apache локально (я люблю це)
• FileZilla - FTP-клієнт
• Firefox Firebug - налагодження jQuery
• Navicat для MySQL - комерційний клієнт MySQL
• Unfuddle.com - SVN-сховище та управління завданнями для клієнтських проектів
• HTTP Scoop - розумний відладчик HTTP
• Fraise - Легкий текстовий редактор (Fork of Smultron )

Windows Vista

Коли я був у Windows Vista, моїм основним набором інструментів було:

• FileZilla - FTP-клієнт
• Firefox Firebug - налагодження jQuery
• Navicat для MySQL - комерційний клієнт MySQL
• Unfuddle.com - SVN-сховище та управління завданнями для клієнтських проектів
• PhpED - налагодження IDE (Нічого кращого у Windows, можливо, навіть PhpStorm + [XDEBUG] [24])
• HeidiSQL - чудовий клієнт з відкритим кодом MySQL
• Notepad2 - Чудова легка та зручна альтернатива блокноту
• TortoiseSVN - Клієнт SVN
• Fiddler 2 - Неперевершений налагоджувач HTTP

Розгортання коду / міграція даних для комутації доменів

Не впевнений, що це саме те, що ви шукаєте, але я розробив плагін для полегшення міграції між локальним сервером розробки, тестовим сервером та сервером розгортання. Я писав про це тут:

• Як я можу легко перемістити ВП від розробки до виробництва?

Сподіваюся, це допомагає

-Майк

Це відповідь робочого процесу, не характерна для IDE або плагіна.

Рішення, яке дуже добре працює для розробки плагінів, - почати з локального веб-сервера apache з кожною варіантом wordpress, встановленою в підпапці.

В окремому місці за межами кореня локального сервера зберігайте робочі копії плагіна / теми для Wordpress. Створіть посилання на відповідний магістраль / тег / гілку у папці / wp-content / plugins для кожного варіанта wordpress.

Під час редагування плагіна у вашій IDE внесені вами зміни, очевидно, будуть представлені у кожній установці wordpress, тому випробовувати кілька варіантів wordpress стає легко.

По суті, ви можете відкрити вкладку браузера для кожної локальної варіації wordpress і протестувати кожну, працюючи над одним проектом та однією базою файлів.

Використовуючи IDE, що підтримує SVN & FTP, все, що вам потрібно зробити, - це відредагувати свою робочу копію та здійснити зміни до сховища.

Як IDE Coda робить це для мене, але мені також подобаються NetBeans і Eclipse.

Після того, як ви щасливі, що ваш плагін працює, і ви внесли ці зміни до свого сховища, ви зможете відкрити проект WordPress і опублікувати змінений плагін безпосередньо на своєму веб-сайті.

У мене відносно непросте налаштування, яке розвивалося з моменту початку моєї сьогоднішньої роботи ~ 2,5 роки тому.

Розвиваюча

Я займаюся всією розробкою через SSH, використовуючи Vim всередині екрану GNU . До плагінів Vim належать:

• zencoding-vim
• FuzzyFinder

Вертикальні розколи і :set hiddenє істотними. Я також віддаю перевагу 256 кольоровому терміналу ( iTerm на Mac OS X) із кольоровою схемою railscasts .

Ми також повільно змінювали dBug відповідно до наших потреб. Хороша заміна print_r()і var_dump()коли ви знаєте, що змінна - це масив або об'єкт.

Розгортання

В даний час я не працюю над багатьма загальнодоступними плагінами / темами, тому не перевіряю сумісність плагінів із кількома версіями WordPress. Я кодую на сервер розробників і переміщую цей код у виробництво за допомогою Subversion.

Процес розробки теми WordPress

• Перетворити провідний кадр Mock Flow в основні XHTML та CSS

• Підключіть XHTML до файлу шаблону master.php та перетворіть у теги шаблону та функції WP

• Розділіть master.php на різні файли шаблонів, тобто: header.php, index.php, sidebar.php та footer.php

• Напишіть будь-які власні запити та функції, які можуть знадобитися

• Підключіть CSS-макет і додайте, div {outline:1px solid red;}щоб допомогти налаштувати макет4.

• Завантажте папку «Тема» в WordPress для тестування та подальшої розробки

Інструменти розвитку WordPress

• Редактор коду Aptana Studio WorkPlace зі вбудованим FTP

• Шпаклівка

• подвійні монітори 1920 x 1200 з відкритим браузером на одній і редактором коду з іншого

• Таблетка Wacom Intuis 4

• Firebug зі швидкістю Yslow та Google Page

Мій робочий процес досить простий. Я йду в ногу з 4 середовищами. Тестування, розробка, постановка та виробництво.

Робочий процес

Я використовую git для свого контролю за редакцією; Я ігнорую файл wp-config.php, щоб цей файл не перезаписався, коли я натискаю і перетягую різні місця. Я використовую unuddle як публічний / центральний сховище для інших, щоб підштовхувати і витягувати.

Це, здається, працює досить добре. Я буду робити зобов’язання так часто, як можу згадати, поки працюю над Тестуванням. Принаймні раз на день, якщо не більше, я синхронізуюсь із скасуванням і змушує сервер розвитку вносити зміни. Я намагаюся не робити будь-якої прямої роботи на сервері, тому я в основному просто втягую зміни. Якщо були внесені значні зміни в базі даних (нові плагіни, оновлений вміст тощо), я скину його з Тестування; зробити резервну копію розробки та імпортувати дамп.

Я використовую той самий процес для постановки. Постановка сидить на тому ж сервері, що і виробництво, це двічі перевірити полірування та переконатися, що всі параметри та модулі працюють на виробничому сервері. Коли я готовий, я створю резервну копію всіх виробничих файлів і баз даних, а також копіюю файли та базу даних з інсценізації.

Оскільки wp-config.php не знаходиться в git, це робить його досить простим, щоб натискати і перетягувати речі. Під час переходу до виробництва з інсценізації я копіюю файли, а не використовую git, тому я повинен переконатися, що wp-config.php правильний.

Я задав подібне запитання , і я збираюся розглянути цей плагін.

Я також думав про використання Capistrano; і створити дуже детальний сценарій міграції, який проходитиме та обробляє всі файли та резервні копії / міграції бази даних, а також оновлює шляхи та URL-адреси файлів.

Інструменти

• Textmate для мого редактора, хоча я починаю використовувати MacVim. Я використовую vim, коли в Linux.
• Sequel Pro для роботи з базами даних. Якщо я не можу зв’язатися з ним, я використовуватиму PHPMyAdmin
• Передайте для FTP, якщо мені це потрібно.
• git для контролю за редакцією. Здебільшого за допомогою командного рядка, хоча я трохи використовував клієнт у Textmate та GittiApp.

Одне, що мені допомагає (особливо коли я працюю над декількома клієнтськими темами) - це використання WordPress Multisite встановити на моєму сервері розробників. Таким чином, я можу мати стільки відкритих робочих місць, скільки потрібно, і не турбуватися про клієнта, який бачить тему клієнта B. Поєднайте це з вичерпним пакетом зразкового вмісту, який я завантажую щоразу, коли створюю новий сайт, і у вас є дивовижна система розробників.

Я роблю від злому на сервері в кишечнику життєвої системи до більш структурованого циклу розробки / тесту / стадії / життя, використовуючи системи контролю версій та автоматизовані тести. Це просто залежить від роботи.

Поруч із цим я повідомляю про помилки у проекті wordpress, коли я переходжу на них.

Для розробки плагінів я намагаюся весь час не винаходити колесо, щоб будувати нові на основі існуючих принципів та зразків.

Ось мій робочий процес:

• Я починаю зі створення каталогу каталогу, як тільки отримую вимоги та конструкції веб-сайту.
• версія Staticта theme/pluginпапку у Dynamicпапках за допомогою Git.

• створити віртуальний хост для проекту. Я дотримуюся цієї конвенції:

  http://project1.dev/

  http://project1.static.dev (необов'язково)

• Зазвичай я дотримуюся цієї організації папок:

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

Я усвідомлюю, що ще не користуюсь buildінструментом щодня, від чого я відчуваю себе погано.

Але я використовую інструмент збірки ANT для свого проекту Sprite2CSS у поєднанні з парою PHP-скриптів для споживання ANT.

Інструменти

Я працюю в Windows або Ubuntu, я використовую наступне:

• Netbeans + SublimeText2 + Блокнот ++
• WAMP - (PHP)
• FakeMail
• Git
• Chrome і DevTools + Firefox з Firebug та Safari + IE для тестування
• YSlow!
• Вбудований FTP-файл Filezilla / WinSCP / NB
• Cygwin + Command prompt
• Композитор
• NodeJS + NPM
• Видання спільноти SQLYog + PHPMyAdmin

Я відкритий для пропозицій щодо покращення мого робочого процесу.

Я працюю в Windows з Denver , FileZilla, Notepad ++, Firefox Firebug та іншими інспекторами (посилання були вище), cPanel і dbForge Studio для MySQL