Skip to content

Latest commit

 

History

History
160 lines (110 loc) · 21.8 KB

DevelopmentTools.md

File metadata and controls

160 lines (110 loc) · 21.8 KB

Инструменты разработки

XF2 предоставляет разработчикам ряд встроенных инструментов, которые вы можете использовать для ускорения разработки плагинов, и мы рассмотрим некоторые из них ниже.

Режим отладки

Режим отладки может быть включен в вашем config.php, который позволит вам получить доступ к определенным инструментам разработки в ACP (например, создавать маршруты, разрешения, навигацию ACP и т.д.), также в нижней части каждой страницы будет отображена отладочная информация в которой подробно описывается, сколько времени потребовалось для обработки страницы, сколько запросов было выполнено для отображения страницы и количества памяти. При наведении на шестеренку, будет показана информация о текущем контроллере, экшене и названии шаблона. Вы также можете нажать на время, и это даст вам подробный обзор того, какие запросы выполнялись, и трассировка стека, которая привела к выполнению этого запроса.

Чтобы включить режим отладки, добавьте следующую строку в config.php:

$config['debug'] = true;

Включение режима разработки

Режим разработки - это специальный режим, который включается в файле config.php, в этом режиме XF автоматически будет записывать ваши действия при разработке в ваш каталог _output. Чтобы редактировать шаблоны прямо в файловой системе, нужно включить этот режим. Поскольку режим разработки будет записывать файлы в вашу файловую систему, важно убедиться, что у вас есть соответствующие права доступа к файлам. Это может варьироваться в зависимости от среды, но в большинстве случаев достаточно убедится, что для любого плагина, над которым вы работаете, у вас есть _output-каталог и установленный chmod на 0777. Например, если вы работаете над плагином с идентификатором «Demo», его вывод разработки будет выписан в src/addons/Demo/_output, и поэтому этот каталог должен быть полностью доступен для записи.

Включение режима разработки автоматически включает режим отладки.

Чтобы включить режим разработки, добавьте следующие строки в файл config.php:

$config['development']['enabled'] = true;
$config['development']['defaultAddOn'] = 'SomeCompany/MyAddOn';

Значение defaultAddOn является необязательным, но если добавить этот параметр, при создании нового контента в ACP, он будет автоматически связан с указанным дополнением .

В дополнение к вышесказанному, вам может потребоваться добавить дополнительную конфигурацию, особенно если вы используете более одной установки XF.

$config['enableMail'] = false;

Это отключит отправку всей почты с вашей установки XF. Это особенно важно, если вы используете копию живых данных с реальными пользователями и реальными адресами электронной почты (не советуем так делать!).

В качестве альтернативы отключению почты напрямую вы можете по желанию использовать сервис MailTrap.io. Он дает вам бесплатный почтовый ящик, который будет получать все электронные письма, отправленные с вашей установки XF, что очень полезно для тестирования любых электронных писем, которые может отправлять ваше новое дополнение.

$config['cookie']['prefix'] = 'anything_';

Если вы используете две или более установки XF на одном домене, могут возникнуть проблемы с перезаписыванием файлов cookie, из-за использования несколькими установками одинаковых префиксов cookie. Поэтому рекомендуется убедиться, что вы изменили префикс cookie для каждой установленной вами установки XF. Без этого вы столкнетесь с проблемами, например, при выходе из одной установки XF при входе в другую.

Команды разработки

XF 2.0 поставляется с несколькими стандартными командами CLI для плагинов, которые направлены на то, чтобы ускорить процесс разработки, возможно, автоматизировать/запустить некоторые обычные процессы.

В этом разделе мы рассмотрим некоторые инструменты и объясним, что они делают.

Дополнительные команды плагинов

Создание нового плагина

$ php cmd.php xf-addon:create

Команда xf-addon:create позволяет создать и настроить новое дополнение. Вам следует ответить на несколько основных вопросов:

  • Введите идентификатор (ID) этого дополнения
  • Введите название
  • Введите идентификатор версии (ID) (т.е. 1000010)
  • Введите строку версии (т.е. 1.0.0 Alpha)

Затем вам будет предоставлена возможность создать плагин и файл addon.json в его каталоге и заданы некоторые вопросы о том, хотите ли вы добавить файл Setup.php.

