Přejít k navigační liště

Zdroják » Různé » Jak vznikal nový Zdrojak.cz

Jak vznikal nový Zdrojak.cz

Články Různé

Malé povídání o tom, jak vznikal nový Zdroják. Co všechno tepe Zdrojáku pod kapotou. Jestli bychom znovu použili Wordpress? Co bychom udělali jinak. Kde můžete získat kousek Zdrojáku pro sebe. Nechybí ani pověstná třešnička na dortu závěrem.

Nálepky:

týmu nového Zdrojáku jsem se připojil zhruba po dvou měsících jeho existence. V té době tým zrovna usilovně pracoval na WordPress šabloně nového Zdrojáku a řešil import dat z původního systému do nové databáze.

Hlavním vývojářem byl tehdy Tomáš Kapler (tímto ho zdravím). Tomáš náš tým bohužel opustil nedlouho po mém příchodu. Zdroják mi tak spadl do klína a na několik měsíců se stal mým denním chlebem (místo mé původní práce). S odstupem času jsem se rozhodl podělit o několik postřehů a poodhalit zdrojáky Zdrojáku.

Začínáme importem dat

Nejvíce jsme si užili hned na začátku, při importu původních dat. Na starém Zdrojáku vyšlo na 2800 zpráviček a zhruba 1000 článků. Do těchto článků bylo vloženo přibližně 600 souborů – většinou se jednalo o obrázky nebo zip soubory. Na první pohled nebyla databáze nijak objemná. Zdálo se, že za týden nebudeme mít co řešit. Postupem času se ukázalo, že původní redakční systém (RS) procházel celou řadou nedokumentovaných změn. Tak například:

  • řada vložených souborů nebyla v databázi vůbec dohledatelná
  • některé soubory už neexistovaly vůbec
  • původní RS dovoloval duplicitní e-maily uživatelů
  • formátování článků se v průběhu let pochopitelně měnilo
  • uživatelé měli několik druhů avatarů na různých místech
  • některé perexové obrázky si Zdroják „půjčil“ z jiného serveru

Importní skript byl napsán v PHP – jako 26 samostatně spustitelných souborů. Data jsme nakonec importovali zhruba měsíc. Tím se vytvořil relativně nepříjemný tlak na rychlé dokončení ostatních plánovaných funkcí. Jako například:

Funkce plnohodnotného redakčního systému

Původní redakční systém byl postaven tak, aby hravě zvládal některé operace, které jsou běžnému WordPressu cizí. WordPress například neumí do procesu schvalování článku začlenit roli korektora článků. Rovněž nedokáže k jednomu článku přidat více spoluautorů. Žádné z existujících řešení nám nevyhovovalo, nebo řešilo naše problémy pouze částečně. Všechny osvědčené postupy ze starého redakčního systému jsme se rozhodli zachovat. To znamenalo napsat si valnou část sami.

Nakonec se vše obešlo bez jediného zásahu do jádra WordPress a vzniklo něco, čemu říkáme redakční flow. Automatizovaný postup, při kterém autor článku uloží své dílo jako draft do systému. Jeho článek je pak buď vrácen redaktorem k přepracování, nebo je schválen a odeslán ke korekci. Zároveň s tím je pak obvykle článek naplánován k publikování. Z celého relativně komplikovaného kódu jsem se rozhodl vybrat několik zajímavých částí. Začnu změnou stavu článku:

add_action('transition_post_status', 'transitionPostStatus', 10, 3);

/**
 * draft -> pending => clánek ke kontrole
 * ? -> draft => vraceno zpet
 * ? -> publish => publikovano hned
 * ? -> future => bude publikovano v budoucnu
 */
function transitionPostStatus($new_status, $old_status, $post) {
    // ošetří revizi článku
    $post = (wp_is_post_revision($post->ID)) ? get_post($post->post_parent) : $post;
    // ignoruj autosave
    if (wp_is_post_autosave($post->ID)) return;

    // autor zmeni stav z draft -> pending (ke schválení) 
    if ( $old_status === 'draft' && $new_status === 'pending' && $post->post_author == get_current_user_id()) {
        // informuj šéfredaktora a všechny redaktory systému o novém článku
    }
    // add...
}

Některé věci jsme museli zakázat, aby nedocházelo k zbytečným omylům. Příkladem budiž znemožnění úpravy článku, který byl poslán ke schválení:

add_action('pre_post_update', 'prePostUpdate');

