Мне интересно, как другие люди разрабатывают темы и плагины для WordPress. Для меня, редактор в браузере в панели администратора просто не обрезает его. В настоящее время я просто использую IDE с плагином PHP (NetBeans), вытаскиваю свой веб-каталог разработки с моего сервера, редактирую там, подталкиваю к тестированию, а затем перехожу на работу.
Я ищу, как другие люди используют свои инструменты для управления рабочими процессами при разработке, тестировании и развертывании тем, плагинов и тестировании последних версий WordPress на их основе, прежде чем начать работу.
Я сделал это вики-сообществом, чтобы другие люди могли делиться там процессом разработки. Я не ожидаю найти единственно правильный ответ здесь - ваш процесс - ваш собственный, и я не ожидаю, что вы делаете, чтобы просто работать на себя или кого-то еще. Я просто заинтересован в улучшении моей способности разрабатывать плагины и темы, чтобы увидеть, что работает или не работает для других людей.
Другой вопрос здесь обсуждает конкретные программные инструменты для поддержки разработки WordPress . Здесь я ищу дополнительные процессы и методологии, которые можно применять независимо от инструментов, за исключением определенных задач, которые могут быть выполнены только в определенном семействе инструментов.
источник
Ответы:
Для справки, я в основном делаю целые веб-сайты и плагины и разворачиваю их. Мой рабочий процесс очень тяжелый.
Чтобы начать работу над новым проектом, у меня есть сценарий оболочки, который позаботится о создании нового виртуального хоста и извлечет последний тег WordPress (из нашего собственного репозитория git, который отслеживает svn).
Основной формой всего веб-сайта является git-репозиторий на wp-content. Он содержит Capfile (файл Makefile capistrano eqiuivalent) и файл конфигурации YAML, которые вместе заботятся о развертывании ( http://github.com/dxw/wp-capistrano ). Также внутри этого репозитория я добавляю тему и плагины как подмодули git (да, мы поддерживаем git-репозитории и для сторонних плагинов - нам нравится использовать последнюю версию, которую мы лично протестировали).
Для темы у меня есть инструмент для создания кода ( github.com/dxw/wp-generate ). Это означает меньше думать о том, куда должен идти код, и у него есть естественный метод разделения между представлением и моделью / контроллером.
При написании плагинов я использую cucumber / webrat для разработки через тестирование ( github.com/dxw/cucumber-wordpress ).
А для переноса баз данных разработки в рабочую среду обычно это просто копирование дампа (WP_SITEURL и WP_HOME устанавливаются capistrano на промежуточные / рабочие машины, поэтому поиск / замена не выполняются).
Я не могу себе представить, сколько часов я сэкономил с этими сценариями.
источник
@Thomas Owens Этот вопрос несколько перекрывает и дублирует вопрос « Программное обеспечение для разработки тем / плагинов WordPress? ». Не уверен, что мы должны закрыться, но это, кажется, немного другой фокус. Так...
Mac OS X
Вот мой основной набор инструментов для Max OS X (всегда в поисках лучшего). Обратите внимание, я попробовал NetBeans и отказался от него. Слишком вяло и слишком мало возможностей.
Виндоус виста
Когда я работал в Windows Vista, мой основной набор инструментов был:
Развертывание кода / миграция данных для переключения доменов
Не уверен, что это именно то, что вы ищете, но я разрабатываю плагин для облегчения миграции между локальным сервером разработки, тестовым сервером и сервером развертывания. Я написал об этом здесь:
Надеюсь это поможет
-Майк
источник
Это ответ рабочего процесса, не специфичный для 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 включают в себя:
Вертикальные расколы и
:set hidden
имеют важное значение. Я также предпочитаю 256-цветный терминал ( iTerm на Mac OS X) с Railscasts цветовой схемой .Мы также медленно модифицировали dBug в соответствии с нашими потребностями. Хорошая замена для
print_r()
иvar_dump()
когда вы знаете, что переменная является массивом или объектом.Развертывание
В настоящее время я не работаю над многими общедоступными плагинами / темами, поэтому не проверяю совместимость плагинов с несколькими версиями WordPress. Я пишу код на сервере разработчиков и перевожу этот код в производство через Subversion.
источник
Процесс разработки WordPress Theme
Конвертировать каркас Mock Flow в базовый XHTML и CSS
Подключите XHTML к файлу шаблона master.php и конвертируйте в теги Template и функции WP
Разделите master.php на различные файлы шаблона, а именно: header.php, index.php, sidebar.php и footer.php
Напишите любые пользовательские запросы и функции, которые могут понадобиться
Подключите CSS макет и добавьте,
div {outline:1px solid red;}
чтобы помочь настроить макет4.Загрузите папку Theme в WordPress для тестирования и дальнейшей разработки.
Инструменты разработки WordPress
Aptana Studio Редактор кода WorkPlace со встроенным FTP
шпатлевка
два монитора 1920 x 1200 с открытым браузером на одном и редактором кода на другом
Wacom Intuis 4 планшет
Firebug с Yslow и скоростью Google Page
источник
Мой рабочий процесс довольно прост. Я не отставал от 4 сред. Тестирование, разработка, постановка и производство.
Workflow
Я использую git для контроля версий; Я игнорирую файл wp-config.php, поэтому этот файл не перезаписывается, когда я перемещаюсь по разным местам. Я использую Unuddle как общедоступный / центральный репозиторий, из которого другие могут выталкивать и вытягивать.
Кажется, это работает довольно хорошо. Я буду совершать так часто, как я себя помню, пока я работаю над тестированием. По крайней мере, один раз в день, если не больше, я синхронизируюсь с unuddle и заставляю сервер разработки вносить изменения. Я стараюсь не выполнять какую-либо прямую работу на сервере, поэтому я в основном просто вношу изменения. Если в базу данных были внесены значительные изменения (новые плагины, обновленный контент и т. Д.), Я исключу это из своего тестирования; сделать резервную копию разработки и импортировать дамп.
Я использую тот же процесс для постановки. Постановка находится на том же сервере, что и производственный процесс, дважды проверьте правильность и убедитесь, что все настройки и модули работают на рабочем сервере. Когда я буду готов, я создаю резервные копии всех рабочих файлов и базы данных и копирую файлы и базу данных из рабочей сцены.
Так как wp-config.php отсутствует в git, он довольно прост в использовании. При переходе к производству из рабочей среды я копирую файлы и не использую git, поэтому я должен убедиться, что wp-config.php указан правильно.
Я задал симлиарный вопрос , и я собираюсь изучить использование этого плагина.
Я также думал об использовании Capistrano; и создание очень подробного сценария миграции, который будет проходить и обрабатывать все файлы и резервные копии / миграции базы данных, а также обновлять пути к файлам и URL-адреса.
инструменты
источник
Одна вещь, которая помогает мне (особенно при работе над несколькими темами клиента), - это использование WordPress Multisite на моем сервере разработки. Таким образом, я могу иметь столько открытых вакансий, сколько нужно, и не беспокоиться о клиенте А, видящем тему клиента Б. Соедините это с полным пакетом примеров контента, который я загружаю каждый раз, когда создаю новый сайт, и у вас есть отличная система разработки.
источник
Я делаю от взлома на месте на сервере в духе жизненной системы до более структурированного dev / test / stage / жизненного цикла с использованием систем контроля версий и автоматизированных тестов. Это зависит только от работы.
Кроме того, я сообщаю об ошибках обратно в проект WordPress, когда запускаю их.
Для разработки плагинов я стараюсь не заново изобретать колесо, а создавать новые на основе существующих принципов и шаблонов.
источник
Вот мой рабочий процесс:
Static
иtheme/plugin
папка вDynamic
папках с помощью Git.создать виртуальный хост для проекта. Я следую этой конвенции:
http://project1.dev/
http://project1.static.dev (опционально)
Я обычно следую за этой организацией папок:
Я знаю, что я еще не использую
build
инструмент изо дня в день, что заставляет меня чувствовать себя плохо.Но я использую инструмент сборки ANT для своего проекта Sprite2CSS в сочетании с парой PHP-скриптов для использования ANT.
инструменты
Будь я на Windows или Ubuntu, я использую следующее:
Я открыт для предложений по улучшению моего рабочего процесса.
источник
Я работаю в Windows с Denver , FileZilla, Notepad ++, Firefox Firebug и другими инспекторами (ссылки были выше), cPanel и dbForge Studio for MySQL
источник