Simpleng CMS: Bakit Mas Maganda ang Maliit kaysa Malaki para sa Karamihan ng Websites

Noong nakaraang tagsibol, inako ko ang isang brochure site para sa isang maliit na law firm. Limang pahina, isang contact form, isang mapa. Tumakbo ito sa WordPress na may 23 plugins, isang page builder na walang naalalang nag-install, at isang database na may siyam na taong spam comments. Ang site ay hindi gumagawa ng higit sa isang tumpok ng HTML files, ngunit kailangan ng buwanang updates, isang security plugin, isang caching plugin, at isang backup plugin para may kasama ang caching plugin. Ang trabahong iyon ang dahilan kung bakit ngayon ay ibinibigay ko sa bawat client ang parehong patakaran: gamitin ang pinakamaliit na tool na kayang gawin ang trabaho. Para sa karamihan ng sites, ang tool na iyon ay isang simpleng CMS.

Tinalakay ng artikulong ito kung ano talaga ang simpleng CMS, ang maintenance costs na hindi isinasaad ng malalaking systems sa invoice, at kung paano malalaman kung aling panig ng linya nandoon ang iyong site.

Ano talaga ang simpleng CMS

Bawasan ang termino at gumagawa ang CMS ng tatlong bagay: iniimbak nito ang iyong content, hinahayaan kang i-edit ang content na iyon nang walang FTP client, at nagre-render ng pages para sa mga bisita. Ginagawa ng simpleng CMS ang tatlong bagay na iyon nang pinakakaunting moving parts hangga't maaari, karaniwang walang MySQL server, walang plugin marketplace, walang theme framework na may sariling release cycle.

• Ang mga Flat-file CMS tulad ng Grav, Bludit, o Pico ay nag-iimbak ng content bilang Markdown o JSON files sa mga folder. Ang site ay mismong file tree.
• Ang mga Single-file CMS tulad ng WonderCMS o ng Restorix CMS ay isinasiksik ang buong admin panel sa isang PHP file na katabi ng iyong content.
• Ang mga Static site generator ay isang hakbang pa: walang live admin talaga, HTML lang na rebuilt sa bawat pagbabago. Maganda, hanggang sa gusto ng client ayusin ang typo nang 9 ng gabi.

Ang isusuko mo ay user accounts, editorial workflows, comments, at isang plugin para sa bawat okasyon. Ang babalik sa iyo ay isang site na sapat na maliit upang kayanin ng iyong isip.

Ang maintenance bill na hindi binabanggit ng sinuman

Hindi kontrabida ang WordPress mismo. Ang pabigat ay mula sa lahat ng umiikot dito. Ang core ay gusto ng updates. Ang theme ay gusto ng updates. Ang bawat isa sa iyong 15 hanggang 40 plugins ay gusto ng updates sa sariling iskedyul, isinulat ng iba't ibang tao, sinusubok sa iba't ibang bersyon. Bawat update ay isang maliit na lottery ticket: karaniwang ayos lang, paminsan-minsan ay white screen sa isang Sabado.

Ito ang aritmetika na ipinapakita ko sa mga client. Kailangan ng isang tipikal na maliit na WordPress site:

• Pagsusuri at paglalapat ng updates: 30 hanggang 60 minuto kada buwan, mas marami sa mga buwan na may nasisira.
• Mga backup na talagang nasubok mo: 30 minuto pa, at dapat mong test-restore kada quarter.
• Database hygiene: revisions, transients, spam, orphaned metadata. Laktawan ito at hahatak ng isang 50-pahinang site ang isang 400 MB database.
• Pagsubaybay sa seguridad: kapag nagbukas ng vulnerability ang isang sikat na plugin, nagsisimula ang iyong patch clock. Ang mga incident-response report mula sa mga firm tulad ng Sucuri ay madalas na sinusubaybay ang malaking bahagi ng CMS infections sa mga out-of-date plugins at themes.

Binababaligtad ng isang flat-file site ang karamihan sa listahang iyon. Walang database na lilinisin o i-i-inject. Ang attack surface ay lumiliit sa isang admin file at iyong PHP version. Ang mga backup ay nagiging cron job na nag-rsync ng folder. Mayroon akong flat-file sites na tumakbo ng tatlong taon sa pagitan ng logins at nakaligtas sa isang server move nang walang drama.

Flat-file vs database: ano ang nagbabago araw-araw

Pansinin na wala sa mga ito ay tungkol sa benchmark charts. Ang isang cached na WordPress site at isang flat-file site ay parehong mabilis maghatid ng pages. Ang pagkakaiba ay lumalabas sa ika-sampung buwan, kung kailan ang simpleng site ay wala pa ring kailangan at ang malaki ay kailangan ang buwanang oras ng pansin.

Mga single-file CMS: ang matinding dulo ng simple

