llSanik

Дякую) Бачив також кладовище "успіхів" або "я у мамки бізнесмен". Але аналізував з трохи з іншого боку. 1) Математика. Мало хто рахує точно, але багато хто рахує так як хочуть бачити успіх. Витрати, закупки і тд, все беруть по мінімум, дрібниці не враховують, і о, воно вигідне! Але своя математика тут не працює. 2) Якщо в ніші є конкуренти, треба мінімум робити так само(маркетинг, спосіб подачі товарі і тд). Це мінімум, але часто цього недостатньо і потрібно робити КРАЩЕ! (з "Краще" теж треба бути обережним). 3) Міф - я зробив сайт, завтра будуть заявки. Реклама, SEO(це взагалі мінімум пів року), SMM, це місяці щоб налаштувати корректно і воно працювало на бізнес в плюс. 4) Кожен місяць аналізувати що було зроблено по сайту, а чого не вистачає або що тягне вниз. 5) Обслуговування клієнтів. Кожна ніша має свої особливості. Як приклад ніколи, Ніколи, НІКОЛИ не садіть за телефон чоловіка, який заїкається, ПРОДАВАТИ ЖІНОЧУ НИЖНЮ БІЛИЗНУ! 6) Будь який бізнес це експеримент. Експеримент часу, експеримент можливостей, експеримент підходу. В одного воно йде, в іншого ні. Різні підходи, різний час, різний маркетинг, різні співробітники. Тому треба бути готовим до того що бізнес може не вистрілити. 7) Найуспішніші сайти - там де клієнт сам знає свою аудиторію, знає як замовляють, чому замовляють, коли замовляють, яку кількість замовляють. Ставить питання, приймає участь у конференціях маркетолог/розробник/дизайнер. (Він міг працювати в цій ніші місяцями або роками, щоб зрозуміти як це реально працює). 8) Бізнес це адаптація, кожен місяць щось може мінятись, податки, ринки, платоспроможність клієнтів, зміна постачальників , курси валют, логістика. Можна гарно стартанути, але план втриматись на 2-5 років провалити. 9) Сайт може бути успішним, гарно працювати, мати гарні позиції СЕО і конверсію реклами. Але внутрішні бізнес моделі і бізнес процеси просто будуть тягнути на дно. 10) І мабуть додам пунктик, який нещодавно для себе виявив. Коли бізнес стикається з труднощами, і замість преадаптації до ринку, часто починаються кардинальні зміни. Які приносить новий "Ефективний ТОП менеджер", який обіцяє золоті гори і кращі практики по типу компаній "Амазон". І те, що працювало роками, ламають за кілька місяців, а відповідальність за невдачі перекладають на співробітників. 11) Бізнес дисципліна. Якщо її немає, навіть не треба починати. Бо "засунув руку в кассу" сьогодні до тьолочок їду гуляти, а завтра перезакрию чи наторгую. Кожні витрати, кожні прибутки, потрібна бухгалтерія - Строга і дисциплінована. Кожні витрати, доходи контроль. Я не кажу бути жмотом і платити співробітникам меньше, але все це має рахуватись, жорстко і холодно.

Без гумору, реально було б почитати таку статтю в блозі) Розкажіть, якщо можете)

Поки кодекс не юзав, але чув що він наче може працювати з курсором. Можна спробувати дуже жорстко задати йому щось на зразок "Ось візард під курсор\клауд. Ознайомся і встанови під себе" і тицьнути йому папку. А після встановлення спитати що за проект і яки правила для нього є.

Повністю згоден з Вами) Opencart це не про VibeCoding. ШІ не замінить розробника в ніякому разі! Він може допомогти, але не більше, особливо на старих проектах, де багато легасі, опенкарт 1.5 і модель товарів має 7к+ строк, і щось зрозуміти можна тільки через Xdebug) ---- Ціль візарду познайомити з проектом ближче, зрозуміти з чим він працює, задати правила і рамки. Мій легасі опенкарт 3.0.2 якому десь років 8, там взагалі весь проект в варнінг зонах) ШІ виконує задачі строго по плану, який я спочатку перевіряю, узгоджую а потім все одно контролюю що там змінилось, і обов'язково тестую потік даних вхід\вихід.

