Установка и базовая настройка

В прошлой части мы договорились сравнивать Laravel и 1С‑Битрикс честно: не как «фреймворк против CMS», а как два инструмента, на которых в реальности запускают проекты.

Сегодня — максимально прикладная часть: проверяем окружение, ставим, смотрим структуру проекта, и делаем “Hello World” именно как API (в Laravel это естественно, а в Битриксе — важно показать, что D7‑роутинг уже существует и это не только urlrewrite.php).

Требования к окружению: что нужно «по‑взрослому»

Laravel: требования и “dev experience” из коробки

• Laravel — это не “готовая система”, а проект на Composer. То есть сначала у вас появляется каркас приложения, а потом вы уже добавляете модули/пакеты/код.
• “Установить Laravel” = собрать окружение (PHP + расширения) и создать проект (через Composer или Laravel CLI).

Минимальные требования (Laravel 12):

• PHP: официально 8.2+ (для новых проектов в 2026 я бы целился в 8.4).
• PHP‑расширения: базовый набор для современного PHP‑стека (например, ctype, curl, dom, fileinfo, mbstring, openssl, pdo, tokenizer, xml и т.п.). Полный список и актуальные требования смотрите по докам Laravel.
• Composer: менеджер зависимостей.
• Node.js + npm (или Bun): для сборки фронтенда.
• Веб‑сервер: Nginx/Apache (или окружение, которое их включает). Для разработки Laravel умеет поднимать свой dev‑сервер.

Варианты локальной установки:

• Laravel Installer — консольная утилита laravel, которая автоматизирует создание проекта (по сути, удобная обёртка над установкой через Composer + настройка стартового набора). Это похоже на “мастер установки”, только в терминале.
• Herd — официальный “локальный сервер” для macOS/Windows: ставит и управляет PHP, Nginx и доменами вида *.test. По смыслу похож на OpenServer Panel, который часто используют, чтобы крутить Битрикс локально на Windows и, кстати, Laravel на нём замечательно работает. Однако, у Herd есть ограничения на бесплатной версии: БД - только SQLite, отсутствие возможности добавления дополнительных сервисов (например, Redis для кеша и очередей или Meilisearch для поиска). За платную просят 100$ за бессрочную лицензию.
• Sail — официальный вариант “Laravel через Docker”: это docker compose, упакованный в удобные команды. По смыслу ближе всего к подходу “поднять окружение контейнерами” (как вы делаете через env-docker в Битриксе).

Ссылки: Laravel 12.x Installation, Laravel 12.x Deployment.

Битрикс: окружение — это часть продукта

Минимальные требования (Битрикс 25.x):

• PHP: официально 8.1+ (для новых проектов в 2026 я рекомендую в 8.3, подробно описывал в статье о выборе версии PHP для Битриксе).
• PHP‑расширения (документация: dev.1c-bitrix.ru): GD, PHP XML, FreeType, регулярные выражения (POSIX, Perl-compatible), Zlib compression, PHP OpenSSL, Hash, Multibyte String, DOM, ZIP, MySQL, PostgreSQL, AMQP, SSL, LDAP.
• Веб‑сервер: Nginx/Apache (или окружение, которое их включает).
• MySQL 8.0+ или PostgreSQL 11+ (для редакций Enterprise)

Варианты локальной установки:

У Битрикса подход отличается от Laravel: установка окружения — это отдельная «линия», и официально предлагаются готовые варианты:

• BitrixVM: виртуальная машина,
• BitrixEnv: скрипт, который ставит и настраивает окружение на сервере RHEL (CentOS 9+, AlmaLinux 9+ и т.д.),
• Docker‑окружение: официальный репозиторий.

Неофициально пользуются популярностью:

• Bitrix in Docker: https://gitlab.com/bitrix-docker/server
• OpenServer Panel: https://ospanel.io/

Документация: Установка окружения.

Поддерживаемые базы данных: где свобода, а где границы

Laravel

Laravel по умолчанию (после laravel new) часто стартует с SQLite для простоты, но свободно работает с популярными СУБД (MySQL/MariaDB, PostgreSQL, SQLite, SQL Server), а всё «экзотическое» подключается через драйверы/пакеты.

Плюс: вы выбираете БД как инфраструктурное решение, а не как “условие платформы”.
Минус: если вам нужен «коробочный функционал» уровня CMS/магазина, вы всё равно это будете писать/собирать, а не «включать галочкой».

Битрикс

Поддерживаются MySQL и PostgreSQL, при этом Postgres - только в редакциях Enterprise от 2 млн руб.

Плюсы: штатно поставляется богатый функционал CMS.
Минусы: "постгря за два ляма" 😁

Установка Laravel: коротко и по делу

Официальная «точка входа» — документация: Laravel 12.x Installation.

Установка через Laravel Installer (наиболее “laravel-way”)

Создаём проект:

        laravel new example-app

    

Заходим в каталог и запускаем то, что Laravel считает нормальным “first run”:

        cd example-app
composer run dev

    

Дальше проект доступен на http://localhost:8000.

Структура проекта после установки (почему это важно)

У Laravel публичная директория отделена:

• public/ — то, что реально торчит наружу (index.php, статика),
• app/, config/, routes/, vendor/ — это код/конфиги, они живут “внутри”.

