XenForo Helgring XF Release Builder 1.2.3

Shum1kh1n · 05.10.2026 21:58:14

Shum1kh1n опубликовал новый ресурс:

Helgring XF Release Builder - Сборка и проверка релизов XenForo add-on через SSH, штатный CLI и контроль целостности ZIP.

Helgring XF Release Builder
Посмотреть вложение 827
✦ Сборка, скачивание и независимая проверка релизов XenForo add-on ✦
Helgring XF Release Builder — портативная Windows-утилита для...

Подробнее об этом ресурсе...

Shum1kh1n · 08.10.2026 15:37:54

Как правильно настроить config.json для Helgring XF Release Builder

✦ Подробная инструкция по заполнению config.json, поиску правильного пути форума, настройке SSH-параметров и подготовке утилиты к работе ✦

Что такое config.json и зачем он нужен:
Файл config.json — это основной конфигурационный файл утилиты Helgring XF Release Builder. Именно в нём указываются все параметры, которые нужны программе для подключения к серверу и сборки релиза XenForo.

Проще говоря, config.json сообщает утилите:

куда подключаться — SSH-хост, порт и логин;
где находится форум — рабочий путь до XenForo;
какой PHP CLI использовать — чтобы команды XenForo запускались корректно;
какой add-on собирать — идентификатор дополнения;
где искать готовый ZIP — путь до папки _releases.

Без правильно заполненного config.json утилита не сможет запустить сборку.

Где должен лежать config.json:
Файл config.json должен лежать в одной папке с EXE-файлом утилиты.

Код:

Helgring XF Release Builder.exe
config.json

Именно в таком виде и рекомендуется использовать публичную версию программы.

Где вводить команды для проверки пути и окружения:
Все команды, которые приведены ниже, нужно вводить не в самой утилите, а в SSH-терминале. Это может быть:

Termius
встроенный SSH-терминал хостинга
PuTTY
любой другой SSH-клиент

Сначала пользователь подключается по SSH к своему серверу, а уже после входа в SSH-сессию вводит команды проверки пути, PHP и структуры форума.

Базовая структура config.json:
Внутри файла обязательно должен быть объект profiles. В нём хранится один или несколько профилей. Каждый профиль — это отдельный набор параметров для конкретного сервера, dev-форума или add-on-проекта.

JSON:

{
  "profiles": {
    "мой_профиль": {
      "host": "ваш_IP_или_домен_сервера",
      "port": 22,
      "username": "ваш_ssh_логин",
      "forum_root": ".",
      "php_bin": "/путь/до/php",
      "addon_id": "Vendor/AddOn",
      "release_dir": "src/addons/Vendor/AddOn/_releases",
      "download_dir": "./downloads",
      "timeout": 60,
      "run_sync_json": false,
      "auth": {
        "method": "password"
      }
    }
  }
}

Расшифровка каждого параметра:

host — адрес сервера для SSH-подключения. Это может быть IP-адрес или доменное имя SSH-сервера.
port — SSH-порт. Обычно это 22, если хостинг не использует другой порт.
username — SSH-логин пользователя, под которым выполняется вход на сервер.
forum_root — рабочий путь до корня форума XenForo с точки зрения SSH-сессии.
php_bin — полный путь до PHP CLI, через который будут запускаться команды XenForo.
addon_id — идентификатор дополнения в формате Vendor/AddOn.
release_dir — путь до папки _releases, где XenForo создаёт готовый ZIP-архив.
download_dir — папка на компьютере пользователя, куда утилита скачает собранный архив.
timeout — таймаут SSH-операций в секундах.
run_sync_json — запускать ли xf-addon:sync-json перед сборкой. Если не требуется — можно оставить false.
auth.method — способ авторизации: password для пароля или key для SSH-ключа.

Как узнать правильный forum_root:
Это один из самых важных параметров. Именно здесь пользователи чаще всего ошибаются.
После подключения по SSH нужно понять, в какой папке реально находится форум XenForo, а не какой путь показывает FTP-клиент или панель хостинга.
Шаг 1. После входа по SSH выполните команду:

Bash:

pwd

Эта команда покажет текущую рабочую папку, в которой вы находитесь после входа по SSH.
Шаг 2. Посмотрите содержимое текущей папки:

Bash:

ls -la

Если в этой папке вы уже видите файлы и каталоги XenForo, например:

cmd.php
src
js
styles
src/config.php

значит вы уже находитесь в корне форума. В таком случае можно указать:

JSON:

"forum_root": "."

Точка . означает: использовать текущую папку как рабочую.
Шаг 3. Проверьте, действительно ли в текущей папке лежит XenForo:

Bash:

ls -la cmd.php
ls -la src/config.php

Если обе команды показывают существующие файлы, значит текущий каталог действительно подходит для работы.
Шаг 4. Если вы не уверены, где лежит форум, можно найти cmd.php так:

Bash:

find . -maxdepth 3 -name cmd.php 2>/dev/null

Если команда возвращает, например:

Код:

./cmd.php

это означает, что cmd.php лежит прямо в текущей папке, а значит forum_root = "." подходит правильно.
Если же команда возвращает, например:

Код:

./public_html/cmd.php

то в таком случае нужно использовать уже другой путь, например:

JSON:

"forum_root": "./public_html"

Почему у одного пользователя forum_root = ".", а у другого нет:
Потому что разные хостинги и разные SSH-аккаунты ведут себя по-разному.

У одного пользователя SSH сразу открывается в корне форума — тогда подходит .
У другого пользователя SSH открывается в домашней папке, а форум лежит глубже — тогда нужно указывать путь вроде ./public_html или другой реальный рабочий каталог.
FTP-путь и SSH-путь не всегда совпадают. Именно поэтому путь нужно проверять через SSH-команды, а не угадывать.

Как узнать правильный php_bin:
После входа по SSH можно проверить, какой PHP вообще доступен, с помощью команд:

Bash:

which php
php -v
php --ini

Но важно понимать, что обычный php из PATH не всегда подходит. На некоторых хостингах рабочий CLI-бинарник может быть, например:

Код:

/usr/local/bin/php8.3

Проверить это можно так:

Bash:

/usr/local/bin/php8.3 -v
/usr/local/bin/php8.3 -m | grep -i '^mbstring$'

Если версия PHP выводится, а mbstring найден, значит этот путь подходит для php_bin.

Как определить правильный addon_id:
Поле addon_id должно совпадать с реальным путём в src/addons.
Например, если ваш add-on лежит здесь:

Код:

src/addons/Spolzer/StickyPost

тогда addon_id должен быть таким:

JSON:

"addon_id": "Spolzer/StickyPost"

Если путь выглядит так:

Код:

src/addons/Helgring/MessageNoticePro

тогда правильно будет:

JSON:

"addon_id": "Helgring/MessageNoticePro"

Как определить правильный release_dir:
Поле release_dir должно указывать на папку _releases именно того add-on, который вы собираете.
Примеры:

JSON:

"release_dir": "src/addons/Spolzer/StickyPost/_releases"

JSON:

"release_dir": "src/addons/Helgring/MessageNoticePro/_releases"

Если путь указан неверно, утилита может успешно собрать релиз на сервере, но потом не сможет найти ZIP для скачивания.

Пример готового config.json для обычного пользователя:

JSON:

{
  "profiles": {
    "мой_профиль": {
      "host": "123.123.123.123",
      "port": 22,
      "username": "мой_ssh_логин",
      "forum_root": ".",
      "php_bin": "/usr/local/bin/php8.3",
      "addon_id": "Spolzer/StickyPost",
      "release_dir": "src/addons/Spolzer/StickyPost/_releases",
      "download_dir": "./downloads",
      "timeout": 60,
      "run_sync_json": false,
      "auth": {
        "method": "password"
      }
    }
  }
}

В этом примере пользователю нужно заменить только свои реальные данные:

IP сервера или хост
SSH-логин
правильный путь до PHP CLI
идентификатор своего add-on
путь до папки _releases