function prePostUpdate($post_id) {
    global $post;

    if ($post->post_author == get_current_user_id() && ($post->post_status === 'pending' || $post->post_status === 'future')) {
        wp_die('Nemůžete upravovat článek, který čeká na schválení')
    }

    // atd...
}

Občas bylo potřeba sáhnout trochu hlouběji. Do míst, kde se běžným způsobem nedostanete. Konkrétně se jednalo o změnu vzhledu divu pro odeslání nebo uložení článku. Potřebovali jsme zde přidat checkbox signalizující, zda článek prošel korekcí nebo ne:

$wp_meta_boxes[$current_screen->id]['side']['core']['submitdiv']['callback'] = 'modifySubmitDiv';
function modifySubmitDiv($post) {

    if (current_user_can('edit_others_posts')) {
        $nonce = wp_nonce_field(plugin_basename(__FILE__), 'nonce', false, false);
        $korekce = PostMetaKorekce::getValue($post);
        require_once 'checkboxKorekce.phtml'; // zobrazí formulář
        return post_submit_meta_box($post);
    }
}

Výsledek vypadá takto: Článek prošel korekcí Co se týče objemu práce, byla tato část jednou z nejnáročnějších. Celé redakční flow využívá dvacet dva WordPress hooků.

Pluginy, pluginy a zase pluginy

Aktuálně pomáhá Zdroják udržovat v chodu 17 pluginů. Všechny pluginy jsme vybírali velmi pečlivě. Nebáli jsme se jich vyzkoušet několik s podobnou funkcionalitou. Volili jsme osvědčenou kvalitu. Cílem vždy bylo najít minimalistické řešení – tedy plugin, který neumí nic navíc.

  • 404 Error logger – nám loguje nenalezené stránky
  • Cipher – pomáhá vkládat zdrojové kódy do článku
  • Co-Authors Plus – za nás řeší správu více autorů
  • Members – řeší správu rolí v systému
  • Simple 301 Redirects – přesměrovává ze starých URL na nové
  • WordPress SEO – generuje sitemapy, přidává metadata pro sociální sítě, řeší formáty description atd.

Pro několik pluginů jsem sáhl do vlastních zdrojů:

  • omSocialButtons – plugin pro automatické vkládání sociálních tlačítek do článků a stránek
  • omPreformat – pomáhá vkládat správně naformátovaný zdrojový kód
  • omRememberMe – abychom si pamatovali přihlášené uživatele

A některé jsme museli napsat. Vybrané kódy jsme zpřístupnili na BitBucket, můžete tak získat malý kousek Zdrojáku pro sebe

  • omLightbox – pro zobrazování obrázků v Lightboxu
  • omSocialLogin – na přihlášení uživatelů prostřednictvím sociálních sítí

Rychlost

WordPress nikdy nepatřil k nejrychlejším redakčním systémům. Protože své čtenáře nechceme trápit, byla rychlost webu jednou z hlavních priorit:

  • Ukládání všech interních objektů dostal na starost mírně upravený memcached plugin.
  • Všechny náročnější procesy, jako např. aktualizaci počtu sdílení článků, jsme přesunuli do cronu.
  • Tam, kde to dávalo smysl, ukládáme výsledky do cache.
  • Nepoužívali jsme zbytečně pluginy tam, kde to šlo vyřešit jinak.
  • Minimalizovali jsme množství requestů.
  • Oddělili jsme komentáře od článku.

Co bychom už znovu neudělali

U každého projektu člověk postupem času dospěje do bodu prozření. Zjistí, že některé věci měl udělat jinak a jiné naopak nedělat vůbec. Osobně považuji za největší chybu to, že jsme začali stavět vlastní šablonu nad defaultní šablonou Twenty Twelve. Tento postup nám na začátku uspořil nějaký čas, ale v současnosti je tomu právě naopak. Komplikuje správu naší šablony. Háže nám klacky pod nohy při úpravách CSS a výsledných HTML kódů.

Pravděpodobně bych znovu nepoužil plugin Co-Authors Plus. Tento plugin nás totiž mnohokrát vypekl. Navíc různé aktualizace a opravy jeden čas vycházely až příliš často. Naštěstí se postupem času vývoj ustálil a plugin zatím funguje.

Měli jsme začít stavět design tak, aby byl responzivní, hned od začátku. Pozdější úpravy často znamenaly spoustu práce navíc a zbytečné předělávání hotových HTML kódů.

