Через несколько месяцев общественности будет представлен гибрид PHP-фреймворка и CMS. По заявлениям разработчиков, фреймворк возьмёт лучшее из философии Symfony и часть её открытых компонентов, при этом устранит недостатки и сложности, с которыми новички сталкиваются при использовании данного фреймворка. Также система позволит создавать простые блоги и магазины в технике zero code, то есть не открывая исходный код и не нанимая разработчиков.
Здесь нужно сделать небольшую паузу, и отметить, что пока единственный разработчик данного проекта - это я. И совсем не факт, что на выходе получится что-то удобное или даже просто вменяемое. Тем не менее, данный челлендж показался мне интересным, и поэтому - почему нет :)
То есть заголовок статьи - отчасти шутка, отчасти декларируемая цель, но не стоит воспринимать его всерьёз.
Вообще историю надо начать с того, что я за последние полгода 3-4 раза помогал знакомому с проектами на Wordpress. Сам я с 2019 года работаю с Symfony, и в общем и целом застал все версии начиная с 2.x, но особенно долго работал с версией 5. Да, сейчас уже вышла седьмая, но основные концепции не сильно изменились.
И работая с сайтами на Wordpress, я буквально успел поседеть от стресса. Вот что меня раздражало больше всего:
Неочевидная система срабатывания хуков. Как понять, в какой очерёдности они будут обработаны?
Сам Wordpress во многом сделан в функциональном стиле. Я раньше в юности сам был адептом такого подхода, но он крайне плохо подходит для больших и сложных систем
Почему-то многие сайты тормозят просто кошмарно, при этом число плагинов в целом выглядит в рамках разумного
Сложности при отладке в PHPStorm (иногда точки остановки не срабатывают, впрочем, тут скорее всего виноваты мои кривые руки - однако на Symfony таких сложностей ещё никогда не было). Причём порой эти сложности фатальны: включим отладку через расширение браузера и откроем главную страницу админки - и вот мы получаем бесконечное зависание загрузки, приходится отключать отладку и повторять всё по новой, а то и делать рестарт вебсервера.
Безобразная система хранения данных. Серьёзно, хранить почти всё в таблицах posts и posts_meta - гениальное решение, вот только для разработчика искать что-либо становится целым квестом, а сами таблицы по вертикали разрастаются до просто чудовищных размеров. Кроме того, данные от разных плагинов сильно фрагментированы, в итоге если получить список, условно, всех способов оплаты для платёжного шлюза - id будут отличаться на огромные величины, если эти способы добавлялись не в один заход, а в течение, например, года. Кроме того, иногда из-за повисших запросов или багов в сторонних плагинах возникают "осиротевшие" строки, которые практически невозможно удалить программным способом, написав сценарий. Сам Wordpress тоже такие чистки делать, вроде как, не умеет.
Сложная процедура добавления кастомных полей - для этого есть ряд плагинов, но в БД это хранится всё так же ужасно, и если всё-таки придётся писать код (а это в 90% случаев так), то придётся писать его с учётом того, какой плагин использовался, т.к. подходы там везде немного отличаются.
Не очевидное для новичков понятие таксономий - сущностей, которые существуют только лишь в коде, но не в БД
Необходимость написать достаточное количество не самого очевидного кода чтобы реализовать AJAX подгрузку элементов в каталоге. Придётся по новой реализовывать сортировку и фильтры, а также убедиться, что сортировка точно совпадает с сортировкой первой страницы, если она грузится не через AJAX.
Из коробки нет никакой ORM, при написании плагинов приходится тащить или писать свою.
Онлайн обновление плагинов в административной панели почему-то часто происходит неоправданно долго.
Теперь о том, какие сложности (болевые точки) возникали у меня при работе с Symfony:
На достаточно больших проектах крайне долго очищается кэш (40-90 секунд). Очистка его просто необходима, если мы находимся в prod окружении и отредактировали шаблон. dev окружение на проектах такого размера тоже изрядно тормозит, причём речь не идёт про ноутбуки с условными Core 2 Duo или железом ещё хуже, тормоза были на топовом iMac 2019 года кастомной конфигурации с 32 Гб RAM и Core i7 9700H на борту.
Из-за бага в xdebug, который разработчики соизволили исправить только в апреле 2024 года, при отладке любой, даже самый мощный процессор постоянно уходил в 100% нагрузку по одному ядру, что приводило на слабых системах к тормозам, а на системах с недостаточным охлаждением вроде ноутбуков и iMac - к ужасному шуму. Причём этот момент не проявлялся на простых страничках, сделанных без фреймворка.
При плохо спроектированной архитектуре Doctrine работает с БД недостаточно быстро.
Например, на моей предпоследней работе на главной странице кабинета клиенту выводилась финансовая сводка по всем его проектам. Код вычислял достаточно простые формулы, но применял эти формулы к большому числу строк. Для крупных клиентов это число легко доходило до 1 миллиона или даже переваливало за него. Как итог - дашборд прогружался 60 секунд, затем PHP завершал скрипт по лимиту времени, но что ещё хуже, 3-4 таких запроса параллельно выжирали всю RAM и сервер банально падал для всех.
У владельцев бизнеса были варианты решения:
Докупить оперативной памяти. Этого делать не стали, т.к. дорого и не особо помогло бы.
Реализовать кэширование на уровне отдельных бизнес-сущностей (одна сущность имеет примерно 10-500 строк/позиций, всё зависит от клиента и его потребностей) или даже ещё мельче - на уровне групп позиций внутри сущности (что они и сделали через Redis, но потом отключили его, потому что он моментально выжирал всю память и всё точно так же падало).
Реализовать просчёт агрегированных формул на чистом SQL - длинно, громоздко, тяжело поддерживать... Но внезапно при тесте, когда я ради эксперимента это сделал, оказалось, что даже для крупных клиентов статистика считается за 0.2-0.5 секунды (правда, я успел перенести только 3 расчётных формулы из нужных 6 или 8, остальное делать не стал, потому что начальство сказало, что через SQL оно делать точно не будет, т.к. не доверяет корректности результатов, а это финансы, поэтому риски слишком велики).
Кэшировать как-то ещё и писать свой велосипед - решили, что долго, дорого и результат ненадёжен. В итоге команду распустили до того, как кто-либо даже попытался сделать такое решение.
Вывод такой: сами расчёты тривиальны, и тормоза явно не из-за них, а во-первых из-за IO (передача большого объёма данных между СУБД и PHP), а во-вторых из-за того, как именно Doctrine работает с сущностями в памяти (для крупных клиентов страница дашборда кабинета очень часто падала по памяти ещё до того, как истекал лимит времени, при этом лимит стоял то ли 2, то ли 3, то ли 4 гигабайта). Если же посчитать вес "чистых данных" позиций, как если бы они хранились в CSV, там явно минимум на 2 порядка меньше.
Это ещё раз подводит к мысли о том, что Doctrine в таких юзкейсах не просто неэффективна, но даже опасна.
У меня были сложности с открытием доступа к отдельным URL внутри пути. Например, на сайте есть веб-версия и API для мобильных приложений, доступное по пути
/api. Так вот, открыть доступ без OAuth токена к отдельному пути внутри/apiу меня не получилось, хотя я потратил на это несколько часов и перерыл весь гугл. А при попытке перенести авторизацию пользователей на новый механизм в соответствии с рекомендациями версий Symfony 5.3 и 5.4 - я вообще пару раз получал ситуацию, когда либо всё доступно без кук вообще, то есть весь сайт открыт, либо наоборот, ничего не доступно, включая главную страницу для гостей и непосредственно форму входа. Но возможно, это опять же мои кривые руки, и стоило обратиться к конфигу Symfony актуальной версии, скачанной с сайта в чистом виде, чтобы посмотреть, как сделано там.
При разработке своей системы я учёл все эти нюансы и стараюсь сделать так, чтобы никто о них больше не спотыкался, включая неопытных новичков.
Система будет уметь:
Поддержку минимум двух движков шаблонов - собственного и Twig. Шаблоны кэшируются после компиляции и остаются в кэше либо до истечения времени жизни, указанного администратором в конфиге, либо до первого изменения исходного шаблона (движок сравнивает время модификации файлов)
Встроенную облегчённую ORM, любезно предоставленную мне товарищем
Три метода авторизации прямо из коробки: Сookie ssid, OAuth2 token, JWT token. Любой из методов можно полностью отключить в PHP конфиге или в админке, и также интуитивно можно менять порядок обработки путём перетаскивания блоков опций
-
Встроенные Entity и простые сервисы для 4 юзкейсов: блог, интернет-магазин, форум и служба технической поддержки. При этом пользователь сможет легко редактировать код встроенных Entity и сервисов, наследоваться от них и добавлять полностью свои. ORM будет доработана так, что автоматически подхватит все вновь добавленные Entity-классы и создаст для них таблицы в БД, а также отследит по специальной команде изменения наборов полей в уже существующих классах и обновит структуру таблиц, добавив или удалив столбцы.
Для некоторых типов проектов данное решение подойдёт плохо или не подойдёт совсем (например, сайт условного небольшого музея, который продаёт билеты в этот музей, то есть в каталоге есть всего один товар, но правила расчёта цен могут быть достаточно нетривиальны). В этих случаях Wordpress вместе с написанием собственного кода (если аккуратно реализовать хранение заказов и скидок в отдельных таблицах), возможно, сможет проще решить задачу.
Редактор всех элементов внутри админ панели
Три роли (Администратор, Редактор и Пользователь), а также детальные ACL правила, определяющие, что может делать каждый из пользователей, а что не может, при этом главный администратор сможет максимально точно настраивать права на уровне категорий объектов, отдельных объектов и действий над ними для каждого отдельного юзера
Что использовано из сторонних компонентов:
Symfony HTTP Foundation - без него никуда
Twig будет добавлен на более поздней стадии
Monolog для ведения привычных логов и для возможностей более тонкой настройки логирования
Firebase PHP-JWT для генерации и верификации JWT токенов
PHPMailer для отправки почты
Что я тащить не стал:
Doctrine, поскольку для простых проектов это оверкилл, и в связи с потенциальными проблемами с быстродействием, описанными выше
Dependency Injection и Autoworing не стал тащить или делать самостоятельно ровно по той же причине
Symfony Cache, поскольку пока не пригодился, а если что, пользователь сможет добавить его сам
Symfony Security, поскольку сам реализую упрощённый аналог
На сегодняшний день работает всё, что не связано с CMS (просмотром и редактированием бизнес сущностей). Нет никаких шаблонов для фронта, нет никакой админки.
Но это та основа, на которой дальше можно работать и наращивать функционал. Хочу услышать ваши мнения и предложения.
Комментарии (49)
MisterClever
17.12.2024 05:11Как-то раз собрались программисты, и поняли, что в мире существует 6 языков программирования. Решили они написать идеальный, седьмой язык, который возьмет все сильные стороны предшественников. Работа кипела 6 долгих лет, и в результате появился идеальный, вылизанный, сверхточный и понятный новый язык программирования
А на следующий день в мире было уже 7 языков программирования
kompilainenn2
17.12.2024 05:11это было в 80-х годах прошлого века, с тех пор количество ЯП и шутеек про них значительно увеличилось
gruzoveek
17.12.2024 05:11Вордпресс маздай. Хуже него наверное только битрикс. Выбор CMS вообще тема такая, что неизбежно чем то жертвуешь, что-то получаешь. Если есть выбор, то лучше начинать новый проект с чего-то более оптимального.
Dadadam999
17.12.2024 05:11Ну не знаю. В последнее время вордпресс больше воспринимаю скорее, как библиотеку, а не cms. Во многом вордпресс и ему подобные cms "зеркало" программиста. Много раз видел, как разработки писали явно плохой код, но все свои косяки списывали на вордпресс.
Мне наоборот не нравятся cms, которые сильно ограничивают разработчика в функционале, взамен на отлаженную работу предусмотренного функционала.
gruzoveek
17.12.2024 05:11Тоже верно. Грамотный разработчик способен построить нормальную систему и на вордпрессе, и на битриксе, и хоть на чем, а если надо то и свое решение написать. Понятно что инструмент сам по себе нейтрален, к нему нужны прямые руки.
Другое дело что когда разработчиков за короткое время сменяется несколько, и между ними нет согласия, то такая "вольная" система быстрее превращается в запутанную свалку кода. И вообще изначально заточенная под написание статей, CMS-ка теперь для чего только не используется, что не добавляет ей стройности.
MetaDone
17.12.2024 05:11А чем вас не устраивают cms на основе, допустим, ларавел? их наплодили вполне достаточное количество для задач что вы описываете:
и еще большая куча других
popov654 Автор
17.12.2024 05:11Спасибо, посмотрел. Первая основана на Laravel, а я его знаю слишком поверхностно, чтобы пытаться как-то оценить её. Но верю, что вполне достойный продукт. Вторая выглядит ещё круче - это прямо какой-то гибрид Tilda и Figma, в общем, конструктор сайтов вообще без написания HTML, как я понял. Здорово, но я не собирался у себя такое реализовывать :)
Мне интересно сделать именно что-то в духе Symfony, но легче - как минимум это хороший опыт. Как максимум - может быть даже окажется юзабельным.
Ozzarius
17.12.2024 05:11А для чего плодить новый Фреймворк? Какие цели вы преследуете? Как он впишется в, функционал уже готовых более простых решений? Вы не сделали ничего нового, грубо "перетасовали карты в колоде", поясню - сама по себе CMS WordPress очень неплоха и если ставить ненужные модули и пытаться построить завод на ней она прекрасно выполняет свои функции, причем очень хорошо. Тут нужно учитывать скорость работы самого php.
Что кардинально решает в данном контексте конкретно ваша реализация, что она удобнее уже проверенного инструмента?
popov654 Автор
17.12.2024 05:11Тут нужно учитывать скорость работы самого php
При чём здесь скорость работы PHP? Вы вообще не понимаете, о чём говорите. Сделайте хоть сами замеры производительности, хоть поищите готовые. PHP не тормозит (если не брать экстремальные случаи вроде перекомпиляции тонны шаблонов на Twig), к нему вопросов нет никаких.
Что кардинально решает в данном контексте конкретно ваша реализация, что она удобнее уже проверенного инструмента?
Проверенного - это, извините, какого? Если речь про Symfony, то я опять же не собирался с ней конкурировать.
FanatPHP
17.12.2024 05:11Статья напоминает новости, которые публикует вторая древнейшая служба Хабра, "В 2035 году в РФ будет выпущено 100500 мильёнов электромобилей, вот даже эскиз нарисовали в фотошопе, то есть 99% работа закончена".
popov654 Автор
17.12.2024 05:11Вполне понимаю, как это выглядит, но я бы не стал писать данную статью, не будь готово 75-80% движка. Так что не совсем так :)
Ссылку на гитхаб не стал выкладывать просто потому, что код ещё недостаточно причёсан, и местами выглядит коряво. Я добавлю её в течение недели в комментарии или прямо в тексте статьи.
lifestyle
17.12.2024 05:11Не задумывались почему Wordpress популярен, и пока ещё ни один велосипед на Symfony, Laravel, Vanilla, etc. не смог превзойти его успех?
Это прежде простота установки, выверенный годами UX/UI, огромное международное комьюнити, куча фич "из коробки", темы, плагины для всего и вся, ...
Это всё-равно, что заявлять об очередном "убивце" Windows, предлагая очередной дистр. Linux.popov654 Автор
17.12.2024 05:11Куча фич из коробки будет и здесь. Да и установка будет ещё проще, чем на Wordpress, по крайней мере точно не сложнее.
Например, сайты на Wordpress хранят имя сайта в одной из таблиц, поэтому если просто накатить дамп базы данных, а не использовать бэкап через специальный плагин, то при развёртывании на локальной машине мы получаем не рабочий сайт, и надо лезть руками в БД. У меня же вообще опции будут храниться в одном файле, БД тут не задействована, там только юзеры и сессии хранятся.Касаемо тем: здесь их будет делать едва ли не проще, это ведь будут просто наборы Twig шаблонов и CSS файлов.
lifestyle
17.12.2024 05:11Вы рассматриваете CMS только с точки зрения разработчика, но нужно рассматривать и ещё и с точки зрения бизнеса, конечных пользователей - они в кончечном итоге определяют успех.
Есть множество CMS с гораздо лучшей архитектурой, качеством кода, современным стеком, но эти проекты часто забрасывают, потому что не находят поддержки.
Если бы мне был нужен проект на CMS, я бы вообще смотрел в сторону Headless CMS.
Но бизнес выбирает как раз то, что более популярно, зарекомендовало себя.
Кто будет поддерживать проекты на вашей CMS?
Разработчиков на WP целая армия, это целая ниша/категория, можно найти разного уровня и на разный бюджет.popov654 Автор
17.12.2024 05:11Так в этом и цель - сломать эту систему. Например, предоставив более красивый/надёжный API, сделав свой движок менее требовательным к железу. Сделав более удобный интерфейс в админке, опять же. Тут я уже смотрю как пользователь, WordPress мне и здесь совершенно не нравится. Joomla приятнее
MaksimMukharev
17.12.2024 05:11Joomla приятнее?
popov654 Автор
17.12.2024 05:11Безусловно, хотя бы из-за ООП. Ну и из-за того, как там плагины организованы, я смотрел простые примеры в учебнике ещё в 2012-2013, хоть и не писал их сам под эту CMS. Всё очень даже неплохо смотрится.
sergeytolkachyov
17.12.2024 05:11На хабре гляньте статьи последних пары лет в хабе Joomla. Посты тоже. Там описания создания разных типов плагинов по новой архитектуре есть, модулей и т.д.
init0
17.12.2024 05:11Красивый API? Серьезно?
sergeytolkachyov
17.12.2024 05:11Начиная с Joomla 4 под капот влит Joomla Framework - полноценный PHP фрейм, пусть и не столь навороченный, как другие его собратья. И плюс не надо искать и прикручивать отдельную админку к нему. Сейчас уже Joomla 5, через год шестерка выйдет. В джумле апи стало гораздо лучше, чем было 12-15 лет назад.
Kononvaler
17.12.2024 05:11Ну на воцап в России большинство сидит, хотя в сравнении практически с любым дерьмо откровенное. Популярность не критерий хорошести.
hokoo
17.12.2024 05:11Есть страны, где до сих пор Вайбер наиболее используемый мессенджер
Kononvaler
17.12.2024 05:11Есть, но не понял к чему. Я про огромное международное комьюнити у вордпресса, отчасти отчего он так популярен. Но это не значит что он лучший.
hokoo
17.12.2024 05:11Я к тому, что у Вайбера нет ни коммьюнити, ни продуманного UI.
У WP есть и то, и другое, что является залогом его попрулярности еще на годы вперед.
Nelman86
17.12.2024 05:11Нет никаких шаблонов для фронта, нет никакой админки.
Уж извините, но это никакая не CMS, а очередной фреймворк основанный из винегрета пакетов. У этой т.н. CMS даже названия нет.
Прежде чем изобретать велосипед, стоит посмотреть по сторонам: вокруг куча готовых фреймворков и CMS.
Также кроме текста об той т.н. CMS, хотелось бы ссылку не репозиторий, где можно было бы взглянуть на код.
popov654 Автор
17.12.2024 05:11Это только пока. В дальнейшем я планирую подключить к разработке больше людей (благо, есть человек, готовый найти разработчиков и их замотивировать). И CMS на основе этого фреймворка обязательно будет.
Название уже выбираю, это не так-то просто сделать...
werwolflg
17.12.2024 05:11>Почему-то многие сайты тормозят просто кошмарно, при этом число плагинов в целом выглядит в рамках разумного
Так по логам там сразу видно из-за чего тормоза, как правило из-за кривых шаблонов, которые делают много запросов к БД, плюс запросы к внешним ресурсам.
А вообще убийцы вордпресса каждый год выходят, и где они и где ВордПресс. Как и смерть пхп каждый год пророчат.
Rax12
17.12.2024 05:11Так ещё и кэширование можно (и нужно) включить. Там вообще нечему будет нагружать железо. Не один год юзаю wp для сайтов. И даже самые дешёвые тарифы и хостингов, тянут все на ура. С огромным запасом.
ilshatkin
17.12.2024 05:11Мы тоже с компаньоном сделали своё цмс. Получилось отлично. Главное сайты делать на ней нравится
Тут есть описание https://getwebspace.org/
popov654 Автор
17.12.2024 05:11Здорово, вы молодцы :)
Кстати, крайне иронично, что мой знакомый, который обещал помочь с продвижением и раскруткой системы, хотел сначала назвать свою вебстудию SpaceWeb Team. Он забыл, что уже хостинг существует SpaceWeb. А тут у вас такой же домен... Вас не Константин зовут?)
ilshatkin
17.12.2024 05:11Нет, мое имя Ильшат, а непосредственно автор цмски Алексей. У нас студия разработки и одно из направлений разработка сайтов. Делаем на своей цмс. Процесс разработки радует и последующая поддержка очень комфортная. В общем мы довольны ею. Алексей как любитель передовых технологий постоянно совершенствует. Тут портфолио сайтов https://u4et.ru/internet-magazin-pod-upravleniem-trademaster
Если интересно, выходи на связь, созвонимся обменяемся опытом https://t.me/ilshatkil .
vitiok78
17.12.2024 05:11Такая CMS существует уже много лет. Называется Drupal. Основана на Symfony, а не на какой-то новой поделке
hokoo
17.12.2024 05:11Попробую понять и ответить на некоторые ваши претензии к WP
Неочевидная система срабатывания хуков. Как понять, в какой очерёдности они будут обработаны? - Почитать исходный код?
Сам Wordpress во многом сделан в функциональном стиле. Я раньше в юности сам был адептом такого подхода, но он крайне плохо подходит для больших и сложных систем - в какой именно момент вам стало сложно? Насколько сложна ваша сложная система для WP?
Почему-то многие сайты тормозят просто кошмарно, при этом число плагинов в целом выглядит в рамках разумного - какая связь с WP? среднее по больнице кол-во тормозящих сайтов слабо коррелирует с используемой CMS.
No comments
Когда ваш проект становится сложнее чем лендинг, вы всегда можете расширить архитектуру кастомными таблицами, благо для этого нужно всего-лишь применить встроенный API.
Сложная процедура добавления кастомных полей. - Метаполя не нужны в большинстве случаев. Но если они нужны вам, то есть несколько плагинов-лидеров ниши, вопрос установки плагина.
Не очевидное для новичков понятие таксономий - сущностей, которые существуют только лишь в коде, но не в БД. - Эти сущности существуют в БД и реализуют связи с постами.
Необходимость написать достаточное количество не самого очевидного кода чтобы реализовать AJAX подгрузку элементов в каталоге. - Вы еще не поняли, что прелесть WP в том, что в нем мало лишнего? Всё, что вам может понадобиться, есть в плагинах.
Вам точно нужна ORM?
Онлайн обновление плагинов в административной панели почему-то часто происходит неоправданно долго. - Вы не на WPEngine хоститесь?
popov654 Автор
17.12.2024 05:11Исходный код плагинов или ядра? Представим, что я не программист, а тупо владелец условного магазина - мне как понимать, кто в какой очерёдности отработает? Я вот правда не понимаю
Ровно в тот момент, когда пришёл на первую коммерческую работу в компанию, где всё было исключительно на ООП. Сразу ощущаешь разницу. Первый месяц сложно, а потом уже жить иначе не можешь. При этом хочу заметить, что да, большая часть объектов - синглтоны, и поэтому если у нас не Entity, а Service, и не хочется юзать DI или делать свою - то почему бы не сделать все методы статичными, а это уже не так сильно отличается от подхода "раскидаем функции по разным файлам и каталогам". Но всё же имхо это опрятнее, плюс можно привязывать к классам статические поля, получая инкапсуляцию, которой нет в функциональном/процедурном варианте.
-
Я не говорю, что нет сайтов, тормозящих на другой CMS, например, на Joomla. Wordpress тут не единственный с этой проблемой. Тормозящих сайтов на джумле не меньше, а тормоза там пожалуй даже побольше будут. Возможно, это беда абсолютно любой CMS? Кто знает.
А что здесь не так? Я не один столкнулся с этой проблемой, могу в личку вам ссылку на багтрекер прислать. Другое дело, что это не вина вордпресса, но вот зависающая намертво админка при включённом отладчике - уже скорее его вина. Что, если мне надо админскую часть своего собственного плагина дебажить?
Но используя кастомные таблицы мы уже по сути практически не используем сам Wordpress. У меня вот за последние пару месяцев было три сайта перед глазами, и собственные таблицы там использовала дай бог если четверть сторонних плагинов, а то и меньше.
Если вы считаете, что это легче, чем прибегать к кастомным полям - зачем нам тогда вообще CMS? Почему не писать на фреймворке? Почему вообще не писать всё самому? Кастомные поля вроде как задумывались чтобы делать жизнь разработчиков легче, а не сложнее.
Мы немного не поняли друг друга. Дело в том, что на популярных сайтах по вордпрессу этот момент объяснён весьма криво. Таксономия на самом деле отсутствует в БД. В БД присутствуют её члены, но не сразу, а после создания первого элемента.
Так вот это и бесит, что на каждый чих нужен плагин. Это всё просто ужасно стыкуется друг с другом - настолько сложно, что проще написать своё решение с нуля.
Безусловно. А вы больше любите чистые SQL запросы, серьёзно? Я понимаю недостатки ORM (например, низкое быстродействие в ряде случаев), но как можно не видеть их достоинства?
Нет, обычный хостинг.
hokoo
17.12.2024 05:11Если вы не против, я подсуммирую все темы в одном тексте. Но если есть желание углубиться в любой из вопросов, я с радостью дам более развернутый ответ.
Работая с WP, действительно, нужно иметь в виду, что он в немалой степени состоит из легаси-кода 20-летней давности, грубо говоря. Это следствие политики "работает - не трогай", которая тоже не на пустом месте возникла, а с целью экономного расходования ресурсов. Отсюда и отсутствие ORM, и функциональный подход (при том ни то ни другое не является по факту проблемой, а делом привычки). Я редко пишу на чистом SQL, даже имея сильно измененную структуру сущностей - за счет неплохого API самого WP. Кастомные таблицы - да, всё еще нужен чистый SQL. Но опять же, само по себе, имхо, это просто особенность движка, я не могу сказать, что это для меня некий стоп-фактор.
Основная суть преимущества WP - это его админка, ориентированная на пользователя. В этом секрет его популярности. Интуитивно понятный интерфейс, неиспорченный горе-разработчиками, предоставляет возможности к неограниченному расширению.
Около 15 лет назад я провел эксперимент какая CMS займет у меня минимум времени на освоение как юзера уровня чайник. Среди Друпала, Жумлы и я уж не помню чего-то еще, WP стал лидером с непреодолимым отрывом. И так до сих пор.
И как программист я до сих пор делаю как простецкие лендинги, так и порталы, мультисайты (самый большой был на 8 тысяч сайтов), мультилендинги, магазины, библиотеки. Очень легко настроить админку как нужно юзеру, очень просто расширить простую архитектуру до нужных структур.
Однако, если у вас вызывает вопросы то, как хранятся таксономии в БД, вы явно не усвоили как работает нативный API. Я уж не помню когда последний раз мне приходилось смотреть по каким таблицам лежат термы, а по каким их связи. Всё это покрыто API, и я не лезу под него.
AndrzejKorab
17.12.2024 05:11Многа букав в каментах напесале.
Если будет как Woo, только проще, с кучей тем и плагинов и с возможностью пилить новые/допиливать старые, в целом быстрый фронт для юзера и очень удобное для редактора/админа, то я за!
Я 2 месяца пилил плагины под Woo, которые работают непосредственно с бд, файлами и фильтрами. Это аццкая боль.
А чтобы что-то кастомизировать на фронте - это адъ.
Даже в самых крутых темах Woo не хватает кучи нюансов, такое ощущение что девы специально хотят помучить покупателей.
Короче на екоммерс надо ориентироваться и чтоб оно гибкое было, круче шопифая, ооочень гибкое. И бесплатное. А за бабки кастомизацию пусть 5 человек в штате пилят.
chifth
17.12.2024 05:11"То есть заголовок статьи - отчасти шутка, отчасти декларируемая цель, но не стоит воспринимать его всерьёз."
- Пример как написать "Кликбейт" длиною в продолжение :)
MX4RS
17.12.2024 05:11Убийца WordPress без комьюнити, без тысяч тем и плагинов, без поддержки.. ну вы только ВордПрессу с 40 % всех сайтов в мире не рассказывайте про такого убийцу - а то не дай бог сердечко у старика станет. Но если автор решил состричь капусты на импортозамещении - то правильный путь выбрал, больше убийц и больше велосипедов!
KOLAMBA97
17.12.2024 05:11Почему почти все cms на php? Очевидно же, что нужно делать на js. Ну dart на худой конец
BugInSky
17.12.2024 05:11Наткнулся на статью в новостной ленте в телефоне, уж больно интригующее название а после прочтения её и комментариев, я и вовсе создал тут учётку, чтобы влиться в обсуждение, уж больно актуальная тема на сегодняшний день. Честно, ожидал очередной тупой критики Wordpress, однако, я был весьма удивлён после прочтения, уж больно точно описана боль Wordpress'а. Я программирую на нём уже лет 5, из которых год (и по сегодняшний день) веду средний проект на нём. Чего только не приходилось изобретать, что-бы как то обойти его недостатки. Правда, как отметили комментаторы - Wordpress не с проста самая популярная CMS ввиду простоты её пользования конечному пользователю, тому же менеджеру интернет магазина, например. Говоря о вашей системе - очень хочется увидеть, так расхвалили, однако пока что с трудом верится в убийцу Wordpress, бывали уже попытки свергнуть его с трона, но пади знай, когда появится претендент достойный внимания, так что с огромным интересом буду наблюдать за развитием, что я теряю то в итоге.
karrakoliko
Уже есть ребята, которые переизобрели "че то полегче для входа, чем симфони, но на симфони компонентах".
Они назвали это ларавель, воткнули Active Record, заменили декларативный сервис контейнер на императивный, наворотили "фасадов", нате.
Че такого грандиозно сложного в symfony, что побуждает делать еще одну "упрощенную" поделку поверх? Table Gateway завезете вместо непостижимого (и весьма специфично реализованного) Data Mapper'а доктрины?
popov654 Автор
Вы сейчас про то, что не нужна лучшая Symfony чем та, что уже есть. А как насчёт CMS, по идеологии похожей на Symfony, пусть и не построенной реально на ней? Вы же прекрасно понимаете, в чём CMS для не программистов лучше, чем Framework :)
Я кстати ничего не сказал про систему плагинов, но она вероятно тоже будет в упрощённом виде: просто объединение готовых классов с классами плагинов (путём раскидывания их по каталогам), с требованием давать уникальные имена - и подписка на события фреймворка (это и в Symfony есть, кстати).
FanatPHP
Открою малюсенький секрет: Джюмла