Približne pred 13 963 hodinami som predpovedal, že náš redakčný systém EDI.TOR vylepšíme na verziu 3. Slovo dalo slovo a moje proroctvo sa naplnilo. Predstavujem vám EDITOR 3.00.

Čo je EDITOR?

Skôr než poviem, čo je nové, mal by som najskôr upresniť, čo je staré.

EDITOR je webový redakčný systém (CMS), ktorý používa Marketinger na svojich weboch.

Má na starosti to, aby si klienti vedeli upravovať obsah, spracovávať objednávky či sami uploadnúť obrázky mačičiek na internet.

Ako EDITOR vznikol, sa môžete dočítať v mojom predchádzajúcom článku. 

V tomto blogu však nebudem písať o dávnej minulosti, keď boli starí bohovia malicherní a krutí, ale o tom, ako sme naše CMS vylepšili v priebehu tohto roka.

EDITOR vznikol pred piatimi rokmi a, rovnako ako Marketinger, rastie a napreduje. Na päťročnicu sme sa rozhodli, že je načase spraviť poriadny update. Ako však taký update vyzerá?

Veľké rozhodnutia

Aktualizácie EDITOR-u väčšinou prebiehali spontánne a ad-hoc. Keď nejaká nová funkcia vyžadovala zmenu jadra, proste som ju urobil a aktualizoval som centrálny server. Funkcie som dopĺňal podľa potrieb pluginov alebo podľa dobrých nápadov, ktoré mi napadli pri meditácii na záchode. 

Bohužiaľ, weby pre klientov boli vždy dôležitejšie. Na vývoj, ktorý nebol vyžiadaný funkciou pre klienta, nezostávalo veľa času.
 

Take your time, but not too much

Tentokrát sme sa rozhodli pristupovať k tomu inak. EDITOR 3.00 sme začali brať ako veľký projekt na úrovni klientskych webov, ktorému sa vyhradil rovnaký priestor.

Klientom sme sa stali my, a teda aj podmienky sme si kládli my sami. Mali sme voľné ruky a sami sme si mohli povedať, čo chceme a čo je pre nás dôležité.

Úlohy project managera sa v tomto prípade zhostil Sučo, ktorý v dobách dávno zabudnutých stvoril prvú verziu EDITOR-u a roky prichádzal s dobrými nápadmi a riešeniami na vylepšenia. 

Vďaka tomu sme mali zabezpečený potrebný čas a aj zodpovednú ruku, ktorá dávala pozor, aby sme stíhali milestony a pohybovali sa vpred.
 

Don’t look behind

Robiť zásadné zmeny v jadre systému nie je až také jednoduché – treba myslieť na spätnú kompatabilitu.

Inými slovami, spýtať sa sám seba: „Budem kvôli tejto zmene musieť na každom webe aktualizovať všetky pluginy, aby fungovali?” Ak je odpoveď áno, treba hľadať iné riešenie.

Preto sme sa rozhodli, že v prípade aktualizácie 3.00 zrušíme potrebu spätnej kompatibility kódu s predchádzajúcimi verziami. To nám umožnilo robiť radikálne zmeny v kóde a hľadať optimálne riešenia namiesto riešení, ktoré čo najmenej zasahujú do kódu.

Pluginy aktualizované pre verziu 3.00 sa teda nedajú používať na verziách 2.00+ a opačne. Ak budeme chcieť používať nové funkcionality na starých weboch, budeme musieť spraviť update na 3.00.

Aby sme však naše staré weby neodsúdili k zastaraniu, pridali sme dôležitú podmienku – každý aktualizovaný plugin musí byť schopný importovať dáta zo starej verzie a skonvertovať ich do novej.

Vďaka tomu nebude aktualizácia bežného webu na 3.0 časovo náročná a drahá položka na faktúre klienta, ale záležitosť bežného servisu stránky.

Taktiež sme sa dohodli, že nový EDITOR bude vyžadovať verziu PHP 7.3 alebo vyššiu, čím sme si otvorili možnosť používať všetky najnovšie vychytávky tohto jazyka, bez obmedzovania sa spätnou kompatibilitou so staršími verziami.
 

The crew

Ďalšie veľké rozhodnutie, ktorým sme upravili výslednú formu systému, bolo rozšíriť tím.

Požiadavky na systém pribúdali a čoskoro sa ukázalo, že budem musieť skončiť so svojou one-man-show a spraviť z toho tímovú vec.

Do EDI.TOR tímu sa pridal náš internetmi ošľahaný programátor Rodebert, ktorý si vzal na starosti úpravy jadra a pluginov, PHP čarovanie a rutinné obety pivným bohom.

