Joomla 3

Za celou dobu, co jsem mlátil PHP, se Joomla moc nezměnila (takže ani jeden z důvodů, proč vzniklo KWCMS). A ani moje hlavní výhrada - totální nepřehlednost a tedy vysoký vstupní práh pokud je třeba něco přidat nebo ohnout. Dokud nevíte, jak se v administraci dělá závislost, kde hodnota v jedné tabulce závisí na druhé (v relačních databázích zásadní fail; mimochodem je to přes samostatně definovaný Field, podobně jako zbytek toho formuláře) nebo jak se vlastně načítají modely a pohledy a předávají prarametry nastavení, tak si neškrtáte. Ostatně, prezentace se dělá aspoň trochu podle MVC, avšak administrace je jeden velký chuchvalec, kde se do MVC ještě míchá generování formulářů pomocí XML. A ani tutoriál na stránkách joomly moc nepomáhá, jelikož pro verzi 3 končí před stylováním administrace (2014) a ani verze 2 neobsahuje vlastní fieldy. Dál nezvládala práci s datem z MySQL (na prezentaci to jde dokopat díky ručním konverzím, administrace mi ale tvrdošíjně ukládala 0) a obchází to přes unix timestamp jako int.

Další neveselá část Joomly je správa součástek. Lze je nainstalovat z balíku, ale už se hůře aktualizují a prakticky nejdou odinstalovat, jenom zakázat. V případě změny ve vývoji, kdy daný plugin už nebude třeba a jeho část je přestrkána někam jinam, prakticky nelze součástku odebrat (ne, není tam triviální delete). Problém to je jak u prezentačních modulů, tak administračních pluginů (položky v nabídkách).

Zvláštní je také rozhození překladů modulů, resp. tvůrci joomly by řekli překladů v některých komponentách. Modul překlady předává do hromadného úložiště, zatímco komponenta si může překlady držet u sebe.

Zvláštní je též přístup k tabulkám. Třída tabulky je definována pouze v administraci a zbytek se na ní odkazuje. To znamená, že pokud se modul potřebuje podívat do databáze, tak controller modulu musí poprosit o data svůj helper, ten se zeptá modelu v prezentační komponentě a odtud letí data do administrace do komponenty s třídou, která napojuje tabulku a nese databázové dotazy. Pro logiku správy je to i docela hezké, pro logiku přísunu dat do prezentace otrava.

Validace jsou v modelech, avšak osobně jsem měl potřebu je přepisovat na styl podobný Cake, kterým lze triviálně umožnit test více položek pouhým přidáním testovací funkce, zhusta jenom s regexpem a hláškou. Originální pojetí jsem zatím moc nepobral. Na druhou stranu validace umožňuje hrábnutí do dat a tedy převody (nutné právě třeba u datumů). Dále se validace musí zavolat ručně, nestačí ji prostě mít nadefinovanou.

Další problém, co jsem viděl, byl se zdvojením kontrolérů pro správu. Neboli je třeba dvou kontrolérů, pohledů i modelů, aby šla data vypsat a upravit. Než jsem na to přišel, stálo mne to spousty času.

Opravdový průšvih je interní mailer, který funguje v prosinci a v dešti... Nedivím se, že je silná potřeba tento mailer nahrazovat něčím dalším, ona stačí i obyčejná funkce mail() z PHP + korektní definice mailu včetně multipart.

Největším kladem je její systém aktualizací a sbírka součástek, kterými se dá vykrmit. Dalším, že proti kódu Wordpressu to má aspoň nějakou uchopitelnou strukturu.