Экспорт .XML файлов _data

$ php cmd.php xf-addon:export [addon_id]

Эта команда предназначена для экспорта всех данных вашего плагина в XML-файлы внутри каталога _data. Он экспортирует данные из того, что в настоящее время находится в базе данных (а не из файлов вывода разработки).

Повышение версии плагина

$ php cmd.php xf-addon:bump-version [addon_id] --version-id 1020370 --version-string 1.2.3

Эта команда позволяет изменить идентификатор и строку версии без необходимости обновления плагина. Вышеуказанные опции являются необязательными, и если они не предоставлены, вам будет предложено указать их. Если вы укажете только идентификатор версии, мы попытаемся вывести правильную строку версии из этого автоматически, если она соответствует нашему рекомендуемому формату версии. По завершению выполнения команда автоматически обновляет файл addon.json и базу данных правильной информацией о версии.

Синхронизация addon.json с базой данных

$ php cmd.php xf-addon:sync-json [addon_id]

Иногда вы можете изменить некоторые параметры в JSON файле напрямую. Это может быть версия, или новый значок, или новое название или описание. Таким образом, изменение JSON может привести к тому, что система плагинов будет думать, что есть ожидающие изменения или что плагин можно обновить. Восстановление или обновление могут вызвать проблемы (например, потеря данных), если вы еще не экспортировали свои текущие данные. Поэтому выполнение этой команды рекомендуется как способ импорта этих данных, не затрагивая ваши существующие данные.

Проверка файла addon.json

$ php cmd.php xf-addon:validate-json [addon_id]

Эта команда позволяет вам проверить, что ваш JSON-файл содержит правильное содержимое и в правильном формате. Валидатор проверяет, может ли контент быть декодирован, что он содержит все необходимые поля (например, название и идентификатор версии), а также проверяет наличие дополнительных ключей (например, описание и значок). Если какие-либо ключи отсутствуют, вам будут предложены исправления. Мы также проверяем, есть ли какие-либо неожиданные поля в файле JSON. Они могут быть преднамеренными или представлять опечатки. Вы можете запустить команду вручную, или команда будет запущена автоматически при создании вашей версии.

Запустить отдельный шаг установки

Иногда бывает полезно проверить правильность шагов вашего класса установки, не выполняя процесс удаления и переустановки.

Есть три команды, которые помогают в этом. Эти команды будут работать только с классами Setup, которые созданы с использованием стандартных параметров StepRunner.

Запустить шаг установки

$ php cmd.php xf-addon:install-step [addon_id] [step]

Запустить шаг обновления

$ php cmd.php xf-addon:upgrade-step [addon_id] [version] [step]

Запустить шаг удаления

$ php cmd.php xf-addon:uninstall-step [addon_id] [step]

Выпуск сборки плагина

После того, как все тяжелые работы были выполнены, стыдно проходить через ряд других процессов, прежде чем вы сможете их освободиться. Даже процесс сбора всех файлов в нужном месте и создания ZIP файла вручную может занять много времени и подвержен ошибкам. Мы можем позаботиться об этом автоматически, включая создание файла hashes.json, с помощью одной простой команды.

$ php cmd.php xf-addon:build-release [addon_id]

Когда вы запустите эту команду, сначала запустся команда «xf-addon:export», а затем соберет все ваши файлы во временный каталог _build и запишет их в ZIP-файл. Готовый ZIP также будет содержать файл hashes.json. Как только ZIP будет создан, он будет сохранен в вашем каталоге _releases и называется <ADDON ID> - <VERSION STRING>.zip.

Расширенный процесс сборки

Помимо создания ZIP-файла выпуска могут быть дополнительные файлы, которые вы хотите включить в свои ZIP-архивы, другие более сложные процессы сборки, которые вы хотите запустить, например, для минимизации или конкатенации JS или выполнения определенных команд оболочки. Обо всем этом можно позаботиться в файле build.json. Это типичный файл build.json:

