Игорь Воротнёв

Если это разовая задача, быстрее всего будет скопировать весь код из редактора WordPress в ваш настольный редактор кода, поиском-заменой изменить все img на a>img с нужными ссылками (тут помогут регулярки в поиске-замене). Потом скопировать результат обратно в редактор WP.

Как уже написали, универсального набора не существует, ибо задачи разные. Но есть некоторые наметки по этому поводу. Сразу оговорюсь - у меня всех без исключения WP-проекты построены на базе Composer, зависимостями (а плагины ими и являются) управлять просто и удобно, плюс autoload. Это позволяет динамически включать-выключать плагины в зависимости от переменных среды или feature flags. А теперь сами плагины. Разобьем им сразу на 2 категории - development и production. Первые нужны для облегчения разработки и отладки проекта, вторые - всегда.

Development-only плагины:

- Query Monitor
- Transients Manager
- WP Crontrol
- Airplane Mode
- Debug wp_redirect
- User Switching
- Rewrite Rules Inspector
- rarst/wps (обертка для Whoops)
- rarst/laps (профайлер)
- Regenerate Thumbnails
- Парочка кастомных mu-plugins которые облегчают жизнь (обертка для symfony/var-dumper и тд)

Production:

- ACF Pro
- Кеширование - WP Super Cache, Batcache, WP Fastest Cache. Redis/Memcached для объектного кеша (все есть от именитых команд типа 10Up, Humanmade и тд) - какой конкретно зависит от проекта
- Для форм использую свою наработку, HTML чистый который делает верстальщик, обработчик - своя кухня которая использует внешний transactional email service (SendGrid, Amazon SES и другие - адаптеры пишутся по необходимости) с их темплейтами для писем, использует composer-библиотеки для валидации и тд. Для всех форм также создается custom post type, все сабмишны пишутся туда с логом (сами данные формы, статус отправки транзакционного письма, лог мейлера и тд - удобно для отладки). На первый взгляд звучит сложно, но благодаря ООП-архитектуре по принципу Laravel / Laravel Nova все настраивается буквально за считанные минуты. Но если бы использовал готовый плагин, то скорее всего CF7.
- Disable Comment - потому что на большинстве сайтов они не нужны
- Classic Editor - потому что все еще не везде подходит/заходит Gutenberg
- Duplicate Post - удобно для работы с контентом, активируется по необходимости
- Enable Media Replace - иногда полезен, активируется по необходимости
- EWWW Image Optimizer Cloud - удобно, дешево
- Lazy Load Optimizer - полезная штука для frontend performance
- Safe SVG - SVG сейчас везде, так что без него никуда
- Cyr-To-Lat - если сайт кириллический / мультиязычный
- Для мультиязычных сайтов чаще всего останавливаемся на WPML
- ElasticPress - для поиска/фильтров
- WP-Minions или Cavalcade - для асинхронных фоновых задач
- humanmade/S3-Uploads - для медиа-библиотеки в S3

Дальше, для разных задач есть свои "фавориты" и/или свои кастомные наработки.

Ну и, конечно же, WP CLI.

Говорят, если отформатировать жесткий диск и поставить с нуля чистую ось, то все снова летает.

Обычно на хуке init висит add_rewrite_rule(), а на хуке template_redirect или template_include висит подключение нужного шаблона. Переменная, которая заполняется в add_rewrite_rule() регистрируется на фильтре query_vars. Поищите глобально в коде перечисленные фрагменты.

Можно гугланалитикс задействовать, с помощью событий. Я бы так делал, потом из такой статистики можно интересные выводы делать по части маркетинга. Ну а чтоб вывести на сайте, используем SDK, тянем из GA и кешируем в postmeta.

CleanMyMac X например

https://codex.wordpress.org/Function_Reference/wp_...
https://codex.wordpress.org/Function_Reference/wp_...

Фронт и бек в отдельных ветках, например frontend и backend. Пулл-реквесты из этих веток в одну, например develop. Конфликты будут раздельные и каждый автор своей ветки (frontend, backend) пусть сам резолвит их у себя пока pull request не позеленеет.

Где физически находится тот или другой разработчик - не важно. Git он как раз про раздельную и независимую работу, в том числе (если не в первую очередь - remote).

Replace in path? Можно сузить поиск по скоупу, директории, отфильтровать (например, только в комментах), а с помощью regex ограничить какие конкретно FQN менять:



зы: и да,

Как во всех phpdoc блоках заменить полные пути на FQN?

FQN это и есть полный путь :)

ззы: Помнится до установки последней версии PhpStorm (и вместе с этим чистки плагинов) был Intention "Replace FQN with import", но сейчас не вижу его у себя.

Если темы делать "по учебнику" (согласно требованиям и рекомендациям из официальной документации и Theme Handbook), с адекватными плагинами, которые исповедуют такой же подход, проблем не будет - все будет совместимо. С говноплагинами проблемы будут, но они будут и на официальной теме, и на платной/премиум, и на любой другой. Ибо говноплагин.

1. Если вы отвечаете за дизайн, то вам нечего делать в blade-шаблонах. Там могут тусоваться бекендеры и фронтендеры, но не дизайнеры.
2. Шаблонизаторы работают так, что сами шаблоны потом компилируются в обычный php/html-код и кешируются. Для рендеринга страницы используется этот кеш (это повышает производительность). Вот если вы поменяли шаблон, а кеш не очистили - изменений вы не увидите.
3. Чтобы очистить кеш, как уже написал antimind нужно в консоли в корне проекта выполнить команду php artisan view:clear