Ку всем.
НАШЁЛ!!!!!1111адинадин

(Пост, возможно, будет обновляться)

Оказалось, я ночью сонный уже, сделал ошибку:
Вместо

<?
$template->pparse('confirm')
?>

написал

<?
$template->pparse('confirm_body')
?>

И форма испарилась
Я даже хотел откатить все изменения. Это было бы трудно, ибо движок уже полностью перепаян под новый обработчик фронт-энда ./details/includes/frontpage.php - он у меня заменил два файла, отдельные примитивные обработчики отдельно шапки и подвала, ./details/includes/page_header.php и ./details/includes/page_tail.php.
Почему я указал, что они были примитивные?
А потому, что они не обрабатывали много чего - например, сейчас можно склепать в составе ./details/includes/frontpage.php обработку респонсив дизайна, ежели потребуется.
Правда, сейчас я занимаюсь тем, что допиливаю обработчик, задаю условия и прочее, но главное уже сделано.
Он мне понадобился именно как цельный обработчик, так как я подзадолбался везде указывать два обработчика и писать много дополнительного кода.
Теперь я задачу вывода и обработки фронт-энда полностью скинул в обработчик.
В модулях достаточно указать

<?
define('IN_%MODULE%', true);
include($incl_path . 'frontpage.' . $phpEx);
?>

И ВСЁ!

Не надо прописывать, какие именно надо брать шаблоны, где, как и почему, можно только задать массив переменных с именами и значениями.
Это в обработчике приводит к запуску

<?
else if(defined('IN_%MODULE%')) // Укажем режим обработки
{
	$definer = 'IN_SMILES';
}

... // Некий код для обработки
... // Некий код для обработки
... // Некий код для обработки

switch($definer) // Выполняем обработанный код
{
	case 'IN_%MODULE%':
$template->set_filenames(array(
	'body' => '%template_name%.tpl'
	));
$template->pparse('header_common'); // Заданный отдельно шаблон шапки
$template->pparse('body');	// Заданный чуть выше шаблон модуля
$template->pparse('footer_common'); // Заданный отдельно шаблон подвала
	break;
}
?>

В итоге, обработчик выдаёт нам заданную страницу - и если надо, можно задать и какие-то особые условия.

Также обработчик фронт-энда реагирует на системную переменную режима страницы $mode, то есть, на вызовы типа (далее пример)
./viewtopic.php?mode=edit&p=1&t=1&f=1,
из чего обработчик делает вывод, что надо грузить форму правки поста, и тд и тп.
Код самих модулей теперь во многом приблизился к phpBB3 - отличие в том, что там, в phpBB3, обработка шаблона реализована функциями, и задаётся в виде вызовов функций page_header('%имя_шаблона%'), page_body('%имя_шаблона%') и page_tail('%имя_шаблона%').
Если разгуляюсь, то и это напишу)))

Такая вот загогулина.

Добавлено спустя 14 минут 16 секунд:
Уже сейчас вижу, что довольно громоздко, хоть и хорошо работает.
Надо бы, по-хорошему, переписать на что-то более общее и компактное. То есть, задавать условия как-то иначе, и сделать один вызов парсера.

<?
// Создаём некий массив в переменной $parse_page
$parse_page = array(
	'header'	=> 'header_common',
	'body'	=> '%template_name%',
	'footer'	=> 'footer_common'
	);

if (некое условие - выбор исходя из условий вызова модулем)
{
бла бла
}

foreach ($parse_page as &$gogo)
{
    $template->pparse('$gogo' . $tplEx); // Тут шаблонизатор парсит каждый шаблон в одну страницу
}
unset($gogo);
?>

В итоге, обрабатывать у нас будет только вот этот кусок кода вместо 25 вызовов, как у меня сейчас.
То есть, обрабатывается и так только один из 25-ти, ну край они по двое вызываются, но и это можно изменить.
Надо подумать, однако...

Позанимался немного движком сегодня. Доделал функцию парсинга тела страницы.

Вот такая вот функция:

<? 
function page_body ($tpl_array = array())
{
global $template, $tplEx, $tpl_array, $phpbb_root_path;	// Глобальные переменные, без них не передаются значения
if (!isset($tpl_array))// Проверка: заданы ли шаблоны?
{
message_die(GENERAL_ERROR, 'Not specified templates!');// Сообщение "амба" и закрытие соединения
garbage_collection();
exit_handler();
}
else
{
foreach ($tpl_array as $var => $value)//Цикл "для каждого члена массива"
{
$template->set_filenames(array(
$var => $value	// Задаём соотношение
));

$template->pparse($var);	// Тут шаблонизатор парсит каждый шаблон в одну страницу
}
}
return;// Возврат управления
}

Функция вызывается так:

<?
// Указываем шаблоны в теле файла
$tpl_array = array(
'jumpbox' => 'jumpbox.' . $tplEx,
'body' => 'viewtopic_body.' . $tplEx
);

бла бла бла разный код
бла бла бла разный код
бла бла бла разный код

page_body('jumpbox', 'body');// Передаём шаблоны парсеру
?>