{
    "additional_files": [
        "js/demo/portal"
    ],
    "minify": [
        "js/demo/portal/a.js",
        "js/demo/portal/b.js"
    ],
    "rollup": {
        "js/demo/portal/ab-rollup.js": [
            "js/demo/portal/a.min.js",
            "js/demo/portal/b.min.js"
        ]
    },
    "exec": [
        "echo '{title} version {version_string} ({version_id}) has been built successfully!' > 'src/addons/Demo/Portal/_build/built.txt'"
    ]
}

Если у вас есть компоненты, такие как JavaScript, которые хранятся вне вашего каталога плагина, вы можете сообщить процессу сборки для копирования файлов или каталогов с помощью массива additional_files в build.json. Во время разработки не всегда возможно хранить файлы вне вашего каталога плагина, поэтому, вы можете хранить файлы в своем каталоге плагина _files. При копировании дополнительных файлов мы сначала проверим их.

Если вы отправляете некоторые JS-файлы с плагином, возможно, вы захотите минифицировать эти файлы по соображениям производительности. Вы можете указать, какие файлы вы хотите минимизировать прямо внутри build.json. Вы можете перечислить их в виде массива или просто указать *, который минифицирует все в вашем каталоге js, если по этому пути будут JS-файлы, после копирования дополнительных файлов в сборку. Все минифицированные файлы, будут иметь суффикс .min.js вместо .js, и исходные файлы так же останутся в пакете.

Вы можете сгрупировать несколько JS-файлов в один файл. Если вы захотите сделать это, используйте массив rollup. Ключ - это имя конечного файла, а элементы внутри этого массива - это пути к файлам JS, которые будут объединены.

Наконец, у вас могут быть определенные процессы, которые необходимо запустить непосредственно перед тем, как пакет будет построен и завершен. Это может быть что угодно. Если это команда, которую можно запустить из оболочки (включая скрипты PHP), вы можете указать ее здесь. Вышеприведенный пример, конечно, бесполезен, но, по крайней мере, демонстрирует, что можно использовать некоторые переменные. Эти переменные заменяются скалярными значениями, которые вы можете получить из объекта XF\AddOn\AddOn, который обычно представляет собой любое значение, доступное в файле addon.json, или сущности AddOn.

Команды разработки

На данный момент существует несколько команд, связанных с разработкой, но здесь рассматриваются только две самые важные.

Чтобы использовать эти команды, обязательно нужно включить режим разработки.

Предупреждение Обе команды могут привести к потере данных по причине рассинхронизации базы данных и директории _output. Мы рекомендуем использовать СКВ (Систему Контроля Версий), к примеру GitHub чтобы смягчить последствия, в случае подобной ситуации.

Импорт вывода разработки

$ php cmd.php xf-dev:import --addon [addon_id]

Выполнение этой команды будет импортировать все выходные файлы разработки из вашего дополнительного каталога _output в базу данных.

Экспорт вывода разработки

$ php cmd.php xf-dev:export --addon [addon_id]

Эта команда экспортирует данные вашего плагина из базы данных в каталог _output.

Отладка кода

Для работы с XF2 вы можете настроить ваш любимый инструмент отладчика (XDebug, Zend Debugger и т.д.). Хотя, иногда, отладка кода может быть столь же элементарной, как просто быстро увидеть, какое значение (или тип значения) переменная держит в данный момент времени

Отладка переменной

PHP, конечно, имеет встроенный инструмент для отладки. Вероятно, вы знаете его как var_dump(). XF поставляется с двумя заменами этого инструмента:

\XF::dump($var);
\XF::dumpSimple($var);

Вариант Simple просто выгружает значение переменной в виде обычного текста. Например, если вы используете его для просмотра значения массива, в верхней части страниц вы увидите такой вывод:

array(2) {
	["user_id"] => int(1)
	["username"] => string(5) "Admin"
}

Фактически, этот инструмент делает то же, что и стандартный var_dump, но его вывод слегка изменен для удобочитаемости и обернутый внутри тегов <pre>, чтобы обеспечить сохранение пробелов при рендеринге.

Альтернативой на самом деле является компонент VarDumper из проекта Symfony. Он выводит HTML, CSS и JS для создания гораздо более функционального и потенциально более легкого для чтения вывода. Он позволяет свернуть определенные разделы, а для определенных значений, которые могут выводить значительный объем данных, таких как объекты, он может автоматически свернуть эти разделы.