Возможно, конечно от «прослоек совместимости» в качестве «потомков» под крупные пакеты стоит применить нечто универсальное, пока не сильно задумывался над этим (но по мере роста объема кода это, возможно, будет неизбежным).
По твигу — действительно, ескейп решается |e насколько помню, но от назначения переменных и операций с ними вряд ли бы спасло (phpdoc там сделан для автокомплита). По поводу эскейпа — в большинстве случаев при отображении используются атрибуты моделей, которые завернуты в html purifier в зависимости от определенных types() входящих пользовательских данных (если для атрибута не указан принудительный тип[text|html|!secure], он автоматом упадет в очистку).

Ну почему же, возможно конкуренция среди Node проектов и ниже, но как минимум я использую cms для ряда своих и не только проектов, хотя сказать что поддержка собственного кода дается легче, чем код популярного фреймворка не могу.

Что вы имеете в виду под «контейнером зависимостей», применение паттерна DI? Он используется, достаточно редко для передачи в конструкторы моделей определенных объектов, которые наследуют интерфейс или базовый класс. Твиг достаточно удобен, но по сравнению с «голым» php различие в синтаксисе не велико (за исключением плюшек типа extend) а местами синтаксис выглядит неявным (к примеру сравнения, к этому синтаксису я привыкал достаточно долго).

Я задумывался над этим вопросом, возможно действительно следует сделать уклон в какое-то определенное нишевое направление, хотя в самых перспективных (eCommerce) конкурентов еще больше.

Ничего, бывает, у меня под вечер у самого глаза еле открыты после рабочего дня и пары публикаций. Зато теперь вы в этом точно уверены, а на последок подкину вам метод развертки проекта в 3 команды:

# установим глобальный asset плагин
composer global require "fxp/composer-asset-plugin:1.2.*"
# выполняем установку ffcms в ./path/to/root
composer create-project phpffcms/ffcms ./path/to/root 3.0.0 --keep-vcs
# загрузка последних обновлений
composer update
# инициализация консольного установщика
php console.php main:install

Развлекайтесь ;)

Конечно, это указано прям в статье и несколько раз. На всякий случай: composer.json / packagist

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

Хоть и с рынком и продажами знаком достаточно поверхностно, но насколько знаю тенденция последних лет — в уменьшении количества «звеньев» между покупателем<->продавцом, но наше государство думает иначе…

Да, я это уже понял позже когда более пристально глянул в «код», если его так можно назвать. Стоит ли оно того конечно вопрос (выходит что конфиг инклюдится, а позже считывается, а при сохранении замены ведутся перебором цикла, и тут шаг в сторону будет равен выстрелу в ногу).

Извините, но что это за убожество и как оно попало на habr? Автор, вы в php 2 недели отроду? Я пожалуй впервые вижу столь извращенный велосипед там, где он совсем не нужен и там, где есть отлично документированные нативные функции php. Отбросим следование стандартам, psr, best practice и другие концепции, давайте по факту.
1. Логика чтения и записи в файл конфигов. Я или очень сильно отстал от жизни, или чего-то не знаю, но зачем делать вот это:

public function getAtributes() {
		$conf_str=file_get_contents($this->file_name);
		foreach($this->date as $n=>$cf) {
			if(preg_match("#".$n."[^\r\n]*//([^\n\r]+)[\n\r]#",$conf_str,$m))
				$this->atribute[$n]=trim($m[1]);
		}
	}

Что вам мешает иметь конфиги вида:

<?php
return [
    'param1' => [
        'param2' => 'value'
    ]
];

и делать прямой инклюд данного конфиг-файла как то так:

.... 
if (!file_exists($path)) {
    return;
}
$configArray = include($path); // look at ex#5 http://php.net/manual/en/function.include.php
if (!is_array($configArray)) {
    return;
}

и вы получите тот же самый массив конфига без извращений через preg_match*, притом что ниже в конструкторе вы так делаете сами (вопрос — а на*рена этот конструктор там вообще?)

public function __construct($file_name) {
    // ....
    $this->date = require $this->file_name;
    // ..... 
}

Поехали дальше. Зачем вы делаете замену значений по ключу в строке?

public function safe(){
    $conf_str=var_export($this->date,true);
    //$atr=$model->getAtribute();
    foreach($this->atribute as $n=>$v) {
        $conf_str=preg_replace("#([^\n\r]*".$n."[^\n\r]*)[\n\r]#is","\\1//".$v."\n",$conf_str);
    }
    file_put_contents($this->file_name,"<? \n return ".$conf_str." \n ?>");
}

выглядит так, будто вы специально пытаетесь выстрелить себе в ногу или сломать ее о свой кривой велосипед. Почему вы не работаете со своим же массивом $this->data не обновляя в нем значения переменных из входящего POST а позже не конвертируете финальный результат в str (var_export)? Какую цель вы преследуете, заменяя значения через preg_replace в сконвертированной строке?
2. Смешались в кучу кони-люди. Зачем вы используете синтаксис html/css в теле функций на echo? Я видал всякое, видал echo внутри php конструкций, видал echo и return'ы внутри функций, но чтобы в теле класса содержимое метода представляли вот так:

<?php
class Configer {
    	function showForm(){ ?>
		
<style>
	#configForm span{display:inline-block; width:150px; }
}

я вижу впервые… не нужно так.

Только хотел оставить такой же комментарий, поправьте если я не прав, но уровень «поддержки оборудования» это системные драйверы а не особенность железяки.

А вот вам сниппет на laravel active record(или замените класс Fruit на DB::table('fruit') если модель не описана):

$red = Fruit::select('name', 'colour', 'calories')->where('calories', '<', 150)->where('colour', 'red')->get();
$yellow = Fruit::select('name', 'colour', 'calories')->where('calories', '<', 175)->where('colour', 'yellow')->get();

как по мне — куда удобней и приятней, чем оба варианта выше.

В том то и дело, что в примерах Query builder не короче, а из автодополнения вы получите только методы

Не короче? Ну посчитайте, хоть через strlen, однозначно короче. Если вы пойдете дальше и будете использовать ActiveRecord с описанием моделей, в том числе phpdoc «property type $column» у вас будет просто замечательный автокомплит.

По вашим публикациям, пожалуй, можно собрать самый яркий список применения анти-паттернов.

Query builder так же слишком далёк, к примеру, я никогда не пойму зачем люди пишут такое (Laravel 5.2):

И жаль что не поймете. Как минимум, QueryBuilder в паре с ActiveRecord (laravel5, yii2) позволяют куда удобней работать с БД чем писать запросы вручную. Кроме того, ООП-синтаксис запросов (builder/ar) куда приятней plain-text'a в sql, а при адекватно настроенной IDE позволяет существенно упростить их написание (при помощи autocomplete). Посмотрите так же на длину и лаконичность запроса через builder/ar либо классический sql. Выше вам так же намекнули на гибкость билдера для разных типов серверов СубДБ.
Ваша реализация с передачей запросов в ->q() [query], ->f() [fetch] имеет сомнительную полезность по сравнению с классическом pdo_prepared, а следующий код поднимает волосы на заднице на голове дыбом:

->qf() === ->f(->q(...))
->qfa() === ->f(->q(...), false, true)
->qfs() === ->f(->q(...), true)
->qfas() === ->f(->q(...), true, true)

В querybuilder'e вы не увидете таких извращений, а запросы select->fetch далаются в 1 строку и вполне читаемы. Такой конструкцией вы усложняете разработку под вашу cms другим людям, ведь это вовсе не классический вид pdo_prepared запросов и не querybuilder (стороннему разработчику придется тратить время и нервы чтобы приноровиться к такому стилю).

Автор лишь показал уязвимое поле (туда можно пихнуть что угодно, вплоть до целевого сплоита). И зря вы думаете, что картинка со стороннего ресурса это абсолютно безопасно — как минимум с ее помощью можно успешно собирать статистику о пользователях сайта.

Добавлю на всякий случай — если для автора уж слишком «проблемно» изучение PDO, то подготавливаемые запросы есть и в mysqli для ооп и процедурного стиля: пруф. При использовании такого подхода разница между mysqli/pdo по синтаксису будет минимальна, а в дальнейшем поможет плавно перейти к PDO.

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

Насколько мне позволяет сказать мой опыт статистики — распределение величин может либо соответствовать либо не соответствовать закону распределения (степень «соответствия» редко кого интересует).
Для определения соответствия закону распределения используют «критерии точности», к примеру колмогорова-смирнова или хи-квадрат — оба сводятся к расчету накопительной суммы квадратов (или модулей с сортировкой по возрастанию) отклонений и сравнению этих отклонений с «критическими» значениями из таблицы (если полученное эмпирическое значение > критического значения t05 то делается вывод о том, что выборка не соответствует закону распределения, или для хи-квадрата отвергается нулевая гипотеза об однородности данных).

Да, видел, вы это, из теглайна и релизов удалите старый с «support php 5.5» и создайте его снова, чтобы в 'stable' нормально стягивало.

Я смотрел, правда очень бегло, но не нашел массового использования основных «фишек» 5.6 — плавающего кол-ва параметров аргументов фу-ии или использования «default», отлова «несуществующих» каллбэков тоже вроде не заметил через try-catch над object, deprecated function вам вовсе рано использовать, так что вам думаю видней в чем там загвоздка была.

В принципе, вполне годная для использования библиотека, код вполне качественный, да и использовать удобно. Но возникло, как говориться одно «но»:

"php": ">=5.6.0"

да, php 5.5 сейчас уже вышел из «active support» и перешел в «security updates only», но некоторые твердолобые до сих пор его используют и объяснить им что срочно необходимо обновляться до 5.6/7.0 проблематично. Есть ли возможность ввести поддержку 5.5?
Еще 1 вопрос о поддержке laravel/lumen — может стоит оформить отдельным пакетом, а базовый выделить как «standalone» и его уже использовать в require для пакета laravel/lumen?