Leaderboard

Более детально ответил в личку.

Коли хтось запитує за знижку на мої модулі я надаю купон в особистих повідомленнях

так, просто докинути на баланс чи карту, почекати хвилин 5 (бо воно там постійно з затримкою гроші заходять) і можна юзати.. на рахунок 4 баксів після реєстрації чесно кажучі як зараз я хз... там раніше давно було теж що давали безкоштовні трохи гроші, але були дуже незручні ліміти, вони для такої безкоштовної демонстрації давали всього 3 запити на хвилину і користуватись з таким лімітом це нереально, тому абсолютно всі одразу закидують пару баксів на акаунт - цього може вистачити аж на 500+ товарів ато і тисячу (залежно від об*єму контента), а також знімає ліміти використання.

Ці купони дают автори напряму. Якщо ви купували шаблони OCTemplates, то в них у кабінеті ціла колекція купонів. Або ви можете написати у приват автору і попросити собі купон.

так, то просто ліміти або неоплачено або баланс закінчився + зараз вони з 8 березня перевели всіх на систему передоплати, тобто раніше можна було користуватися і раз на місяць приходив рахунок, а зараз - треба передчасно закинути якісь пару баксів на баланс. і судячи з усього це саме ваш випадок)

Можу запропонувати вам даний модуль

Бред Частковий бред Деякі вказані модулі мають інтерес, але не є обов'язковими

UPDATE Платон наконец-то забанили мудаков Считаю правильным убрать упоминания из статьи (они не просили)

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

Теж згідний що облік товару, взаєморозрахунки з контагентами має відбуватися в обліковій системі, а не в самому опенкарті. Але якщо підходити з точки погляду, що ви вчора торгували на базарі з записником, а потім вирішили освоїти інтернет, то для людини яка починає цей шлях, освоювати кілька програм, а вони ще і платні у своїй більшості, ой як не легко, і у 80% людей скажуть "та нахрен воно надо". Повинна бути проста система, зі зрозумілим інтерфейсом, де буде зразу все і зразу що потрібно для старту, а не 2-4 окремих софта. Бо сьогодні витрати часу на вивчення і освоєння певної кількості програм, дуже сильно загоняє у депресію. Тому люди сидять на пром.юа, хорошопі, тільда, і інших конструкторах, які за певну суму за рік часу, позбавляють геморою та економлять час.

Ще трохи треба прикрутити модулів до OpenCart 4, i буде більше розуміння чого бракує для мінімальної CRM. У свій час встиг поюзати Бітрікс, так і не зрозумів за що хочуть грошей. Постійно потрібно щось виправляти, після оновлення те що працювало, перестає працювати, і пішло поїхало все по новій. Сам по собі OpenCart містить багато данних, інформацію про покупця, адресу доставку, інформацію про товар, опції, і відповідно ділитися безкоштовно цими даними з "платними хмарними рішеннями" у більшості людей немає бажання. Наступне не відомо де і коли спливе "чутлива інформація" з хмарної CRM, що мені особисто не сильно подобається про це навіть думати.

а то я мабуть 10 років з якимось іншим опенкартом працюю))) при використанні модифікаторів конфлікти будуть завжди! Причому їх буде дуже багато. Бо модифікатор змінює код самого опенкарту. І питання тут не у тому правильно написаний той модифікатор чи ні, конфлікти будуть у будь-якому випадку бо модулі пишуть різні розробники і один взагалі нічого не знає і не може знати що у голові у іншого... Я пишу свій модуль і прив'язуюся в модифікаторі до якогось конкретного куска коду в стандартному опенкарті, добавляю свій код після нього. І все працює, бо у стандартному опенкарті цей код є. А до мене якийсь інший розробник змінив цей кусок коду на інший чи дописав щось своє, бо для його модуля саме це треба було зробити, і що буде? мій модуль вже не знайде потрібний код та не добавить свій код після нього. І що це як не конфлікт? маємо помилку і або один модуль не буде працювати або два. Або і ще гірше - два модуля будуть працювати і жодних помилок не буде, але логіка роботи зміниться і наприклад десь у корзині якась ціна буде нараховуватися неправильно.. і подібні помилки взагалі дуже тяжко виправляти бо все вроді працює і в логах чисто.. Так ще не розповідайте басні, що ніяких конфліктів не буде, якщо у магазині встановлено декілька десятків модулів (практично у кожному магазині так) і кожен із модулів вносить десятки змін у код самого опенкарту + ще встановлена якась тема тиду джорнал яка сама по собі переписує половину опенкарту і в результаті отримуємо опенкарт, встановити якийсь новий модуль на який ще те задоволення.. сидиш і тупо виправляєш конфлікти бо все не так як треба.

