Від шаблону до реального магазину: як я розробляю проєкт WordPress/WooCommerce разом із Codex

Встановити WordPress, активувати WooCommerce та імпортувати демонстраційний контент теми — ще не означає створити готовий інтернет-магазин. Після початкового налаштування ми отримуємо лише технічну основу: стандартні сторінки, тестові товари, умовні банери, демонстраційне меню та блоки, які показують можливості теми. Щоб перетворити цю основу на реальний комерційний сайт, потрібно адаптувати її до структури конкретного бізнесу, наповнити справжнім контентом, налаштувати каталог і змінити стандартну поведінку WordPress там, де вона не відповідає вимогам проєкту.

У моєму випадку таким проєктом став інтернет-магазин жіночого спортивного одягу замовника. Для його розробки я використовую WordPress, WooCommerce, тему Flatsome та Codex як технічного помічника, здатного працювати не лише з окремими фрагментами коду, а з усім локальним середовищем проєкту.

Головна особливість цього підходу полягає в тому, що я формулюю завдання переважно мовою очікуваного результату. Мені не обов’язково заздалегідь знати, в якому PHP-файлі потрібно зробити зміну, яке поле оновити в базі даних або яку команду WP-CLI виконати. Я описую бізнес-завдання, обмеження та критерії готовності, а Codex аналізує структуру сайту, визначає технічний спосіб реалізації, вносить зміни та перевіряє результат.

Початкова точка: WordPress, WooCommerce і Flatsome

На початку роботи сайт уже мав встановлений WordPress, WooCommerce і тему Flatsome. Також було імпортовано demo content — набір демонстраційних сторінок, блоків, меню та інших матеріалів.

Demo content корисний тим, що дозволяє швидко отримати готову структуру й побачити можливості теми. Замість створення кожної секції з нуля можна взяти за основу вже налаштовані блоки: слайдер, каталог, банери, сторінку контактів, FAQ, вкладки або інформаційні секції.

Однак демонстраційний контент не можна просто залишити на сайті. Він містить сторонні назви, умовні тексти, тестові посилання та структуру, яка не враховує потреб конкретного магазину. Тому наступним етапом стала інвентаризація:

• які сторінки вже існують;
• які з них можна адаптувати;
• які матеріали потрібно видалити або приховати;
• які сторінки пов’язані з меню;
• які блоки Flatsome можна використати повторно;
• які стандартні сторінки потрібні WooCommerce;
• де демонстраційний контент може конфліктувати з майбутніми URL.

Цей етап важливий ще й тому, що WordPress зберігає значну частину структури не у файлах теми, а в базі даних. Сторінки, меню, UX Blocks, налаштування теми, товари, категорії та значення плагінів можуть бути пов’язані між собою. Через це необережне видалення одного об’єкта інколи впливає на кілька частин сайту.

Перетворення demo content на реальні сторінки

Замість того щоб повністю видалити демонстраційні сторінки та створювати все заново, частину з них я вирішив використати як основу. Сторінки вже мали придатні макети Flatsome, тому їх можна було перетворити на сторінки реального магазину.

Так на сайті з’явилися:

• «Про наш магазин»;
• «Чому обирають наш магазин»;
• «Розмірна сітка»;
• «Догляд за одягом»;
• «Доставка»;
• «Способи оплати»;
• «Повернення та обмін»;
• «Часті запитання»;
• «Контакти»;
• «Політика конфіденційності»;
• «Умови придбання».

Під час такого перетворення недостатньо змінити лише заголовок у редакторі. Для кожної сторінки потрібно перевірити:

• назву;
• URL, або slug;
• статус публікації;
• вміст;
• шаблон сторінки;
• посилання в меню;
• внутрішні посилання;
• можливі конфлікти з іншими сторінками.

Наприклад, у demo content уже могла існувати сторінка зі slug faq. Якщо просто присвоїти такий самий slug новій сторінці, WordPress автоматично створить адресу на кшталт faq-2. Технічно сторінка працюватиме, але URL буде неохайним і невдалим для пошукової оптимізації.

Тому Codex спочатку перевіряв наявні сторінки та конфлікти, а вже потім змінював назви, адреси й контент. У випадку конфлікту демонстраційна сторінка зберігалася, але отримувала іншу адресу, після чого потрібній сторінці призначався чистий slug faq.

Це хороший приклад різниці між простою командою і бізнес-завданням. Я міг сформулювати запит приблизно так:

Перетвори демонстраційні інформаційні сторінки на сторінки реального магазину. Збережи придатні макети Flatsome, створи зрозумілі URL, не змінюй службові сторінки WooCommerce та перевір, щоб не виникло дублів.

Після цього Codex мав самостійно визначити, які об’єкти можна змінювати, які слід захистити та як уникнути конфліктів.

