---

OpenCart

---

Tohle je systém na e-commerce (průměrný e-shop). Výhoda je v lehkotonážnosti, takže funguje i tam, kde bych molochy jako Magento fakt nerozjížděl. Běží to na PHP5/MySQL, chce to průměrný stroj na část s kódem a lepší stroj na část s databází. Tím dobré zprávy končí. Dál už budou ne vždy pozitivní postřehy z mého zápasu s ním. Pro umisťování prvků použiji terminologii Joomly, protože mi přijde poměrně rozumná (budu s ohledem na ní i předělávat dokumentaci KWCMS).

Celý OpenCart je napsaný s ohledem na pozicování modulů v šabloně komponenty. Základní informací tedy je, jaká komponenta to je a kde v ní je ten modul. V jedničce si tyto informace nosí přímo správa komponenty, ve dvojce je přemístěna vedle na hromadu do extra pluginu. V obou verzích má hezky rozdělenou strukturu pro kontroléry, modely, pohledy a překlady, ale samotný kód toho nijak slušně nevyužívá.

• Pro programátora je rozdíl mezi jedničkou a dvojkou hlavně v umístění doprav a plateb a způsobu, jakým se vypisují data do šablon. Rozumně objektová ale opravdu není ani jedna verze.
• Hlavním tahounem celé aplikace jsou kontroléry a ne modely, co mají reprezentovat databázové vztahy, se kterými se reálně pracuje. To ale také znamená nakynutý kontrolér, kde 1000 řádků není nic neobvyklého.
• Autorovi rozhodně mnoho neříká "rozděl a panuj" - více menších funkcí, které spolu interagují a místo toho vše cpe do sady IFů v rámci kontroléru. Výsledkem je nateklá procedura, ve které se téměř nikdo nevyzná.
• Dalším problémem pro mne byla neznalost elementů (kousků šablon s opakovaně využitým kódem) - suplovaly to napozicované moduly, což je často neoptimální.
• Samostatnou kategorií je práce s překlady. Informace o jazykové mutaci (ba i o měně) je v defaultu přepínána pomocí odeslání formuláře. Samotný překlad nestačí jenom nadefinovat v šabloně a v překladech, ale je třeba ho ještě přidat v patřičné proceduře kontroléru (a pokud není, tak inicializovat). Ve chvíli, kdy je tam těch textů trochu víc, tak to žere řádky. Je ale pravda, že externě inicializovaný překlad je vhodný pro vyplňování mailů, které shop posílá.
• O užití dědičnosti přímo řvou vypisování šablon (pozic pro kontroléry hlavičky, patičky a jiných zbytků) a vypisování chybové stránky. Protože pak se otočí jeden IF a navrátí se funkce s výpisem šablony chybové stránky a na závěr se zase dá návrat se šablonou daného pluginu. Naopak do ní nějaký "expert" přihodí javascript a je opravdu hotovo.
• U překladů se dá dále diskutovat o kategorizování podle modelů. Jde o to, že třeba překlad "Doručovací adresa" je zároveň ve 4 souborech. Místo jednoho.
• Ač z EU, tak kontroly DPH a IČ je třeba dohackovat ručně. Toho se týká validace DPH (daň pro validní zahraničí spadne na 0).
• Daně ve vanilkách neumožňují nastavit i nulovou tím, že prostě nastavím daň na 0. A vůbec - chce to zlepšit mechanizmus na zobrazení osvobození od daní (paradoxně to dle zákonů jde)...
• Autor dotazů do databáze asi nikdy neslyšel o operátoru 'IN ()'. Spousta výčtů je tak komplikovaně ošetřitelná. Hodí se ale třeba i k prohrabávání podkategorií.
• Podkategorie se vyznačují neexistující rekurzí, takže podporují jen ty natvrdo udělané 2 úrovně.
• Kategoriím dále chybí umožnění výpisu a počítání produktů v podřazených kategoriích v těch nadřazených.
• Některé texty jako jsou třeba platby kartou se ukládají natvrdo k objednávce. To je fuj, protože zobrazující nemusí mít stejnou jazykovou mutaci (nakopala mne takhle němčina).

