Обновление (октябрь 2026 г.): GLPI 12 вышел 7 октября 2026 г. со стабильной версией 12.0.0. Что меняется, какие требования и когда обновляться — в статье Вышел GLPI 12: что меняется, требования и когда обновляться. То, что мы протестировали в release candidate, по-прежнему доступно в статье GLPI 12 RC: что мы проверили на практике и когда обновляться.
GLPI 12 всё ещё находится в разработке, но уже можно следить за некоторыми изменениями, над которыми ведётся работа в официальном репозитории.
Речь идёт не только о новом интерфейсе или визуальных изменениях. Проект проходит серьёзную модернизацию своей структуры, прежде всего во фронтенде, в организации компонентов и в сокращении устаревших зависимостей.
Поскольку стабильной версии пока нет, всё, что мы представляем в этом материале, следует рассматривать как анализ текущего состояния разработки. Функциональность, требования и даже технические решения ещё могут измениться.
Модернизация интерфейса
Одно из главных изменений, над которыми идёт работа, касается фронтенда GLPI.
Сегодня в системе всё ещё есть компоненты, созданные на разных этапах проекта. В одних разделах используются традиционные PHP-страницы, в других — уже Twig, современный JavaScript и Vue.js.
В GLPI 12 тенденция — расширить эту модернизацию и сильнее стандартизировать интерфейс.
Среди работ, которые мы уже можем наблюдать:
более широкое использование Vue.js;
постепенная замена старых компонентов;
снижение зависимости от jQuery;
модернизация селекторов;
переработка компонентов загрузки файлов;
стандартизация полей и форм;
улучшения навигации;
переход процесса сборки на Vite.
Vite должен упростить разработку и поддержку компонентов фронтенда. Однако для конечного пользователя главным выигрышем должен стать более согласованный интерфейс с более стандартизированным поведением.
Тем не менее эта миграция ещё в процессе и не должна считаться завершённой до выхода стабильной версии.
Более стандартизированный интерфейс
Те, кто администрирует GLPI уже некоторое время, знают, что некоторые разделы ведут себя по-разному.
Это происходит потому, что части интерфейса создавались в разное время и с использованием разных технологий.
GLPI 12 должен уменьшить эту проблему за счёт повторного использования компонентов.
Это может принести улучшения в таких областях, как:
выбор организаций;
иерархические деревья;
поля форм;
вложения;
меню;
фильтры;
сообщения валидации;
выпадающие списки;
редакторы;
поиск.
На практике система, скорее всего, станет более предсказуемой для пользователей и более простой в поддержке для тех, кто разрабатывает плагины или интеграции.
База знаний
База знаний также претерпевает изменения.
Работа затрагивает редактор контента, управление файлами, навигацию между статьями и организацию информации.
Это важная область для компаний, которые используют GLPI не только для заявок, но и как:
базу процедур;
внутренний портал документации;
центр самообслуживания;
репозиторий решений;
поддержку для команд обслуживания.
Поскольку функция ещё тестируется, остаются незавершённые доработки, связанные с интерфейсом, переводами, производительностью и поведением категорий.
Поэтому пока нельзя точно сказать, какой будет база знаний в финальной версии.
Пользовательские активы
Пользовательские активы стали одной из главных новинок GLPI 11.
Эта функция позволяет создавать новые типы активов без необходимости напрямую изменять исходный код GLPI.
Компания может использовать эту возможность, например, для учёта:
промышленных машин;
медицинского оборудования;
транспортных средств;
мебели;
инструментов;
лабораторного оборудования;
любого другого объекта, специфичного для деятельности компании.
В GLPI 12 ожидается, что эти активы будут всё теснее интегрированы с остальной платформой.
Среди аспектов, которые должны продолжать развиваться:
поиск;
права;
связи;
организации;
история;
формы;
правила;
API;
импорт.
Это развитие важно, потому что позволяет использовать GLPI за пределами традиционной инвентаризации компьютеров, мониторов, принтеров и сетевого оборудования.
Внутренняя модернизация
Не все изменения будут видны на экране.
Значительная часть работы над GLPI 12 происходит во внутренней структуре системы.
Среди наблюдаемых аспектов:
рефакторинг PHP-кода;
сокращение унаследованного кода;
более широкое использование шаблонов Twig;
создание переиспользуемых компонентов;
замена старых библиотек;
улучшения автоматизированных тестов;
переработка фронтенда;
улучшения системы переводов;
развитие API;
совместимость с более новыми версиями PHP;
пересмотр совместимости с поддерживаемыми СУБД.
Такие изменения обычно привлекают меньше внимания, чем новый экран, но они необходимы для устойчивости проекта.
Чем меньше зависимость от старого кода, тем проще исправлять проблемы, внедрять новую функциональность и поддерживать совместимость плагинов.
Текущая техническая документация GLPI уже отражает этот переход к более модульной архитектуре, основанной на контроллерах, шаблонах, API и современных компонентах.
API и интеграции
Ещё один момент, за которым нужно внимательно следить, — развитие API.
Сегодня многие среды используют GLPI в интеграции с:
HR-системами;
ERP-системами;
инструментами мониторинга;
BI-решениями;
Active Directory и LDAP;
платформами автоматизации;
n8n;
собственными системами;
внешними порталами;
решениями для инвентаризации.
Смена мажорной версии может изменить эндпоинты, права, поля или форматы ответов.
Поэтому тем, у кого есть критичные интеграции, нужно в первую очередь протестировать:
аутентификацию;
создание и обновление заявок;
чтение активов;
поиск;
отправку документов;
связи между объектами;
права пользователей API;
ответы эндпоинтов.
Небезопасно считать, что интеграция, которая работает в GLPI 11, продолжит работать так же в GLPI 12 без проверки.
Безопасность
Работа над безопасностью в проекте продолжается.
Уже есть обсуждения и реализации, связанные с дополнительными мерами контроля для чувствительных операций, пересмотром прав и повторной аутентификацией при определённых действиях.
Тем не менее важно не ждать GLPI 12, чтобы поддерживать среду в безопасности.
Исправления безопасности по-прежнему публикуются в сопровождающих версиях GLPI 11. Поэтому производственные среды должны оставаться обновлёнными.
Базовые рекомендации также остаются в силе:
не изменять ядро;
поддерживать плагины в актуальном состоянии;
удалять заброшенные плагины;
пересматривать права;
защищать конфигурационные файлы;
использовать HTTPS;
поддерживать PHP и СУБД в актуальном состоянии;
правильно выполнять автоматические действия;
пересматривать пользователей API;
делать резервные копии базы данных и файлов.
Совместимость плагинов
Вероятно, это будет одним из главных поводов для внимания при миграции.
Новая мажорная версия может изменить классы, методы, хуки, JavaScript-компоненты, шаблоны и структуры, используемые плагинами.
Перед обновлением нужно будет проверить:
есть ли у плагина совместимая версия;
продолжает ли проект поддерживаться;
какие версии PHP поддерживаются;
есть ли изменения в базе данных;
изменились ли хуки;
продолжает ли работать фронтенд плагина;
остаются ли права корректными;
работают ли автоматические действия;
существует ли официальный процесс миграции.
Заброшенные плагины или плагины, которые напрямую изменяют поведение ядра, представляют больший риск.
Тем, у кого установлено много плагинов, следует начать тестирование до выхода стабильной версии.
Доработки ядра
Если в среде есть изменения непосредственно в файлах GLPI, обновление будет сложнее.
Эти изменения могут быть перезаписаны при обновлении или просто перестать работать.
В идеале доработки должны выполняться с использованием:
плагинов;
API;
вебхуков;
внешних интеграций;
официальных средств настройки.
Перед тестированием GLPI 12 важно собрать перечень всех существующих изменений в среде.
Сюда входят:
изменённые PHP-файлы;
изменённые шаблоны;
пользовательский CSS;
пользовательский JavaScript;
ручные изменения в базе данных;
триггеры;
представления (views);
интеграции;
собственные плагины.
Без такого перечня трудно отличить проблему GLPI от проблемы, вызванной старой доработкой.
Можно ли уже использовать GLPI 12 в продакшене?
Нет.
Текущую версию следует использовать только в лаборатории.
Её можно использовать, чтобы:
познакомиться с новым интерфейсом;
протестировать плагины;
проверить интеграции;
проанализировать технические изменения;
выявить возможные несовместимости;
протестировать процессы обслуживания;
подготовить команду к миграции.
Поскольку версия ещё в разработке, возможны:
ошибки;
регрессии;
изменения в базе данных;
незавершённая функциональность;
изменения в интерфейсе;
несовместимость с плагинами;
проблемы с переводом;
изменения без предварительного уведомления.
Мы также не рекомендуем подключать версию для разработки напрямую к производственной базе данных.
Тестирование следует проводить на изолированной копии базы данных и файлов.
Мы следим за GLPI 12 и тестируем его
В Nextools и JMBA Soluções мы уже следим за разработкой GLPI 12 и проводим тесты на доступных версиях.
Наша цель — заранее выявить влияние на:
плагины;
интеграции;
базу данных;
инфраструктуру;
аутентификацию;
API;
доработки;
процесс обновления.
Чтобы упростить такое тестирование, мы предоставляем Docker-образ с версией GLPI 12 для разработки.
Чтобы скачать:
docker pull jmbasolucoes/glpi:12-dev
Образ предназначен исключительно для тестирования.
Его не следует использовать в продакшене.
С его помощью можно быстро развернуть среду, чтобы:
оценить интерфейс;
протестировать плагины;
проверить LDAP и SSO;
протестировать интеграции;
проанализировать инвентаризацию;
проверить формы;
проверить правила;
выявить несовместимости.
Перед тестированием обновления всегда используйте копию среды.
Не подключайте этот образ к производственной базе данных.
Пример Docker-среды
Ниже приведён простой пример запуска GLPI 12 с отдельной базой данных для лаборатории:
services:
glpi:
image: jmbasolucoes/glpi:12-dev
container_name: glpi-12-dev
restart: unless-stopped
ports:
- "8080:80"
environment:
TZ: America/Sao_Paulo
volumes:
- ./files:/var/lib/glpi
- ./config:/etc/glpi
- ./plugins:/usr/share/glpi/plugins
- ./marketplace:/usr/share/glpi/marketplace
depends_on:
- db
db:
image: mariadb:11.4
container_name: glpi-12-dev-db
restart: unless-stopped
environment:
TZ: America/Sao_Paulo
MARIADB_DATABASE: glpi
MARIADB_USER: glpi
MARIADB_PASSWORD: altere_esta_senha
MARIADB_ROOT_PASSWORD: altere_a_senha_root
volumes:
- ./database:/var/lib/mysql
Чтобы запустить:
docker compose up -d
Затем откройте:
http://localhost:8080
Этот compose — лишь лабораторный пример, и его следует адаптировать под вашу среду.
Как подготовиться к GLPI 12
Не нужно ждать стабильной версии, чтобы начать подготовку.
Первый шаг — привести в порядок текущую среду.
Обновите GLPI 11
Прежде чем думать о GLPI 12, поддерживайте GLPI 11 в актуальном состоянии.
Миграция со старой версии увеличивает объём изменений и затрудняет выявление проблем.
Проведите инвентаризацию плагинов
Составьте список всех установленных плагинов и зафиксируйте:
версию;
разработчика;
назначение;
критичность;
статус поддержки;
зависимости;
совместимость.
Установленный, но неиспользуемый плагин следует удалить.
Задокументируйте интеграции
Зафиксируйте:
эндпоинт;
метод аутентификации;
используемого пользователя;
отправляемые поля;
получаемые поля;
периодичность;
зависимости;
обработку ошибок.
Создайте тестовую среду
Тестовая среда должна максимально воспроизводить продакшен:
PHP;
СУБД;
плагины;
настройки;
аутентификацию;
правила;
уведомления;
cron;
интеграции.
Составьте сценарий проверки
Недостаточно просто открыть GLPI и убедиться, что экран загрузился.
Нужно протестировать основные процессы:
создание заявок;
правила назначения;
SLA;
уведомления;
формы;
согласования;
задачи;
инвентаризацию;
LDAP;
SSO;
автоматические действия;
API;
отчёты;
дашборды;
права;
организации.
Чего мы на самом деле ждём от GLPI 12
Судя по тому, что мы смогли увидеть на данный момент, GLPI 12 будет не просто сменой версии.
Проект готовит более современную основу на ближайшие годы.
Основные моменты:
модернизация фронтенда;
более широкое использование Vue.js;
сокращение устаревших зависимостей;
стандартизация интерфейса;
развитие пользовательских активов;
улучшения базы знаний;
пересмотр API;
внутренние улучшения безопасности;
более простая поддержка кода;
лучшая основа для будущей функциональности.
Пока нельзя сказать, какие функции войдут в первую стабильную версию.
Также нельзя гарантировать, что всё, что сегодня появляется в разработке, будет выпущено именно в таком виде.
Сейчас время следить, тестировать и выявлять последствия.
У тех, у кого простая среда, процесс миграции, вероятно, пройдёт спокойнее.
Тем, у кого много плагинов, интеграций и собственных изменений, нужно начинать проверку заранее.
Чтобы начать тестирование:
docker pull jmbasolucoes/glpi:12-devВ следующих материалах мы поделимся тестами, которые проводим, отличиями от GLPI 11 и проблемами, обнаруженными в ходе этой подготовки.
Уже тестируете GLPI 12? Расскажите нам, что заработало, что сломалось и какие изменения вы обнаружили.
Примечание: этот материал отражает состояние разработки GLPI 12 на июль 2026 г. Поскольку версия ещё не стабильна, функциональность, требования, структура и поведение могут измениться.
