Розробка інтернет-магазинів на OpenCart

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

Магазин відрізняється від звичайного сайту тим, що після кнопки «купити» починається найважливіше. Товар має списатись із наявності, покупець — отримати лист із номером замовлення, менеджер — побачити заявку, а ви ввечері — зрозуміти, що продалось за день.

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

• структура каталогу: категорії, характеристики, фільтри
• картка товару, кошик і оформлення замовлення
• оплата й доставка так, як ви працюєте насправді
• адмінка, у якій ви самі додаєте товари й ціни

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

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

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

У магазину є ядро — його «двигун», спільний для всіх сайтів на OpenCart. Найпростіший спосіб щось змінити — залізти в цей двигун і переписати шматок коду. Працює одразу, але при першому ж оновленні платформи ваші зміни зникають: файл замінюється на новий.

Ocmod працює інакше: це окремий файл-інструкція, який каже «у такому місці підстав ось це». Ядро лишається недоторканим, а правка живе поруч: оновили магазин — інструкція застосувалась знову. Ще й вимкнути таке доопрацювання можна одним перемикачем, якщо воно раптом заважає.

• свої поля в картці товару чи у формі замовлення
• нестандартні знижки, комплекти, опт від кількості
• зміни в кошику: менше кроків, менше зайвих полів
• правки готових модулів під вашу логіку роботи

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

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

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

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

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

• вивантаження товарів, категорій, фото й характеристик
• клієнти та історія замовлень — наскільки віддає стара система
• переадресація зі старих адрес на нові, сторінка в сторінку
• перевірка після переїзду: чи все відкривається й індексується

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

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

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

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

Різниця з індивідуальним дизайном проста. Індивідуальний макет малюють під вас: ваш покупець, ваш асортимент, ваші акценти. Шаблон дає готовий каркас, який ми підганяємо під бренд: швидше й дешевше, але в межах того, що шаблон уміє.

• підбір теми під ваш тип товару й обсяг каталогу
• кольори, шрифти, логотип, вигляд картки товару
• збирання головної сторінки з потрібних блоків
• прибирання зайвого: демо-блоків, чужих банерів, неробочих кнопок

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

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

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

Найпростіший приклад — склад. Ціни й залишки живуть у 1С або BAS, а на сайті стоять цифри місячної давнини: покупець замовляє товар, якого вже немає, менеджер передзвонює й вибачається. Обмін це прибирає — змінили ціну в обліку, сайт підхопив; товар закінчився — картка сама показала, що його немає.

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

• платіжні системи: оплата картою, частинами, рахунок для юросіб
• служби доставки: розрахунок вартості й накладні з адмінки
• 1С або BAS: ціни, залишки, замовлення в обидва боки
• прайс-агрегатори: товари самі оновлюються на торгових майданчиках

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

Перед підключенням 1С чи CRM корисно навести лад у самому обліку: єдині назви, коди товарів, актуальні залишки. Це дешевше зробити один раз, ніж потім ловити помилки на сайті.

Магазин — це не картина на стіні: він щодня приймає гроші, і за ним треба стежити так само, як за касою в офлайн-точці.

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

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

• оновлення платформи й модулів, спершу на копії
• резервні копії файлів і бази даних
• нагляд за швидкістю, помилками й оформленням замовлень
• звіти: що купують, звідки приходять, де губляться

Оновлювати наосліп теж не можна: свіжа версія платформи може посваритись зі старим модулем, і магазин перестане приймати замовлення. Тому порядок завжди однаковий — копія магазину, оновлення на ній, перевірка замовлення наскрізь, і лише потім те саме на живому сайті.

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