Дякую за пораду з MCP, але зазвичай відкрито 3-4 PHPStorm проекту, часто проекти міняються. Тому MCP треба кожному свій порт назначати щоб працював корректно, і 3 місяці тому була проблема що в Claude він відвалювався посеред задач, тому його не юзаю(той що вбудований в PHPStorm). Структура бази повністю не лізе в ШІ, він звертається тільки за потреби, якщо вона є)

Согласен, ящик открыли они. Но раз вы взяли на себя труд написать гайд, который читают 4 подписчика и индексирует Google — давайте копнём глубже, не для срача, а чтобы тема была реально полезной. Потому что "WorkFlow і Review" — это не страховка, это благие намерения. Конкретика, которой не хватает: 1. Snapshot перед каждой сессией. Без вариантов. bash git checkout -b ai-$(date +%Y%m%d-%H%M) mysqldump --single-transaction --routines --triggers --quick db | gzip > backup-pre-ai.sql.gz tar czf files-pre-ai.tar.gz catalog/ admin/ system/ Без этого ваш тезис "Кожна нова сессія = нова задача" — это русская рулетка с пустым барабаном до первого выстрела. И к слову, "в опенкарті git рідко використовую" — это и есть та самая базовая страховка, которой не хватает. Не "иногда под Laravel", а всегда, везде, в каждом проекте. 2. Version-lock контекст в каждой сессии. Ваш getMap.php — это снимок схемы. Через две недели после установки трёх модулей мапинг устаревает, и ШІ планирует UPDATE по полю, которое уже переименовано или удалено. В каждую новую сессию AI должен получать актуальный срез: версию ocStore (VERSION константа) версию PHP, MySQL, MariaDB SELECT code, version FROM oc_extension — список модулей с версиями SHOW CREATE TABLE по ключевым таблицам на момент сессии diff core-файлов против эталонного ocStore (cmp с чистой сборкой) Иначе AI работает с фантомной схемой и пишет код под БД, которой уже нет. 3. Инструментальная инконсистентность Клода. Один и тот же рефакторинг Claude сегодня делает через str_replace, завтра через sed, послезавтра через Python с re.sub, а в среду через heredoc в bash. Каждый из этих методов по-разному ведёт себя с: BOM в файлах (а он есть в некоторых install/upgrade-скриптах) CRLF vs LF (Windows-разработчик + Linux-сервер = классика факапов) многобайтными кириллическими комментариями и строками Лекарство — жёсткий system prompt с одним разрешённым методом редактирования + pre-commit hook на проверку кодировки/EOL/BOM. 4. migrations.php как закомментированный файл — это запись в один конец. Где down()? Где идемпотентность (что будет, если разработчик случайно прогонит ADD COLUMN дважды)? Где гарантированный порядок применения, если сессий было пять? Это не миграции, это TODO-лист. Для пет-проекта норм, для коммерческого магазина — недопустимо. Минимум — timestamp в имени, IF NOT EXISTS где возможно, отдельный rollback-блок. 5. "Review" — это что конкретно? Глазами по diff на 800 строк? Минимальный чек-лист: phpstan analyse --level=5 на изменённые файлы semgrep --config=p/php + custom rules для OpenCart: поиск eval, отключения CSRF-токенов, file_get_contents на внешние URL, новых записей в oc_user, новых SQL-функций проверка, что все правки прошли через OCMOD/install.xml, а не в core-файлы (иначе следующее обновление ocStore их затрёт) diff списка таблиц/колонок до и после сессии — AI мог по-тихому создать oc_helper_* для своих нужд 6. Сценарий, который вы пока не словили. AI: "Сейчас оптимизирую oc_product — добавлю составной индекс". Выполняет ALTER TABLE через migrations.php. На 2 млн товаров. На проде. Без понимания, что у клиента InnoDB row format COMPACT и таблица заблокируется на 40 минут на запись. Сайт лёг, заказы не пишутся. Ваше "ШІ доступу до БД не даю" тут не спасает — разработчик скопировал SQL из migrations.php в phpMyAdmin не подумав. Резюме: ваш Wizard — нормальная стартовая точка для джунов, которые хотят попробовать ШІ под ocStore. Но для коммерческой работы это 1 пункт из 10 инженерного чек-листа. Остальные 9 — та самая дисциплина, которую AI не заменяет, а усиливает требования к ней. Без обид — я полгода в этой же теме, у меня тоже есть папка факапов. После третьего начал страховаться до сессии, а не после. P.S. И ещё момент: для коммерческих магазинов все правки от AI должны идти через OCMOD/install.xml, а не в catalog/controller/... напрямую. Иначе апдейт ocStore выкосит работу AI за полгода. У вас в гайде этот момент опущен. О) Дякую за розгорнуту і чесну критику) Це те що хотілось) Але Ваш підхід більш автоматизований, мій більш ручний) І знову таки, моє рішення подружити ШІ з опенкартом, а не автоматизувати все і перестраховуватись абсолютно від більшості) Як буде вільний час, більш детально розберу і можливо щось спробую примінити з описаного Вами вище) P.S. міграції це просто тестовий файлик тут. В проектах в мене своє рішення накатив\відкатив ближче до ларавелу. P.S2. є бажання дати своєму бітовому рабу написати хоч щось, але всеж це форум а не ТГ)

