EE_FrameWork

EE_FrameWork — это PHP-фреймворк с MVC-ядром, встроенным административным контуром, гибкой контентной моделью и upgrade-safe слоем проектной кастомизации через custom/.

Проект ориентирован на разработку не шаблонных сайтов, а систем, где важны:

управляемая архитектура без избыточной магии;
быстрый старт для нового разработчика;
встроенная админ-панель;
гибкая модель сущностей, свойств, категорий и страниц;
расширяемость без правок ядра;
готовность к реальному production-использованию.

Что такое EE_FrameWork

EE_FrameWork объединяет в одном репозитории:

HTTP entrypoint и MVC-поток обработки запроса;
Router, View, Cache, Hook, Auth и logging-слой;
административный модуль для управления контентом и системой;
проектный слой custom/, который не должен теряться при обновлении ядра;
встроенные механизмы для поиска, фильтрации, lifecycle-синхронизации, агентного cron и работы со свойствами сущностей.

Это не микрофреймворк и не “голая CMS-тема”. Это основа для развития собственных проектов и сложных контентных систем.

Ключевые возможности

1. Явная MVC-архитектура

Поток запроса остаётся прозрачным:

URL -> Router -> Controller -> Model -> View -> Layout -> Response

Это упрощает:

отладку;
онбординг новых разработчиков;
развитие проекта без скрытых магических слоёв.

2. Встроенный административный контур

В проект уже входит admin-модуль, который покрывает:

пользователей и роли;
свойства, типы свойств и наборы;
типы категорий, категории и страницы;
импорт;
логи;
системные инструменты;
health/operational сценарии.

Дополнительно в ядре предусмотрены role-based auth hooks, которые позволяют проекту управлять разделением контуров /admin, /manager и /user через custom/hooks.php, не зашивая project policy в core.

3. Гибкая контентная модель

EE_FrameWork поддерживает связку:

property types -> properties -> sets -> category types -> categories -> pages

Это позволяет строить сложные модели данных без жёсткой привязки к одной предметной области. В property layer поддерживаются как простые поля, так и структурные значения вроде date-range и вложенных repeatable-group.

4. Встроенный legal-контур для пользователей

В платформе есть штатная поддержка двух обязательных документов:

Политика в отношении обработки персональных данных;
Согласие на обработку персональных данных.

Отдельно доступен шаблон согласия на обработку персональных данных, разрешённых для распространения. Он не входит в обязательный registration gate по умолчанию и подключается проектом там, где пользователь публикует контактные данные, изображения или иные материалы.

Для пользователя сохраняется не только сам факт принятия, но и metadata:

дата и время;
IP;
user-agent;
версия документа.

Это работает и в обычной регистрации, и в обязательном consent-gate для существующих аккаунтов.

5. Upgrade-safe расширяемость

Проектный код не должен жить в ядре.

Для этого есть:

app/ — маршруты, контроллеры, views, модульные js/css;
custom/ — project-specific hooks, bootstrap и сервисные классы, которые не нужно терять при обновлении платформы.

6. Production-oriented базовые подсистемы

В ядре уже предусмотрены:

кэширование;
логирование;
аутентификация и доступ;
routing cache и HTML cache;
агентный cron и очереди фоновой обработки;
резервное копирование через очередь и offsite targets SFTP/FTP;
lifecycle jobs;
операции обслуживания системы;
поисковая и фильтрационная подсистемы.

Для каких проектов подходит

EE_FrameWork особенно хорошо подходит для:

кастомных CMS и контентных платформ;
каталогов и экспертных систем;
информационных проектов со сложной структурой сущностей;
административных back-office систем;
платформ, которые должны эволюционировать в сторону маркетплейса, кабинетов, интеграций и тяжёлой бизнес-логики.

Быстрый старт

Требования

PHP 8.0+
MySQL/MariaDB
PHP-расширения:
- mysqli
- mbstring
- json
- session
- fileinfo
- openssl
- curl
Redis опционален, если нужен Redis backend для кэша

Права на директории

Веб-процесс должен иметь доступ на запись в:

cache/
logs/
uploads/