Vizuálne úpravy administrácie a zlepšenie UX ovládacích prvkov som si chcel vziať na starosť ja, no pod ruku nám padol frontendista Viktor, ktorý sa v polovici vývoja pridal do nášho house a usadil sa s nami v našej IT pivnici.

Nový dizajn

Black is the new black

Prvá vec, ktorá používateľovi udrie do očí, je zmena dizajnu administračného rozhrania.

Niektoré farebné prvky sme vymenili za čiernobiele a farby sme preriedili. Ale zase nie všetky – farby však teraz využívame na komunikáciu významu.

Ak je gombík zelený, niečo potvrdzuje. Ak je červený, ruší alebo maže. Ak je modrý, bude zase vykonávať nejakú neutrálnu činnosť. Ak je biely alebo čierny, pravdepodobne je to len klasický link.

Používateľ tak na prvý pohľad aj bez čítania textov uvidí, kam má kliknúť, keď chce niečo potvrdiť.

Nový dizajn je trochu odvážnejší a trochu menej “funky” veselý. Ale zase nevyzerá až príliš seriózne. Nazval by som to CMS verziou “business casual".

EDI.TOR predtým.

EIDTOR 3.00.

Lang redesign

Jedna z najčastejších úprav, s ktorou sa klient stretne, je úprava textov. Na to využívame dva spôsoby – takzvané Texty, ktoré sa používajú na úpravu dlhých formátovaných textov, a Langy (skratka od Language Specific Phrase) na úpravu krátkych textov bez formátovania.

Tieto funkcionality sú v EDITOR-e od úplného začiatku. Langy však dostali trošku lásky a vyzerajú krajšie. Používateľ teraz už počas úprav textu okamžite uvidí, ako bude text po uložení vyzerať.

Swal

Ďalšia vizuálna zmena, ktorú si používateľ rýchlo všimne, je náš nový Swal. Nie sval, ktorý hýbe kosťami, ale Swal, knižnica na vypisovanie hlášok pre užívateľa. Nahradila zastarané notifikácie, ktoré nevedeli správne reagovať na modernejšie časti kódu.

Veľká zmena v názve

Po rokoch sme sa taktiež rozhodli trochu pozmeniť aj samotný názov. Z EDI.TOR prechádzame na EDITOR CMS, čo nás zbaví jednej otravnej bodky (ktorá aj tak nevyzerala dobre) a upresní doteraz veľmi všeobecný názov systému.

Môj pôvodný plán pomenovať aktualizáciu EDITOR 3F, bohužiaľ, nakoniec nevyšiel, keďže ma zvyšok tímu prehlasoval, že slogan EDITOR 3F – Faster, Fancier and Fuckin’ awesome! by mohol vyvolávať pohoršenie.

Modernizácia loga

Logo EDITOR-u, robot s jedným okom a rukami, nebolo nikdy plánované ako nejaká super premyslená vec. Sučo ho dostal od kamaráta so slovami: „Ja ho nepotrebujem, kľudne ho využi.” A on ho využil na svoje CMS. A tak nejak tam ostal dodnes.

Nakoniec sme sa rozhodli, že si nášho robota ponecháme, avšak trochu sme ho prerobili a rozšírili si tak možnosti. Keďže nové logo tvoril náš dizajnér, máme možnosť pridávať nové varianty, robiť animované gifká a podobne.

Pages

Asi najväčší prírastok do EDITOR-u je nový plugin Pages.

Ten umožňuje administrátorovi vlastnoručne spravovať štruktúru webu. Môže tak kedykoľvek vytvoriť novú podstránku, cez rozhranie si vyklikať množstvo a typy sekcií a vyplniť si ju podľa svojho.

Potom ju vložiť do príslušnej navigácie na správne miesto a nastaviť SEO parametre. Všetko cez jedno spoločné rozhranie.
 

Šablónový systém

Nový šablónový systém nám umožňuje dynamicky na web vkladať ľubovoľné sekcie, ktoré sú vopred pripravené podľa požiadaviek klienta.

Ten má vďaka tomu obsah webu vo svojich rukách a nie je limitovaný fixným dizajnom, ako to bolo doteraz.

Šablónový systém sme niekoľko rokov pomaly vyvíjali a používali na niektorých webstránkach, avšak len v podobe prototypu, ktorý nebol vhodný na široké nasadenie.

Na základe získaných skúseností sme systém od základu prepísali a pripravili na to, aby sa dal používať na každom novom webe. A aby bol user friendly.

