Редизайн
и рестайлинг сайтов
в Краснодаре

Если он устойчив структурно — да. Если нет, мы собираем все заново, с расчетом на масштаб.

Именно из-за этого важна система. Мы создаём правила, по которым живут файлы.

У нас все работает по правилам. Мы до работ задаем рамки, чтобы команда не гадала, «как правильно по бренду».

Да. Структура сохраняется и на полке, и на экране, и в презентации.

Нет. Но, возможно, пора выстроить систему целиком.

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

Да, и так правильно. Шаблон компонента копируется в тему и правится там, стандартный остаётся нетронутым. Иначе обновление платформы затирает правки, и сайт возвращается к прежнему виду в неожиданный момент. Перед работой мы проверяем, нет ли уже таких правок в стандартных файлах от прежних подрядчиков.

Через сохранённую копию файла шаблона и записанную дату изменения. Правка обратима, пока копия лежит рядом и её содержимое совпадает с тем, что было до выката. Мы сверяем копию побайтово, а не по имени файла: одинаковое имя при разном содержимом даёт ложное чувство, что откат готов.

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

Если текущая версия получает обновления безопасности — не обязательно. Если нет, обновление идёт первым и своим шагом, с сохранением вида. Совмещать обновление платформы и смену дизайна в одном выкате не стоит: при поломке непонятно, что именно её вызвало, а откатывать придётся оба изменения сразу.

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

Это наш обычный случай. Работа начинается с осмотра: где лежат шаблоны, какие правки уже внесены в стандартные файлы, есть ли рабочая копия и свежий бэкап. По итогам осмотра становится понятно, что можно править шаблоном, а что потребует более глубокого вмешательства, и оценка выдаётся уже после этого, а не до.

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