Побудова зрозумілої навігації

Окремим завданням стала структура головного меню. Демонстраційне меню теми добре показує можливості Flatsome, але не відповідає логіці реального покупця.

Для магазину важливо, щоб людина могла швидко перейти до каталогу, знайти потрібний тип одягу, дізнатися про доставку, оплату, повернення або підібрати розмір. Тому інформаційні сторінки було згруповано в окремий розділ «Інформація».

Під час цієї роботи важливо було не видалити самі сторінки разом із непотрібними пунктами меню. У WordPress пункт меню та сторінка — це різні об’єкти, хоча в адміністративній панелі цей зв’язок не завжди очевидний.

Codex перевірив ідентифікатори меню та сторінок, видалив лише застарілі пункти навігації, а потім розмістив потрібні сторінки в заданому порядку. Після виконання скрипт додатково перевіряв, що контент сторінок, товарні категорії та інші меню не змінилися.

Цей підхід показує ще одну важливу перевагу програмної роботи з WordPress: зміна може супроводжуватися автоматичною перевіркою її меж. Скрипт не просто виконує дію, а контролює, що випадково не було змінено нічого зайвого.

Формування каталогу WooCommerce

Наступний великий етап — перетворення стандартного каталогу на каталог реального бренду.

У WooCommerce товар — це не тільки назва, ціна та фотографія. Він може містити:

• унікальний артикул SKU;
• короткий і повний описи;
• категорії;
• атрибути;
• варіації;
• розміри;
• статус наявності;
• головне зображення;
• галерею;
• податкові параметри;
• пов’язані товари.

У каталозі інтернет-магазину були окремі види спортивного одягу: легінси, шорти, спортивні бра, топи, комбінезони та готові комплекти. Для товарів потрібно було узгодити назви, SKU, категорії, описи, ціни, розміри та фотографії.

Особливу увагу ми приділили варіативним товарам. Наприклад, комплект одягу мав загальний товар і окремі варіації для розмірів S, M та L. Кожна варіація отримувала власний SKU, ціну й статус наявності.

Для пакетного створення комплектів Codex підготував PHP-скрипт, який працював через API WooCommerce. Перед імпортом він перевіряв:

• чи існує потрібна категорія;
• чи налаштований атрибут розміру;
• чи наявні терміни S, M і L;
• чи не використовується вже такий SKU;
• чи існують усі потрібні фотографії.

Лише після успішної перевірки створювалися товари та їхні варіації. Якщо під час імпорту виникала помилка, створені в межах поточного запуску товари видалялися. Це захищало каталог від частково імпортованих або дубльованих позицій.

Саме тут особливо добре проявився принцип взаємодії через бізнес-завдання. Запит міг звучати так:

Створи категорію готових комплектів. Кожен комплект повинен бути варіативним товаром із розмірами S, M і L, власним SKU, ціною, описом і відповідною галереєю. Перед імпортом перевір дублікати та не залишай частково створених товарів у разі помилки.

У такому формулюванні немає назви PHP-класу чи конкретної команди. Але є опис результату, структури даних і правил безпеки.

Робота із зображеннями товарів

Для магазину одягу фотографії є одним із головних елементів сторінки товару. Потрібно було не тільки завантажити зображення, а й правильно пов’язати їх із конкретними моделями.

Для цього використовувалися SKU товарів і номери фотографій. Codex спочатку виконував аудит: знаходив товар за SKU, перевіряв наявність усіх файлів і показував, скільки зображень уже прикріплено до товару та скільки має бути після заміни.

Лише після такої перевірки запускався режим фактичного застосування змін. Перше зображення ставало головним, а решта формували галерею. Для завантажених файлів WordPress створював attachment-записи та стандартні зменшені копії.

Окремо оптимізовувалися зображення для блогу. Вони приводилися до єдиного співвідношення сторін і розміру 1600 × 900 пікселів, переводилися у формат JPEG та стискалися до прийнятного обсягу. Скрипт поступово підбирав якість, щоб зберегти достатню деталізацію і водночас не перевищувати встановлене обмеження розміру файлу.

Таким чином, оптимізація була не випадковим стисканням, а контрольованим процесом із конкретними критеріями.

Головна сторінка як система блоків

Головна сторінка магазину — це не просто декоративний макет. Вона повинна пояснювати позиціонування бренду, показувати товари та вести користувача до покупки.

У Flatsome сторінки часто побудовані зі спеціальних shortcode-блоків: секцій, рядків, колонок, банерів і UX Blocks. Тому зміни можна вносити як через UX Builder, так і програмно через post_content.

Під час роботи на головну сторінку було додано блок запуску колекції. Спочатку він містив німецьку й англійську версії тексту в одному макеті. Після налаштування перекладів логіку змінили: у контенті залишився основний німецький текст, а англійська версія почала підставлятися системою локалізації.