Vzory

K šablónam pribudli aj takzvané vzory, ktoré umožňujú uložiť rozloženie individuálnej stránky a uložiť ho pre budúce použitie. Potom neskôr, pri tvorbe novej podstránky, je možné načítať uložený vzor a používateľovi sa automaticky vložia presne vybrané sekcie.

Gallery

Ďalšia z dôležitých súčastí aktualizácie je vylepšenie pluginu Gallery. Galéria totiž mala viacero problémov, ktoré nám znepríjemňovali prácu.
 

Veľkosť obrázkov

Čím viac obrázkov je na webe, tým dlhšie sa web načítava používateľovi. Veľmi dobré pravidlo preto je neukazovať používateľom obrázky, ktoré sú v skutočnosti väčšie, ako vyzerajú.

Ak má obrázok 800px, no používateľovi sa načíta 1600px súbor, posiela sa mu omnoho viac dát, ako v skutočnosti využíva.

Naša galéria tento problém čiastočne riešila – nahraté obrázky uložila na serveri a potom vytvorila kópiu obrázku vo veľkosti 250px. Tá sa dala používať v náhľadoch na fotky, v zozname produktov a podobne.

Len čo však dizajn vyžadoval obrázok v rozmere 500px a používateľ nahral na server 1600px, musí sa načítať celý veľký obrázok a následne zmenšiť pre používateľa, aby sa správne zobrazil.

Nový EDITOR tento problém rieši poriadne. Správnym použitím kódu dokáže vygenerovať URL obrázku, ktorá presne určuje, o aké rozmery je záujem. Systém následne vygeneruje obrázok v požadovanom rozlíšení, ten ukáže používateľovi a neodošle žiadne zbytočné dáta.

Obrázok sa následne uloží na serveri pre budúce použitia ostatných používateľov. Pri použití tej istej URL sa obrázok nemusí znovu transformovať.

Funkcionalita je, samozrejme, opatrená aj automatickým čistením nepoužívaných verzií obrázkov a zabezpečením proti manipulácii s URL.
 

Zabezpečenie zdrojov

Popri úpravách vo veľkosti obrázkov sme vylepšili aj bezpečnosť. Adresy obrázkov už nesmerujú priamo na uložený súbor na serveri, ako to bolo v minulosti, ale ku skriptu, ktorý zobrazí súbor až po spracovaní parametrov.

Takto je galéria chránená pred odhalením “susedných” obrázkov alebo pred nepovoleným prístupom k pôvodnému obrázku v plnom rozlíšení.

Taktiež nám to umožňuje obmedziť prístup k obrázku tak, aby bol dostupný len vybraným používateľom a skrytý pred verejnosťou.
 

Roxy Image Picker

Mnohí používatelia nášho CMS pri práci s blogmi krútia hlavou, prečo sa pri vkladaní obrázkov do textu a vkladaní obrázkov na webe používajú dve úplne rôzne vyskakovacie okná – každé s vlastnou galériou, bez vzájomnej komunikácie.

V minulosti sme tento systém používali kvôli technickým obmedzeniam. Náš textový editor CKEditor totiž používal na správu súborov systém Roxy Fileman, zatiaľ čo zvyšok systému používal natívny Image Picker.

Image picker.

Toto nezapríčinil rozmar programátora, ale technické obmedzenia – snažili sme sa aplikovať natívny Image Picker na CKEditor, no ani po dlhšej snahe sa nám to úspešne nepodarilo.

Rozhodli sme sa teda pre opačný prístup. Miesto snahy vymeniť Roxy Fileman za iný, sme spárili Image Picker a Roxy a vznikol hybridný Roxy Image Picker.

Ten využíva technické výhody Roxy, avšak je napojený priamo na náš Gallery plugin – a teda sú vždy a všade dostupné všetky obrázky.

Navyše nám umožnil rozšíriť galériu o stromovú štruktúru. Galérie na našich existujúcich weboch sú na jednej úrovni, zatiaľ čo v 3.0 je možné vnoriť galérie do seba a mať tak v súboroch omnoho väčší poriadok.

Nový picker sme aplikovali na všetky využitia obrázkov, takže sa používateľ viac nestretne s dvoma rozhraniami na tú istú vec.

Rework jadra Pluginov

Už od začiatku projektu bolo jasné, že jedna z prvých vecí, ktorá sa musí zmeniť, sú pluginy.

Varovanie: nasledujúce odseky budú technického charakteru. Ak teda nie ste v tejto problematike doma, pokojne preskočte na záver článku. 

