A téma szerteágazó volta miatt több postot szánok a témának. Az első két részben áttekintést nyújtok a szerkesztőségi rendszer működéséről, elemeiről. A további részekben a felszínesebb bemutató után a legfontosabb elemekkel kapcsolatos ismereteim, tapasztalatom alapján próbálok gyakorlatias ötleteket, inspirációt adni. Reményeim szerint minden fontosabb témáról külön post lesz, így ami ebben a postban még homályos az idővel részletes leírást kap.

Pre és pro

A CMS alkalmazások kikerülhetetlenek, ha webes fejlesztésekkel foglalkozunk. A fejlesztők általában nagyon gyorsan eljutnak oda, hogy saját CMS-t akarnak írni. A project managerek nagyon gyorsan szembesülnek azzal, hogy a legtöbb problémát a CMS jelenti cégen belül. Az újságírók nagyon hamar megutalják a nehézkes, logikátlan alkalmazást.

Sokszor hallom (általában sárgaöves) fejlesztőktől, hogy miért kell CMS-t írni, ott vannak a jól bevált opensource CMS rendszerek, azokkal bármilyen siteot meglehet csinálni, és még ingyenes is. Barnaövtől felfelé már jól ismertek az okok:

• megterheltség,
• biztonság,
• fejleszthetőség.

Az ingyenes rendszerek mellé általában legalább olyan képzettségű fejlesztő kell, mintha nulláról fejlesztenénk saját CMS-t. Természetesen lehetséges jól üzemelő, nagy forgalmú siteot készíteni opensource rendszerekkel, de fejlesztés során szem előtt kell  tartani, miért is választottuk azt a CMS-t amit.

Ugyanakkor tény, a php frameworkök egyre jelentősebb szerepet kapnak a fejlesztések során, egyre inkább közeledik az időszak, mikor már megéri a framework alapú fejlesztés nagy megterheltségű rendszerek esetében is.

A legfontosabb indok azonban az online újságírói igények. A siker kulcsa az újságírói munka maximális kiszolgálása. A project sikere azon fog, múlni, mennyire tudjuk felmérni az igényeket és mennyire vagyunk képesek fejleszteni újságírói gondolkodásmóddal. Sok esetben az online újságírók közel digitális analfabéták, a szerveri oldali technológiákhoz (a szakírót nem beleszámítva) alig pár újságíróért. El kell fogadni, meg kell érteni, hogy nem dolguk ismerni a lehetőségeket.

<sarcasm>CMS-t fejleszteni igazán kreatív és kihívásokkal teli feladat. </sarcasm> A legfontosabb: take it easy. Ha megvan a zen, ne engedjük el.

CMS vs. szerkesztőségi rendszer

Az online szerkesztőségek életében a CMS sokszor csak egy szoftver „elnevezése”, amivel weben keresztül viszik fel a cikkeket, híreket a site-ra. Fejlesztőként, project managerként azonban tovább kell gondolkodni. A CMS fejlesztésénél a következő területeken is tervezni kell:

• Üzemelési környezet
• Hardware
• Szerkesztőségi work flow
• Online sales
• SEO
• GUI-k
• Kimenetek, formátumok
• Hírügynökségi területek
• Újságírási munkafolyamatok, szokások, szerkesztőség működés

Még egyértelműben, a szerkesztőségi rendszer az alábbi modulokból áll (a teljesség igénye nélkül):

• CMS ADMINGUI ::content admin,
• CMS ADMINGUI ::content pool (news room),
• CMS ADMINGUI ::statisztika report,
• CMS ADMINGUI ::webmester, moderátor, traffic/admester,
• CMS PUBLICGUI ::user felületek
• CMS SERVER::LOGGER
• CMS SERVER::CACHE BUILDER
• CMS SERVER::OUTPUT API
• CMS SERVER::SEARCH INDEXER / CACHE
• CMS SERVER::NEWSLETTER / CONTENT PUSHERS
• SERVER::SQL
• SERVER::LOAD BALANCER
• SERVER::BACKUP
• SERVER::MAIL

CMS. De hogyan? Az Elmélet

Az alábbiakban egy multi domain CMS-t veszek példának. Ahogy előbb utóbb mindenből kalapács (vagy szög) lesz, a CMS-ből is multi domain szoftver lesz.

A multi domain CMS lényege, hogy egy engine több, egymástól teljesen függetlenül működö hír siteot szolgál ki, úgy hogy az adatbázis egységes, és a különböző domaineken futó hír siteok újságíróit segíti a közös munkában. Figyelem, ez a koncepció nem azonos a fejlesztőcégek által használt weblap "gyár" CMS-ekkel. A hangsúly a közös munkán, az egységes hírgyártás és a content átjárhatóságán van, nem a gyors fejleszthetőségen.

