Hľadám CMS podľa mojich podmienok
Na úvod: nejde o uspokojenie konkrétnej potreby – nechcem ani nehľadám CMS k priamemu nasadeniu. Chcem si len rozšíriť obzory o Tvoje vedomosti.
Hľadám CMS s týmito vlastnosťami a stačí ak doporučené CMS splní aspoň jednu:
* v texte príspevku pri vytváraní hyperlinku sa zvyčajne zobrazuje dialóg pre vloženie URI, ja ale chcem také CMS, ktoré mi po stlačení tlačítka čojaviem s názvom Internal Link, ktoré zobrazí VÝBER z dokumentov (iných článkov, dokumentov, ankiet, diskusných fór…) a do textu to vloží ako symbolický hyperlink. Tento hyperlink sa „premení“ na skutočný odkaz až po publikovaní. Mohol by vedieť prípadne aktualizovať zmeny – napr. pri zrušení dokumentu, na ktorý je odkazované nejakým spôsobom „zareaguje“ – najlepšie ponúkne možnosti ako na toto má reagovať dokument, ktorý odkazuje na práve mazaný.
* inteligentnejšie vkladanie obrázkov – klepnem na tlačítko, zobrazí sa ponuka vo forme fotogalérie a napr. ťahaním myšou môžem vybrať obrázok. Prípadné funkcie navyše (crop, resize) uvítam.
* štruktúra databázy je dostatočne zrejmá alebo existuje rozhranie, ktorým ľahko „vyexportujem“ skriptom dáta von. Situácia: CMS na separátnom stroji a web na úplne inom stroji dokonca voliteľne s iným typom databázy resp. aj bez nej. Vyexportované dáta by mali byť zrozumiteľné – žiadny DUMP :-) tak, aby som si dokázal naprogramovať vlastný systém, ktorý bude tieto dáta kombinovať v mojom šablónovaciom systéme a zobrazovať ako HTML.
* nie je príliš orientovaný „webzinovo“ takže žiadne „články“, „príspevky“ alebo „chronologicky zoraďované“ zoznamy dokumentov. Nie je podmienkou ani komentárový systém, diskusný systém a vlastne všetka bežná „interakcia“ čitateľa s webom.
Najmä prvé tri body sú veľmi vyčerpávajúce pri hľadaní, tretí je dokonca neprekonateľný…
hmmm, co takto si nieco take naprogramovat? a na tie exporty dat – xml? Mas ich pekne strukturovane a vies co s nimi, resp. mozes s ni mi spravit hocico :)
[1] diky za tip, ktory ma samozrejme nenapadol <g>
Takže špeciálne a znovu: nejde o uspokojenie konkrétnej potreby – nechcem ani nehľadám CMS k priamemu nasadeniu. Chcem si len rozšíriť obzory o Tvoje vedomosti.
Zaujímavé požiadavky na UI, ale uniká mi ten tretí bod – nerozumiem o čo Ti ide. Inak nemám veľa skúseností s CMS, takže sorry za offtopic…
[3] ide mi o to, ze drvivá väčšina známych CMS je „jednostrojová“ a kompaktná. Čiže ak vieš, že nejaká webka beží pod daným CMS, tak si môžeš byť istý, že niekde „tam“ beží aj adminstračné rozhranie.
Takže jedna vec je „príprava dát“, ich uloženie kdesi v databázach. Následne TO isté CMS má stroj, ktorý „vyskladá“ konečnú webku a zobrazí.
V treťom bode hovorím o tom, že by malo byť jednoduché „vyťahovať“ (pravidelne, neinteraktívne alebo na základe udalosti) štrukturovane a zmysluplné dáta, ktoré som pomocou toho CMS vytvoril.
Predstav si, že si v tom CMS urobím produktové portfolio, každý produkt má nejakú štruktúru (názov, fotka, krátky popis, cena, plná špecifikácia, fotogaléria, väzby na príbuzné produkty alebo doporučované). Tieto dáta by malo CMS vedieť „vypľuť“ von v štrukturovanom formáte (xml, ale aj taký, čo si určím) – chce to nejakú formu značkovacieho jazyka. Tieto dáta uloží do statického súboru alebo „odpovedá“ formou API na „dotazy“.
Na druhej strane, ktorú nespomínam, mám svoj separátny stroj – webový server, ktorý nejako prevezme tie dáta – je jedno ako, kľudne aj prekopírovaním disketou – ale už nie je nijako inak závislý na samotnom CMS. Sám má vlastný systém ako dáta spracuje a zobrazí ako html stránku. Samozrejmosťou sú okrem surových dát aj vyexportované isté „vzťahy“ ak je to účelné riešiť.
Vysvetlím aj na čo je to dobré – ak ti na tom istom stroji beží aj CMS, tak je riziko, že sa to zneužije. Zároveň je to celkom škoda – kompromitácia webovej prezentácie znamená aj kompromitáciu CMS a dát v ňom. To je škoda najmä ak fyzicky CMS ohrozený nebol a nebol ani ohrozením. Pri kompromitácií však sú prezradené aj nepublikované dáta… Ďalšia vec – oddelený stroj pre web môže byť „slabší“ a „nahraditeľný“.
Istú formu takéhoto CMS som už naprogramoval ale nespĺňa to VŠETKY body.
Asi bude něco na tom, že dneska se každé CMS snaží nabídnou články a diskuse pro blog či e-zine, na ostatní pak nezbývá čas :-)
Snad neprozradím moc (a omlouvam se za malou reklamu), ale nová verze našeho pub. systemu Atrium, bude splňovat body 2, 3 a volitelně i bod 4.
A bod 1 budeme resit primárně pro obrázky (cili pri smazani obrazku se bude kontrolovat, zda není pouzit nekde v nejakem clanku), ale obecne by to slo i pro jiný typ dat. Vlastne nam to funguje uz ted a ciste strukturovanych dat. Chci smazat rubriku – zkontroluje se, zda v ni nejsou nejake clanky. Takto to kontroluje jakekoliv propojeni, pokud existuje a pokud bylo nadefinovano (par kliknuti).
Atrium, zejména tuhle novou generaci, koncipujeme tak, ze to není ani blog, ani eshop, ale může to být cokoliv, vše závisí jen na imaginaci toho, kdo na tom provozuje web.
Na výčet všech vychytávek zde není prostor, ale bude-li čas, představím to na svém blogu, až to budeme mít hotové.
Jinak na předchozí generaci tohoto systému běží Euroskop.cz, NGPrague.cz, Hlava.net, eDotace.cz, Zeleni.cz a mnoho dalších. Na nové poběží nové verze některých z výše uvedených projektů.
1. drviva vacsina sucasnych CMS je dvojstrojova – DB moze bezat kludne na uplne inom stroji, pri instalacii CMS predsa zadavas (alebo pises do konfiguraku) IP adresu databazoveho stroja (nemusi to byt len localhost).
2. Tretia podmienka sa da krasne ojebat. Nebude to sice uplne ciste, ale funkcne:
Majme dva stroje – A a B. Na stroji A bude bezat administracna cast CMS a na stroji B bude prezentacna cast pristupna navstevnikom.
Na oba stroje nainstalujeme ten isty CMS, DB budu takisto pouzivat spolocnu, finta bude len v tom, ze len stroj A bude mat do DB pristup aj na zapis, kdezto stroj B bude moct len citat. To sa da vyriesit dvoma roznymi DB usermi (nie CMS usermi) – pre kazdy stroj jeden.
Takze uzivatel CMS sa pri svojej praci bude pripajat len na stroj A, ktory publikovane data posle na stroj s DB. Navstevnik webu sa bude pripajat na stroj B (o stroji A nebude ani tusit), ktory data bude opat cerpat z toho isteho stroja s DB.
[7] zrovna taky sposob „delenia“, ze SQL je na inom stroji. Som na mysli nemal.
2. zrovna taky sposob „rozdelenia“ je ten, ktoremu sa chcem vyhnut ;-)
Je tam totiz jedna a ta ista databaza.
Prave o to mi ide, ze stroj A je neprekonatelne oddeleny a to tak, ze neexistuje k jeho databaze „normalny“ pristup.
Neviem ci si rozumieme.
Predstav si to tak, ze mas redakcny system cely v osobnom pocitaci, ktory proste po ukonceni prace vypnes.
Ale webka pre ktoru pripravujes data funguje neustale. Takze musis vymysliet nenarocny sposob aby webka (stroj b) mala data uz u seba.
A aby to nebolo vzdy prenasanie desiatok megabajtov.
Teda idealny by bol nejaky inkrementalny update vzdy?
[9] s mojou chabou znalostou SQL si predstavujem, ze nejaky komponent toho CMS urobi export dat, okrem „puheho“ dumpu vsak tie data budu mat aj nejaku logiku, aby som zasa dalsim skriptom vedel z toho „vybudovat“ sajtu naliatim tych dat do sablony (vzhladu). Cize nie „obideny“ dvojstrojovy system ale naozaj precizne oddelene dva stroje. A to dokonca tak, ze nebudu mat „spolocny“ stroj s databazou. Snad som sa vyjadril presne – napr. ten „prezentacny“ nemusi ani pouzivat ten isty tym „databazy“ ale kludne tie data moze mat v xml, plain, to je fuk. ide o to, ze ak by som sa rozhodol tie data generovat napr. na disketu, tak to musi aj takto fungovat :-)
Cize – ak by padol cely stroj s CMS, tak mi web pofrci v klude. Ak mi padne SQL, tak mi pofrci web v klude. :)
Neviem, ci som uz zasiahol nad ramec predstavivosti ludi, co roky srotia v trojke PHP, SQL, Apache :-)
[9] k tomu tvojmu inkrementalnemu dam hint: rsync.
Nie je nutne, aby ten system musel zlozito vypocitavat „inkrementalne“ prirastky :)
Potom si skus ten system zostavit sam napojenim viacerych sluzieb na seba. Bud sa to da urobit platformovo nezavisle (teda java / php) alebo to urobit zavislo na OS sluzbach typu rsync (pod win asi nebude)…
[12] fakt sa mijame v predstave :-)
cely vysledok, co by to mohlo robit je ten, ze do nejakeho adresara nasype subory.
k tomu samozrejme nejaky popis formatu, alebo uz hotovy balik kniznic, ktory mi tie data zasa „nacitava“ – priklady skriptov a pod.
Ja to jednoduchsie neviem popisat ako: CMS na jednom nezavislom stroji a web na druhom.
Nezavisle znamena to, ze stroj s CMS a SQL (ak je naozaj nutna) moze kludne padnut do pekiel a na webe sa nic nedeje. A opacne, web mozu napadnut hackeri hocaj zo severnej korei a stroja s CMS sa to ani teoreticky nedotkne. Uz som to popisoval: stroj s CMS moze byt kludne notebook schovany v sufliku (nezalezi na tom ci java alebo apache alebo co tam je) ;-)
Ja len chcem vediet, ci niekto nieco take nevidel :-)
Alebo inak: tipy typu „naprogramuj si to“ alebo „to by islo“ poznam ;-)
nevidel, nepocul. ty v podstate chces nieco, co uz ma dvojvrstvovu bezpecnost a to bezny opensource CMS moc neriesi (ani nema preco: hackli mi blog. no a? ;-) ).
[14] vies, ja som napr. premyslal, ze skusim, ci zafunguje joomla, ked zmazem adresar s administraciou. ale neskusil som to este. snad by som naplatal tam nejaky system s dvomi sql databazami, medzi ktorymi by sa data prenasali kabelovo ale kvoli inym vlastnostiam joomla to nema cenu ani skusat ;-)
No čítal som túto diskusiu už dlho, ale až teraz som azda pochopil, o čo ide :) Možno aj nie.
Podľa mňa, ak by si v Joomla vymazal DB, tak nič sa nestane. Nemám vyskúšané.
ALE CMS Made Simple som práve skúšal. Zmazal som admin adresár. Ostalo mi tam iba SMARTY a nejaké lib súbory, čo je nevyhnutné a myslím, že to aj spĺňa niektoré atribúty, o ktorých si písal. Prehrabal som sa v PHP skriptoch a vyzerá to dosť prehľadne, niektoré som aj upravoval. Je to jednoduchý a vcelku výkonný CMS.
[16] jo bingo, ci najblizsie :-)
v podstate mi ide o to aby mi ludia pospominali co vsetko skusali a tak. tych cmsiek je na mraky a preberat sa vsetkymi je nonsens.
dnes dokonca uvazujem, ze asi nevydam oficialne balik limbo cms prerobeny na table less layout. kto ma zaujem, dostane ho.