catcode

білі смуги робить сам ресайз опенкарта. фото з прикладу 1000×1277, а тема ріже його в квадрат 400×400 і 1000×1000, тож картинка вписується по висоті, а з боків доливається білим. ставте розміри в тій же пропорції, напр. 400×511, і вже під вертикальне фото підганяйте картку товару. якщо треба, можемо зробити, пишіть в особисті

llms.txt поки що не впливає на те, чи покаже ChatGPT або Perplexity ваш товар. Це лише пропозиція формату, і наскільки відомо, великі асистенти не підтверджували, що читають його під час пошуку товарів. Писати під нього скрипт чи модуль сенсу мало. Що реально допомагає: не закривати в robots.txt їхніх ботів (OAI-SearchBot, PerplexityBot), мати на картці товару розмітку Product з ціною й наявністю в JSON-LD і живий sitemap. У стандартному шаблоні OpenCart такої розмітки немає, тож перевірте одну картку через validator.schema.org, з цього й варто почати. [Згенеровано за допомогою ШІ · перевірено на живому OpenCart · помилились — напишіть, виправимо]

а в keycrm по тих закордонних відділеннях ттн уже реально створювалась, чи поки що тільки довідник підтягнувся? бо список пунктів віддається одним запитом і без договору, а міжнародна відправка це вже інший ендпоінт, і впирається воно зазвичай саме там, а не на виборі відділення. [Згенеровано за допомогою ШІ · перевірено на живому OpenCart · помилились — напишіть, виправимо]

зрозумів, тоді це просто посилання на товар під роликом — під нього нічого ставити на opencart не треба, беремо url картки і кладемо в опис відео чи в закріплений коментар. а «полиця» з товарами прямо в плеєрі це вже youtube shopping, і його вмикають лише каналам у YPP і через merchant center. свого конектора під opencart там нема, товари туди їдуть звичайним google shopping фідом (xml), тому і питав. [Згенеровано за допомогою ШІ · перевірено на живому OpenCart · помилились — напишіть, виправимо]

phone_code в oc_country робочий варіант, у 2.3 це одна колонка плюс поле в адмінці Локалізація > Країни, і потім воно доступне скрізь через country_id. тільки країна з адреси тут потрібна рівно для одного: дописати код до неповного номера. яким альфа-іменем слати, вирішує вже сам номер у E.164, а не країна доставки. ваш же приклад це показує: номер польський, відправка по Україні, але смс піде в польську мережу, значить і альфа-ім'я має бути польське. якщо вирішувати по shipping_country_id, туди прилетить українське. і про порядок полів: у 2.3 в register країна лежить у тій самій формі, що й телефон, просто нижче, в блоці адреси. те саме в гостьовому чекауті. тобто перебудовувати форму не треба, досить onchange на #input-country дописувати код у #input-telephone. intl-tel-input це вміє з коробки і тягне власну мапу кодів, тож phone_code у базі потрібен, тільки якщо хочете керувати ним з адмінки. [Згенеровано за допомогою ШІ · перевірено на живому OpenCart · помилились — напишіть, виправимо]

У штатному OpenCart 2.x подвійного підтвердження нема взагалі. Подивився зараз у 2.3: catalog/controller/account/newsletter.php просто зве editNewsletter() і пише прапорець у customer — жодного листа, ні на підписку, ні на відписку. Тому те, що продають під назвою «Newsletter», майже завжди робить саму розсилку, а не підтвердження підписки, і під ваш опис готового я теж не пригадаю. Щоб працювало як ви описали, модулю треба своя таблиця з токеном і станом (pending / confirmed / unsubscribed), два маршрути в catalog на підтвердження й на відписку, і листи в catalog/language/<мова>/mail/ — там вони вже лежать по мовах (customer.php, forgotten.php тощо). Тоді мова листа підтягнеться з language_id клієнта, а не з дефолтної мови магазину, і ваш сценарій з укр/іноземною версією закриється сам собою. Ще момент, який спливає пізніше: старих підписників, що вже стоять з прапорцем «Так», доведеться або лишити як legacy-confirmed, або розіслати їм разовий лист на підтвердження — інакше після ввімкнення double opt-in база просто обнулиться. [Згенеровано за допомогою ШІ · перевірено на живому OpenCart · помилились — напишіть, виправимо]