Установщик подготавливает обязательные runtime-директории:

cache/
logs/
logs/errors/
uploads/
uploads/tmp/
uploads/tmp/backups/
uploads/files/
uploads/images/
uploads/images/avatars/

Практически лучше использовать:

общего владельца или общую группу для CLI и web;
SGID/наследование группы для logs/ и cache/, чтобы фоновые задачи и веб не конфликтовали по правам.

Важно:

после клона разработчик не должен править ядро;
inc/configuration.php создаётся установщиком и не хранится в публичном репозитории;
для репозитория используется inc/configuration.sample.php;
если runtime-папка отсутствует или недоступна для записи, установка завершится явной ошибкой.

Установка платформы

Первичная установка выполняется через web-мастер:

/install/

Или через CLI:

php inc/cli.php install:run \
  --site-host=example.com \
  --site-author="Site owner" \
  --site-email=mail@example.com \
  --admin-email=mail@example.com \
  --db-name=project_db \
  --db-user=project_user \
  --db-pass=secret

Установщик:

создаёт inc/configuration.php из inc/configuration.sample.php;
проверяет подключение к базе данных;
при необходимости создаёт БД и пользователя;
разворачивает таблицы и стартовые данные;
создаёт bootstrap-пользователей;
проверяет состояние системы;
блокирует повторный запуск через web-интерфейс.

Настройки ENV_PROTO_LANGUAGE, ENV_CONTENT_LANGS, ENV_BOOTSTRAP533_CDN и ENV_FONT_AWESOME_CDN задаются в установщике как часть конфигурации проекта.

Минимальный запуск

Для первого локального smoke-теста достаточно:

php -S 127.0.0.1:8080 -t .

После этого можно проверить:

http://127.0.0.1:8080/install/
php inc/cli.php help

Важно:

встроенный сервер удобен для запуска установщика;
для полноценных красивых URL нужен Apache/Nginx с rewrite-правилами.

Что происходит при входе в систему

На верхнем уровне запрос проходит так:

index.php проверяет окружение;
запрос /install/ передаётся установщику до обычного runtime bootstrap;
для установленного проекта подключается inc/bootstrap.php;
inc/bootstrap.php загружает config из inc/configuration.php, вычисляет runtime-константы и подключает inc/startup.php;
вызывается runtime bootstrap;
поднимаются core-сервисы и custom/;
Router определяет контроллер и action;
управление передаётся контроллеру.

Важно:

inc/configuration.php предназначен только для настроек;
runtime-хелперы, вычисляемые значения, redirect-политика и ранний bootstrap живут в inc/bootstrap.php.

Схема БД И Развёртывание

Схема БД разворачивается только явным запуском установщика.

Что это значит на практике:

web-мастер /install/ и CLI-команда install:run выполняют один и тот же сценарий установки;
таблицы и стартовые данные создаются только во время установки;
обычные web/CLI-запросы не создают таблицы автоматически;
если проект не установлен, runtime сообщает об ошибке установки вместо автоматического развёртывания схемы.

Источник развёртывания один: установщик проекта.

Репозиторий И Runtime

В GitHub-репозиторий должны попадать:

ядро фреймворка;
custom/ как project layer;
документация;
hand-crafted артефакты проекта, если они нужны как часть исходников.

В репозиторий не должны попадать:

cache/
logs/
uploads/
экспортные ZIP-пакеты
боевой inc/configuration.php

В репозиторий должен попадать inc/configuration.sample.php: это шаблон, из которого установщик создаёт рабочий конфиг конкретного сайта.

.gitignore уже настроен под этот сценарий.

Security И Production Hardening

Production-развёртывание EE_FrameWork строится вокруг front controller:

публичная PHP-точка входа для HTTP - только index.php;
error.php используется как внутренний error endpoint;
PHP во внутренних директориях не должен исполняться напрямую через HTTP;
ENV_DEBUG=false, display_errors=0;
в webroot не должно быть phpinfo(), экспортов, SQL dump, тест-планов и operational notes;
inc/, classes/, layouts/, config/, custom/, app/cron/, data/, exports/, testplan/, logs/ и cache/ закрываются на уровне веб-сервера;
security headers задаются в Apache/Nginx;
admin API keys выдаются только доверенным интеграциям;
публичный rich text выводится только после allowlist sanitization.

