Рерайтинг движка | GitHub

3 Авг 2022
Доброго времени суток. Набрёл на движок с интернета. Подобные системы - не моя специальность, но я всегда рад помочь в улучшении, если то возможно. Сам занимаюсь Java/C#, но в свободное время балуюсь подобными вещами, поэтому решил подсобить/ускорить его преображение.
Вчера просмотрел движок, чуток очумел от количества мусора, но не всё потеряно. Как я понял, пользуются системой исключительно те, кто любит максимально простой и понятный вид кода без "всяких ваши ООП и т.п.". И хоть двиг подутратил свою востребованность, но, как я увидел, есть ещё много ньюфагов, которые пользуются и, надеюсь, учатся на этой системе.
Мне не помешает человек (или несколько человекОВ), которые давно пользуются этим движком и которые уверенно ориентируются в коде, дабы, при возникновении у меня вопросов, я мог кому-то написать.
На своём старом аккаунте GitHub создал репозиторий для движка. За основу взял версию DS-Special из-за введённой мультиязычности.
ФУЛЛ переписи не планируется, дабы, если у кого-то будет желание, переход на обновлёнку не был тяжёлым. Привычная архитектура, думаю, будет сохранена. Обновления затронут стилизацию кода и удаление излишнего мусора.
Для примера в одном только /sys/inc/user.php было ~27 лишних запросов в базу данных.
От mysql мы уйдём в сторону PDO (простота и, прежде всего, безопасность). Уже имеется обёртка, которая позволит легко и просто осуществлять запросы в базу. "Документация" по ним будет так же на GitHub.
Здесь в теме буду кратко писать ChangeLog'и по изменениям в коде. По мере переписи файлы будут загружаться на git.
Ссылка на репозиторий: GitHub - Dcms-Social

Последний раз редактировалось biket 1 Сент 2022

Комментарии:

MarkPrior 7 Авг 2022
Автор темы
ChangeLog 07.08 21:40
Сегодня по большей мере изменения коснулись лишь фронта, чтобы было приятно хотя бы самому себе сидеть работать над этим. smile

Полностью рабочие светлые и тёмная темы. Переход между ними для пользователя: ?design=dark/light. Информация хранится в поле user[set_them].
На скриншотах примеры:
Скрин 1
Скрин 2
Скрин 3
Скрин 4
Скрин 5
Скрин 6
Скрин 7
Скрин 8
Скрин 9 (немного съехали иконки сбоку, забыл класс обновить)
Скрин 10
Завтра-послезавтра форум уже будет полностью переделан. Таблица особо не трогается, стараюсь по крайней мере. При переходе на двиг данные утеряны не будут + будет обеспечен скрипт, который за вас перетащит и поставит данные из старой таблицы в новую.

MarkPrior 7 Авг 2022
Автор темы
ChangeLog 07.08 16:40
* гостевая дописана, работает хорошо.
* /forum/:
=> на данный момент можно создавать подфорумы и темы в простом варианте.
=> количество подфорумов пока что безлимитное:
==> таблица forum_r на данный момент невостребована, все форумы хранятся в forum_f (возможно, изменится).
==> это позволяет в подфорумах создавать новые подфорумы и темы одновременно.
=> создание форума/подфорума/темы обрабатываются в едином месте: create=<объект>[&forum_id=<id>].
создание форума: ?create=main.forum
создание подфорума: ?create=sub.forum&forum_id=id
создание темы: ?create=thread&forum_id=id
ссылка на подфорум: ?forum_id=id
Внешний вид форума на данный момент:
Скрин 1 - главная
Скрин 2 - подфорум
Скрин 3 - подфорум подфорума
(ToDo) после доработки форума можно оформлять главную страницу.
(!) файлы форума пока что выгружаться не будут до доработки вывода тем в подфорумах.

Kokosik 7 Авг 2022

MarkPrior (7 Авг 2022):
Kokosik, смысл в возможности перехода, даже если архитектура той же БД значительно изменится. По завершению будет писаться скрипт, который всё аккуратно припаркует в изменённой БД. Смысла писать с нуля нет никакого, основной кор по сути будет таким же. Цель - в чистке и структурированности архитектуры двига с сохранением простоты использования для любого ньюфага.
Уже сейчас тот же /sys/inc/user.php сокращён более, чем в 2 раза. Хлам уходит.
Ну и всё-таки я не тот, кто будет что-то с нуля делать без оплаты. smile

MarkPrior, но по факту твоя работа будет куда сложнее чем начать с ноля, в любом случаи молодец и желаю тебе успехов.

MarkPrior 7 Авг 2022
Автор темы
Kokosik, смысл в возможности перехода, даже если архитектура той же БД значительно изменится. По завершению будет писаться скрипт, который всё аккуратно припаркует в изменённой БД. Смысла писать с нуля нет никакого, основной кор по сути будет таким же. Цель - в чистке и структурированности архитектуры двига с сохранением простоты использования для любого ньюфага.
Уже сейчас тот же /sys/inc/user.php сокращён более, чем в 2 раза. Хлам уходит.
Ну и всё-таки я не тот, кто будет что-то с нуля делать без оплаты. smile

Kokosik 7 Авг 2022
Автор молодец, но смысл в чем? Так выходит что это новый движок но с хламом старого.. может стоит сделать просто новый двиг? По функционалу похожий и привычный но полностью заного

MarkPrior 7 Авг 2022
Автор темы
Пояснение
Почему нет полноценного перехода на ООП?
Потому что в этом нет никакого смысла. Есть DCMS 7.5, у которого есть замечательный форк, не уступающий по оформлению и наполнению модулями данному движку.
Разница между этими системами - dcms 7.5 будет куда сложнее в понимании обычному обывателю.
Мой же вариант предполагает возможность самостоятельно, не копаясь в классах, редактировать код "на месте". Для пущего удобства в каждом разделе всё будет разделено на псевдо виджеты, представляющие собой просто куски конкретного участка кода, что позволит быстрее найти нужное место для изменения.
Надо отредачить форму гостевой? Зашёл в /guest/index.php, увидел инклуд формы - пошёл в /sys/widgets/guest/form.php - отредачил. Быстро и комфортно для обычного человека.
"Ультра" оптимизации не требуется, PHP 7 и так почти в 3 раза быстрее PHP 5.x, что уж говорить о PDO по сравнению с обычным MySQL.
Главная проблема этого движка - чрезмерная захламлённость лишним кодом и лишними запросами в БД, что, собственно, постепенно меняется.
Заметка
Пока оформление сырое - выгружаться на git оно не будет.

MarkPrior 7 Авг 2022
Автор темы
ChangeLog 06.08 23:40 0.2
===> user::metadata('get', 'name', 'string') - получить строку, если был сохранён массив
===> user::metadata('get', 'name', 'array') - получить массив, если была сохранена строка вида one|two|three
===> user::metadata(<N>, 'name', ['value']) - получить значение по индексу N или, если указано value с плейсхолдером %s, строку, в которой плейс будет заменён значением (будет удалено)
===> user::metadata('remove', 'name') - удалить инфу.
Так реализовано, потому что подавляющее большинство не умеет устанавливать такие кешеры, как, к примеру, APC(u). Пользуем, что имеем.