Цей ящик пандори відкрив не я а OpenAi + Antropic =) Я лише витратив пів року на вивчення і поступову інтеграцію в свій воркфлоу, і мабуть місяць психозу, щоб підібрати робочий варіант, як з ним працювати більш корректно) Вже під все(або майже все) є системні промти, React, Node, Android/Ios, Laravel, WordPress, Drupal і прости господи Joomla. А для деяких речей взагалі збірки піплайн з воркерами, автотестуванням, автодеплоєм і тд). Чого не спробувати зробити під опенкарт? Може комусь буде корисно) В будь якому випадку, під комерційні проекти(а особливо під існуючі робочі проекти) потрібен контроль досвідченого розробника, який розуміє що робить ШІ. Так, Ші може дропнути базу, разом з бекап сервером) Або при написанні Update/Delete промахнутись і тд. В самого є папчка факапів прикладів) Але якщо його вивчати, і не впадати в ШІ істерію і бездумний ваб-кодинг можна: - Підвищити якість свого коду або вивчити нові підходи до розробки(що ще круто, два різні підходи можна протестити за 40 хвилин замість 2х днів). - Зменшити кількість годин на рутинні речі (наприклад інтерфейс в адмін панелі штапмує швидко, зручно і в потрібній стилістиці, тільки кажеш де що підправити). - Огляд існуючого коду, пошук вразливостей, швидкі рефактор - зміни назв функцій і тд. - І приємний бонус чудово допомагає розібрати свій говнокод який писався більше 6 років тому п'яткою) Це не золоте яблуко, і не рішення всіх проблем. Але в більшості випадків, для девів, допоможе і прискорить)

Дякую за застереження, але таких факапів не було поки що) Кожна нова сессія = нова задача. Для кожної задачі контрольований WorkFlow і Review Якщо ви про гіт, в опенкарті його рідко використовую, частіше під ларавел, але то вже інша історія і методи/підходи до розробки)