Teď fatální chyby:

• Jazyk faktury je volen podle státu, který má nastavený správce. Ne podle státu, který má nastavený objednávající.
• Zákaznické adresy jsou postavené vůbec podivně. Místo aby se připojily pomocí svého ID k objednávce, jsou tam překopírovány. To zanáší databázi opakovaným hnojem.
• Ceny se u produktů vrací jako jeden string, což je fajn jenom do chvíle, kdy je třeba vybírat, co že se to má zobrazovat (s/bez DPH; se slevou/bez slevy). Takže je vracet jako čísla jak bez daní, tak s nimi, protože některé státy požadují jedno, jiné obojí a kdo to má furt přepisovat....
• Vyjímky v kódu jsou asi sprosté slovo. Proč ale nemohou nastávat a následně na ně reagovat zobrazením chybové stránky s připravenou hláškou a vzadu logem?
• Nastavení SSH se s SSH spojením slušně nechová - proč neumí na zabezpečeném spoji připravené linky (které nikdo nezadal "natvrdo") prefixovat? Vůbec všechny prefixovat nebo rovnou generovat knihovnou, jinak je v tom jenom bordel.
• Maily odchází podle jazyka odesílatele, což je v případě odeslání z adminu špatně. Příjemce si nepočte.
• Na počítání tam má být nějaká abstrakce, protože slušný e-shop zná věci jako BCMATH. A až když to nezná server, má být možnost fallbacku na běžné provedení.
• Zaokrouhlování cen bez DPH a s DPH je v ČR rozdílné. První se ukazuje na 4 desetinná místa, druhé na 2. A navrch konečná cena se zaokrouhluje bez desetinných míst. Tohle Opencart taky nezná.
• Vývoj a testování přes PHPUnit to taky nikdy nevidělo.

Co tam máme dál:

• Filtry... Jsou v základu docela hezné, jenže jsou díky svému provedení jen s obtížemi rozšiřitelné.
• Dále nutnost přiřazovat každý filtr kategorii extra je taky na přeshubu. Proč tam nejde vložit celá skupina filtrů? Když je potřeba je vypsat na více kousků, tak to není jak odlovit. Násobná sranda začne, když si někdo poručí, že chce filtrovat "zvláštně", tedy podle atributů (zažil jsem). V tu chvíli filtry přestávají stačit, protože správce bude líný a nedodá i hodnotu z filtru. A u číselných hodnot pro rozsah s tímto ani počítat nelze.
• Dále tomu nic neříká využití indexů pole, ve kterých se dají krásně tahat unikátní klíče.
• Jiná storry je seo, neboli hezké url. Je třeba je obejít přes externí plugin, který nageneruje metatagy a pak následně další plugin zaktivuje přesměrovávání. Opět je to o neexistující knihovně.
• Další zádrhel jsou u linků historické adresy, protože nejsou nikde skladovány a tak pro ně není jak vyrobit přesměrování.
• Díru o přístupu k funkcím kontroléru (včetně konstruktoru), které vývojář nezazdil aspoň pomocí protected radši neřeším.
• To, že vyžaduje na kdejakou pitomost modul a pozici a na obojí jak kontrolér, tak pohled, je též silně frustrující. Díky tomu vzniká roztahávání HTML kódu a následně nemožnost hlídat uzavření tagů taktéž nepotěší.
• Všechny moduly se co se cesty týče chovají jako cakeovské (2.x) pluginy, takže i úvodní stránka je vlastně jenom plugin.
• Tokeny v administraci jsou fajn jen do chvíle, kdy uživatel využije více panelů prohlížeče a je potřeba třeba srovnat hodnoty dvou produktů (resp. kde to kvůli rozdílnosti drhne) - suše to při překliku ve špatném okně odhlásí.
• Naprosto prazvláštní přístup je v procesu tvorby objednávky - objednávka se zapisuje ještě před potvrzením. Jediný případ, kdy je toto chování žádoucí, je snad jenom volání platební brány, kde je třeba předat unikátní platební řetězec.
• Na druhou stranu to znamená zjednodušit ukládání číslování pokusů na platební brány a tím i následné implementace validací plateb, a potřeby ukládat datum platby.
• Díky tomu, že celý shop nemá části oddělené skrz API, nejde tam rozumně vyrobit adaptér, kterým by se bavil s externími systémy.
• I produkty v košíku jsou držené ne jako obsah tabulky, ale jako serializovaný řetězec u uživatele.
• Struktury v databázi jsou také trochu divné. Normalizace tomu vůbec nic neříká.
• Nakonec - výrazně postrádá dokumentaci zdrojáku. Dokumentace na stránkách je pouze prudce obecná.