Ang pinakaradikal na bersyon ng ideya ay ang single-file CMS: ang buong admin, editing, saving, file management, sa loob ng isang PHP file. Itinayo ng WonderCMS ang buong pagkakakilanlan dito, na nagbibigay ng admin bilang nag-iisang index.php. Ginamit namin ang parehong ruta sa aming Restorix CMS: isang file sa /webarchive-cms.php, idinagdag sa bawat restored site na ide-deploy namin, na may content editing, site-wide search & replace, at file manager sa loob.

Bakit pipigilin ng sinuman ang isang CMS sa isang file? Tatlong praktikal na rason:

1. Walang install. Walang wizard, walang database credentials, walang version matrix. I-upload ang file, buksan, i-edit.
2. Walang footprint. Burahin ang file at ang site ay muling plain HTML. Walang nagtatago sa database na nakalimutan mong i-export.
3. Mahirap sirain. Ang Restorix CMS ay nagpapadala na naka-on ang safe mode bilang default, at bawat deployed site ay nakakakuha ng sariling randomly generated admin password, na ipinapakita sa iyong dashboard. Maliit na surface, maliit na blast radius.

Hindi kailanman magpapatakbo ang isang one-file admin ng online magazine, at hindi naman iyon ang layunin. Umiiral ito upang ma-edit ang isang 40-pahinang company site nang dalawang beses sa isang taon nang hindi kumukuha ng taong tatandaan kung paano gumagana ang admin.

Saan nagkukulang ang isang simpleng CMS

Mas pipiliin kong mawala ang deal kaysa ibenta ang maling tool, kaya narito ang tapat na listahan. Laktawan ang simpleng CMS kapag:

• Nagbebenta ka ng mga bagay. Totoong catalog, cart, taxes, invoices, ang WooCommerce o isang dedicated shop platform ay karapat-dapat sa complexity nito. Ang store ng isang client na may 800 SKUs ay hindi flat-file candidate.
• Maraming kamay ang humahawak ng content. Mga editorial role, approval flow, per-user permissions. Karaniwang umaasa ang mga simpleng system sa isang admin.
• Relational ang content. Mga event na naka-link sa venues na naka-link sa cities, faceted filtering sa limang taxonomies. Ito ang home turf ng database.
• Kailangan mo ng accounts, forums, o comments. Ang isang 2009 phpBB forum na may 60,000 posts ay mananatili sa database. Period.
• Alam na ng team ang isang malaking CMS. Minsan mas mahal ang retraining kaysa maintenance. Nakakabagot, pero totoo.

Panuntunan: kung kailangang mag-log in at gumawa ng mga bagay sa iyong site ang mga estranghero, kailangan mo ng database. Kung magbabasa lang ang publiko, malamang hindi.

Isang mabilis na decision checklist

Sagutin ang limang tanong na ito bago pumili ng kahit ano:

1. Ilang pahina ang magkakaroon ito sa loob ng dalawang taon? Sa halos 500 pababa ay ayos lang bilang flat files.
2. Sino ang nag-e-edit, at gaano kadalas? Buwanang edits ng isang tao ay pabor sa simpleng tooling.
3. Nakikipag-interact ba ang publiko, accounts, carts, comments? Anumang oo ay itutulak sa iyo patungo sa database.
4. Sino ang magmamaintain nito pagkatapos ng launch? Kung ang tapat na sagot ay 'wala talaga', ang simplicity ay isang feature, hindi compromise.
5. Anong mangyayari kung ma-hack o mamatay ang host? Sa isang simpleng CMS, ang tapat na sagot ay 'i-upload ulit ang folder'.

Kung apat o lima ang iyong puntos patungo sa 'maliit at read-only', makakatipid ka ng totoong pera sa loob ng tatlong taon gamit ang isang simpleng CMS, karamihan sa mga oras na hindi mo na gagastusin.

Paano subukan ang isang simpleng CMS sa isang tunay na site

Hindi mo kailangan ng greenfield project para subukan ang ideya. Dalawang low-risk na ruta:

Una, i-rebuild ang isang maliit na umiiral na site. Kunin ang limang-pahinang brochure site na iyon, kopyahin ang text, at i-rebuild sa Grav o Bludit sa ilalim ng isang subdomain. Saklaw ng isang weekend, kasama ang learning curve. Kung na-edit ng client nang hindi ka tinatawag, pumasa ang eksperimento.

Pangalawa, ang rutang nakakalimutan ng mga tao, i-restore ang isang lumang site na nawala mo na. Kung namatay ang isang site dahil sa expired domain o lapsed hosting plan, ang mga pahina nito ay karaniwang nandoon pa rin sa Wayback Machine. Ipasa ito sa isang free estimate: binibilang ng Restorix ang mga archived files at kinakandado ang presyo bago ka magbayad, tapos ide-deploy ang restore sa iyong hosting na may naka-install na single-file CMS. Ang babalik sa iyo ay hindi isang frozen museum copy kundi isang maliit na editable site, na eksakto ang niche na pinupunan ng isang simpleng CMS. Kung may mabigo, awtomatikong mapupunta ang refund sa iyong balance.

Anuman ang ruta, ang test ay tumatagal ng mga araw, hindi buwan. Iyon ang buong punto ng simple.