Привіт! Вирішив поділитись як я приловчився зручно працювати з ШІ. Можливо комусь буде корисно, бо хтось поділиться своїми порадами) Вирішив я подружити опенкарт з такими ШІ як ClaudeCode і Cursor які активно використовую. І зробив такий ось Wizard - задача якого менше косячити саме у Вашому Опенкарті. https://github.com/lSanik/.oc-ai-install Як це працює: 1) Закидуємо папку .ai-oc-install в корінь опенкарту там де admin,catalog,images,system 2) Виконуємо на проді .ai-oc-install/getMap.php і закидуємо папку .ai-oc-install/map до нас в проект(суть така, ви отримаєте мапінг БД для ШІ, якщо ваша середа Remote (Shared/VPS) тоді треба перенести до себе в локальну середу розробки). 3) Кидаємо Cursor або ClaudeCode файлик ai-oc-install.md 4) Відповідаємо на питання, знайомимо з проектом, тонкостями, які критичні зони, правки, нюанси саме Вашого проекту. 5) Все, тепер ШІ добре знає Ваш проект) Суть в тому що в /.oc-ai-install є загальні правила, ШІ генерує свої файли в папках .claude/.cursor з посиланням і детальним описом Вашого проекту. А загальні правила можуть динамічно мінятись, оновлюватись з гіта. Також є мапінг, список загальних таблиць + детальна DLL кожної таблиці, які поля і їх типи з обмеженнями. ---------------------- Я зібрав різні правила із косяків ШІ які часто були під opencart\ocstore 3.х, а також задав обмеження для роботи з контролерами, моделями, темплейтами, адмінкою, css,jss Тепер ШІ знає опенкарт, працює в більш адекватних рамках і не намагається грузити моделі через include 'catalog/model....' =) Також ШІ добре орієнтується в мапінгу БД і знає що де і як міняли БД плагіни або програмісти. ---------------------- Я мінімум пишу код руцями. PHPStorm(Ревью, FTP,GIT, DB) + в штормі є офіційний плагін ClaudeCode. Cursor юзаю рідко, але там токени просто не вбиваємі, хоча помилок і виправлень більше. Для крупних задач потребую від ШІ створення детального плану(в інсталері описано /plan/ папка і як з нею працювати, також про папку /done/ як виконані задачі), який потім корегується і запускається на виконання. Всі зміни в базу данних пишуться в файл тектом запити в закоментований файл migrations.php, звідки зручно взяти і вставити в phpMyadmin (ШІ доступ до БД не даю, навіть якщо дев). Загалом задачі які раніше займали 100 годин реально зробити за 10 за допомогою ШІ) За пів року протестував на ~10 інтернет магазинах. Навіть на важкому легасі працює дуже задовільно) ------------------- Є короткі загальні промти які користуюсь для клауд/курсору в загальному побуті, підходить і під Laravel. claude-global-instructions-light.txt cursor-global-instructions-light.txt ------------------- І головне, це підходить тільки для програмістів. Так як ШІ завжди робить унікальні перли, які потрібно обов'язково контролювати.

Так, була тоді тільки одна проблема, недостаток знань і вітер в голові) Що в принципі мабуть буде і актуально через 10 років сказати і про теперішній час.

Маю такий свій приклад. Ще ~12 років тому, коли з другом робили стартап і свій інтернет магазин а бюджету на цей стартап було 0.... Хоч стартап і прогорів(привіт 2014) Я вивчив мову програмування PHP і тепер сам роблю сайти, архітектури, застосунки) Доречі сайт вийшов гарний, нулед шаблон lexus pavothemes під opencart 1.5 . Але довелося вивчити що таке Back-Door і чому не варто так робити)

Може комусь колись буде корисно, або хтось захоче зробити свій плагін: ---- Окремий класс який має доступ до регістру опенкарту. Має свій конфіг. Він перевіряє чи приймає контролер участь в аб тестах чи ні <?php $tests= [ 'catalog/product/index'=>[ 'variant_a'=>'view/tests/catalog/product_a.twig', 'variant_b'=>'view/tests/catalog/product_b.twig', 'variant_c'=>'view/tests/catalog/product_c.twig', 'default'=>'view/tests/catalog/product.twig', ], ]; ---- Також класс фіксує кукіс, робить органічний розподіл по тестувальникам (у мене був трохи підкручений рандум + кеш розподіл, погрішність складала десь 5%). Контролюючий класс підключав бібліотеку на JS яка слала ціль в гугл аналітику(брала данні з кукісів) до кого належить цей користувач (variat_a,variant_b і тд). ---- view на видачі приймає сигнал чи є темплейт в тесті, якщо так підміняв його. ============== - По суті ми в гугл аналітиці могли бачити з яким темплейтом проходив візит. - Хто скільки додав в кошик з тим чи іншим варіантом. Також загальні конверсії і тд. - Я ще додатково трекав час на сторінці (bounce_30s,bounce_55s) щоб додатково аналізувати хто скільки часу реально був(для деяких тестів) Якщо на сайті стоїть розширена гугл аналітика, тоді все можна побачити у своїх кастомних звітах. Брав від 1000 до 10.000 користувачів на тест. Для прикладу я тестував дизайн варіацій товарів. Зменшення відмов кошика. Цікавість контенту(тут додавав додаткову позначку по скролу до певного блоку). -------------------------- В принципі метод був легкий. Назва тесту, окремий темплейт, свій звіт в гугл аналітиці. Бачиш все як на долоні. Клієнту давав гіпотези, отримував добро на тести, при досягненні певної кількості тестувальників робив звіт, і залишав найуспішнішу версію. Так по суті теж можна підміняти і CSS/JS файли якщо це потрібно для тесту. Деякі тести можна проводити паралельно. Єдиний мінус зараз, дуже багато AD-block через що бажано робити трекінг GoogleAnalytics через бекенд.