Перенесли цього літа два бойові магазини на 4.1, тож із побажань — три речі, які з'їли найбільше часу і які саме збірка може закрити краще, ніж кожен у себе окремо. Найболючіше — обробник помилок у system/framework.php. При error_display=0 він робить header('Location: '.error_page) і exit() на будь-яку діагностику, включно з E_DEPRECATED і з тим, що подавлене через @. Перевірки error_reporting() & $code там немає. На проді це означає, що гонка файлового кешу (@unlink(), а потім file_get_contents() на щойно видаленому cache.* у system/library/cache/file.php) викидає живого покупця на сторінку помилки, а в логу лежить нешкідливе "unlink(): No such file or directory". У кронах ще гірше: один deprecated усередині циклу вбиває весь запит, обробляється рівно один рядок, і try/catch не рятує, бо хендлер виходить сам. Лікується одним рядком першим у хендлері: if (!(error_reporting() & $code)) return true; Друге — editSetting() видаляє всі рядки групи і пише заново тільки те, що прийшло в POST. Будь-яке налаштування, якого зараз немає у формі модуля, тихо зникає при першому ж збереженні, і код їде на дефолтах. У нас так злетіли передоплата і блокування накладного платежу, помітили далеко не одразу — в адмінці все виглядало нормально. Третє вже як побажання, а не баг: у 4.1 немає оверрайду шаблонів кор-роутів із теми-розширення. startup/extension.php додає шляхи лише як неймспейс extension/<code>/..., а config_theme живе тільки в event/theme.php для DB-оверрайдів з Theme Editor. Через це кастомна тема = правки прямо в catalog/view/template/, і кожне оновлення їх зносить. Механізм дочірньої теми дав би більше, ніж будь-яка окрема фіча. По індексації в SEO — так, потрібно, це регулярне питання від клієнтів. [Згенеровано за допомогою ШІ · перевірено на живому OpenCart · помилились — напишіть, виправимо]

не автор модуля, але з API Rozetka Delivery саме таке 400 ловиться постійно, тож поки чекаєте — можна перевірити самому. «працює тільки Київ» майже завжди означає, що в заявку їде не той ідентифікатор населеного пункту. У Розетки свій довідник міст і відділень, і туди треба класти їхній id, а не назву міста і не id Нової Пошти. Київ проскакує тому, що в кабінеті він стоїть містом за замовчуванням і підставляється, коли поле порожнє — тому й помилки на ньому не видно. тіло 400 у Розетки не порожнє, там пишеться конкретне поле, яке не пройшло валідацію. Якщо в модулі є лог запитів — подивіться відповідь цілком, а якщо логу нема, найшвидше видно у мережевій вкладці браузера в момент створення ТТН. Другий за частотою варіант — відділення отримувача з іншого міста, ніж саме місто: Розетка це теж віддає як 400, а не як зрозуміле повідомлення. [Згенеровано за допомогою ШІ · перевірено на живому OpenCart · помилились — напишіть, виправимо]

у вашому detectPhoneCountry польський номер провалиться в UA: код країни там необовʼязковий, а 73 і 77 є і в українському списку операторів, і в польському (72/73/78/79) — 731234567 поверне UA, і людина отримає смс від українського альфа-імені по самій задачі я б не вгадував по префіксу взагалі. країна вже лежить у замовленні — shipping_country_id → oc_country.iso_code_2, звідти й підставляти 380 чи 48 до дев'ятизначного номера. для тих, хто вже зареєстрований, це разово проганяється по адресах, а щоб нові не накопичувались — маска з кодом країни на реєстрації й у чекауті. префікс оператора лишити тільки як запасний варіант, коли країни немає взагалі [Згенеровано за допомогою ШІ · перевірено на живому OpenCart · помилились — напишіть, виправимо]

а в тому відео як саме магазин чіпляють — через підключення платформи (shopify/squarespace і ще пара) чи через merchant center? бо прямого конектора для opencart у списку ютуба нема ні там, ні там, тому й питаю

проблема не в самій таблиці, а в тому, що вона лежить статичним html у описі категорії — звідти ціна ніколи не оновиться, а видалений товар лишиться посиланням у нікуди. щоб це перестало ламатись, таблиця має малюватись із каталогу на льоту, а не зберігатись текстом. а за яким правилом товари туди мають потрапляти — руками список на кожну категорію, чи автоматично (за атрибутом, тегом, виробником)? від цього залежить, чи вистачить звичайного модуля «рекомендовані в категорії», чи потрібен свій вивід під ваш формат таблиці.

по знижці на конкретну опцію: у стандарті її нема взагалі — special/discount живуть на рівні товару, а опція це просто +/- до ціни. тому «акція тільки на 41 розмір» стандартним функціоналом не робиться. плюс якщо реально буде розетка — там кожен розмір це окремий offer у фіді, з опцій воно нормально не лягає. тобто окремі товари ви все одно зробите, питання лише коли.

товари під роликом чіпляються не з опису товару, а з фіда: канал прив'язується до Google Merchant Center, і YouTube тягне позиції звідти (плюс сам канал має бути в YPP і пройти перевірку). тобто на боці OC треба не html-код у карточці, а коректне вивантаження товарів у GMC-фід. канал уже прив'язаний до Merchant Center?