Build from the ground

Pluginový systém bol jeden z prvých kusov kódu, ktoré boli pre EDITOR napísané. V priebehu rokov sme ho mnohokrát upravovali a zlepšovali, avšak jeho základy boli stále tie isté.

Pre ilustrácie archaickosti kódu – v čase, keď som ho písal, som ani len netušil, že PHP podporuje objektové programovanie.

Nanovo sme napísali väčšinu kódu, ktorý sa staral o správu pluginov. S pomocou objektového programovania sme výrazne sprehľadnili ich kód a pridali im flexibilitu. 

MVC

Ďalšia z podmienok aktualizácie 3.00 bola, že musíme inovovať a začať používať niektoré svetovo uznávané štandardy.

V dôsledku toho sme sa rozhodli, že v pluginoch prejdeme naplno na systém MVC – Model View Controller, ktorý je v moderných CMS štandardom.

EDITOR MVC čiastočne využíval už niekoľko rokov, ale tak nejak po svojom. Modely neboli modelmi, viewy viewami a controllery boli tiež také svojské.

Model

Do role Modelu sme pasovali osvedčenú triedu EditorRecord a desiatky jej detí. Tie boli v pluginoch uložené v priečinku /classes, spolu s inými nie-modelovými triedami.

Vytvorili sme priečinok /models, do ktorého sme ich presunuli. Autoloader teraz vie podľa umiestnenia hneď určiť, či ide o model alebo inú triedu.

View

Používateľské rozhranie pluginov bolo doteraz riešené veľmi jednoducho – každý plugin mal priečinok /UI a v ňom súbory uložené, ako keby išlo o vlastný mini-web, kde mala každá podstránka pluginu vlastný php súbor.

Administračné rozhranie a jeho kód sme v 3.00 presunuli do súboru view.php, ktorý okrem HTML snippetov obsahuje aj routing pluginu – rozhoduje o tom, aké kľúčové slovo v URL otvorí ktorú časť rozhrania.

Aby sme predišli problémom s extrémne veľkými súbormi kvôli rozsiahlym HTML blokom, rozhodli sme sa priečinok UI v niektorých prípadoch ponechať. Avšak už iba ako úložisko HTML súborov na includovanie podľa direktív Viewu.

Controller

Na záver naplnenia MVC sme museli vyriešiť Controller. Toto bolo z trojice najjednoduchšie, keďže EDITOR využíval controllery, len pod vlastným názvom commands.

Tie boli obsiahnuté v súboroch commands.php, riadené funkciou switch a množstvom možností pre každý plugin. Fungovať to fungovalo, ale od elegancie to malo veľmi ďaleko.

Pre každý plugin sme teda pridali súbor controller.php, ktorý obsahuje všetky príkazy, ktoré vie plugin vykonať. Každý je definovaný ako metóda triedy a má v sebe striktne zadefinované bezpečnostné podmienky, za akých sa môže aktivovať.
 

Flexibilita pluginov

Informácie o plugine, ktoré sa predtým skriptom vyťahovali zo súboru info.xml, sme vybrali a vložili do nového súboru plugin.php, ktorý obsahuje základné informácie o plugine spolu s jeho základnými funkciami.

Vďaka tomu sú jednoduchšie dostupné, keďže na ich získanie netreba spracovať XML súbor, ale všetky informácie sú parametre triedy.

Zmeny v jadre systému nám umožnili odpútať niektoré funkcionality od obmedzení, ktoré mali doteraz. Napríklad základné údaje o plugine, ako jeho názov, ikona alebo popis, sú fixne zapísané v kóde.

Ak vyžadoval v minulosti klient zmenu názvu pluginu pre interné potreby, museli sme prepísať kód pluginu, čo znepríjemňovalo kompatabilitu s aktualizáciami.

V 3.00 sa všetky informácie presúvajú na úroveň databázy, čo nám umožňuje ich dynamicky meniť. Teraz už nie je problém plugin premenovať, skryť či presunúť v hlavnej navigácii podľa potrieb individuálnych webov.

Záver

Aktualizáciou 3.00 sa však vývoj EDITORa nekončí, práveže naopak. Začína sa nová etapa vývoja, obohatená o tímovú prácu, poriadny project management a nové ambície do budúcna. 

Je mnoho vylepšení, o ktorých som tu nepísal, lebo sú zatiaľ len na plánovacej tabuli. Keď ich však zase zopár zrealizujeme a vyplníme napríklad verziu 3.10, možno sa objaví ďalší update aj tu na Free Times.

A možno nie.