Это не «красота», а безопасность и удобство деплоя: если веб‑сервер внезапно начинает отдавать файлы как статику (ошибка конфигурации/обновление/сбой PHP‑FPM), у вас в public/ просто нечего “слить”, кроме того, что и так публичное.

Установка Битрикс через мастер установки

Установка дистрибутива у Битрикса обычно сводится к:

• положить в корень сайта bitrixsetup.php,
• открыть его в браузере,
• пройти мастер (лицензия → проверка → БД → админ → установка).

Подробно в документации.

А что Composer?

В контексте Битрикса Composer чаще означает:

• подключать сторонние библиотеки,
• подключать инструменты разработки (CLI, аннотации и т.д.),
• организовать зависимости так, чтобы они не конфликтовали с ядром.

Ключевой нюанс из документации:

• Битрикс по умолчанию ищет composer.json в /bitrix/, но рекомендуется размещать composer.json за пределами DOCUMENT_ROOT (чтобы его нельзя было “случайно отдать наружу”).

Это важный “звоночек” по архитектуре.

Структура проекта Битрикса и главный архитектурный минус: ядро в публичке

Стандартная структура Битрикса после установки (документация: структура директорий):

• /bitrix/ — системные файлы,
• /local/ — пользовательские доработки (сюда и нужно класть своё),
• /upload/ — загружаемые файлы.

Почему «ядро в публичке» — это минус (даже если “так принято”)

Факт: директория /bitrix/ находится в DOCUMENT_ROOT и физически доступна по URL (пусть и через выполнение PHP).

Чем это плохо на практике:

• Ошибки конфигурации веб‑сервера становятся опаснее. Если PHP на каком‑то участке перестал выполняться (или конкретные расширения/пути отдаются как файл), то риск «внезапно скачать то, что не должно скачиваться» выше.
• Смешение системного и пользовательского мира. Да, у Битрикса есть /local/, но рядом всё равно живёт огромное ядро, и человеческий фактор (“быстро поправил в /bitrix/”) встречается слишком часто.
• Деплой и неизменяемость. Современная практика — делать инфраструктуру и приложение максимально “immutable”. Когда ядро живёт в публичке и включает много исполняемых скриптов, дисциплина обновлений/прав доступа становится критичнее.

Как с этим жить правильно:

• всё своё — только в /local/,
• composer.json и связанные конфиги — вне DOCUMENT_ROOT,
• права на php_interface и конфиги — как на “сердце проекта”, а не как на обычные файлы.

“Hello World” как API: Laravel vs Bitrix (D7‑роутинг)

Laravel: “Hello World” в API за 30 секунд

В Laravel для API обычно используется routes/api.php.

Нюанс Laravel 12: API‑часть не установлена “из коробки” в чистом проекте — сначала выполните:

        php artisan api:install

    

Дальше добавляем маршрут в routes/api.php:

        use Illuminate\Support\Facades\Route;

Route::get('/hello', function () {
    return 'Hello, world!';
});

    

Проверка:

        curl -s http://localhost:8000/api/hello

    

Битрикс: “Hello World” как API через роутинг (main 21.400.0+)

В Битриксе роутинг поддерживается главным модулем main с версии 21.400.0 (см. документацию).

Шаг 1. Включаем входную точку роутинга

Нужно направлять обработку несуществующих файлов на routing_index.php:

• Apache — правка .htaccess
• Nginx — try_files $uri $uri/ /bitrix/routing_index.php;

Примеры есть в документации.

Шаг 2. Подключаем файлы роутинга в /local/.settings.php или /local/.settings_extra.php

Добавляем секцию routing, например чтобы подключить api.php:

        'routing' => [
    'value' => [
        'config' => ['api.php'],
    ],
    'readonly' => true,
],

    

Шаг 3. Создаём /local/routes/api.php и отдаём "Hello world!"

Самый простой “API hello” без модулей и автозагрузки — через static handler:

        <?php

use Bitrix\Main\Routing\RoutingConfigurator;

return static function (RoutingConfigurator $routes) {
    $routes->get('/api/hello', static function () {
        return 'Hello, world!';
    });
};

    

Проверка:

        curl -s https://your-domain.test/api/hello

    

Следующий шаг — вынести API в контроллеры на базе \Bitrix\Main\Engine\Controller, потому что там удобно работать с JSON, входными данными и политиками доступа (см. документацию по контроллерам).

Подробный процесс установки Битрикса и создание первого роута показаны в нашем видео на YouTube: Создаём первый API роут в Битрикс на чистом D7.

Плюсы и минусы: установка и первый запуск

Небольшая честная таблица — без религии.

Шкала (сквозной рейтинг по серии): от -2 (явный минус) до +2 (явный плюс). В конце статьи суммируем — и получаем накопительный счёт по проекту.

Короткий вывод (и что делать дальше)

Если вы ставите новый проект и хотите максимальную предсказуемость — Laravel даёт её уже на этапе установки.

Если вы ставите платформу с коробочным функционалом — Битрикс выигрывает тем, что много вещей «просто появляется» после мастера установки. Но за это платите архитектурными особенностями (включая “ядро в публичке”) и необходимостью держать дисциплину.

В следующей части перейдём к тому, что сразу бьёт по рукам на практике: структура проекта и архитектурные соглашения (где лежит код, как организовывать модули, и почему “всё в /local” — не просто рекомендация, а стратегия выживания).