Codex не просто вставив HTML у довільне місце. Скрипт знаходив конкретну секцію-якір і перевіряв, що вона зустрічається рівно один раз. Якщо структура сторінки не відповідала очікуваній, зміна не виконувалася. Це допомагало уникнути ситуації, коли блок випадково додається двічі або потрапляє не в ту частину сторінки.

Багатомовність як робота не лише з текстом

Мультимовний магазин — це значно більше, ніж переклад видимих абзаців. Перекладати потрібно:

• назви та описи товарів;
• категорії;
• сторінки;
• елементи меню;
• кнопки;
• повідомлення WooCommerce;
• блоки головної сторінки;
• записи блогу;
• метадані;
• окремі рядки теми та плагінів.

У проєкті основною мовою стала німецька, а додатковою — англійська. Частина перекладів зберігалася в контенті WordPress, а частина — у словнику TranslatePress.

Це створювало цікаві технічні ситуації. Наприклад, текст блоку міг фізично міститися в post_content, тоді як його переклад зберігався в окремій таблиці бази даних. Тому просто замінити текст у сторінці було недостатньо: потрібно було також перевірити й оновити відповідний запис у словнику перекладів.

Під час локалізації товарів змінювалися не лише назви, а й slug, короткі описи, повні описи та характеристики. Опис товару формувався як структурований матеріал із розділами про дизайн, посадку, параметри моделі, склад і догляд. Завдяки цьому картки товарів стали послідовними за стилем і зручними для покупця.

Блог як частина магазину

Блог у цьому проєкті не є окремим інформаційним додатком. Він виконує одразу кілька функцій:

• знайомить аудиторію з брендом;
• відповідає на запитання покупців;
• допомагає обрати одяг;
• пояснює правила догляду;
• створює додаткові сторінки для пошукових систем;
• приводить читача до відповідних категорій каталогу.

Було підготовлено статті про вибір спортивного одягу, догляд за ним, типи фігури, посадку легінсів, готові комплекти, купальники та тенденції спортивної моди.

Для записів оновлювалися заголовки, адреси, основний текст, анонси та зображення. Окремо створювалися англійська й німецька версії матеріалів. Важливо було зберегти єдину структуру: логічні заголовки, короткі абзаци, корисні рекомендації та природні переходи до товарів магазину.

У цьому випадку Codex допомагав не лише технічно розміщувати матеріали, а й підтримувати однаковий формат записів та перевіряти відповідність файлів конкретним публікаціям.

Налаштування WooCommerce під реальний магазин

Стандартне встановлення WooCommerce створює основу для продажів, але потребує адаптації. Потрібно перевірити валюту, адресу магазину, податки, доставку, способи оплати, статуси замовлень, електронні листи, сторінки кошика й оформлення замовлення.

Також необхідно врахувати, що частина налаштувань належить самому WooCommerce, частина — темі Flatsome, а частина може контролюватися сторонніми плагінами. Тому одна й та сама зміна іноді потребує роботи з кількома рівнями системи.

Наприклад, посилання на соціальні мережі могли зберігатися одночасно:

• у налаштуваннях теми;
• у дочірній темі;
• у футері;
• на сторінці контактів;
• у відповідях FAQ.

Зміна лише одного значення залишила б на сайті старі або тестові посилання. Тому Codex знаходив усі пов’язані місця, оновлював Instagram, Pinterest і Facebook, а потім очищав кеш WordPress.

Це і є приклад зміни стандартної поведінки системи відповідно до бізнес-вимоги: завдання формулюється як «усі посилання на соціальні мережі мають вести на офіційні сторінки бренду», а не як «зміни конкретне поле в таблиці options».

Як я формулюю завдання для Codex

Під час роботи я намагаюся описати не спосіб виконання, а потрібний результат. Хороше завдання для Codex зазвичай містить чотири складові:

1. Поточну ситуацію.
2. Очікуваний результат.
3. Обмеження.
4. Спосіб перевірки.

Наприклад:

На сайті залишилися демонстраційні інформаційні сторінки Flatsome. Перетвори їх на сторінки реального магазину, але збережи придатні макети. Не змінюй сторінки кошика, оформлення замовлення та облікового запису. Додай нові сторінки до розділу «Інформація» в головному меню та перевір усі посилання.

Або:

Для категорії готових комплектів потрібно створити варіативні товари з розмірами S, M і L. Використай передані SKU, ціни, описи та фотографії. Не створюй дублікати. Якщо частина даних відсутня, зупини імпорт і покажи проблему.

Або:

Замінити фотографії товарів відповідно до списку SKU. Перед заміною перевір наявність усіх файлів, збережи правильний порядок галереї та після завершення переконайся, що кожен товар має очікувану кількість зображень.