Частые ошибки пользователей:

Неверный forum_root — пользователь указывает красивый FTP-путь из панели хостинга, но в SSH этот путь не работает.
Неверный php_bin — пользователь пишет просто php, хотя рабочий CLI-путь на сервере другой.
Неверный addon_id — из-за этого утилита не находит каталог дополнения.
Неверный release_dir — утилита не может найти готовый ZIP после сборки.
Ошибки синтаксиса в JSON — лишние запятые, неправильные кавычки или поломанная структура файла.

FAQ:

Можно ли использовать один профиль? Да. Это самый простой вариант. Если профиль в config.json только один, утилита может использовать его автоматически.
Можно ли хранить несколько профилей? Да. Это удобно, если вы собираете несколько разных add-on-проектов.
Нужно ли редактировать EXE-файл? Нет. Пользователь меняет только config.json.
Что делать, если не получается определить forum_root? Подключиться по SSH и проверить команды pwd, ls -la, ls -la cmd.php, ls -la src/config.php, find . -maxdepth 3 -name cmd.php 2>/dev/null.
Что делать, если программа не подключается по SSH? Проверить host, port, username, правильность пароля или SSH-ключа, а также доступность SSH на сервере.
Что делать, если программа не находит add-on? Проверить поля addon_id и forum_root.
Что делать, если готовый ZIP не скачивается? Проверить release_dir и убедиться, что релиз действительно был создан в папке _releases.

Итог:
Файл config.json — это центральная часть настройки Helgring XF Release Builder. Если он заполнен правильно, утилита сможет подключиться к серверу, проверить окружение, официально собрать релиз XenForo и скачать готовый архив на компьютер пользователя.

Главное правило простое: не угадывать пути, а проверять их через SSH. Именно это помогает правильно определить forum_root, php_bin и другие ключевые параметры без лишних ошибок.

Shum1kh1n · 08.10.2026 15:38:25

Как правильно включать JS, Styles и внешние файлы в релиз:
Если add-on использует не только файлы внутри src/addons/Vendor/AddOn, но и внешние ресурсы вроде js, styles или отдельных файлов в корне upload, то для их корректной сборки через xf-addon:build-release необходимо явно указать их в специальном файле build.json.

По умолчанию XenForo не будет автоматически угадывать и добавлять такие внешние файлы в релиз. Если их не описать отдельно, они не попадут ни в ZIP-архив, ни в hashes.json. Поэтому для правильной сборки релиза нужно заранее подготовить add-on к работе с дополнительными файлами.

Где нужно создать build.json:
Файл build.json создаётся внутри папки самого add-on, рядом с addon.json. То есть путь должен быть таким:

Код:

src/addons/Vendor/AddOn/build.json

Для примера с KL EditorManager это будет:

Код:

src/addons/KL/EditorManager/build.json

Что нужно записать в build.json:
Если плагин использует внешние JavaScript-файлы, style-ресурсы и отдельный публичный файл klEMProxy.php, то содержимое build.json должно быть примерно таким:

JSON:

{
  "additional_files": [
    "js/editor-manager",
    "styles/editor-manager",
    "klEMProxy.php"
  ]
}

Именно этот блок сообщает XenForo, что при сборке релиза нужно дополнительно включить в архив:

папку upload/js/editor-manager
папку upload/styles/editor-manager
файл upload/klEMProxy.php

Важно: одних записей в build.json недостаточно
Файл build.json сам по себе не создаёт ресурсы автоматически. Он только указывает XenForo, какие внешние файлы нужно забрать в релиз. Поэтому эти файлы должны реально существовать в исходной структуре add-on.

Иными словами, если в плагине используются js, styles и отдельные внешние PHP-файлы, они должны быть правильно подготовлены в исходниках до запуска xf-addon:build-release.

Как понять, какие внешние файлы вообще использует плагин:
Это очень важный момент. Перед созданием build.json нужно сначала определить, какие именно внешние пути реально относятся к конкретному add-on. Для этого можно использовать несколько простых способов:

Проверить оригинальный архив плагина — если в исходном релизе уже есть папки upload/js/..., upload/styles/... или отдельные файлы вроде upload/klEMProxy.php, значит они относятся к add-on и должны быть учтены в новой сборке.
Посмотреть hashes.json оригинального архива — если в hashes.json есть записи на js/..., styles/... или отдельные файлы в корне upload, значит они тоже входят в релизный состав плагина.
Проверить код add-on — иногда внешний файл прямо упоминается в PHP-классе, шаблоне или proxy-логике. Например, в KL EditorManager использовались klEMProxy.php, missing-audio.mp3 и missing-video.mp4, поэтому их отсутствие ломало или урезало часть функционала.
Проверить структуру работы плагина — если дополнение подключает собственный JavaScript, SVG-иконки, proxy-файлы, аудио/видео-заглушки или style-ресурсы, значит эти внешние элементы нужно явно учитывать при сборке.

Пример на практике для KL EditorManager:
В случае KL EditorManager в релизе использовались следующие внешние файлы:

js/editor-manager — JavaScript-файлы плагина
styles/editor-manager — SVG и мультимедийные заглушки
klEMProxy.php — публичный proxy-файл

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

Итог:
Если add-on использует внешние ресурсы вне стандартной папки src/addons, то их необходимо явно описывать через build.json. Без этого XenForo не включит их в официальный релизный архив.

Главное правило простое: сначала определить, какие внешние файлы реально использует плагин, а уже потом добавить их в additional_files. Именно это позволяет получить полный ZIP-архив и корректный hashes.json без пропусков по js, styles и другим внешним ресурсам.

Shum1kh1n · 08.10.2026 15:38:42

Как правильно настроить Helgring XF Release Builder 1.1.1 через SSH Key

✦ Подробная инструкция по настройке config.json, созданию SSH-ключа, проверке подключения и правильному использованию новой версии 1.1.1 ✦

Что изменилось в версии 1.1.1:
Главное изменение версии 1.1.1 заключается в том, что теперь публичная версия Helgring XF Release Builder ориентирована на работу через SSH Key, а не через обычный SSH-пароль.

Это означает, что для работы утилиты теперь рекомендуется использовать приватный SSH-ключ, а в config.json указывать:

JSON:

"auth": {
  "method": "key",
  "key_filename": "~/.ssh/id_ed25519"
}

Такой вариант удобнее для постоянной работы, потому что не требует каждый раз вводить пароль вручную. Если же вы не хотите настраивать SSH Key, можно использовать версию 1.1.0, где применяется auth.method = password.

Где должен лежать config.json:
Файл config.json должен лежать в одной папке с EXE-файлом утилиты.

Код:

Helgring XF Release Builder.exe
config.json

Пользователь редактирует только config.json. Сам EXE редактировать не нужно.

Базовая структура config.json для версии 1.1.1:

JSON:

{
  "profiles": {
    "my_server": {
      "host": "YOUR_SERVER_OR_DOMAIN",
      "port": 22,
      "username": "YOUR_SSH_LOGIN",
      "forum_root": ".",
      "php_bin": "/usr/local/bin/php8.3",
      "addon_id": "Vendor/AddOn",
      "release_dir": "src/addons/Vendor/AddOn/_releases",
      "download_dir": "./downloads",
      "timeout": 60,
      "run_sync_json": false,
      "auth": {
        "method": "key",
        "key_filename": "~/.ssh/id_ed22319"
      }
    }
  }
}

Что означает каждый параметр:

host — SSH-хост сервера. Это может быть домен или IP, если SSH действительно доступен по IP.
port — SSH-порт. Обычно это 22.
username — SSH-логин пользователя.
forum_root — путь до корня XenForo с точки зрения SSH-сессии.
php_bin — полный путь до PHP CLI на сервере.
addon_id — идентификатор add-on в формате Vendor/AddOn.
release_dir — путь до папки _releases, где XenForo создаёт ZIP-архив.
download_dir — локальная папка на компьютере, куда утилита скачает готовый релиз.
timeout — таймаут операций SSH.
run_sync_json — выполнять ли xf-addon:sync-json перед сборкой.
auth.method — способ авторизации. В версии 1.1.1 рекомендуется использовать key.
auth.key_filename — путь до приватного SSH-ключа пользователя на его компьютере.

