Ну смотрите.

*. Не используются стандарты кодирования. См. PSR, не буду перечислять.
*.1. Сюда же - названия переменных, классов, файлов или не очевидны, или избыточны (systpayment, generalscript, addapplication, dirdownfiles и т.д.).
*.2. Куча опечаток. mainModul, moduls, да много где.
*.3. Логика расположения. Мешанина из файлов. Гляньте папку allinclude, у вас там и js, и php. Рядом. Две папки для конфигов (почему не сделать одну с иерархией?). Есть папка images, есть папка templates (почему не все в одной? назовите assets). Внутри templates все вперемешку: css, html, php,
*.4. Куча неиспользуемых переменных в методах, тот же phpStorm их прекрасно подсвечивает.
*.5. Туча констант для такого объема кода.
*.6. В коде куча мест со вставками вёрстки внутрь строк. Сегодня даже Wordpress старается уходить от этого подхода.
*.7. Ядрёная смесь транслита и переводных частей. Пример:



>. js без стандартов (учите хотя бы es15), без сборщиков (ну ладно, не всегда они нужны, но в вашем случае - нужны), без модульности (я имею ввиду модульность js по современным стандартам, а не вашу реализацию на кусках кода). Дальше не смотрел.
>. php: используется язык версии 5.6 (* согласно анализу phpStorm`ом, все совпадения выдуманы). На дворе 2021, 8я версия крутится в продакшне.
>. css/js - нет сборщиков, а значит - нет полифиллов, нет анализа, нет ничего.

#. Шаблоны проектирования: ни стандартного MVC, ни event-system, ничего более-менее стандартного. Может, что-то там и есть (я не весь проект просмотрел), покажите, где. Вместо нормального использования хоть какого-то паттерна доступа к данным везде все тычется в глобальные переменные. SOLID принципов даже отдаленно не видно.
#.1. Жесткий процедурный код. Классы вроде как есть, но внутри они - процедурные, то есть вы просто берете и пишете логику сверху вниз внутри методов классов.
#.2. Про классы и ООП: нет ни абстракций, не определена видимость методов. Между собой классы не взаимодействуют или почти не взаимодействуют (покажите, где). Естественно, нет типизации. Не используются пространства имён.
#.4. Толпа комментариев по делу и без. Простое правило: если вам требуется больше 2-3 строк комментария для метода, его, скорее всего, следует разбить на несколько. См. script/class_base_user_part.php, стр. 626 как пример.
#.5. Нет нормальной ORM, запросы фигачатся как в 2004.
#.6. Отладка оставлена в комментах, просто поищите строку "//var_dump" по коду
#.7. Про тесты - молчу.
#.7. Поговорим-таки за безопасность. Тут используются сырые данные из $_POST и $_GET. В том числе, в запросах к БД. Это всё, что следует знать о безопасности. Не вижу смысла перечислять возможные варианты атаки, они ВСЕ возможны.

В общем, все, что я вижу - нестандартный велосипед неопытного разработчика. Я не претендую на то, что всегда пишу чистый код, как и не призываю упарываться в абстракции. Нет.
Я за то, чтобы код решал вопрос пользователя, и при этом был читаем и понимаем моими коллегами.
Здесь я вижу кучу кода, который потенциально очень слаб в поддержке и развитии, морально устарел до момента его написания, не структурирован, не безопасен.
С точки зрения разработчика, написание такого велосипеда - большой прогресс в изучении языка и понимании, в целом, как оно работает. Это хорошо для автора, но на этом нельзя останавливаться, т.к. в образовании существуют огромные дыры, которые нужно срочно закрывать.
С точки зрения потребителя, получая (даже бесплатно) сайт на этой системе, он приобретает большие проблемы для своего бизнеса.

Надеюсь, никого не обидел. Консультации и прочее, увы, платные.

Сообщение отредактировал Nell - 7.10.2021, 18:12

но к сожалению же это касается и многих популярных движков
тот же битрикс - его нельзя назвать беспроблемным, например

Спасибо, что покапались в моем коде, и написали замечания.
1. Как раз все очевидно, каждый каталог сделан не просто так, а есть свое назначение (есть логика в этом). К примеру, systpayment содержат файлы для платежных система, многие ПС системы требуют отдельные файлы, иначе никак. generalscript содержать общие функции, которые могут быть использованы в любом месте кода.
2. CMS-ку эту я начал разрабатывать больше 10 лет назад, тогда знаний у меня было немного, оставлено это все для совместимости с старыми сайтами.
3. Опять все логично. К примеру, в папке allinclue находятся файлы, которые либо подключаются к сайту в коде (к примеру, <script src='../allinclude/..'><script>), либо через ajax передаются данные или отдаются сайту. Папка /images в корне сайта содержит изображения независящие от шаблона сайта, к примеру, изображения для водяного знака для фотографий товара, и т.п. Какие проблемы что "Внутри templates все вперемешку: css, html, php"? Все эти файлы относятся к данному шаблону, функции, которые находятся в php файлах используются исключительно в шаблоне.
4. Не совсем так. Это универсальная CMS, на ней я сделал скрипт интернет-магазина, скрипт доски объявлений, и свой сайт www.boxcode.ru. Более сложный функционал у скрипта доски объявлений. Все переменные нужны, но могут не использоваться в конкретном скрипте. А какой-либо нагрузки или сложностей они не создают.
5. Константы я использую для настроек сайта. Исторически так сложилось, переделать такой объем кода очень сложно и обновить существующие сайты особенно.
6. Не совсем понял. Весь дизайн пользовательской части формируется в шаблоне.
7. Уже писал, исторически так сложилось. Но проблем тут не вижу.




Не понимаю, зачем мне сборщики файлов js и css? Значительная часть js-файлов и css файлов у меня собираются в один файл (в смысле один js и отдельно css), а не каждый по отдельности подключается к сайту. Только не сжимается код. Над использование SCSS я думал, но будет очень большой объем работы.
CMS давно сделал, чтобы работала на php 7.3. Недавно подкорректировал, и проверил на локалке - на php 8.1 работает. Только скрипт интернет-магазина, но скрипт доски объявлений не проверял (нет времени), она более сложнее. Но думаю, что будет спокойно работать на php 8.1 - читал я изменения, сделанные в php 8.


1. Не совсем понял, про что вы пишите. Классы не просто есть, движок построен на классах, главный модуль и дополнительные модули - все это классы. И добавлю - там где надо, использую классы, там где не надо - функции. Проблем тут не вижу.
2. Абстракции не интересны, если посчитаю, что нужны - буду использовать. Модули взаимодействуют еще как. Типизацию мне лень использовать. Пространство имен зачем мне?
4. Комментариев как раз не так много. То что вы привели в пример - вообще не понятно, это описание данных массива (который используется в меню, то есть структура данных), без этого комментария даже я не вспомню, как нужно формировать данный массив.
5. Не считаю пока что необходимым использовать ORM.
6. В чем тут проблема? Специально оставляю.
7. Не разобрались с этим вопросом. Все данные проверяются и даже класс есть специальный для этого. Это все проверено годами.


Не обижайтесь, но вы не разобрались с моей CMS. Но это не удивительно - наскоком ее не понять. Я много времени разрабатываю свою CMS, и у меня хорошая обратная связь с клиентами. У меня даже форум, основные разделы которого доступны только клиентам (форум я уже закрыл, так как сейчас есть другие популярные способы связи - соц. сети). В общем-то моя CMS - это не открытое ПО, я написал ее для себя, в том числе дорабатывать ее за оплату. Но получилось так, что сразу клиенты решили ее дорабатывать самостоятельно и я помогал им в этом, даже форум сам написал для этого . Многие пользователи самостоятельно дорабатывали функционал, а дизайн даже делали полностью свой - то есть шаблон переделывали полностью под свои требования.
Некоторые вещи в моей CMS довольно просто доработать, главное понять принцип ее работы. Те кто понимал - нормально так дорабатывали мою CMS-ку .
Подытожу на счет безопасности - безопасность CMS-ки проверена годами. Клиентов взламывали подбором и воровством паролей, но к самой CMS-ке это не имеет значение (добавлю, что у меня не раз пытались тем или иным способом украсть пароли, подробности раскрывать не буду).

А в общем, спасибо вам, за потраченное время (я ответ писал очень долго ), некоторые вещи написанные вами обязательно приму во внимание.

Rybakin, я негативно отношусь к битриксу,но...
У него есть комьюнити и кучу разрабов.

Конечно, каждый велосипед по-своему уникален. У меня не было задачи вникнуть во все ваши идеи и просмотреть все 100500 файлов, которые там есть. Я изначально написал, что архитектуры нет.
Вы это подтвердили:

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



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


Может потому, что вы не реализуете паттерны для подобных случаев? Из применимых примитивов можете посмотреть DTO && Builder.


Процедурный код можно доработать, кто же спорит? Вот только это не говорит о его удобстве.


Я про то, что используются возможности языка, соответствующие версии 5.6. Вы пишете заранее устаревший код.


Я думал, что программистам, написавшим свои собственные системы, не надо объяснять актуальность билдеров, минификаторов, препроцессоров и полифиллов.
Ну и legacy-код - не повод для гордости. Это ж не ваш личный пет-проект, вы его продаёте.


Я вам "за архитектуру", вы мне - "за проблемы". Это неконструктивно.
И все же: почему вместо придумывания своего велосипеда нельзя взять готовые паттерны, хотя бы базовый MVC, и реализовать его (я ж не призываю к оверхэду типа DDD)? Неужели самому нравится копаться в тонне процедурки без поддержки IDE? Или просто не с чем сравнить?

Сообщение отредактировал Nell - 8.10.2021, 22:58

Nell, сейчас у меня нет времени на все отвечать. Только одно напишу.


Напишите, уж ради принципа, хоть одну "дыру", может быть вы правы, а я не вкурсе .

xweb, если Вы так уверены в безопасности своей CMS, то оплатите проверку на уязвимости товарищу Nell с оплатой за найденные "дыры". Я думаю он согласиться.

EvilGomel, за что я должен заплатить Nell? За то, чтобы он убедился, что "дыр" нет? Пока что, его слова ничем не подтверждены и для подтверждения своих слов пусть надет хотя бы одну "дыру".

Без обид, но я достаточно проблем расписал вам в стартпосте. Бесплатно. И сейчас ввязываться в тред "а белое не черное" я не хочу.
Из того, что я помню, у вас ни в одной форме нет CSRF защиты, следственно, атака на любую из форм может привести к выполнению этого сценария. Устроит? Или вам надо, чтобы я, условно, достал с вашего сайта БД? Если да, давайте сначала заключим договор на аудит безопасности с отказом от претензий и соответствующим ценником, затем получите список проблем.
P.S. Я тут свои услуги не предлагаю, и предложение выше - гипотетический сценарий. Опять же, я начал про архитектуру. Давайте ее обсуждать.

Сообщение отредактировал Nell - 9.10.2021, 19:52

А каким?
Может форумчанами скинутся ради такого интересного челенджа )