Щоб Вам радив(якщо не багато кастомного коду, або є можливість): 1) Створити сайт клон(окремо зібрати пак плагінів + шаблон), перенести туди всю інформацію по базі даних. Тобто так, фактично зробити новий сайт але з тим же набором плагінів. 2) Закрити адмінку веб авторизацією. Тобто весь шлях /admin/ (можна одразу, деякі хостинги дозволяють це робити з панелі адміністрації) 3) Доступи ФТП, доступи БД, Доступи адмінку завжди і інші доступи, пароль завжди генератор мінімум 8 кракозябр (великі, малі, цифри, спецзнаки), ніяких Admin123 (можна зараз змінити і після апдейту ще раз) 4) Всі плагіни обов'язково ліцензійні. Навіть незначні, прості з одного погляду. Завжди ставити ліцензію (це не гарантія від взлому самого плагіну, але вірогідність дірки одразу в 10 разів меньша). 5) Вірно налаштовані ролі і права користувачів (наприклад встановлення плагінів, чи налаштування стора для менеджерів) 6) Доступ в адмінку по двохфактору (СМС/Google Auth) з прив'язкою до IP сесії. (компьютер користувача адмінки може теж бути заражений). ----------- Навіть якщо ви закриєте старі дірки, навіть якщо візьмете бекап за 3 місяці - півроку, ви не зможете точно відслідкувати чи були вже там шкідники чи ні. Отже якщо Ваш бізнес дозволяє, краще переробіть сайт, але ні в якому разі не змішуйте хостинг розробки з старим сайтом. Як буде готовий новий сайт, все старе видалити повністю, і потім тільки скопіювати нове. (також змінити ФТП + Базу + Паролі Хостинг панелей). ------------ При частих зломах гугл дійсно може помітити Сайт як шкідливий, а відновлення СЕО позицій можуть бути дуже довгими і болісними. Антивіруси, відстеження не дадуть(є приклад коду який майже не можливо відстежити, а при знаннях CMS і можливостях сучасних штучних інтелектів це анріал). Якщо проект був скомпроментований не арабськими мамкиними хацкерами, бекдори можна пів року чистити, і потім все-одно залишитись з дірками.

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

Вітаю! Я не впевненний чи сюди треба писати з данного приводу, але знайшов невеликий баг. Мені потрібно було отримати список мультимовних посилань в одній сессії, а для цього вирішив пропустити detectLanguage за допомогою існуючої перевірки $this->ajax і зіштовхнувся з такою проблемою https://github.com/ocStore/ocStore/blob/3.0.x.x/upload/system/library/seopro.php В 30 строці маємо виклик $this->detectAjax(); Але в самому методі: private function detectAjax () { if (isset($this->request->server['HTTP_X_REQUESTED_WITH']) && strtolower($this->request->server['HTTP_X_REQUESTED_WITH']) == 'xmlhttprequest') $this->ajax = true; } Ми маємо отримати $this->request який за замовченням ще пустий, так як деклариться в 37 строці. Я так розумію по логіці воно повинно спочатку задекларити request а вже потім перевірка на HTTP_X_REQUESTED_WITH ?)