Розробка WordPress-сайту не закінчується в момент, коли готові всі сторінки й функції. Попереду залишається не менш відповідальний етап: перенесення проєкту на продакшен, налаштування хостингу, перевірка сайту на реальному домені, оптимізація зображень, внесення останніх правок і передача результату замовнику.
Саме на цьому етапі особливо важливі уважність і послідовність. Навіть добре протестований локальний сайт після перенесення може поводитися інакше: змінюються адреси, версії PHP, права доступу, налаштування сервера, кешування та спосіб надсилання пошти.
У завершальній частині проєкту Codex знову працював як другий розробник. Він допомагав виконувати технічні операції через SSH, знаходити причини проблем після міграції, вносити правки в код, працювати із зображеннями та швидше закривати зауваження замовника.
Підготовка сайту до продакшену
Перед перенесенням важливо переконатися, що локальна версія справді готова до публікації. На цьому етапі я ще раз перевірив основні сторінки, меню, форми, адаптивність і функціонал WordPress.
Окрему увагу приділив речам, які легко пропустити:
- чи немає тестових текстів і зображень;
- чи правильно працюють усі кнопки та посилання;
- чи налаштовані заголовки сторінок і метаописи;
- чи немає помилок у консолі браузера;
- чи коректно відображається сайт на смартфонах;
- чи видалені тимчасові облікові записи та непотрібні плагіни;
- чи створена актуальна резервна копія.
Codex допоміг систематизувати цю перевірку. Замість того щоб покладатися лише на ручний перегляд, можна сформувати чіткий чекліст і послідовно пройти весь сайт. Якщо в проєкті вже є автоматичні тести, їх також потрібно запустити перед перенесенням.
Налаштування хостингу через SSH
Для роботи з продакшен-сервером я використовував SSH. Це дає значно більше можливостей, ніж звичайний файловий менеджер у панелі хостингу.
Через SSH можна:
- перевірити структуру каталогів;
- завантажити або розпакувати файли сайту;
- налаштувати права доступу;
- перевірити версії PHP та інших серверних компонентів;
- виконувати команди WP-CLI;
- працювати з базою даних;
- переглядати журнали помилок;
- очищати кеш;
- швидко створювати резервні копії.
Codex допомагав складати й перевіряти команди, аналізувати відповіді сервера та знаходити причини помилок. Це особливо корисно, коли проблема проявляється лише на хостингу.
Продакшен потребує обережності. Перед змінами я перевіряв поточний каталог, робив резервну копію та переконувався, що команда не зачепить сторонні файли. Codex прискорює роботу, але остаточне рішення про виконання потенційно небезпечної операції залишається за розробником.
Перенесення WordPress-сайту
Сам процес перенесення складався з кількох частин:
- Підготовка домену та каталогу на хостингу.
- Завантаження файлів WordPress.
- Створення бази даних і користувача.
- Імпорт локальної бази.
- Налаштування
wp-config.php. - Заміна локальних адрес на продакшен-домен.
- Перевірка постійних посилань.
- Налаштування HTTPS.
- Очищення кешу.
- Повторне тестування сайту.
Особливої уваги потребує заміна URL у базі WordPress. Звичайний пошук і заміна можуть пошкодити серіалізовані дані, тому для цього краще використовувати інструменти, які розуміють структуру даних WordPress, наприклад WP-CLI.
Codex допомагав контролювати послідовність перенесення та швидко реагувати, якщо після міграції зникали стилі, не відкривалися окремі сторінки або WordPress продовжував посилатися на локальний домен.
Перевірка сайту на реальному сервері
Успішне відкриття головної сторінки ще не означає, що перенесення завершене. Після запуску потрібно перевірити весь основний користувацький шлях.
Я протестував:
- головну сторінку та внутрішні розділи;
- навігацію й мобільне меню;
- контактні форми;
- відправлення електронних листів;
- пошук;
- сторінку 404;
- завантаження зображень;
- авторизацію в адміністративній частині;
- роботу сайту через HTTPS;
- відображення на різних розмірах екрана.
Також перевірив журнали PHP і вебсервера. Частина проблем може не бути помітною для відвідувача, але вже фіксуватися в логах. Codex допомагав читати ці повідомлення, знаходити пов’язані файли та пропонувати конкретні виправлення.
Фінальна робота із зображеннями
На завершальному етапі часто з’ясовується, що окремі фотографії потрібно замінити, обрізати або додатково підготувати для сайта. Саме зображення значною мірою визначають перше враження від готового проєкту.
В одному з таких завдань потрібно було делікатно відретушувати фотографію першого слайда головної сторінки: прибрати дрібні плями на шкірі, зайві родимки та волоски, що вибивалися із зачіски. При цьому було важливо не змінити риси обличчя, фігуру, одяг, освітлення, кольори й композицію кадру.
Codex допоміг організувати весь процес:
- знайти файл, який фактично використовується у слайдері;
- зберегти оригінал окремо;
- сформувати точне завдання для ретуші;
- проконтролювати розмір і формат;
- оптимізувати готове зображення для вебу;
- встановити нову версію на сайт;
- перевірити результат на головній сторінці.
Тут важлива не лише якість ретуші, а й технічна підготовка. Занадто важке зображення може сповільнити завантаження першого екрана, тому після обробки потрібно знайти баланс між деталізацією та розміром файлу.
Передача сайту замовнику
Коли технічна перевірка завершена, сайт потрібно підготувати до передачі. Замовник має отримати не просто посилання, а зрозумілий і керований продукт.
До передачі я підготував:
- окремий обліковий запис адміністратора;
- актуальну резервну копію;
- доступи до хостингу та домену;
- короткі інструкції з редагування основного контенту;
- пояснення щодо оновлення WordPress і плагінів;
- перелік встановлених компонентів;
- рекомендації щодо резервного копіювання та безпеки.
Паролі краще передавати захищеним способом, а не зберігати у звичайному документі чи надсилати всі доступи одним повідомленням.
Codex також може допомогти підготувати документацію для конкретного сайту: описати, як змінювати банери, додавати записи, редагувати сторінки, працювати із зображеннями та відновлювати сайт із резервної копії.
Правки після демонстрації
Навіть якщо сайт повністю відповідає технічному завданню, після першої демонстрації майже завжди з’являються додаткові побажання. Коли замовник бачить проєкт на реальному домені й користується ним як звичайний відвідувач, він помічає деталі, які складно оцінити на макеті.
Це можуть бути невеликі зміни:
- скоротити заголовок;
- замінити фотографію;
- пересунути кнопку;
- збільшити відступ;
- змінити текст у формі;
- виправити мобільне відображення;
- додати нове посилання;
- приховати непотрібний блок.
Головне — перетворити повідомлення замовника на конкретні технічні завдання. Codex допомагав знаходити потрібні шаблони, стилі та налаштування, а також оцінювати, чи не вплине одна правка на інші частини сайту.
Після кожної серії змін я повторно перевіряв не лише виправлений елемент, а й пов’язані сторінки. Наприклад, зміна глобального стилю кнопок може вплинути одразу на весь сайт, а заміна зображення — на швидкість завантаження та вигляд мобільної версії.
Codex не замінює фінальний контроль
На завершальному етапі Codex особливо корисний як технічний партнер. Він швидко аналізує файли, допомагає працювати із сервером, знаходить пов’язані ділянки коду, готує команди та прискорює внесення повторюваних правок.
Але продакшен потребує відповідального контролю. Розробник повинен розуміти, що саме змінюється, мати резервну копію та перевіряти результат у реальному браузері. Особливо це стосується команд через SSH, роботи з базою даних, прав доступу та конфігурації сервера.
Найкращий результат виходить тоді, коли Codex виконує роль другого розробника, а людина відповідає за архітектурні рішення, безпеку, візуальну якість і фінальне приймання.
Висновок
Завершальний етап WordPress-проєкту — це не просто натискання кнопки «Опублікувати». Він охоплює налаштування хостингу, перенесення сайту, роботу через SSH, перевірку на продакшені, оптимізацію зображень, передачу доступів і внесення останніх побажань замовника.
Codex допоміг зробити цей процес швидшим і структурованішим. Він став корисним не лише під час написання функціоналу, а й у тій частині роботи, де потрібно уважно довести проєкт до готового результату.
Саме після цього сайт можна вважати завершеним: він працює на реальному домені, перевірений на різних пристроях, зрозумілий замовнику та готовий до подальшого використання.