Подробный чеклист hardened-развёртывания лежит в Security и production hardening.

Документация

Продуктовая документация лежит в custom/docs/.

Базовые разделы уже включают:

архитектуру;
routing;
content model;
импорт;
cron-агенты;
backup;
debug/health;
security и production hardening.

README.md должен оставаться короткой входной точкой для разработчика, а подробные сценарии поддержки и эксплуатации — жить в custom/docs/.

Первый модуль

Быстрый способ добавить собственный маршрут — новый модуль в app/.

Пример структуры:

app/hello/
├─ index.php
├─ views/
│  └─ v_index.php
├─ js/
└─ css/

Пример контроллера:

<?php

use classes\system\ControllerBase;

class ControllerHello extends ControllerBase {
    public function index($params = []): void {
        $this->view->set('message', 'Hello from EE_FrameWork');
        $this->html = $this->view->read('v_index');
        $this->parameters_layout['layout_content'] = $this->html;
        $this->showLayout($this->parameters_layout);
    }
}

Пример шаблона:

<?php if (!defined('ENV_SITE')) exit(header('Location: /', true, 301)); ?>
<h1><?= htmlspecialchars((string) ($message ?? ''), ENT_QUOTES) ?></h1>

После этого маршрут будет доступен по:

/hello

Как устроен проект

/index.php                 HTTP entrypoint
/inc/                      bootstrap, шаблон конфигурации, core hooks, language files
/inc/installer/            web/service-layer установщика
/inc/cli_commands/         CLI-команды установки, diagnostics, ops и cron
/classes/system/           ядро платформы
/classes/helpers/          helper- и service-классы
/app/                      модули, контроллеры, views, js/css, модели
/app/docs/                 docs-модуль как обычный маршрут
/custom/                   upgrade-safe слой проектной логики
/custom/docs/              исходники пользовательской документации
/layouts/                  layout-шаблоны
/assets/                   фронтовые и редакторские ассеты
/uploads/                  пользовательские файлы
/app/cron/                 только scheduler-wrapper'ы для реальных cron-задач
/inc/cli.php               единый CLI entrypoint для install, cron, diagnostics и ops
/error.php                 штатная обработка ошибок

Где писать код

В app/:

маршруты;
контроллеры;
views;
модульные js/css;
модели, относящиеся к конкретному модулю.

В custom/:

проектные hooks;
custom bootstrap;
сервисные классы проекта;
интеграционная логика, которую нельзя терять при обновлении ядра.

В ядре (inc/, classes/) стоит менять код только тогда, когда вы действительно развиваете сам фреймворк, а не отдельный проект на нём.

Основные подсистемы

Router

Отвечает за преобразование URL в:

модуль;
контроллер;
action;
аргументы.

Поддерживает route cache и debug-диагностику.

ControllerBase

Общий базовый слой контроллеров:

работа с View;
layout rendering;
доступ и redirect-сценарии;
интеграция с пользователем, языком и общими параметрами страницы.

Models

Модели инкапсулируют:

SQL;
валидацию данных;
lifecycle-операции;
транзакционную логику;
OperationResult для мутаций.

View и Layouts

Отвечают за:

передачу данных в шаблон;
рендер view;
сборку layout;
частичный кэш блоков;
безопасный вывод данных.

Hook API

Система хуков позволяет расширять поведение без правок core hooks:

Hook::add(...)
Hook::run(...)
Hook::filter(...)
Hook::until(...)

Проектные callback-ы регистрируются через custom/hooks.php.

Auth и доступ

В платформе есть отдельный auth-слой с:

пользователями;
ролями;
credential/session/challenge-моделью;
проверкой доступа на уровне контроллеров и административных маршрутов.

CacheManager

Общий cache-слой поддерживает:

file backend;
Redis backend;
route cache;
HTML cache;
block cache;
namespace/version изоляцию.

Logger

Система логирования ориентирована на production-эксплуатацию:

уровни логов;
каналы;
request_id;
контекст запроса;
ротация;
удобный просмотр логов в админке.

CLI и фоновые задачи

Для ручного запуска служебных команд и диагностики используется единый entrypoint:

php inc/cli.php help

Через него запускаются:

установка проекта;
scheduler-команды;
diagnostics-команды;
operational health-check сценарии.

Основные команды установки:

php inc/cli.php install:status
php inc/cli.php install:run --help

Каталог app/cron/ оставлен только для реальных scheduler-wrapper файлов, которые можно ставить в cron напрямую.

В production используется один минутный entrypoint:

php app/cron/run.php

Он не содержит бизнес-логики сам по себе. Вместо этого:

расписание задач хранится в БД;
handler-код живёт в проекте;
агентами управляет админка /admin/cron_agents;
scheduler сам учитывает блокировки, лимиты нагрузки и stale recovery.

Обязательные системные агенты для работы платформы создаются установщиком при развёртывании.

Почему архитектура EE_FrameWork удобна в развитии

Поток запроса легко читать в коде.
Проектный слой отделён от ядра.
Админка, lifecycle, поиск и фильтры уже встроены.
Большая часть системы не требует “догадок” о том, где лежит логика.
Есть понятные точки расширения:
- app/ для модулей и маршрутов
- custom/ для project-specific поведения
- hooks для точечного расширения

Карта документации

Подробная документация лежит в custom/docs/ и доступна как в репозитории, так и через docs-модуль.

Основные разделы

Если вы только знакомитесь с проектом, лучше идти именно в этом порядке.

Практические принципы разработки

Не кладите проектную логику в inc/hooks.php и inc/startup.php.
Используйте custom/ как upgrade-safe слой.
Не смешивайте SQL, HTML и сценарную логику в одном месте.
Для мутаций моделей придерживайтесь OperationResult.
Используйте hooks для расширения, а не как замену нормальной архитектуре.
Не считайте кэш источником истины.
Держите logs/, cache/ и uploads/ в корректных правах ещё до первых тестов.

Состояние проекта

EE_FrameWork развивается как реальная production-oriented платформа, а не как демонстрационный skeleton.

В репозитории уже есть:

административный модуль;
пользовательская документация;
кэширование;
логирование;
auth и доступ;
docs-модуль;
import и lifecycle-контур;
поисковая и фильтрационная подсистемы;
custom-layer для upgrade-safe развития проекта.

Это хорошая база для дальнейшего развития публичного фронта, project-specific бизнес-логики и интеграций.

Лицензия

См. LICENSE.md.

Name		Name	Last commit message	Last commit date
Latest commit History 67 Commits
app		app
assets		assets
classes		classes
custom		custom
inc		inc
layouts		layouts
.gitignore		.gitignore
.htaccess		.htaccess
LICENSE.md		LICENSE.md
README.md		README.md
error.php		error.php
favicon.ico		favicon.ico
favicon.png		favicon.png
index.php		index.php
robots.txt		robots.txt

Folders and files

Latest commit

History

Repository files navigation

EE_FrameWork

Что такое EE_FrameWork

Ключевые возможности

1. Явная MVC-архитектура

2. Встроенный административный контур

3. Гибкая контентная модель

4. Встроенный legal-контур для пользователей

5. Upgrade-safe расширяемость

6. Production-oriented базовые подсистемы

Для каких проектов подходит

Быстрый старт

Требования

Права на директории

Установка платформы

Минимальный запуск

Что происходит при входе в систему

Схема БД И Развёртывание

Репозиторий И Runtime

Security И Production Hardening

Документация

Первый модуль

Как устроен проект

Где писать код

Основные подсистемы

Router

ControllerBase

Models

View и Layouts

Hook API

Auth и доступ

CacheManager

Logger

CLI и фоновые задачи

Почему архитектура EE_FrameWork удобна в развитии

Карта документации

Основные разделы

Практические принципы разработки

Состояние проекта

Лицензия

About

Topics

Resources

License

Uh oh!

Stars

Watchers

Forks

Releases

Packages 0

Uh oh!

Uh oh!

Contributors

Uh oh!

Languages

Packages