Такі формулювання залишають Codex свободу вибору технічного рішення, але чітко визначають межі роботи.

Що Codex робить усередині проєкту

Після отримання завдання Codex може:

• досліджувати структуру файлів;
• читати конфігурацію;
• знаходити потрібні шаблони та скрипти;
• аналізувати структуру WordPress;
• працювати через WP-CLI;
• використовувати API WordPress і WooCommerce;
• створювати контрольовані PHP-скрипти;
• оновлювати записи та метадані;
• працювати зі словниками перекладів;
• оптимізувати зображення;
• очищати кеш;
• перевіряти результат;
• створювати резервні копії перед ризикованими змінами.

Фактично Codex працює не як генератор випадкового фрагмента коду, який ще потрібно вручну копіювати в редактор. Він бачить локальний проєкт як систему і може виконати повний цикл: дослідження, реалізація, перевірка та звіт.

Водночас це не означає, що контроль людини стає непотрібним. Я визначаю зміст, структуру магазину, стиль бренду, логіку каталогу й очікувану поведінку. Codex допомагає перетворити ці рішення на технічні зміни.

Безпека змін і перевірка результату

Робота безпосередньо з базою WordPress може бути ефективною, але потребує обережності. Тому в проєкті використовувалися кілька рівнів захисту.

Перед складними етапами створювалися резервні копії бази та файлів. Скрипти перевіряли початковий стан і зупинялися, якщо він не відповідав очікуваному. Для важливих об’єктів використовувалися контрольні відбитки даних, щоб переконатися, що сторонні сторінки або меню не змінилися.

У деяких операціях застосовувався двоетапний режим:

• спочатку аудит без внесення змін;
• потім окремий запуск із підтвердженим застосуванням.

Після виконання перевірялися:

• кількість створених товарів;
• унікальність SKU;
• наявність варіацій;
• правильність категорій;
• порядок фотографій;
• адреси сторінок;
• структура меню;
• відсутність небажаних змін;
• відображення на сайті після очищення кешу.

Такий підхід особливо важливий для WordPress, де одна необережна масова операція може змінити десятки записів.

Переваги спільної роботи з Codex

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

Codex прискорює повторювані операції, допомагає обробляти великі набори товарів і зменшує кількість ручних помилок. Особливо корисним він є там, де одну й ту саму логіку потрібно застосувати до багатьох об’єктів: сторінок, записів, товарів, перекладів або зображень.

Ще одна перевага — відтворюваність. Якщо зміни виконуються підготовленим скриптом, залишається зрозумілий запис того, що саме було зроблено. Таку операцію легше перевірити, повторити на іншому середовищі або адаптувати до нових даних.

Обмеження та відповідальність розробника

Codex не приймає бізнес-рішення замість власника або розробника. Він може запропонувати спосіб реалізації, знайти технічний конфлікт або автоматизувати процес, але не знає сам по собі, якою повинна бути структура бренду, які тексти є юридично коректними або які умови доставки відповідають реальній роботі магазину.

Тому відповідальність людини залишається ключовою. Потрібно:

• чітко визначати вимоги;
• перевіряти вихідні дані;
• встановлювати межі змін;
• переглядати контент;
• тестувати критичні сценарії;
• контролювати резервні копії;
• перевіряти сайт очима реального покупця.

Що точніше сформульований очікуваний результат, то надійнішою буде реалізація.

Висновок

Розробка цього інтернет-магазину показала, що WordPress-проєкт можна будувати як спільну роботу людини та інструмента штучного інтелекту.

Я визначав структуру, зміст, бізнес-логіку та візуальний напрям. Codex досліджував технічне середовище, працював із файлами, WordPress, WooCommerce, базою даних і конфігурацією, автоматизував повторювані дії та перевіряв результат.

У такому форматі Codex стає не заміною розробника, а технічним партнером. Він допомагає скоротити шлях від сформульованої потреби до робочої функції на сайті. Водночас якість результату залежить від поєднання автоматизації з людським контролем, розумінням бізнесу та уважною перевіркою.

Саме так встановлений WordPress із демонстраційним шаблоном поступово перетворюється на реальний багатомовний WooCommerce-магазин: зі зрозумілою структурою, повноцінним каталогом, інформаційними сторінками, блогом, локалізацією та власною логікою роботи.

Весь описаний у статті обсяг розробки було виконано протягом одного тижня — у середньому по 1–3 години роботи на день. Такий темп став можливим завдяки вдалій взаємодії з Codex: замість витрачати час на рутинний пошук потрібних файлів, налаштувань і способів реалізації, я формулював очікуваний результат, контролював ключові рішення та перевіряв виконані зміни, а Codex брав на себе значну частину технічної роботи й автоматизації.