Použili bych znovu WordPress? Já říkám, jednoznačně ano! Je to výborný systém. Dají se na něm postavit zajímavé a kvalitní weby. Je prověřen neuvěřitelným množstvím lidí. Ono ve finále je vlastně jedno, na čem svůj web postavíte, hlavně to musí fungovat.

Na co se chystáme

Od znovuspuštění Zdrojáku uběhlo už půl roku. Máme v plánu Zdroják nadále vylepšovat. Chystáme například tolik žádané preview komentářů. Musíme ještě zapracovat na vylepšení vyhledávání. Chceme vám dát možnost posílat tipy na různé zajímavosti rovnou z webu. Budeme dál upravovat a ladit vzhled stránek. Budeme naslouchat.

Třešnička na dortu závěrem

Na závěr jsem si pro vás připravil dvě třešničky: statistiky našeho git repozitáře a hezké video vizualizující, jak pilně pracujeme:

Pro generování statistik jsem použil nástroj git_stats s malou úpravou. Video jsem vytvořil pomocí vizualizačního nástroje Gource.

Komentáře

Subscribe
Upozornit na
guest
11 Komentářů
Nejstarší
Nejnovější Most Voted
Inline Feedbacks
View all comments
Mastodont

Je mi vcelku fuk, jestli šablona je nebo není „responzivní“. Ale není mi jedno, že je hnusná.

Lamicz

No, sám teda taky nepíši „hvězdný“ kód, ale teda ten ve WP je extrémně odporný (coding standards, kilometr dlouhé názv fcí…). Úplně jsem byl ovanut PHP 4 časy a to asi není úpně dobře :).
BTW teď si uvědomuji, jak je to OOP přehledné ve smyslu kontextů:
např. $user->getId(); vs. get_current_user_id()

Jan Rybařík

Je to tak. Pokud člověk pouze předělává již existující šablony pro nějaké rozsáhlé řešení, dříve nebo později narazí. Není nad to začít na čisto a vše si připravit podle svého, tak aby to bylo i do budoucna snadno rozšiřitelné. Ze začátku to zabere více času ale ta investice se vyplatí.

karel

A když už konečně dovedeme projekt do stavu, kdy nahradí stávající funkcionalitu, tak opět narazím a pro změnu zase přepracuju celý web podle nějakého hotového řešení. Stejně tak, jako udělali chyby vývojáři wordpressu, tak je udělají vývojáři úplně nového systému.

David Grudl

Romane a neuvažovali jste nad tím si napsat vlastní redakční systém? To množství energie a času vloženého do hledání vhodných pluginů, jejich ohýbání atd. by nejspíš bylo srovnatelné s tím napsat vlastní systém na míru, ale na konci byste měli vše plně pod kontrolou.

Samozřejmě je správné upřednostnit hotové řešení před znovuvynalézáním kola, ale v tomto případě WordPress rozhodně „hotovým“ řešením nebyl, protože je vidět, jak teprve postupně řešíš (nebo řešíte) jednotlivé bugy a funkčnost i uživatelský komfort mi připadají stále pozadu za původním systémem.

Martin Hassman

Z pohledu uživatele redakčního systému (tedy nikoliv programátora) jsem hlasoval pro použití hotového CMS řešení; jsem přesvědčen, že většinu důležitých drobností, které třeba WP má by nikdo nespecifikoval a nenaprogramoval a trvalo by (jsem přesvědčen, že nejspíš i) roky dosáhnout téhož komfortu. To jsou věci, které většinou čtenář nevidí, ale píšící autor ano.

Jan Pobořil

Jak to tak vidím, tak to redakční workflow byl docela kámen úrazu. Jaké tedy byly důvody jít do CMS vhodného na blogy místo CMS vhodného na komplexnější redakční práci? Tipuju správně, že to rozhodla kvalifikace programátorů, kteří byli k dispozici?

Enum a statická analýza kódu

Mám jednu univerzální radu pro začínající programátorty. V učení sice neexistují rychlé zkratky, ovšem tuhle radu můžete snadno začít používat a zrychlit tak tempo učení. Tou tajemnou ingrediencí je statická analýza kódu. Ukážeme si to na příkladu enum.

Pocta C64

Za prvopočátek své programátorské kariéry vděčím počítači Commodore 64. Tehdy jsem genialitu návrhu nemohl docenit. Dnes dokážu lehce nahlédnout pod pokličku. Chtěl bych se o to s vámi podělit a vzdát mu hold.