Open f4z4on opened 4 years ago
Tento úkol do značné míry závisí na #1 a #2, takže určitě bude potřeba sledovat jak pokračuje práce na nich a přizpůsobovat se tomu.
Nejdříve vyřešme, co nás bude zajímat, to prodiskutujme s ostatními. Potom bych navrhoval zběžný výběr konkrétních technologií. Nakonec se ten užší výběr podíváme více formálně.
Ať to vykopnu, tak bych navrhoval následující kritéria:
zralost řešení: Ta se může projevovat třeba frekvence k dramatickým změn (jak často probíhá release nové major verze a jak dramatické ty major verze jsou), podrobnost changelogu a upgrade dokumentů nebo něco hůře kvantifikovatelného jako umírněnost a „profesionalita“ komunity.
velikost komunity: Jedná se o nástroj v nějaké programátorské nice, nebo jde o řešení, se kterým jsou komfortně schopni pracovat tisíce, ne-li miliony vývojářů na světě?
křivka učení: Jak snadné bude někoho zapojit někoho nového do skupiny? Tohle možná budeme muset udělat podle rolí (např. editorka, správce šablon, kodérka). Možná bude nutné si stanovit nějakou základní znalost a tu předpokládat (např. u kodéra, že rozumí HTML/CSS/JS na elementární úrovni).
komplexita řešení: Umístění na škále v závislosti na množství „ozubených koleček“ (pluginů, nastavení, …). Například pokud se Jekyll generátor s Jekyll adminem je ultra primitívní. WordPress s pluginy pouze od Automatticu je vyšší. Open source generátor, napojený na open source CMS od úplně jiného projektu s nutností běhu nějaké webappky bokem může být ještě vyšší (nebo taky nemusí).
množství vlastního kódu: Opět nějaká škála posuzující, zda jde všechno naklikat jako ve Webflow nebo ještě snáze a zvládne to i editor? Nebo zda editoři budou mít k dispozici pouze editaci texty a šablony budou muset dělat kodérky?
existence pokročilých webových funkcí: přístupnost (zda spravovaný web funguje návštěvnictvu se speciálními potřebami), vícejazyčný obsah (občas možná napíšeme něco romsky, slovensky nebo jinak, možná nebude od věci mít možnost udělat jednoduchou anglickou stránku), SEO/Semantic Web.
Tady máme vyjádření od bývalého člena skupina, který nedávno více zkoumal CMS:
Žádný dokument ohledně těch CMSek bohužel nemám, rád se však zapojím do diskuze. Nad čím v současné době uvažujete?
Já jsem byl proponent Webflow v případě, že se bude dělat pouze „brochure website,“ protože to výrazně urychlí development i aktualizace. V případě velkorysejšího pojetí té webové prezence jsem byl pro Wordpress, protože je to dle mého mínění nejstrategičtější volba pro takovýhle podnik založený na dobrovolnické práci. Jak z hlediska vývoje, tak z hlediska administrace. Zkrátka ho zná každý, je to už v podstatě takový industry standard. S trochou snahy ho lze i slušně zabezpečit a zajistit únosnou performance. U samotného Wordpressu je však možné volit několik možných cest. Je možné psát si vlastní šablonu, ohnout si nějaké kvalitní placené theme […] nebo to postavit pomocí builderu. Tam mohu doporučit pouze Elementor (všechno ostatní je příšerné). Elementor má super-friendly UI, obrovskou komunitu a především dokáže pracovat s ACF a Custom Post Types, což jsou pluginy, které dělají z Wordpressu plnohodnotný CMSko.
Jako alternativu k těžkopádnému Wordpressu bych zvažoval headless Kirby (vím, že na něj nedá dopustit designer a developer Ivo Mynttinen) a podíval bych se na Twill, což je relativně nové CMS vyvíjené mou oblíbenou agenturou Area 17.
K tomu bych jeste doplnil jednu cestu. Wordpress lze pouzivat i jako tzv. "headless" CMS, kde se pouziva jeho industry-standard admin rozhrani k plneni obsahu, ale samotny render uz zajistuje jiny stack. V posledni dobe roste na oblibe static site rendering (napr. Gatsby s pluginem gatsby-source-wordpress) a to zejmena kvuli rychlosti a bezpecnosti. Ad buildery, zkousel jsem nekolik zavedenych builderu pro WP a osobne je to pro me nepouzitelne. Predevsim v tom smyslu, ze jde casto o konglomerat pluginu a komplexita a "magicnost" cele veci dramaticky roste. Pokus o nejaky rozumny WP stack (vcetne render casti teda) jsem nedavno zaznamenal zde: https://www.zdrojak.cz/clanky/wordpress-kit-naswp/
Na konci by mělo existovat srovnání různých technologií pro správu obsahu, podle kterého se pracovní skupina rozhodne jak postupovat dále a který by měl sloužit jako vstup pro dokument typu ADR.