1. я вам вище написав як працюють події - там все дуже просто, після виконання якоїсь події запускається якийсь метод модуля, все. Що тут складного? Якби була нормальна документація зі всіма подіями, до яких можна підключитися та реальні приклади роботи з ними то освоїти події можна максимум за 1 день це якщо комусь ну дуже тяжко дається щось нове, а так то їх можна вивчити за півгодини. 2. до чого нас довела "простота" опенкарту ми всі вже прекрасно бачимо, до ручки вже дійшли. Далі по суті 2 шляхи - або почати щось змінювати вже зараз (точніше це потрібно було робити ще декілька років тому) або весь опенкарт просто приречений, він і надалі буде занепадати поки не загнеться остаточно.. нажаль. Бо у 2023 році писати SQL запити вручну а потім ще й змінювати це все за допомогою модифікаторів це.. гм.. пц. короче. я ж ніде не написав, що опенкарт потрібно перетворити у престашоп чи вукомерс, до речі трохи працював і з тим і з тим і код там просто жесть.. Задача якраз таки залишити всю простоту опенкарта при цього добавити функціоналу та зменшити к-сть конфліктів. Якщо замість sql запиту на півсторінки буде один зрозумілий $sql->select('*')->where('...')... при чому не потрібно буде вручну писати весь sql код, не потрібно буде скрізь писати префікс таблиці, не потрібно буде екранувати всі дані (бо конструктор це все зробить за тебе) і саме головне будь-який sql на сайті можна буде дуже легко змінити при чому без конфліктів з другими модулями у майбутньому то де тут ускладнення? Як на мене то все навпаки стане простішим. І при чому тут престашоп? У нас буде той самий опенкат, тільки з яким працювати буде в рази комфортніше і к-сть конфліктів буде в десятки разів меншою, якщо все буде працювати через події. Тут якраз таки навпаки ми отримаємо велику перевагу бо по якості та функціоналу опенкарт стане багато у чому не гіршим за конкурентів, а у простоті освоєння в рази простішим. А якщо тупо викинути події бо комусь вони знаються надто складними та повернутися назад до модифікаторів - то це тупо шлях в нікуди і якщо років 10-15 тому на це ще можна було якось дивитися то зараз, то у 23 році це жесть, це архітектура, яка вже мінімум років 10 як застаріла.

Якраз Opencart простий в освоєнні та швидкий тому, що в ньому по суті немає івентів і додаткових рівнів абстракцій, а просто код, який читаєш, розумієш і міняєш. Порівняйте час освоєння розробки для Opencart та Prestashop/WooCommerce.

