Комментарии 55
В css-файле информация о теме, в json-файле цвета, шрифты и прочее. Л - логика!
Информация о теме в style.css - старое наследие WordPress, этот файл является обязательным, из него берется информация о теме. Механизм не меняется годами для обратной совместимости, не вызывает трудностей. А вот json файл - это фича автора, которая никак не конфликтует с требованиями wp
Да, всё верно, style.css это обязательное легаси, которое носит сугубо технический характер, а theme.json файл - это специальный инструмент для работы с внутренним редактором Gutenberg, который позволяет делает предустановки для базовых стилей: цвета, шрифты, отступы - это позволяет ограничить возможности контент-редактора к произвольному изменению дизайна, мы туда прописываем правила из UI kit
Нет смысла искать недостатки в WP их список практически бесконен. Важно то что у тебя практически нет альтернатив, когда тебе нужно сео и контент менеджмент из коробки. Поисковики очень плохо работают с js фреймворками, практически никак, и даже если это решить костылями. Результат будет не тот. Так что только CMS в этих случаях, есть и другие походы но долго и дорого.
А среди цмс выбирать сильно не приходится они все ужасны.
Почему acf храните в json а не php? Ведь так удобнее работать с данными, завезти константы, обернуть функциями и бизнес логикой.
json для быстрой синхронизации созданных в админке в интерфейсе acf полей
Но ведь сам плагин ACF позволяет регистрировать все эти поля программно, так что при локальном разворачивания проекта они автоматически применяется, а Ваш вариант нужно будет каждый раз в админке руками импортировать.
P. S. Сам сперва импортировать и контролировал через репозиторий, но потом ушёл в Регистраторы. Понравилось, гораздо удобнее
Попробуйте Joomla, будет интересно)
WordPress далеко впереди Joomla
В чём?
И чем же он дальше?
Ну например по популярности в 25 с лишним раз
При чем тут популярность, когда речь идёт о разработке. Пыха она и в Африке пыха. J4 и j5 это чистый код, охрененное ядро, все современные подходы к разработке. Я вообще использую symfony, но joomla шикарна, у меня на ней очень много проектов. Ну а WordPress дыра сплошная если прям из коробки и только допиливать, да и код сплошные костыли. Хотя тот же битрикс взять если, то там вообще сплошное дно, но бизнес требует
Та шож такое, и код у нее чистый, и ядро охрененное, и все современные подходы к разработке... но нафиг никому не уперлась и все выбирают "сплошную дыру".
В чем именно? Вы вообще joomla 5 щупали?
Это был явно сарказм)
Я попробовал в этому году - понравилось. Теперь часть проектов на Joomla, часть на WordPress. Joomla по части написания кода прям радует, но и WordPress знатно подтянулся!!!
для крупных клиентов
А как Вордпресс будет скалироваться в условном кубе для сотен тысяч rps и далее?
PHP сам по себе скалируется бесконечно.
Вопрос, как организованы походы в базу? Когда база перестанет справляться?
Вопрос правильный, именно база часто ахиллесова пята) Нам пока что удавалось справиться с любыми нагрузками, это делается довольно стандартным набором методов: правильное кеширование, правильное распределенное хранение (для некоторых сущностей мы создаем новые таблицы), оптимизированные запросы к базе (именно в них часто кроется проблема).
Тот же самый принцип, например у нас в проекте используем Galera
Есть решения для шардинга БД в WordPress, которые используются на самом wp.com
Вертикально, а что?
Расскажите, ACF используете в большинстве проектов и в версии PRO? Для проектов приходится докупать лицензию?
Большие проекты на wordpress, поддерживать очень сложно. На каком то этапе решение задачи начинается с того, чтобы "выключить" доступный из коробки функционал wp, т.к. он начинает мешать. Работал со всяким на wp, даже с маркетплейсом, то еще извращение))
На сегодняшний день мы твердо уверены, что проблемы проекта начинаются с его инициализации. Важно понимать что будет из себя представлять продукт на старте и какой у него потенциал развития, исходя из этого мы планируем как архитектуру приложения, так и серверную.
Так же хочу обратить внимание, мы упомянули в статье, что к каждой задаче свой инструмент и использовать Wordpress в таких сервисах как "маркетплейс" уже нецелесообразно, ну просто потому что объем разработки будет на WP будет равен объему разработки на Laravel, а второй объективно поддерживать легче
Большие проекты на любом движке, фреймворке, языке, системе и прочем поддерживать тяжело, именно от того, что он большой имеет много физических разных машин, много разных сетей, много разного софта, многие части системы написаны на разных языках, разными людьми, в разное время и разным подходом, и далее, далее, далее. Если для бизнеса нужен этот большой проект, чтобы бизнес приносил прибыль, этот проект будет поддерживаться пока бизнес не сдохнет, а если от него ничего не зависит, и он так для понтов, то он быстро как и команда иссякнет
Как с индексацией и ранжированием фронт-реактивного сайта на WordPress?
Мы напишем об этом отдельную статью, но при использовании Vue или React мы, конечно, рассматриваем SSR решения для индексных страниц, но бывают и хитрости, у нас был опыт написания SPA на интерактивных страницах и рендер статики для индексных. Вы можете посмотреть пример на одном из наших проектов https://parking-strogino.ru/, статичные страницы получают контент из Gutenberg и хранятся в статике, а страница "объекты" работает в режиме SPA
Почему ACF, а не carbon fields?
Пожалуй, худшее что случалось с PHP
Я согласен. Так сложилось, что после долгой работы с yii/laravel пришлось включиться в проект с вордпрессом. Это буквально руководство о том, как не надо писать код. Не удивительно, что PHP приобрел такую репутацию: огромное количество разработчиков на нем учились писать код начиная с вордпресса, впитывая дурные привычки.
А аргументы у вас есть, с примерами?
Да конечно. Возьмем хотя бы их "wordpress coding standards" из Кодекса. То есть официальных рекомендаций, как писать код на php в вордпрессе.
https://developer.wordpress.org/coding-standards/wordpress-coding-standards/php/
Начнем с того, что рекомендации вордпресса идут вразрез с PSR. Можно сказать, что это вкусовщина, однако стандарты берутся и развиваются не просто так. Многие подходы к форматированию кода устарели и от них отказались, однако в вордпрессе они продолжают существовать. Например, выравнивание пробелами по оператору присваивания.
$integer = 123;
$str = 'aaa';
Я считаю, что работа с вордпрессом прививает дурной вкус и привычку к небрежности. Причем, если бы было желание, рекомендации по форматированию когда можно было бы легко приблизить к стандартам, поскольку они не влияют на обратную совместимость.
Если идти глубже, то я бы вспомнил обилие глобальных переменных, хуков и процедурного кода. Это даже не спагетти.
Как пример, навскидку могу вспомнить, что если у нас есть пост с кастомными полями, и ты хочешь показать их в админке в списке постов, то тебе нужно перехватывать SQL через хук и редактировать его чуть ли не через регулярки.
В этом весь вордпресс. Да, в нем легко работать контет-менеджеру. На нем легко сделать что-то простое. Но как начинающему разработчику научиться писать хороший код, если у него пред глазами сборник того, как делать не надо?
Начнем с того, что рекомендации вордпресса идут вразрез с PSR.
Начать надо с того, что PSR это не стандарт, а рекомендации и что WPCS обязателен только для ядра, для плагинов и тем это так-же рекомендация. То есть ничто не запрещает вам использование PSR в последних.
Например, выравнивание пробелами по оператору присваивания.
Так а что здесь плохого? Я наоборот вижу здесь только благо - это визуально намного проще читать код с таким выравниванием.
Если идти глубже, то я бы вспомнил обилие глобальных переменных, хуков и процедурного кода.
Глобальные переменные есть и от них невозможно отказаться разом ввиду обратной совместимости, а во многом благодаря этому WP и стал таким популярным. В хуках не понятно что плохого то? Это еще одна фича WP благодаря которой он относительно прост и удобен для разработки. Что вы понимаете под "процедурным кодом". Функции в глобальном scope? Большее количество функций под капотом используют вызовы методов классов под капотом, что опять-же очень удобно.
Это даже не спагетти.
То есть лучше или хуже? Что в вашем понимание "спагетти" и приведите примеры такого в WP.
Как пример, навскидку могу вспомнить, что если у нас есть пост с кастомными полями, и ты хочешь показать их в админке в списке постов, то тебе нужно перехватывать SQL через хук и редактировать его чуть ли не через регулярки.
Ну тут уже понятно, что познания в разработке под WP у вас практически отсутствуют. Для вывода метаполей вообще не стоит использовать какие-либо SQL запросы т.к. тогда не работаю все хуки для них и не работает Object Cache.
Если суммировать все выше:
WP как разработчик вы не знаете (ваш пример с "кастомными полями" это прям дичь)
Я вижу одну валидную претензию - глобальные переменные, но не уверен, что это является критическим фактором
Все остальные ваши пассажи я проигнорировал т.к. там или ваше оценочное суждение или нет примеров.
Начать надо с того, что PSR это не стандарт, а рекомендации и что WPCS обязателен только для ядра, для плагинов и тем это так-же рекомендация. То есть ничто не запрещает вам использование PSR в последних.
PSR — php standards recommendations. То есть это да рекомендации, но все-таки буквально по СТАНДАРТАМ. Обязателены ли они к исполнению? Ну конечно нет — мир не рухнет, если каждый будет писать, как попало. Этакий рабочий бардак. Еще могут возникнуть сложности с некоторыми инструментами, например composer autoload, который ожидает соблюдения определенных стандартов в наименовании директорий, файлов, классов и неймпспейсов. Но это мелочи, да.
Так а что здесь плохого? Я наоборот вижу здесь только благо - это визуально намного проще читать код с таким выравниванием.
Эта тема давно рассосана и поднималась разными авторами. Навскидку, в книге «Совершенный код» Стива Макконнелла. Избыточные пробелы не несут в себе никакой пользы. Со стороны может казаться, что выравненный таким способом код выглядит аккуратно, но на деле, от того что название переменной отдаляется от ее значения, восприятие только ухудшается.
Глобальные переменные есть и от них невозможно отказаться разом ввиду обратной совместимости, а во многом благодаря этому WP и стал таким популярным. В хуках не понятно что плохого то? Это еще одна фича WP благодаря которой он относительно прост и удобен для разработки. Что вы понимаете под "процедурным кодом". Функции в глобальном scope? Большее количество функций под капотом используют вызовы методов классов под капотом, что опять-же очень удобно.
Да, благодаря всем этим "фичам" очень легко кодить по принципу х*як-х*як и в продакшн. Начинающим разработчикам очень легко нагуглить куски кода и впихнуть их себе. И да, это будет работать! В этом несомненный плюс вордпресса: можно быстро и без особых навыков накрутить что-то несложное. Проблемы всплывут позже, при поддержке или при росте проекта.
Однако я именно про это и говорю: вордпресс буквально учит плохой разработке. С одной стороны может показаться удобным, что можно перехватить хуком какой-нибудь параметр и переписать его. Коварство этого подхода в том, что это может сделать кто угодно, где угодно и сколько угодно раз. И потом попробуй разобраться в результате. Это, кстати, также отвечает на вопрос про "спагетти".
Для вывода метаполей вообще не стоит использовать какие-либо SQL запросы т.к. тогда не работаю все хуки для них и не работает Object Cache.
А кто сказал, что кастомные поля - это только простые метаполя? Это раз. Ну а два, перехват и модификация запроса используется и в разных уважаемых плагинах (тот же ACF), и даже в ядре.
Вот, например, пример из кодекса:
add_filter( 'posts_where' , 'posts_where' );
function posts_where( $where ) {
if( is_admin() ) {
global $wpdb;
if ( isset( $_GET['author_restrict_posts'] ) && !empty( $_GET['author_restrict_posts'] ) && intval( $_GET['author_restrict_posts'] ) != 0 ) {
$author = intval( $_GET['author_restrict_posts'] );
$where .= " AND ID IN (SELECT object_id FROM {$wpdb->term_relationships} WHERE term_taxonomy_id=$author )";
}
}
return $where;
}Эта тема давно рассосана и поднималась разными авторами. Навскидку, в книге «Совершенный код» Стива Макконнелла.
Отлично, вы только забыли маленькую деталь, цитату/ссылку на это.
Избыточные пробелы не несут в себе никакой пользы.
Вред несут?
Со стороны может казаться, что выравненный таким способом код выглядит аккуратно, но на деле, от того что название переменной отдаляется от ее значения, восприятие только ухудшается.
Опять-же ваше оценочное суждение, я противоположного мнения.
Да, благодаря всем этим "фичам" очень легко кодить по принципу хяк-хяк и в продакшн.
А "эти фичи" во множественном числе это вы так увыжительно "на вы" называете глобальные переменные?
Начинающим разработчикам очень легко нагуглить куски кода и впихнуть их себе.
Это вообще относится к любому языку программирования, при чем тут WP?
В этом несомненный плюс вордпресса: можно быстро и без особых навыков накрутить что-то несложное. Проблемы всплывут позже, при поддержке или при росте проекта.
Именно так, у кого нет познаний, опыта накрутит как придется - как вы, например, предлагали SQL запрос менять для получения метаполей. Я таких поделок под WP за свой опыт работы видал тысячи... и ничего страшного, для более-менее серьезного проекта выбирают имеено опытных разработчиков.
Однако я именно про это и говорю: вордпресс буквально учит плохой разработке. С одной стороны может показаться удобным, что можно перехватить хуком какой-нибудь параметр и переписать его. Коварство этого подхода в том, что это может сделать кто угодно, где угодно и сколько угодно раз.
Вы пишете, право, глупости. Это можно сделать в любом другой CMS (да той-же симофони) через рефлексию или даже тупо залезть в код ядра.
И потом попробуй разобраться в результате.
Довольно несложное занятие кстати, когда знаешь как и где искать.
Это, кстати, также отвечает на вопрос про "спагетти".
Не отвечает, т.к. тот подход, что вы описали выше можно применить где угодно. Я спрашивал где "спагетти" в самом WP.
А кто сказал, что кастомные поля - это только простые метаполя?
Потому, что это так и есть. И не бывает "не простых" метаполей.
Ну а два, перехват и модификация запроса используется и в разных уважаемых плагинах (тот же ACF), и даже в ядре.
При чем здесь сторонние плагины и WP. Их пишут совершенно разные команды. Про ядро вы выдумываете, в WP объявлены только хуки и само ядро их не использует. Вам дан инструмент, хотите пользуйтесь, хотите - нет.
Отлично, вы только забыли маленькую деталь, цитату/ссылку на это.
Это платная книга, ее нет в открытом доступе, так что разумеется я не могу быстро указать ссылку на нужную цитату. Однако тема форматирования поднимается во многих подобных книгах. Или вы их не читали?
Вред несут?
Да. И я об этом написал.
Опять-же ваше оценочное суждение, я противоположного мнения.
Это не мое оценочное мнение, а один из аргументов, которые я привел из книг.
Вы пишете, право, глупости. Это можно сделать в любом другой CMS (да той-же симофони) через рефлексию или даже тупо залезть в код ядра.
Ну кто же спорит. Однако где-то для этого надо постараться, а где-то это лежит прямо в документации как вполне себе рекомендованный способ.
Потому, что это так и есть. И не бывает "не простых" метаполей.
Метаполя - это всего лишь таблица в бд. Соответственно запрос может быть любой сложности. Если вы этого не понимаете, то у меня большой вопрос о том, какой сложности проекты вы вели.
При чем здесь сторонние плагины и WP. Их пишут совершенно разные команды. Про ядро вы выдумываете, в WP объявлены только хуки и само ядро их не использует. Вам дан инструмент, хотите пользуйтесь, хотите - нет.
Ну так я привел кусок кода из ядра, что выложен в кодексе.
Это платная книга, ее нет в открытом доступе, так что разумеется я не могу быстро указать ссылку на нужную цитату.
То есть у вас нет никаких пруфов относительно выравнивания?
Да. И я об этом написал.
Я не увидел где вы написали какой вред наносит форматирование (конкретно выравнивание пробелами), укажите?
Это не мое оценочное мнение, а один из аргументов, которые я привел из книг.
Все еще жду цитаты.
Метаполя - это всего лишь таблица в бд.
Это не таблица, а сущность WP. Таблица (а точнее таблицы т.к. она не одна) это реализация.
Соответственно запрос может быть любой сложности. Если вы этого не понимаете, то у меня большой вопрос о том, какой сложности проекты вы вели.
Ну явно не того уровня, что вы, у меня в проектах получение метаполей SQL запросами не практикуется.
Ну так я привел кусок кода из ядра, что выложен в кодексе.
Это не код ядра, а пример использования хука.
Вся проблема WordPress - в обратной совместимости вплоть до очень старых версий. Но это же являеься его сильной стороной. Ни одна CMS не может себе этого позволить, поэтому количество установок говорит само за себя. А что до стандартов, так WordPress появился задолго до PSR/PHP-FIG. С появлением в проекте Gutenberg WPCS (WordPress for CodeSniffer) стандарты стали обязательны для ядра, а теперь и для разработчиков плагинов. Откровенный говнокод более в репозиторий не попадает. Но это долгий процесс, так как плагинов тысячи и их часто пишут люди, далекие от программирования. У WordPress своя ниша и свой огромный (почти 50% мирового интернета) кусок, с этим приходится считаться и уважать труд разработчиков, кто тянет на себе этот проект многие годы. А стандарты подтянутся, недаром в РНР внесли правки, чтобы оно работало с WordPress более лучше ;-)
Публикации
Как и почему в 2024 году мы разрабатываем сайты для крупных клиентов на WordPress?