Röviden

A hírsiteok esetén multi domain CMS-k kialakulásáért a hírverseny a felelős. Magyarországon különösen, khm finoman fogalmazva is, necces a hírfogyasztási szokás, a nagyon széles horizontális portálok idővel igyekeznek a jól menő rovatokat vertikális oldalakká alakítani

Ideális esetben a CMS-t ilyenkor a domain vezérli, de gyakori, hogy a CMS engine-t "klónozzák" szerverekre. (Utóbbi egyébként hibás elgondolás abban az esetben, ha az adatbázisok között nincs strukturális kapcsolat, pl. eltérő tag adatbázis, más hiearchiában épített tag csoportok, összerendelhetetlenség.)

A portálosodás hatása, hogy a rovatoldalak általában elhalnak, nagyon minimális user számmal rendelkeznek. A forgalmat siteon belül nehézkes terelni, az aggregátor siteokról érkező traffic nagy átlagban zárja a böngészőt, további cikkeket ritkán olvasnak.  A korábban már említett hírverseny miatt nagyon sok hír eltűnik egy nagyon széles, vertikális (hír)portálon. Ezért sok esetben a rovatokból önálló brand válik, önálló szerkesztőséggel, önálló tartalmi koncepcióval, a széles vertikális site helyett több, vertikális site jön létre, melyre optimális esetben a horizontális gyűjtő siteról érkező userek mellett direkt traffic is létre jön idővel.

A web CMS fejlesztés során meg kell ismerkednünk a tartalom biznisz alapjaival, mindennapi működésével. Nagy általánosságban elmondható, hogy a tartalom biznisz a sok látogató = sok tartalom képlet alapján működik. Ez számszerűsítve azt jelenti, hogy egy nagy forgalmú hír site képes százas nagyságrendben cikkeket előállítani naponta.

A multi domain CMS lényege az azonos adatbázis (struktúra), mely átjárhatóságot biztosít a tartalmak között. A tartalmak cross linkelése mellett olyan "láthatatlan" funkcióval is felruházható, mint a közös news room, ki, milyen témával dolgozik, hol melyik téma forog. A news room kollaborációs funkció, melynek segítségével a tartalmi piramisok, időzített körbe linkelések alakíthatóak ki, külön megbeszélések nélkül. A vertikális szerkesztőség önálló munkája így egy - egy téma esetén napokig, hetekig a felszínen tud tartani jól pörgő anyagokat.

Példa: Egy cikk megjelenhet a hírportálon. Megjelenhet a tematikus site-on. Mindkét megjelenési helyen más címkéket kaphat. Licenszelési okok miatt a kisebb forgalmú oldalon több képet, galériát kaphat. Megjelenhet más nyelven. Más szöveget kaphat. Megjelenhet más platformon pl. print. Eladható hírügynökségi tartalomként. A későbbiek során, a szerkesztőségi felületen listázható a cikk összes verziója, megjelenési formái, helyei.

Hosszabban

Az újságírók ideje drága. De nem annyira drága, mint az információ. Nem meglepő módon a világban keletkező hírek száma véges. A mai magyar média piacon talán a legnagyobb pénz a hírcsinálásban van. Az álhír piac dübörög, ha nincs hír, akkor csinálni kell, különben nincs mit eladni.

Egy jól szervezett szerkesztőségi rendszerben nincs elveszett információ, a jól megírt cikkek körbe mennek a networkön, a lehető legtöbb olvasót kell elérnie, az a bizonyos bőr sokszor lesz lehúzva.  A digitális média, bár nem beszélünk róla, még mindig erős versenyben van a print és elektronikus médiával. A print médiát az online már megverte nagyon sok területen, de a legfontosabban, a bevételekben még csúnyán alulmarad. (A printet egyébként a saját területén tudná megverni egy online cég, a délutáni "sávban" szabadon van az ingyenes, metropol jellegű újságok piaca.) Az elektronikus média pedig nagyon mélyen van beégve a hírfogyasztási szokásokba, jó pár év kellene mire megverhetnénk, de ez idő alatt valószínűleg a két platform nagyon közel fog egymáshoz járni, más jellegű verseny fog kialakulni.

A magyar piacon is létező üzleti modell, hogy külföldi (társ)oldalakon keletkezett cikkeket fordítanak magyarra. Ez a tartalom refactoring jelenleg az egyik legjobb megoldás a "költséghatékony" tartalom előállításra. A refactoring  (becézve hírgyár) a gyakorlatban egy információ feldolgozása, több stílusban, több platformra. Az MTI ebben profi, az áltála gyártott hírek (bocs) gyakorlatilag platform függetlenek.