Результат:
(не обращаем внимания на лишнее - это проверка работоспособности, она убирается потом)

Ку всем.
Я пока что перевожу сайт на показанную выше систему.
Добавлено спустя 9 часов 33 минуты 50 секунд:
Пока что не срастается перевести на указанную систему мною же написанный index.php 
Проблема - в модульности: при организации парсинга через функцию ломаются переменные, и модули не получают данные из БД. Объявлял переменные глобальными - не помогает голосовалке и системе отображения через гриды, они (гриды) ломаются.
Оставил пока что костыль: шапка и подвал грузятся функцией, а модули и гриды - через мною же тоже написанный frontpage.php.
Полагаю, надо грузилку модулей писать в виде класса или функции, тогда она будет доступна из любого места кода.
Также переписываю фотоальбом: он слишком блочит картинки - для запрета хотлинкинга выдаёт фотки через Myme Type, а не по имени-отчеству, да и доступ к нему надо местами ограничить.
Для этого он будет переведён на режим работы а-ля админка, с валидатором доступа и фреймами, но картинки будут работать по-другому, через прямые ссылки. Надо будет вообще переписать отображательную часть и грузить их через объявляемое автором (постером) разрешение на хотлинк для каждого фото. Это если смогу...

Записываю мыслю:

Вот что было бы дельно (я на phpBB постараюсь продумать реализацию) - это возможность вместо первопоста выделять несколько постов, а потом при показе объединять их в один якобы, первопост.

Думаю, тут такое:
1) Выделяем галками несколько постов, после их написания, в мод.панели, как первопост. Либо иначе - см. п.3
2) В БД, в таблицу "posts" надо добавить поле 'pointed' - там будет обращение к постам как к добавке к первопосту.
3) Когда псто пишется, в форме ответа (не в быстрой, хотя и так можно) ставим галку "добавка к первопосту" - это приводит к вотыканию единички в поле в п.2
4) При показе топика смотрим, есть ли указание в БД п.2, или нет? Если да - добавляем контент этого поста к контенту первопоста. Если нет - идём дальше.

Сделать такое реально - но из подводных камней у нас сложности в прописыванием обращения к полю п.2 во все обращения к таблице "posts".
Я это с новостями проходил - только с третьей или четвёртой попытки я прописал всё, что надо, а допиливал потом почти полмесяца. Но это я, я не торопился, хотя оно и всё равно сложно.

Так мы обойдём ограничение по объёму контента постов применительно к первопосту. Таким образом, у нас будут формально в БД несколько постов - но видны они будут как один очень большой пост нереально большого объёма.

Возможно, скажете вы, проще будет реализовать добавку сообщения к предыдущему, как оно много где реализовано?
Так вот нет, скажу я вам: там контент следующего поста доливается к контенту предыдущего (если совпадает юзернейм), в одну и ту же ячейку БД, с прибавкой текста (добавлено итд и тп).

Если надо - дарю идею, творите сами

Я на очередном тестовом сайте в Денвере, реализовал так наз. "чистые ссылки".
Вот как оно бывает? Позвонил мне мой начальник, попросил найти кой-какую документацию в интернетах и бросить в него ссылкой, чтоб он скачал себе уже сам.
Я пошёл рыть интернеты и нарыл сайтец маленький, но с большим хранилищем требуемой информации. Так как эта инфа и мне самому нужна - слил сайт целиком себе; в начальника кинул ссылками, и взялся качать.
Покуда вкукоживал его в Денвер, попробовал вкукожить и это дело, взяв код из новостного исходного своего сайта.

И получилось

Прикол - в адресной строке: неким не очень пока что постижимым для меня образом через Symfony, из имён ссылок получается значение для переменных $page и $mode.
Впрочем, краем головы я уже догадываюсь, как именно это сделано

Сделал через подключение Symfony, оно работает отлично.
Но вот чтоб вкукожить в мой движок - мама дорогая, это же ж работы на месяцы
Это же придётся:
а) Добавлять поля в БД - дабы топик ещё при создании получал имя.
б) Обрабатывать это дело - например, создавать имя будущей ссылки на лету при постинге по примеру тех же Вордпресса или там Джумлы.
в) Прописывать код во все места.
г) Делать поддержку управления этим всем через админку - типа ВКЛ/ВЫКЛ в настройках.

Такая вот загогулина - и работает!

ЗЫ Теперь надо на тестовом сайте придумать, как всю папку ./vendor перенести в принятую у меня ./details/
Добавлено спустя 1 час 36 минут 45 секунд:
Перенёс, банально добавив в index.php ./details/ в путь к папке vendors.
Странно, сначала это не работало...

Хе-хе, не срослось полностью мигрировать на Apache 2.4 и php 7.0 - зато я всё равно вкукожил их как параллельный поток!   
Для них были написаны новые "запускалки", запускающие Денвер параллельным путём
А именно:

1) В hex-редакторе подправлены вендовые экзешники-заглушки run.exe, stop.exe и restart.exe, в каждый внесён ключ запуска main24 вместо просто main
2) Добавлен каталог \scripts\init.d24 - на него ссылаются Python-заглушки в каталогах \scripts\start\, \scripts\stop\ и \scripts\restart\
2) Апач 2.4 установлен по адресу \usr\local\apache24
3) php 7.0 установлен в каталог \usr\local\php7
4) В меню запуска и трей-иконку внесены изменения для запуска двух комплектов виндовых экзешников-заглушек - два комплекта, Apache 2.2+php5 и Apache 2.4+php7
5) Можно теперь запускать либо то либо то.
6) Ещё добавлю отдельное включение разных версий Mysql - их есть у меня версий 5.5 и 5.7

Иллюстрации:

Правда, ещё надо крепко новый сервер настраивать - это дело небыстрое, со временем настрою, тем более, что я преимущественно буду на старом серваке обитать.

Такая вот загогулина.
Добавлено спустя 27 минут 25 секунд:
Если будут желающие - распишу подробнее, что и как, в виде некоего мануала.
ЗЗЫ Совсем забыл - файлы других версий взял тут.

Ку всем!

(пост будет обновляться)

Навоевавшись с сервером (я свой самописный сервак вкукожил-таки вместо Денвера!), проверив и настроив работу, правда, только пока что старого Апача, так как он мне нужен, я взялся за сайт.
Кстати, как ни странно, вебсервер стал намного быстрее - чудеса просто...
Он и грузится быстрее, и сайты отдаёт тоже реактивно. Как оно так произошло - пёс его знает.
И это притом, что я починил и подключил померший давно Постгрес.

Победил запрос в БД, который будет мне выдавать выделенные темки (они же у меня и передовицы) за последнюю неделю.
Думаю, надо бы дополнить код приблудой, которая будет постить что-то другое, если выделенных тем нету, то есть, проставлять самые свежие темки как выделенные - однако, при этом, надо бы продумать распределение по разделам...
Либо по одной на раздел, либо просто свежие брать.

И надо писать карусельку, дабы прикинуть - сколько анонсов тем влезет в карусель. Ну, допустим, пять: на оригинальном сайте их четыре в карусели слайдера, одна загружена полностью. Так как дизайн карусели я придумал взять готовый, лишь изменив его внешний вид под свои нужды, в него влезет пять в ряд и одна загружена полностью - итого шесть.
Но это решаемо.

Я вот думаю вот что: надо писать код, который будет при вызове модулей "Новости" или "Передовица" делать такие телодвижения: проверять дату и сносить выделение тем, которые висят на сайте уже больше недели: если тема просто выделена (то есть, topic_type = 1) - убираем выделение, если объявление (то есть, topic_type = 2) - оставляем. Если простая тема (то есть, topic_type = 0) - идём мимо.

Потом надо начинать-таки думать о разделении новостей по сельсоветам  - то есть, организацию и обработку таблицы phpbb_settles и добавки куда надо (например, в phpbb_topics) полей settle_id.

Если организую phpbb_settles - то потом по этому же образцу можно и таблицу phpbb_hashtags (и полями hashtag_id) замутить, вот тебе и хэштеги)))

ЗЫ Иллюстрации забыл.

ЗЗЫ Тестировал запрос тем, что нагадил в БД три целевые темки и заставил сайт выдать их данные.
Получил три поста из выделенных тем. Экономичный, правильный запрос в БД - один удар и три дырки)))
Правда, я ещё не продумывал ограничение - а его надо делать, иначе оно мне всю оперативку загадит, если тем за неделю будет много...

Работает приблуда, надо дальше писать.

Озвучиваю идею.
Если кто-то задумает применить - на здоровье, главное, сошлитесь на автора, то есть, меня
Делаем разметку шаблона страницы гридами, причём не так:

А вот так:

То есть, "квадратиками-шмадратиками". Не обращайте внимания, что левая картинка, пример надо было клепать слишком долго, принцип ясен и так, а именно - разграфить страницу сеткой примерно в 20px.
Таким образом, получаем возможность привязать любой элемент страницы в любое её место, а если применить механизм в админке для задания квадрата, то даже можно делать это из БД динамически.

Как вам мысля?

Не знаю уж, успею ли написать до отъезда, потому и записал сюда.

Сложности такие в этом: задолбаешься задавать сетку, притом желательно применять не пикселы (px), а "фольксвагены" (vw). Остальное дело техники.
Подход с area тоже возможен.

Попутно, новость об оригинальном движке сайта, который до сих пор применяется.
Пока я комаров кормил на северах, в движке покопался его автор, к нему обращались коллеги и таки сумели достучаться (ранее не могли, оттого и меня в принципе позвали).
Слил я обновлённый движок и заметил, что сайт локально у меня на компе грузится архидолго!

Страница грузится тридцать секунд, Карл!

Что он там натворил - пока без понятия.
Меня попросили вкукожить радио-плеер на сайт, в шапку, и я это сделал. Обкатал локально и закинул в сеть на сайт.
Там летает - у меня локально, аццки тупит!
Натурально, у меня процессоры нагружаются до 80% при загрузке!
Вот отчего серваки и умирают...

ЗЫ Другие сайты на локальном сервере - летают, только этот тупит.
Это называется "неэффективный код".