Как создать SSH Key на Windows:
Если у вас ещё нет собственного SSH-ключа, его можно создать через PowerShell.
Шаг 1. Откройте PowerShell и выполните:

Код:

ssh-keygen -t ed25519

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

Код:

C:\Users\ИМЯ_ПОЛЬЗОВАТЕЛЯ\.ssh\id_ed22319
C:\Users\ИМЯ_ПОЛЬЗОВАТЕЛЯ\.ssh\id_ed22319.pub

Важно: файл id_ed25519 — это приватный ключ, его нельзя никому передавать. Файл id_ed25519.pub — это публичный ключ, его как раз и нужно добавлять на сервер.

Как получить содержимое публичного ключа:
В PowerShell выполните:

Код:

Get-Content $env:USERPROFILE\.ssh\id_ed25519.pub

Скопируйте всю строку целиком. Именно её нужно добавить на сервер в authorized_keys.

Как добавить SSH Key на сервер:
После входа в SSH-сессию на сервере нужно убедиться, что каталог .ssh существует, а публичный ключ добавлен в файл authorized_keys.

Bash:

mkdir -p ~/.ssh
chmod 700 ~/.ssh
nano ~/.ssh/authorized_keys

Вставьте туда содержимое своего публичного ключа, сохраните файл и затем выполните:

Bash:

chmod 600 ~/.ssh/authorized_keys

После этого сервер сможет принимать вход по вашему SSH-ключу.

Как проверить, что SSH Key действительно работает:
Проверьте подключение вручную через PowerShell:

Код:

ssh -i $env:USERPROFILE\.ssh\id_ed25519 ваш_логин@ваш_хост

Если вход выполняется успешно и сервер пускает вас в SSH-сессию, значит ключ настроен правильно и его можно использовать в config.json.

Как узнать правильный forum_root:
Это по-прежнему один из самых важных параметров. Проверять его нужно через SSH, а не по красивому пути из FTP-клиента или панели хостинга.
Шаг 1. После входа по SSH выполните:

Bash:

pwd

Шаг 2. Посмотрите содержимое текущей папки:

Bash:

ls -la

Если вы уже видите cmd.php, src, js, styles, src/config.php, значит, скорее всего, вы уже находитесь в корне форума и можно использовать:

JSON:

"forum_root": "."

Шаг 3. Проверьте это явно:

Bash:

ls -la cmd.php
ls -la src/config.php

Шаг 4. Если нужно найти форум глубже:

Bash:

find . -maxdepth 3 -name cmd.php 2>/dev/null

Если команда возвращает, например, ./public_html/cmd.php, тогда forum_root должен быть уже не ., а путь вроде:

JSON:

"forum_root": "./public_html"

Как узнать правильный php_bin:
После входа по SSH проверьте:

Bash:

which php
php -v
php --ini

Но для XenForo лучше указывать именно рабочий CLI-путь, например:

Код:

/usr/local/bin/php8.3

Проверить его можно так:

Bash:

/usr/local/bin/php8.3 -v
/usr/local/bin/php8.3 -m | grep -i '^mbstring$'

Если PHP запускается, а mbstring найден, такой путь подходит.

Пример готового config.json для версии 1.1.1:

JSON:

{
  "profiles": {
    "my_server": {
      "host": "123.123.123.123",
      "port": 22,
      "username": "my_ssh_login",
      "forum_root": ".",
      "php_bin": "/usr/local/bin/php8.3",
      "addon_id": "Vendor/AddOn",
      "release_dir": "src/addons/Vendor/AddOn/_releases",
      "download_dir": "./downloads",
      "timeout": 60,
      "run_sync_json": false,
      "auth": {
        "method": "key",
        "key_filename": "~/.ssh/id_ed25519"
      }
    }
  }
}