A célunk tehát a hír refactoring maximalizálása. Az újra "megírt" cikkeket a lehető legtöbb felületen meg kell jelenítenünk és a CMS rendszerünknek tudnia kell, mi, hogyan, mikor jelent meg és ezekkel az adatokkal, információkkal támogatni kell a főszerk, szerkesztők, újságírók munkáját.

News room, info queue

Az újságírás meglehetősen időigényes dolog. Az újságíró kollegák munkáját egy jól megírt news room modul nagymértékben segítheti. A news room modul feladat a témamutatás, a felhasználható infók és cikkek áttekintése.

Ideális esetben a news room nem csak a belső anyagokat mutatja, de trendeket, ügynökségi anyagokat, RSS forrásokat is beránt. Egyre fontosabbá válik a real-time események figyelése, nyomkövetése, a hype hullámok elsőkénti meglovagolása.

A news room tehát minden keletkező hírt, tartalmat megjelenít. Közös munka felületet ad az újságíróknak, figyeli a konkurencia híreit, integrálja a külső információforrásokat, trendeket figyel.

A szerkesztőségi rendszer. A gyakorlat

Az igények 90%-a fejlesztés közben fog érkezni. Akkor, mikor már látható, hogyan is működik a szoftver. A project ilyenkor nagyon közel állt a végtelen loophoz, tapasztalatom szerint érdemes hetes ciklusokkal "kifárasztani" az ötletbörzét és ez idő alatt a lehető legtöbb kívánságot megvalósítani, még akkor is, ha életképtelen az ötlet. Az idő előre haladtával szépen letisztul minden funkció. Csak(!) idővel és idegekkel kell bírni.

A megterheltségi mutatók és hardware tervezésekor a skálázhatóság, hirtelen peakek jelentik a legnagyobb problémát. A CMS fejlesztésekor a kódnak, a cache rendszernek és az sql enginenek minimum rendundásnak kell lennie és lehetőség szerint maximalizáni kell a cache használatot. De. A hírnek realtime meg kell jelennie minden frontenden egy időben. Ez általában fájl cachet jelent, kisebb nagyobb dinamikus elemekkel tűzdelt statikus html fájl.

Template rendszereket, opcode-t, sql cache megoldásokat kell alkalmazni a tartalom megjelenítéshez. Logikailag érdemes különválasztani a tartalom megjelenítést a user funkcióktól, azaz a tartalom megjelenítés prioros, ha választani kell, akkor a user belépés, testre szabási funkciók kikapcsolása kisebb veszteség, mint az üres vagy timeoutolo oldal.

Fizikálisan mindenképp külön működik a szerkesztőség, a frontendek, meghalhatnak, az admin felület nem. A stabilitás kulcskérdés, az egy-két frontendes, fél rack szekrényt elfoglaló megoldások mellett ismert és széles körben használt a sok, kicsi noname pc alapú szerverfarmok és valamilyen load balancer (dns, cél hardware, szoftveres) megoldással vitt rendszer. Ízlések, pofonok, pénztárca.

A lényeg: az adatbázis

A db fizikai megvalósítására mindenki rendelkezik saját, jól bevált módszerrel, technológiával.

Az alábbiakban az adatstruktúra darabolását mutatom be, ami ugyan sok programozói irányelvnek mond ellent, de a gyakorlatban több, tőlem független projectben bevált.

Az adatstruktúra darabolás nem keverendő össze a db sharding-gal. Előbbi esetében a priorizált adatoknak adunk dedikált vasat, utóbbiban az adatokat daraboljuk ideális méretűre.

Funkció szintű SQL adatbázis bontásra példa, adat priorizálva:

• content,
• design,
• ad, banner, reklámok,
• archívum (keresés),
• userek,
• log (user, ad),
• stat (user, ad).

A túlságosan darabolt adat struktúra ugyanakkor más jellegű problémákat hozhat, melyeket az egyre több eleme folyamatba vonása generál. A darabolás előnye a skálázhatóság, a funkció szintű adatbázis "sharding". Hátránya a több hiba lehetőség, további hátrány lehet a kód fejleszthetőség és kód rugalmasság csökkenése, kódlassulás.

A darabolás meglehetősen egyszerű okokra vezethető vissza. Az olvasást igénylő táblákról leválasztott írást igénylő táblák fizikálisan más RDBM kapnak, eltérően optimalizált konfiggal. Ha jó arcok a rendszergazdák, a hardware is tükrözi az RDBM funkcióját.

Az adatbázisok esetén rengeteg eszköz áll a rendelkezésünkre. Amiket nyugodt szívvel ajánlok:

