Если вы тот, кто использует WordPress, чтобы зарабатывать на жизнь и рассказывать свою историю, увидеть изменения, которые вы добавили в базу кода WordPress, — это довольно увлекательная вещь. Я знаю, это было для меня.
В этом уроке вы узнаете несколько простых вещей, которые вам нужно знать, чтобы создать патч для WordPress, который может быть принят в основное программное обеспечение.
Хотя WordPress — это программное обеспечение с открытым исходным кодом, которое каждый может загрузить и изменить, только небольшая часть основных участников может зафиксировать свои изменения в самом WordPress. Если вы хотите внести изменения в основные файлы WordPress, вы можете предложить их либо путем создания заявки с подробным описанием предлагаемого изменения и прикрепления заплатки, либо путем прикрепления заплатки к существующей заявке.
Файл патча или diff — это файл, в котором подробно описываются изменения, внесенные вами в источник, который система контроля версий, такая как SVN или GIT, может использовать для применения ваших изменений. Создать патч легко с помощью командной строки или с помощью инструмента с графическим интерфейсом, такого как SourceTree .
В этой статье я подробно расскажу, как использовать превосходное приложение GIT GUI SourceTree для извлечения последней версии WordPress и создания файла патча. Вы можете использовать графический инструмент по вашему выбору или командную строку, если хотите.
Найти или создать билет в Core Trac
Когда вы отправляете свой патч в ядро WordPress, он должен быть прикреплен к заявке в трекере проблем WordPress, которая называется trac . Поэтому первым шагом в отправке патча является поиск или создание заявки.
Хотя возможно, что новый билет с новой функцией может быть принят, это не очень вероятно. WordPress имеет буквально миллионы пользователей, и имеет смысл только то, что ведущие разработчики очень осторожно относятся к внедрению новых функций. Почти все новые функции теперь разрабатываются отдельно в виде плагинов, и только после всестороннего тестирования и разработки они объединяются в ядро.
Лучшим вариантом для получения патча является создание патча для существующего тикета. Недавно основной трек был переработан, чтобы упростить поиск билетов с легкими исправлениями и теми, которые, скорее всего, будут включены в следующий выпуск и следующую версию WordPress.
Сообщения об ошибках
Если вы хотите создать новый тикет в Core Trac, что будет здорово, если вы нашли новую ошибку, вы можете сделать это здесь . Просто убедитесь, что вы искали trac для любых отчетов по той же проблеме, прежде чем создавать новый тикет, и что вы убедились, что ошибка существует в самой последней версии WordPress.
Я имею в виду не самый последний выпуск, а главную ветвь в терминологии GIT или транк в терминологии SVN. Я опишу, как получить последнюю версию позже в этом уроке.
Как минимум, вы должны заполнить поле сводки, которое является названием заявки, и поле описания, которое является содержимым заявки. В описании билета будьте как можно более наглядны.
На семинаре для участника WordCamp Orlando 2013, в котором я участвовал, ведущие разработчики WordPress Марк Джакит и Эндрю Нацин создали этот список того, что входит в хороший отчет об ошибках:
- шаги для воспроизведения проблемы, начиная с самого раннего шага
- описание ошибки
- то, что вы видели, в сравнении с тем, что вы ожидали
- сообщения об ошибках или коды ошибок
- Ошибки PHP (что было предупреждением на странице, что вошло в журнал, есть ли ошибки JavaScript или Apache / nginx?)
- какой браузер?
- окружение (ваша версия PHP, MySQL Apache или версия nginx)
- Это происходит без плагинов и темы по умолчанию?
- скриншоты для проблем пользовательского интерфейса
- быть ясным и лаконичным
- сначала укажу, потом детали.
- связанный номер билета
- одна ошибка на билет
- настройки постоянной ссылки
- Мультисайт включен или нет?
- WP_DEBUG или эквивалент включен?
- пользовательская роль вошла в систему, когда возникла проблема (или изменила роли в базе данных)
Имейте в виду, что не все из них имеют отношение к каждой ошибке, но чем больше информации вы можете добавить, тем лучше.
Если вы не уверены в том, что в них указывать, вам следует оставить поля ниже описания в покое и позволить основному участнику использовать их для соответствующей классификации заявки. Я бы порекомендовал вам использовать тег «Имеет патч» или «Требуется патч» в зависимости от того, устанавливаете ли вы патч для исправления ошибки или нет.
Извлечение последней версии WordPress из GitHub с помощью инструмента с графическим интерфейсом
Перед созданием патча для любого тикета важно, чтобы у вас была абсолютно последняя версия WordPress, так как в нее ежедневно вносится множество изменений. Невозможно узнать, работает ли ваше исправление или ваша ошибка все еще существует, если вы не используете самый последний код. Ваш патч, скорее всего, не будет принят, если он изменяет код, который уже изменился.
WordPress управляется в SVN, но этот код отражается как GIT-репозиторий в двух местах:
git://core.git.wordpress.org/- https://github.com/WordPress/WordPress
GitHub репозиторий является самым простым в использовании. Просто имейте в виду, что, хотя это официальное репозиторий GitHub, оно по-прежнему не используется для отслеживания проблем, и вам не следует отправлять на него запросы извлечения.
Есть много способов получить последнюю версию WordPress через SVN или Git. Лично я считаю, что проще всего использовать отличный инструмент GIT GUI SourceTree для клонирования зеркала GitHub. Это так же просто, как выбрать «New / Clone» в меню файлов, ввести адрес для репозитория Git в поле «Source Path / URL», а затем указать локальный путь для клонирования, который будет внутри вашего XAMMP или Vagrant. среда тестирования.
Говоря о Vagrant, популярная конфигурация WordPress Vagrant VVV имеет предварительно сконфигурированную среду тестирования для ядра WordPress, включая последний код и модульные тесты.
Создание файла исправления
После того, как вы внесли изменения в WordPress, которые необходимы для решения проблемы, которую вы пытаетесь исправить, и протестировали исправление, вам нужно создать файл исправления для загрузки в тикет. SourceTree включает в себя способ создания файла исправления или вы можете использовать командную строку.
В SourceTree вы можете создать файл исправления, перейдя в свою рабочую копию и щелкнув правой кнопкой мыши по файлам, которые были изменены. В контекстном меню выберите «Создать патч».
Кроме того, в своем терминале перейдите в корневой каталог репозитория WordPress и используйте эту команду для создания diff:
git diff —non-prefix ~/name.path
Независимо от того, как вы создаете свой файл патча, вы должны называть его после того номера билета, для которого он предназначен. Если это второй патч, загруженный в тикет, добавьте .2 к концу номера или .3, если это третий и т. Д. Например, пятый патч для билета # 12358 будет называться # 12358.5
Загрузка патча в Trac
Теперь, когда ваш патч готов к работе, вам нужно загрузить его в тикет Core Trac. На любом существующем тикете под описанием есть кнопка «Прикрепить файл», которую вы можете использовать для загрузки своего патча. На следующем экране обязательно добавьте описание того, что делает патч.
Будь терпелив и будь понимающим
WordPress — это масштабный проект, поэтому ожидать ответа на ваш патч нецелесообразно. Также следует понимать, что стандарты для патча, применяемого к WordPress, должны быть очень высокими, чтобы наилучшим образом обслуживать всех его пользователей.
После того, как вы отправили свой патч, наберитесь терпения и поймите все полученные отзывы Ведущие разработчики очень доступны, если у вас есть вопросы по поводу вашего патча или почему он не был улучшен, не стесняйтесь задавать один из них в IRC-канале # wordpress-dev.
Ожидание ответов и необходимость вносить изменения могут быть разочаровывающими, но это того стоит, когда ваш патч зафиксирован на WordPress, а описание набора изменений вас признает.