Чужой WordPress-проект — это часто зоопарк тем, плагинов и «быстрых правок через редактор». Главное здесь не показать, какой прошлый разработчик был плохой, а исправить ситуацию так, чтобы сайт продолжал обновляться и не падал после каждого клика в админке.

Сначала разбираюсь, во что вообще лезу

Перед любыми правками я смотрю, на чём стоит сайт:

какая тема активна и есть ли дочерняя, какие плагины установлены, есть ли кастомные плагины или «кухонные» файлы типа my-functions.php, как устроены меню, виджеты, конструктор страниц. Параллельно делаю полный бэкап базы и файлов, а лучше — поднимаю копию на отдельном домене или поддомене. Любые серьёзные изменения сначала обкатываю там.

Никогда не правлю файлы ядра и «родительской» темы

Правка в wp-includes или wp-admin — это стопроцентная мина: при следующем обновлении всё затрётся. Туда не лезу вообще. То же самое с родительской темой: если тема не своя, а купленная или бесплатная, править её файлы — значит добровольно отказаться от обновлений.

Если там уже есть правки, я стараюсь их найти (по датам изменений, по комментариям в коде), переложить нужную логику в дочернюю тему или отдельный плагин и вернуть родительскую тему к «чистому» виду, чтобы её можно было безопасно обновлять.

Дочерняя тема — место для верстки и шаблонов

Если дочерней темы нет, а править верстку всё равно нужно, я создаю child theme и переношу туда всё, что касается внешнего вида: functions.php с аккуратными хуками, переопределённые шаблоны (single.php, page.php, archive-*.php, файлы WooCommerce и т.п.), стили и JS. Так все визуальные доработки переживают обновления родительской темы.

Важно: не тащить в functions.php дочерней темы бизнес-логику и интеграции. Для этого удобнее завести свой мини-плагин.

Свой плагин для логики, а не «кухонные сниппеты»

Любая логика, которая не про внешний вид, лучше живёт в отдельном плагине: интеграции с API, доп. поля, хук на оформление заказа, нестандартные крон-задачи. Я обычно завожу один кастомный плагин вроде my-site-core и складываю туда всё, что относится к этому проекту.

Плюсы: код отделён от темы (можно поменять тему, не потеряв функционал), проще искать, где что реализовано, нет искушения править всё подряд прямо в functions.php родительской темы.

Минимизирую конфликты с обновлениями

Перед обновлением ядра, темы или плагинов я проверяю:

совместимость версии PHP, есть ли что-то критичное в changelog’ах (особенно у WooCommerce и крупных плагинов), нет ли у клиента кастомных правок прямо внутри этих плагинов. На тестовой копии сначала обновляю там, пробегаюсь по ключевым сценариям (главная, корзина, форма заявки), и только потом повторяю то же самое на бою.

Если понимаю, что крупное обновление может сломать кучу всего, фиксирую текущую версию в wp-content/plugins/composer.json и обсуждаю с клиентом план: либо тратим время на аккуратную адаптацию, либо пока живём на этой версии с осознанным риском.

Документирую то, что сделал После доработок я оставляю короткое текстовое описание: где лежит кастомная логика, какие хуки используются, какие шаблоны переопределены, что нельзя обновлять без проверки. Это может быть простой readme в репозитории или заметка, которую я отправляю клиенту. Через полгода это спасает и меня, и следующего разработчика: не нужно разгадывать, почему что-то сделано именно так.

Итог Безопасная доработка чужого WordPress-проекта — это дисциплина: не трогать ядро, выносить верстку в дочернюю тему, логику в свой плагин, обновления гонять через тестовую копию и хоть как-то документировать изменения. Тогда даже очень «уставший» сайт можно привести в порядок так, чтобы он жил дальше, обновлялся и не падал от каждого чиха в админке.

#wordpress #разработка #php #фриланс