Пользователю нужно заменить этот шаблон только на свои реальные данные сервера и своего add-on-проекта.

Частые ошибки пользователей:

Неверный host — указан не тот SSH-домен или неверный IP.
Неверный username — используется не тот SSH-логин, который действительно работает на сервере.
Неверный forum_root — указан красивый путь из FTP, который в SSH не существует.
Неверный php_bin — на сервере используется другой путь до PHP CLI.
Неверный addon_id — из-за этого утилита не находит каталог дополнения.
Неверный release_dir — релиз собирается, но ZIP не находится для скачивания.
Указан key_filename, но сам ключ отсутствует — пользователь вписал путь до ключа, которого реально нет на его ПК.
Публичный ключ не добавлен в authorized_keys — локальный ключ есть, но сервер не знает о нём и вход не выполняется.
Ошибки JSON-синтаксиса — лишние запятые, неправильные кавычки или сломанная структура файла.

FAQ:

Нужно ли редактировать EXE-файл? Нет. Меняется только config.json.
Можно ли использовать один профиль? Да. Это самый простой вариант.
Можно ли хранить несколько профилей? Да. Это удобно, если вы работаете с несколькими форумами или add-on-проектами.
Можно ли использовать пароль вместо ключа? Для новой публичной версии 1.1.1 рекомендуется SSH Key. Если вы не хотите настраивать ключи, используйте версию 1.1.0, где применяется password.
Нужно ли передавать кому-то свой приватный ключ? Нет. Приватный ключ должен храниться только у вас.
Что делать, если SSH не подключается? Проверить host, port, username, наличие ключа на ПК и наличие публичного ключа на сервере в authorized_keys.
Что делать, если не удаётся определить forum_root? Подключиться по SSH и проверить pwd, ls -la, ls -la cmd.php, ls -la src/config.php, find . -maxdepth 3 -name cmd.php 2>/dev/null.
Что делать, если программа не находит add-on? Проверить addon_id и forum_root.
Что делать, если ZIP не скачивается? Проверить release_dir и убедиться, что релиз реально создан в папке _releases.

Итог:
Версия 1.1.1 — это более удобный и современный вариант Helgring XF Release Builder, ориентированный на работу через SSH Key. Такой подход избавляет от постоянного ввода пароля, делает запуск релизной сборки удобнее и лучше подходит для регулярного использования.

Лично я сам перешёл на эту версию, проверил её в рабочем использовании и решил поделиться ей со всеми. Если же вам не хочется заморачиваться с SSH Key, можно спокойно пользоваться версией 1.1.0, где авторизация работает через password.

Редактор тем

Настройка страницы Внешний вид

Выбор цветов

Переключить палитру цветов

Типография

Макет узлов

Включить сеточный макет

Стили

Выбор стиля

XenForo Helgring XF Release Builder 1.2.3

Shum1kh1n1

❤️ Энтузиаст

Shum1kh1n1

❤️ Энтузиаст

Shum1kh1n1

❤️ Энтузиаст

Shum1kh1n1

❤️ Энтузиаст

Официальное уведомление

Мы ценим вашу конфиденциальность

Редактор тем

Настройка страницы Внешний вид

Выбор цветов

Переключить палитру цветов

Типография

Макет узлов

Включить сеточный макет

Стили

Выбор стиля

XenForo Helgring XF Release Builder 1.2.3

Shum1kh1nПрофиль пользователя Shum1kh1n подтверждён.1

❤️ Энтузиаст

Shum1kh1nПрофиль пользователя Shum1kh1n подтверждён.1

❤️ Энтузиаст

Shum1kh1nПрофиль пользователя Shum1kh1n подтверждён.1

❤️ Энтузиаст

Shum1kh1nПрофиль пользователя Shum1kh1n подтверждён.1

❤️ Энтузиаст

Официальное уведомление

Мы ценим вашу конфиденциальность

Shum1kh1n1

Shum1kh1n1

Shum1kh1n1

Shum1kh1n1