• connection pool managerek, load balancerek
• tárolt eljárások, triggerek alkalmazása,
• adatbázis klónozás, master, slave megoldások,
• tablespace alapú optimalizálás (gyors tábláknak kisebb, de gyorsabb disk / ssd terület megadása).

Amit nem ajánlok, és nem is próbáltam:

• egy darab index.php fájl
• egy nagy adatbázis a contentnek, design elemeknek stb stb.

Összegezve: a CMS lelke az adatbázis. A fizikális adatstruktúra elválasztható a logikai struktúrától. Az adatbázis és az RDBM optimalizálható írásra, olvasásra. Spice must flow. Az admin felületnek minden körülmények között élnie kell, inkább legyen duplázódás az adatokban, mint üresjárat a szerkesztőségbe. Adatot nem veszíthetünk. A RDBM megterheltség skálázható

Ninjaken::Cache

Cache alatt sok mindent értünk, a lehető legtöbb adatot, fájlt szeretnénk a klienssel cacheltetni, a lehető legtöbb tartalmi és design adatot szeretnénk memória és fájl cacheban tartani.

A cache tervezésekor a rugalmasságot érdemes szem előtt tartanunk. A cache építés időigényes folyamat, lehetőség szerint saját vezérlésű eljárással építendő, a felhasználói requesttel indított cachelést csak biztonsági folyamatként érdemes a kódban tartani.

A legjobb megoldás folyamatos cache ellenőrzés és cache replace, az adat bemeneti pontoknál, tipikusan admin felület, triggereljünk cache modósítást, lehetőség szerint a cacheből nyert adatok bővítsük és ne a teljes cachet építsük újra.

A cache folyamatokat érdemes logolni és a missed cahce hit-ekről értesítést küldetni a fejlesztőknek, üzemeltetőknek.

Végül: sose bízz a cacheban. Vagy ott van, vagy nincs amit keresel. Ha ott van, örülünk, ha nincs irány az adatforrás.

Admin GUI

Bár szakmailag nem a legnagyobb kihívás, mégis a CMS admin felületével fogjuk aratni a leghangosabb sikereket. Ismételten le kell szögezni. Ebben a projectben az újságíró a király. Az admin felület ennek megfelelően a legidétlenebb funkciókat kaphatja. Ugyanakkor a "statikus" funkciókat érdemes "dinamikussá" tenni. Ilyen magic funkció az automatamentés, a kapcsolódó írások mutatása, a tag ajánlás, a word "kompatibilitás", az előre-hátra lépegetés hibaüzenet nélkül, az on-the-fly preview, a drag and drop cikk elem (kép, videó, keretes) mozgatás, a session független user auth (egy-két évig aktív session), és ami a legfontosabb: böngésző függetlenség. Talán az IE5 nem fog szerepelni, de azon kívül szinte bármi felbukkanhat. Ez persze nem azt jelenti, hogy minden böngésző alatt ugyan annak kell megjelennie, de minden böngészővel működnie kell a cikk felvitelnek. Technikai okok miatt nem állhat újságírói munka.

Gyakori, hogy az admin gumi valamilyen erőszak eredményeképpen megkapja a site designt. Az admin felületeket nyugodtan kezeljük webappként. Ennek megfelelően gazdagon alkalmazhatunk website idegen megoldásokat. Lehetőség szerint gondoljunk a "modemes" újságírókra, akik terepről, mobilneten keresztül próbálkoznak. Jó irány, ha egy heavy light, minimál design fogadja őket és ha akarnak váltanak a javascripttel tuningolt csilivili felületre. Ha pedig mindez meg eszköz (felbontás) függő designnal is megcsináljuk, jogosan érezhetjük magunkat fekete övesnek. Hint: az interneten a gyorsaság az elsődleges.

Összegezve: az admin legyen egyszerű, de az egyszerűség ne korlátozza a funkcionalitást. A sok funkció közül keveset fog használni az újságíró, ha nem vezetjük a felülettel. Az újságírók általában a MS Wordön edukálódtak. Az office shortcutok közül a ctrl+s beépítése a felületbe sokat segíthet az újságíró lelki állapotán, még akkor is, folyamatosan mentjük a munkáját. Az újságíró bárhonnan, bármivel belogolhat az adminra cikkírás okán.

A quest akkor sikeres, ha ninjaként minden technikai nehézségtől megóvjuk újságíróinkat és képesek vagyunk több tízezernyi cikket összelinkelni különböző sitekon. Akár utólag is, az új cikket linkelni a régebbi cikkben.
A következő részek tartalmából: folyamatos fejlesztés, content delivery network, ajax, user gui, site kereső optimalizálás, mail server optimalizálás, biztonságtechnikai kontrollok, üzemelési környezet optimalizáció és még sok minden más.

Google+ syck