Znovupsát CMS v Symfony? Nebo zkusit Bolt/Sulu? Máte doporučení? rubrika: Programování: PHP
1
vosykapavel
Rádi pracujeme v Symfony a sestrojujeme aplikace na míru potřebám klienta. Nemáme žádné svojeCMS, které by nám bylo koulí u nohy.
Co když ale součástí takové aplikace má být blog?
No takže, když se řekne hotové CMS, k dispozici jich je hromada. A já hledám nějakou integraci do Symfony, protože v tom děláme rádi.
Šel jsem tedy na web Symfony a potěšil se seznamem CMS, které plně nebo s části integrují Symfony: https://symfony.com/projects/category/cms
- Drupal
- Joomla
- eZ Platform
- Grav
- Symfony CMF
- TYPO3
- Sulu
- Bolt
- PageKit
- ForkCMS
- Kunstmaan Bundle CMS
- Zikula
- concrete5
- Roadiz
- Contao
- init CMS
- Pico CMS
Nimcéně mnohé jsou:
- historické a od Symfony pořád hodně daleko
- mladé ambiciózní ale už mrtvé
- ošklivé nebo hodně neintuitivní
- mi doposud neznámé
- ještě navíc koupené jinou firmou a nově placené
Moc by mě zajímalo jaké máte reálné zkušenosti vy!
Používáte nějaké CMS v Symfony? Je z tohoto seznamu? Píšete všechno cihlu po cihličce - i blog? Používáte nějaké nadstavby, které vám psaní (blogu) zjednodušují - např. generované CRUD (ať už jednorázově nebo na základě zápisu v YAML)? Nebo máte oblíbený rich html editor, který problém zatím vyřešil?
Díky moc za inspiraci do roku 2022 a dál :-)
Následují zbytky původní otázky...(nemusíte číst)
Řešená poptávka
Stojí před námi poptávka na webík s placeným obsahem. Optikou jednoho programátora je to celkem komplexní - kategorizované články, videokurzy, kvízy, kalendář událostí, FAQ, prodej jednorázových služeb, předplatné atp.
Já jsem nasadil takovou optiku, že je to vlastně jenom CMS + nějaká obsluha kvůli tomu zpoplatnění. Že by zkrátka backend programátor ani moc nemusel vědět, co tam mají za obsah (stačí mu jestli je placený, za kolik, která skupina má přístup). Zbytek prostě bude vědět programátor "integrátor", který s klientem domluví strukturu obsahu. A samozřejmě programátor frontendista, který to pěkně vypiplá.
Proč nevymýšlet kolo?
A rád bych se vyhnul psaní CMS od začátku. Nejen že mě to nebaví, je to zdlouhavé, a to zvlášť když to má být UX friendly. Ale myslím, že jsme kvůli tomu jednoho klienta ztratili, protože třeba práce s obrázky pro něj byla tak složitá, že nám články posílal ve Wordu ve složce na dropboxu, kde byly ty další obrázky. :-/
K čemu jsem nahlédl
- Wordpress Udělal jsem si za 4 hodiny prototyp té administrace ve Wordpressu (custom post types a taxonomies přes plugin Pods). Ovladatelnost pro redaktory by byla moc fajn. Jeden paywall web v něm vyvíjíme, ale programátorům se to moc nelíbí (nejen EAV model, ale celkově ta WP logika...). Ještě na jiném webu máme dokonce propojení Symfony + Wordpress API, ale moc toho s tím zatím neumíme, bál bych se problémů. Takže Wordpressu bych se raději vyhnul. Ale ten rychlý prototyp mě přesvědčil, že ta moje optika není úplně od věci.
- Bolt Díval jsem na Bolt CMS, který je sympaticky integrován do Symfony. Myslím, že by to pro programátory bylo mnohem příjemnější - máme tu připravené nějaké šablony ve twigu, a taky univerzální entitu Content, ke které můžu dělat vazby pro jiné entity pěkně přes Doctrine. Content je trochu abstraktní a může představovat různé content types a podle toho mít různé fields. Používá taky EAV model, což není moc hezký ale o to univerzálnější. Snadno lze definovat nový typ obsahu a zaměřit se na pohodlí redaktorů, případně zobrazení na frontendu čtenářům a jako programátoři nemáme moc příležitostí tam toho tolik zvorat. (video představení)
- Sulu ~~Pokud jsem to pochopil, Sulu konečně nepoužívá ten univerzální model, ale je to generovaný admin back-end podle schématu mých entit. To je programátorům asi sympatičtější.~~ Působí to na mě ale příliš robustně, stojí to myslím jako samostatná aplikace (edit, tak možná ne, viz video) a je to psané v javascriptu jako SPA. Tam se obávám té složitosti. (video představení)
1
vosykapavel
Symfony + Wordpress přes REST API
Napsali jsme si experimentálně vlastní maličké napojení na Wordpressové REST API s metodami getAllPosts(), getPostBySlug($slug), getAllCategories(), .... Jde o náš malý prezentační web bez databáze. V Symfony máme šablonu, formuláře a podobně.
Je to experiment, nicméně spatřujeme tam nějaké výhody:
- Pěkný editor, umí s tím i naše grafička/redaktorka, zvyklá z jiných blogů.
- Programátoři by mohli dál vyvíjet svojí aplikaci a nebudou přitom házet redaktorům klacky pod nohy kvůli své neschopnosti udělat uživatelsky přívětivý editor (v rámci omezeného budgetu)
- Programátoři by taky neměli nadávat, že dělají v tom zlém Wordpressu, protože jsou odstíněni tím API.
- Kodér může v klidu používat twig
- Samotný wordpress lze víc "zabezpečit" (přístup jen přes basic auth / VPN) - stačí třeba zpřístupnit světu jen složku "uploads" s obrázky
- Výsledky kešujeme v Symfony, takže nás wordpress příliš nebrzdí
Omezení (alespoň našeho současného řešení) je celá řada, napadají mě:
- Omezená působnost pluginů (a to dost).
- Koupenou šablonu nevyužiješ.
- Naše řešení je read-only - neřešíme nijak komentáře (ale jinak WP REST API není read-only).
- Naše řešenní není ze symfony přímo napojené do wordpress databáze (ale teoreticky bychom mohli)
Ukázka:
- Nudný výpis článků: https://www.umimeweby.cz/blog/.
- Příklad článku s obrázky: https://www.umimeweby.cz/blog/optimalizace-obrazku-web.
Dá se tím řešit popsaný problém? Ano. Napadají mě dvě cesty:
- V Symfony budeš mít pro článek třeba entitu ArticleProxy (kde budeš udržovat hlavně wordpressové post_id a třeba slug) a taky budeš všechno tahat přes to API.
- Sdílet stejnou databázi, tabulky třeba prefixovat (wp_ / sf_ ), udělat si entitu podle tabulky wp_posts a přes doctrine ORM jí vhodně anotovat. Udělat si třeba ještě entitu Article vazbu 1:1 na tu tabulku wp_posts. Případně pak udělat podle sloupečku post_type dědičné entity ArticleUdálost, ArticleVideokurz, ArticleFaq.
Přikláněl bych se k té druhé, ale programátoři jsou pak od toho wordpressu méně odstínění.
Pro zobrazení všech 4 odpovědí se prosím přihlaste:
Nebo se přihlaste jménem a heslem:
Komentáře