Ух, яку тему пропустив)) Якщо ще не пізно то вискажу свою думку, яку вже не раз висловлював тут. Взагалі такий проект потрібно починати ніяк не із стилів кодування, це якраз можна зробити і потім. Головне - це концепція, що у даної збірки буде такого, що буде якісно відрізняти її від теперіншього опенкарту, який докотився все "до ручки".. І зробити це дуже не складно - за основу беремо недоліки опенкарту (які ми всі дуже добре знаємо) та просто їх виправляємо, залишивши при цьому всі переваги. А не просто переписати все на статичні класи і все, це не вирішить жодних проблем. Це те саме що по суті робить сам Даніел - замість того щоб виправляти глобальні проблеми в коді добавляє нові шаблонізатори та змінює версії бутстрапу. Як на мене це всеодно, що починати ремонт у старій хрущовці не з заміни сантехніки, електрики, штукатурки итд. а з переклеювання шпалер та вкладання нової плитки в у санвузлі, яку будуть ложити на старі гнилі та іржаві труби та стару штукатурку - зовні може буде і гарно, але не це ж пц повний.. Які переваги у опенкарта: 1. Немала популярність, вона знижується, але на ньому все ще працює дуже багато сайтів 2. Дуже багато розробників які з ним працюють і на яких по суті все і тримається і які повинні бути дуууже зацікавлені щоб опенкарт розвивався і далі 3. Сам двіжок дуже простий в освоєнні та роботі та дуже швидкий, я бачив магазини на опенкарти де було більше мільйона товарів! 4. Величезна к-сть модулів, плагінів та тем 5. (можете доповнити) Недоліки (і їх також вистачає) 1. За розвиток всього двіжка відповідає аж одна людина, яка робить виключно те, що сама вважає за необхідне. На мою думку у Даніела просто не має необхідного технічного досвіду, щоб зробити з опенкарта нормальний двіжок. З нього б вийшов дуже гарний та відповідальний міддл розробник, який би працював з вже спроектованою архітектурою, але спроектувати велику систему самостійно він тупо не може.. З самого початку у мене таке враження що основу двіжка він десь злизав з якогось фреймворка (мені код дуже нагадує перші версії codeigniter) а далі вона взагалі не розвивається. Тобто сам зробити не може, а іншим не дає.. 2. Дуже жахливе відношення Даніела до інших розробників, коли для кожної нової мінорної версії двіжка потрібно писати нову версію модуля, бо там змінилася якась дрібниця типу створення посилань чи ще щось. Коли для кожного модуля потрібно писати гору html коду а потім його щей переписувати під кожну нову версію твіга чи бутстрапа. Коли за 15 років існування двіжка все ще немає нормальної системи розширень. Коли будь-які пропозиції та побажання щось виправити тупо ігноруються.. на і так дал. Тобто, розробників на яких все тримається тупо посилають подалі з їхніми проблеми. Писав про це ось тут 3. Примітивне ядро самого двіжка. Всі говорять, що опенкарт простий і це його плюс, ні, він, не простий - він примітивний і це не плюс, а насправді величезний мінус. І те, де опенкарт опинився зараз це якраз і результат цього. Відсутність нормальної системи розширень. Гарна система розширень це по суті основа, фундамент любого двіжка. Бо навіть якщо там буде дуууже примітивний функціонал, то маючи гарну систему розширень інші розробники самі все допишуть та щей зароблять на цьому продаючи різні розширення. Я вважаю і багато розробників цю думку підтримують що система модифікацій vqmod/ocmod це дійсно зло. Цей підхід суперечить багатьом фундаментальним принципам програмування. Наприклад принципи SOLID, другий принцип O - принцип відкритості-закритості, який говорить що програмі рішення повинні бути відкриті для розширень та закриті для модифікацій коду, тобто всі розширення повинні робитися через інструменти, які при цьому не змінюють програмний код! В опенкарті ж це не просто робитися як виключення, на цьому побудована вся! система розширень самого двіжка.. Це просто вибух мозку для мене бо це породжує просто нереальну кількість конфліктів та проблем. І в результаті з цього двіжка втікають як самі розробники, так і прості користувачі, яким постійно приходиться стикатися та виправляти якісь помилки. Для чого їм це якщо зараз є десятки сервісів, де вони можуть в пару кліків мишки створити свій магазин взагалі без знань програмування, і не просто створити, але і розширити його модулями та темами. І при цьому їм не прийдеться виправляти жодної помилки! І це на мою думку головна проблема опенкарту! (як мінімум одна із головних) і її потрібно вирішувати в першу чергу, без цього просто неможливо створити нічого якісно кращого за теперішній опенкарт. Як це можна виправити? Добавити систему Подій (Events) Вони взагалі не складні! Вся суть у тому, що коли у системі настає якась подія то до чи після неї запускається якась функція модуля. Все. Що тут складного? Просто Даніел спочатку добавив події без жодної документації, потім постійно у кожній новій версії їх змінював змінюючи і синтаксис і самі події, а потім взагалі забрав модифікатори, коли за допомогою подій не можна було вирішити великої к-сті необхідних задач.. і що в такій ситуації робити розробникам?? Самі події це дуже простий та елегантний концепт, це готовий патерн програмування, який використовується величезною к-сть інших двіжків, фреймворків та систем ітд. І скрізь це працює. Так чому ж це не працює в опенкарті? Тому що для впровадження цього інструменту мало створити клас Event.. тут потрібно змінювати сам двіжок, щоб він їх у повній мірі підтримував. Щоб через Events можна було вирішити не половину всіх можливих задач, а максимально набализитися до 100%, покриваючи фактично всі можливі задачі. Як це можна зробити не буду повторюватися, писав тут Ось вам готовий варіант двіжка, концепт, який буде якісно відрізнятися від існуючого опенкарта (а не тупо скопіює всі його проблеми не вирішивши їх, замінивши об'єкти на статичні класи..) і на який я б наприклад з радістю перейшов замість сьогоднішнього опенкарту, який вже якщо често в печінках сидить через свої баги, конфлікти, помилки та жахливе ставленням Даніела до всіх розробників.