Сайт на WordPress работает, но прежний разработчик больше не отвечает, а бизнесу нужна новая форма, раздел или правка в каталоге. В такой ситуации не обязательно начинать проект с нуля. Доработать сайт может другой специалист, если перед изменениями удаётся понять, как устроены тема, плагины и нужный сценарий. Главное — оценивать не только задачу, но и состояние проекта.
Когда текущий сайт ещё имеет смысл дорабатывать
Разовая правка обычно оправдана, если страницы открываются, администратор может войти в панель, заявки и заказы проходят, а изменение можно привязать к конкретному месту. Например, нужно добавить поле в форме услуги или изменить вывод вариаций товара. В этом случае существующий контент, адреса страниц и рабочие связи могут остаться на месте.
Новый сайт стоит обсуждать, когда любая правка вызывает новые поломки, одна и та же функция дублируется в нескольких плагинах, а доступы и резервные копии не контролирует владелец. Это не автоматический диагноз: сначала нужно увидеть проект и отделить локальную проблему от системной.
Что проверить до оценки задачи
Для первичного разбора не нужны пароли в открытом сообщении. Важно описать, что сейчас происходит и каким должен быть результат, а затем подготовить доступы безопасным способом. Полезно проверить:
- адрес сайта, панель WordPress и место, где размещены файлы и база данных;
- активную тему, дочернюю тему, визуальный редактор и собственные фрагменты кода;
- список плагинов и функции, которые зависят друг от друга;
- страницу или сценарий, который нужно изменить: действие пользователя, исходные данные и ожидаемый результат;
- наличие свежей резервной копии и возможности проверить изменение на копии сайта.
Дочерняя тема — отдельный слой темы, в котором хранят изменения, чтобы обновление основной темы не затёрло их. Но её наличие само по себе не говорит, где безопасно менять код: нужно посмотреть шаблоны, настройки и связанные плагины.
Как описать задачу, чтобы не получить оценку «на глаз»
Фраза «сделайте современный каталог» слишком широкая. Лучше назвать страницу, действие и ограничение: «в каталоге нужно оставить фильтр по размеру, добавить сортировку по цене и не менять адреса существующих товаров». Для формы полезно указать, какие поля видит посетитель, куда должна попасть заявка и что сейчас происходит после нажатия кнопки. Такой бриф помогает отделить новую функцию от соседних процессов.
Если решение зависит от чужого кода, нормальный план начинается с диагностики, а не с обещания готового результата. Сначала определяют затронутые файлы и зависимости, затем согласуют объём, способ проверки и только после этого вносят изменение.
Как принять доработку
Проверяйте не сам факт изменения файла, а пользовательский сценарий. Откройте страницу как обычный посетитель, выполните действие с реальными для сайта вариантами данных и убедитесь, что результат появился там, где его ждут. Если менялась форма, проверьте отправку и получение уведомления. Если затронут каталог или магазин, дополнительно посмотрите соседнюю карточку, корзину и мобильное отображение.
Отдельно зафиксируйте, что именно изменилось и какие места не входили в задачу. Это снижает риск, что следующая правка будет оцениваться без контекста.
Когда переходят к новому проекту
Новая разработка становится разумным вариантом, если требования уже не помещаются в текущую структуру, а поддержка старых зависимостей обходится дороже, чем понятная новая основа. Решение принимают после осмотра сайта, списка задач и ограничений бизнеса, а не только по возрасту темы или числу плагинов.
Если нужно оценить конкретный WordPress-сайт, опишите его адрес, текущий сценарий и желаемое изменение в анкете ZALMAR. Для общего контекста услуг разработки и доработки можно посмотреть описание работ ZALMAR.