Co zlepšit (budu se opakovat, je to z druhého souboru):

• Platby a dopravy - u obojího umožnit multiple na více oblastí, než je jenom jedna nebo vše.
• Kombinace doprav a plateb - nějaká platba je jen pro vybrané dopravy - obzvlášť časté jako dobírka a pošta.
• Dědičnosti a rozhraní - je vhod, aby se doprava a platba dala zaktivovat až tehdy, pokud má vše potřebné v rozhraní.
• Dopravy - závislost na daňové třídě, protože jsou i požadavky na dopravu chemie, která je z podstaty věci dražší (nabídne se nejlevnější dostupná z poskytovatele)
• Dopravy - přeorat ve smyslu, že jejich ceny se ukazují a hodnotí jak bez, tak s DPH. Opět je to o validaci proti EU. Stejně jako u produktů.
• Šablony - v controllerech není slušná dědičnost, je tam dobré místo na narvání centrálního zpracování šablon (výpisová a error)
• Načítání překladů - zase přes ruku, že se vše krmí na povel. Na druhou stranu zachovat část toho stávajícího systému pro maily (nutnost je nechat podle jazyka)
• Srovnat překlady v databázi, takže to nebude rozházené jako dosud, ale uložené +- stejně
• Srovnat překlady v shopu a udělat z nich větší logické celky, takže se nebudou některé věci opakovat
• Faktury - jazyk faktury závisí od státu, kam má být účtována, ne od toho, co to prodává.
• Výpis měny - je třeba ho předávat co nejořezanější, kdo tam narval ten span, tak zhyne!
• Měny - ta co se zobrazuje před určením cíle a ta, co skončí na faktuře jedno nejsou! Obzvlášť u těch nepřihlášených.
• Hromadné maily - zlepšená správa, odeslání na více kategorií uživatelů najednou, kontrola, že už uživateli odlezl.
• Zákaznické adresy - vůbec hnůj, formát pro doručovací i fakturační je stejný, stačilo by k objednávce ukládat jejich ID a pak zamezit mazání přiřazených. Mazání by přiřazenou adresu pouze odpojilo od zákazníka.
• Pozice v šablonách - když už na to přijde a je třeba nová pozice, tak je editace již hezčí, avšak stále to není D-R-Y.
• Atributy - umožnit vlastní enum podle něčeho (vůbec typy atributů), prakticky něco podobného jak jsou v order_methods, pak s nimi do filtrů
• V šablonách omezit podmíněné php, to nemá front vůbec zajímat, zavést elementy, což tohle zjednodušší. Jak už jsem psal, protože jinak se určitě najde případ, který nechá vyIFovat Javascript.

Nemám čas na dodělání, ale někde se válí nástřel:

• modul Post - pošta obecně. Je fuk, kdo je pod tím jako poskytovatel.

Závěr:

Pokud chcete rychle e-shop, máte rozumné požadavky a někdo vám na to naplácne grafiku, klidně to použijte. Ale jakmile budete chtít víc specifických věcí souvisejících s rozvojem podnikání, je čas tohle hodit přes palubu, protože nemáte tolik peněz, abyste mohli kupovat takhle levné věci. Na spojování s čímkoliv dalším rovnou zapomeňte. Programátor, který toto udržuje, by měl dostávat příplatek na nervy. A ten, kdo toto vyvíjí, vrátit všechny vydělané prostředky a získané tituly z IT. NE, takhle se opravdu neprogramuje kvalitní a robustní aplikace.