Po odchodu do Habari se projekt začal vyvíjet. V březnu 2007 se Robin Adrianse (rob1n) stal prvním dočasným revizorem WordPressu, když na tři měsíce získal přístup k revizím, aby pomohl Ryanu Borenovi řešit váznoucí tickety v tracu.
V březnu byl také spuštěn adresář pluginů. Před vznikem adresáře pluginů hostovali vývojáři své pluginy na svých webových stránkách. Díky adresáři se tak dostali do povědomí obrovského množství uživatelů WordPressu. Samuel Wood (Otto42) vzpomíná, jak ho adresář pluginů povzbudil k šíření jeho kódu. “Psal jsem je i předtím, ale nikomu jsem je nedával. Povzbudilo mě to k vydání pluginů, protože jsem je měl kam umístit.”
WordPress 2.1 byl spuštěn v lednu 2007, po více než ročním cyklu vydávání. WordPress 2.2 byl první verzí, která přijala nový 120denní cyklus vydávání. Tento cíl, který se později stal kodifikovaným, protože termíny nejsou libovolné ve filozofii WordPressu, byl trvalou výzvou. Byl vyzkoušen ve WordPressu 2.2, který obsahoval nový systém taxonomie – dosud největší změnu architektury databáze. Vývoj v prostředí open source znamená nechat si čas na to, aby byl vyslyšen každý hlas, čekat na dobrovolníky s nabitým životem, aby mohli věci dokončit, a diskutovat o nových funkcích a architektonických změnách. Je to výzva, kterou by WordPress musel řešit cyklus vydání za cyklem vydání.
Na začátku roku 2000 se na internetu vedly diskuse o nejlepším způsobu uspořádání informací. K obsahu jsou přiřazena metadata, která lze použít k uspořádání a zobrazení informací. Tradiční metody klasifikace webu vnucovaly kategorizační strukturu shora dolů. Webová stránka vytvořila strukturu kategorií a uživatelé umisťovali svůj obsah do správné kategorie. Tyto struktury byly často rigidní a nutily uživatele, aby svůj obsah zařadili do něčeho, co do nich nutně nepatřilo. Objevil se nový způsob klasifikace — tagy, forma klasifikace zdola nahoru, při níž lze na základě klíčových slov, která tvůrce použije na obsah, vytvořit index nebo cloud.
Jako první začal tagy používat web Del.icio.us. Del.icio.us sice nebyl průkopníkem ve správě záložek, ale jeho systém štítků ho odlišoval. Uživatelé označují odkazy, které ukládají, a štítky se pak používají k seskupování odkazů ve vlastní sbírce i v celé sociální síti. Při návštěvě odkazu http://delicious.com/tag/php se zobrazí všechny odkazy označené PHP.
Klasifikační systém, v němž uživatelé sami třídí obsah a vytvářejí sítě hromadného označování, se stal známým jako folksonomie.
V roce 2005 spustil svůj vlastní systém tagování vyhledávač blogů Technorati. Ten umožnil uživatelům spustit vyhledávání pomocí tagů napříč hlavními platformami, jako jsou Blogger a Typepad, systémy CMS, jako je Drupal, a dalšími službami, jako jsou Flickr, Del.icio.us a Socialtext.
WordPress zaostával a komunita svobodného softwaru i WordPress.com vyvíjela tlak na přidání štítků do platformy. Nativní formou klasifikace ve WordPressu jsou hierarchické kategorie shora dolů. Pro interakci se systémem WordPress převzala společnost Technorati “tag” z kategorie příspěvku ve WordPressu. Pro mnoho uživatelů to bylo nevyhovující, protože kategorie a štítky jsou dva různé typy klasifikace.
Carthik Sharma na svém blogu napsal:
Kategorie mohou být štítky, ale štítky nemohou být kategoriemi. Kategorie jsou jako obrovské cedule, které vidíte na uličkách v supermarketech – “Potraviny”, “Hygiena”, “Mražené” atd., které vás navedou do sekcí, kde najdete to, co hledáte. štítky jsou jako štítky na samotných výrobcích.
Kategorie a štítky řeší dva odlišné případy použití. Kategorie jsou pevnější, zatímco štítky představují lehčí způsob klasifikace obsahu. Existoval samozřejmě plugin, který tuto úlohu plnil: Uživatelé WordPressu si nainstalovali doplněk Ultimate Tag Warrior (uživatelé WordPress.com však nemohli).
V roce 2007 Ryan Boren otevřel ticket, aby do WordPressu přidal podporu tagů. Konečně by WordPress měl tagy. Dalším krokem bylo určit schéma databáze.
Databáze uchovává veškerý obsah a data uživatele WordPressu. Databáze obsahuje různé tabulky, ze kterých se data načítají. Existuje například tabulka post, která uchovává data související s příspěvky. V tabulce user se ukládají údaje o uživateli. Provádění změn v databázi není triviální. Veškeré změny je třeba provádět správně, protože jejich vrácení zpět v budoucnu může být obtížné. Změny musí být výkonné. V nastavení PHP/MySQL může zvýšení počtu databázových dotazů zpomalit web. Vyvstala otázka: Kam bychom měli ukládat data pro tagování? Měla by být v nové tabulce? Nebo by měla být uložena ve stávající tabulce?
Ryan navrhl dvě databázová schémata. Jedno z nich vytvořilo novou tabulku pro tagy. Matt byl nadšený z druhého návrhu – umístění tagů do databázové tabulky kategorií. Domníval se, že nemá smysl vytvářet další tabulku totožnou s tabulkou kategorií. V komentáři v tracu napsal:
Kolem kategorií již máme spoustu infrastruktury pro přepis, API atd. Většinou vidím tagování jako nové rozhraní k datům. Na straně zobrazení chtějí lidé mít své tagy uvedeny odděleně od kategorií a pravděpodobně něco jako funkci tag cloud.
WordPress již dříve úspěšně používal tabulky, například příspěvky, stránky a přílohy jsou uloženy ve stejné tabulce a v té době obsahovala tabulka kategorií také kategorie odkazů. Označování z pohledu uživatele umožňovalo označovat příspěvky, zobrazovat seznam štítků a zobrazovat příspěvky se stejným štítkem. Jaký mělo smysl duplikovat infrastrukturu, když toho bylo možné dosáhnout v rámci stávajícího systému tabulek?
Jen málo vývojářů podporovalo vkládání tagů do tabulky kategorií. Někteří se domnívali, že by se tabulka stala přeplněnou, a tvrdili, že přidání tagů do ní znamená začlenění dalšího kódu, který by udržel oba typy taxonomií oddělené. Tento dodatečný kód by mohl přinést chyby a ztížit vývojářům budoucí údržbu a rozšíření tabulky.
Na serveru wp-hackers se v dubnu 2007 diskutovalo o novém databázovém schématu pro taxonomie. Návrh, který získal značný ohlas v komunitě, bylo rozdělení kategorií, odkazových kategorií a štítků do samostatných tabulek – nebylo však možné dosáhnout konsenzu.
Po ověření struktury taxonomií s jedinou tabulkou (sady změn #5110 a #5111) zveřejnil Matt na wp-hackers nové vlákno, v němž se vyslovil pro použití tabulky kategorií. Argumentoval tím, že:
- Byl by rychlejší, protože by nebylo nutné provádět žádné další dotazy na podporu štítků . Samostatná tabulka štítků by vyžadovala nejméně dva další dotazy na front end.
- Poskytla by lepší dlouhodobý základ. štítky a kategorie by mohly sdílet výrazy (například kategorie “psi” a značka “dogs”).
- Nevyskytly se žádné problémy na straně uživatelů ani na straně pluginů.
V tomto vlákně také navrhl alternativu inspirovanou taxonomickým systémem Drupalu: vytvoření nové tabulky pro termíny v rámci konkrétní taxonomie. Termíny jsou položky v rámci kategorie, štítky nebo jiné taxonomie; pes, kočka a kuře jsou termíny v rámci taxonomie “zvířata”. Tato dodatečná tabulka umožnila sdílení termínů mezi taxonomiemi, přičemž měly stejné ID (ID identifikuje položku v databázi). V databázi by byl uložen pouze jeden termín – například “pes” – a tento termín by mohl být použit v jakékoli taxonomii.
Ryan Boren navrhl kompromisní řešení, které by umožnilo, aby jednotlivé termíny byly součástí jakékoli taxonomie a zároveň si zachovaly stejné ID. Jednalo se o třítabulkové řešení s tabulkami pro termíny, taxonomie a objekty. Následovala diskuse, byl otevřen nový ticket v systému trac a na základě tohoto návrhu byla vytvořena nová struktura. První tabulka, wp_terms, obsahuje základní informace o jednotlivých termínech. Tabulka wp_term_taxonomy zařazuje termín do taxonomie. Poslední tabulka, term_relationships, spojuje objekty (například příspěvky nebo odkazy) s term_taxonomy_id z tabulky term_taxonomy.
Výhodou tohoto přístupu bylo přiřazení jednoho ID názvu termínu a zároveň použití jiné tabulky pro jeho přiřazení ke konkrétní taxonomii. Je rozšiřitelný pro vývojáře pluginů, kteří mohou vytvářet vlastní taxonomie. Umožňuje také velkým sítím více webů, jako je například WordPress.com, vytvářet globální taxonomie – jednotné systémy označování, v nichž mohou uživatelé různých blogů sdílet termíny v rámci taxonomie.
Stejně jako mnoho jiných funkcí WordPressu přistály tagy na WordPress.com dříve, než byly dodány do WordPressu. Nová struktura od počátku způsobovala velké technické problémy. Nárůst počtu tabulek znamenal, že WordPress.com potřeboval více serverů, aby zvládl další dotazy. “Bylo to pomalejší, abych byl zcela upřímný,” říká Matt. “To byly náklady, které jsme na WordPress.com viděli zcela reálně, ale také skryté náklady, které jsme však uvalovali na všechny, kteří WordPress ve světě provozovali.”
Implementace taxonomie poukázala na problémy v procesu vývoje. Těžká diskuse znamenala, že se vývoj protáhl. Někteří chtěli vydání odložit. Někteří chtěli funkci stáhnout. Jiní chtěli schéma v další verzi přepracovat. Andy Skelton reagoval na diskusi wp-hackers:
Zařazení předčasné funkce do včasného vydání snižuje kvalitu produktu. Mám na mysli nejen kód, ale i stav komunity. Přírůstky mají směřovat k lepšímu, ne pouze k většímu počtu. Lepší by bylo vydávat včas se skromnou sadou stabilních aktualizací.
Zablokovat vydání, zatímco se vyřeší jedna nová funkce, by bylo špatným nastavením priorit. Pokud se vám zdá, že verze 2.2 je málo sexy, budiž. Lepší je dodržet slíbené datum vydání.
120denní harmonogram vydávání byl ohrožen kvůli jednomu problému. Provádění zásadních architektonických změn v jádře jen několik týdnů před vydáním bylo v rozporu s cíli nového vývojového procesu. V jednom vlákně se objevil návrh na odložení vydání verze 2.2. Architektonické změny byly příliš důležité na to, aby byly provedeny neuspokojivým způsobem.
Nakonec se Matt rozhodl vydání verze 2.2 odložit, stáhnout štítky z jádra a zavést widgety – funkci zaměřenou na uživatele, která by lidi povzbudila k aktualizaci jejich verze WordPressu.
Andy Skelton vyvinul widgety pro uživatele WordPress.com; vytvořil je proto, aby bloggerům poskytl větší flexibilitu při rozvržení jejich stránek. Widgety jsou bloky kódu, které mohou uživatelé přetahovat na místo prostřednictvím uživatelského rozhraní. Umožňují bloggerům přidat do postranního panelu kalendář, vyhledávací panel nebo nějaký text (mimo jiné) v libovolném pořadí. Na webu WordPress.com se jednalo o velmi oblíbenou funkci; velký úspěch měl také plugin pro WordPress. Spuštění widgetů na webu WordPress.com znamenalo, že je mohlo otestovat mnoho různých uživatelů, než se dostaly do jádra jako funkce.
Nová funkce tagování byla nakonec dodána ve WordPressu 2.3 – ve struktuře, která byla výsledkem rozsáhlého vyjednávání a handrkování. Tento proces dohadování má od té doby pro vývojáře WordPressu své důsledky. Sdílené podmínky měly trvalé důsledky pro vývojáře jádra, vývojáře pluginů i uživatele. Problém se sdílenými termíny spočívá v tom, že položka může mít více různých významů, ale databáze se všemi zachází stejně. Například slovo jablko. Vývojář vytvoří taxonomii “Firmy” a taxonomii “Ovoce” a uživatel do obou umístí termín “jablko”. Koncepčně se jedná o odlišné položky – společnost a ovoce – a v uživatelském rozhraní se zobrazují jako dvě odlišné entity. Databáze s nimi však zachází jako se stejnou věcí. Pokud tedy uživatel provede změny v jedné z nich — například ji napíše velkým písmenem — změny se provedou v obou.
V příspěvku z roku 2013 Andrew Nacin napsal, že “zpětný pohled je 20/20 a sdílené termíny jsou zhoubou taxonomií ve WordPressu”. Každý termín je reprezentován dvěma různými způsoby. Vzhledem k tomu, že se jednotlivý termín může objevit ve více taxonomiích, není jednoduché identifikovat skutečný termín ve skutečné taxonomii, který chcete. Stalo se výzvou vytvářet nové funkce, které používají jeden způsob identifikace, když existují části systému WordPress, které používají druhý způsob.
Příklad: aby bylo možné připojit metadata k termínu, musí existovat jeden identifikátor objektu. Veřejný identifikátor však používá jiný identifikátor. Je velmi obtížné důsledně zaměřit data, pokud jsou identifikována více způsoby. WordPress se dlouhodobě zavázal k zachování zpětné kompatibility, takže vytvoření nového schématu není možné. Snaha zbavit se sdílených výrazů musí postupovat krok za krokem, v průběhu několika hlavních vydání (v řadě 4.x se to provádí ve třech vydáních).
Přepracovaný systém taxonomie vznikl na základě dohadů a kompromisů. Když bazarový model funguje, může přinést software, který lidé rádi používají. Model selhává, když neřešitelné hádky vedou ke kompromisům, se kterými není nikdo stoprocentně spokojen. Nový taxonomický systém však obsahoval jednu pozoruhodnou výhodu. Ani jeden z původních návrhů schématu taxonomie (vložení štítků do tabulky kategorií nebo vytvoření nové tabulky pouze pro štítky) by vývojářům neumožnil vytvářet vlastní taxonomie, a ta se stala hlavním prvkem při přechodu WordPressu z jednoduché blogovací platformy na plnohodnotný systém pro správu obsahu.
I přes tyto neúspěchy pokračoval vývoj softwaru většinou podle plánu. Vzhledem k tomu, že tagy byly staženy z verze 2.2, mezi vydáním WordPressu 2.1 a 2.2 bylo pouze 114 dní a mezi vydáním verze 2.2 a 2.3 pak 129 dní. Zpoždění se sice v některých budoucích verzích opakovala, ale nic se nepodobalo dlouhému temnému roku mezi verzemi 2.0 a 2.1.
Zdroj: Github.com – 25. Creating a Folksonomy
