Как организовать разработку и поддержку блога на WordPress в 2К19 году и не налажать

[mihdan]

Вместо RusToLat пора давно использовать Cyr2Lat.

[Clickru]

Вы ведь есть среди авторов плагина Cyr2Lat. Расскажите, пожалуйста, чем они отличаются и почему именно нужно использовать Cyr2Lat?

[mihdan]

— Поддержка PHP 5.6 — 7.4
— Поддержка новый версий WordPress 5+
— Страница настроек в админке.
— Изменение таблиц траслитераций в админке или по хуку
— Работа с ACF, WPML и еще несколькими популярными плагинами
— Фоновые задачи конвертации (актуально если на сайте больше 10к записей)
— Интерфейс конвертации для WP-CLI
— Исправление более 30 ошибок старых форков
— 100% покрытие тестами
— ООП интерфейс

Ну и много-много улучшений, которые остались под капотом и которые можно видеть в ченджлоге.

[Clickru]

А если прям сейчас заменить RusToLat на Cyr2Lat — какие проблемы могут всплыть?

[mihdan]

Проблем быть НЕ должно, так как сейчас cyr2lat при установке ничего не делает, чтобы не ломать чужие урлы, как это делают форки.

Единственное что может быть — некоторые буквы в RusToLat НЕ соответствовали ГОСТ, а в cyr2lat они по ГОСТ, поэтому могут быть отличие в буквах Ё, Й, Я, Ш, Щ.

Сайт при этом сломаться не должен.

[mihdan]

Введия для поста — похоже на ошибку в чеклисте.

[Clickru]

Да, действительно. Спасибо за внимательность, исправили.

[mihdan]

Например, даты публикации поста в карточках и в отдельном посте у нас в кириллице и умеют склоняться. Почему-то этого нет в коробке WordPress

В ядре есть date_i18n(), которая и занимается этим.

[Clickru]

Спасибо! Есть повод переписать то, что есть у нас.
Если кому-то тоже интересно, то начать можно с этого: developer.wordpress.org/reference/functions/date_i18n и/или wp-kama.ru/function/date_i18n

[monochromer]

Лучше использовать такой трюк:

<link rel="stylesheet" type="text/css" href="<?php echo get_template_directory_uri(); ?>/assets/styles/style.css?<?php echo time(); ?>" />

Наверно, хотели написать filemtime() вместо time()?

[Clickru]

Да, при верстке использовали не тот пример кода. Спасибо, что указали на ошибку.

[Clickru]

> Ещё у вас страницы с записями авторов немного странно выглядят blog.promopult.ru/author/admin :)
Уже поправили, спасибо:)

2. Насчет обновления версии Wordpress: обновляться до 5.2 мы планируем в ближайшее время (основные уязвимости ветки 5.1 исправлены в 5.1.1).

[VolCh]

Кстати, как с таким подходом обновления проходят? Вы же сам вордпресс в репозитории храните?

[Clickru]

Да, сам WordPress и всё связанно с ним (без пользовательских медиа-файлов) хранится в репозитории. Это накладывает определённые особенности на процесс обновления, но в целом всё это — ручное обновление версии WP: wordpress.org/support/article/updating-wordpress/#manual-update

На ревью--ветке всё тестируется и в не пиковые часы (ночь любого выходного дня) по посещаемости, выкатывается.
Скоро как раз новое обновление ставить.

[Clickru]

«тема — только для оформления, плагины — только для расширения функционала»

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

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

Спасибо вам за солидарность.

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

[vlad-yermolayev]

Расскажите пожалуйста где Вы храните БД? Например для того, чтобы поднять такую же копию как на продакшене мы берем файлы c master, а как быть с БД?

[Clickru]

БД живёт своей жизнью. БД, как и всё на сервере регулярно бэкапится. Если нужно что-то где-то развернуть — берётся свежий дамп базы.

Заботится о копиях БД для использования нужно, если проекты на WP идут потоком, как в студиях. У нас такого кейса просто нет. Поднимается БД, блог, настраиваются бэкапы и начинается работа уже с кодом, через git.

[Alexufo]

По идее в шаблонах лучше не вызывать css сайта, там эта строчка не нужна, а подключать так

wp_enqueue_style( 'site-style', get_stylesheet_uri() ,false,filemtime(get_template_directory().'/style.css'));

Плюс особенные вещи сайта, навроде модификаций админок, кастомные типы полей лучше выносить в плагин, чтобы при редизайне не переносить функционал.

[Clickru]

А расскажите, пожалуйста, почему именно «в шаблонах лучше не вызывать css сайта» и что именно значит «не нужна»? И чем именно предложенный способ подключения отличается или лучше использованного в моём варианте? Я видел много упоминаний wp_enqueue_style() и wp_register_style(), но какого-то внятного ответа на вопрос: «А чем оно лучше и почему именно правильнее?» не получил.

Про модификации и ситуацию редизайна: я выбрал такой вариант, где всё, что имеет отношение к своим доработкам (модификация админки, кастомные RSS-ленты, лайки, кнопки «Нравится», похожие посты и проч.) подключаются через набор include-конструкций в файле functions.php. В случае же редизайна или переезда на новую тему — просто копируются файлы и подключения в файле функций и всё работает.

[Alexufo]

Потому что в шаблоне будет меньше кода. Зачем там это если все равно все подключится в wp_head();
Регистрации стилей нужны, чтобы плагинописателям можно было не подключать библиотеки десять раз, тот же JQuery, это актуально для любителей плагинов, конечно. Так да, больше незачем.

[Clickru]

Любопытная позиция, спасибо за советы.
А можете показать пример темы, где подключение статики (стили, скрипты) реализовано через wp_enqueue_style()?

[Alexufo]

ну стандартные, та же twentynineteen. Они, кстати, используют wp_get_theme()->get( 'Version' ) т.е подставляют версию темы, чтобы не кешировались ресурсы, вместо того чтобы каждый раз дергать файловую систему. Это вроде бы как еще корректнее, но тогда стоит вопрос чтобы настраивать автоинкремент версии. Тут уже все от процесса разработки зависит. На девелоперской версии нет кеширования, а при накате продакшена можно действительно увеличивать версию темы ручками.

Используемые вами файлы для админки через inlcude в тему работают только когда тема активна. Если подключать их как плагин, то независимо от активности темы функционал админки не теряется. Это бывает важно, когда начали делать новую версию темы, но что-то нужно поправить вот прям вот ща на старой. Тогда каждый раз приходится добавлять себе в новую тему функционал из старой.

Мне как-то логичнее чувствовать, что все что связано с админкой лежит плагином. А Все что со фронтом — в теме.