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

Это позволяет строить сложные модели данных без жёсткой привязки к одной предметной области.

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

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

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

Для пользователя сохраняется не только сам факт принятия, но и 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-расширения:
- pdo и драйвер вашей СУБД
- mbstring
- json
- session
- fileinfo
- openssl
- curl
Redis опционален, если нужен Redis backend для кэша

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

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

cache/
logs/
uploads/

Ядро само подготавливает обязательные runtime-директории при install/bootstrap-проверке:

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;
если runtime-папка отсутствует или недоступна для записи, install-check завершится явной ошибкой.

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

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

php -S 127.0.0.1:8080 -t .

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

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

Важно:

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

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

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

index.php проверяет окружение;
подключается 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.

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

Единый install/deploy-источник схемы БД — это classes/system/Users.php, метод createTables().

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

install создаёт базовый набор таблиц через Users::createTables();
subsystem-инфраструктура поднимается из install-контура с явным force=true;
runtime-сервисы больше не должны делать CREATE TABLE/ALTER TABLE во время обычных web/CLI-запросов.

Роль файлов констант такая:

classes/system/Constants.php — рабочий файл констант ядра;
classes/system/Constants_clean.php — чистая копия для синхронизации и контроля изменений.

Они не являются двумя разными механизмами схемы БД. Источник развёртывания один: install/deploy-контур ядра.

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

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

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

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

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

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

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

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

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

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

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, configuration, core hooks, language files
/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 для 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 сценарии.

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

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

php app/cron/run.php

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

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

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

Почему архитектура 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 57 Commits
app		app
assets		assets
classes		classes
custom		custom
inc		inc
layouts		layouts
.gitignore		.gitignore
.htaccess		.htaccess
CHANGELOG.md		CHANGELOG.md
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

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

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

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

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

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

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