De ce am renunțat la WordPress cu 30 de pluginuri

Cel mai frumos site pe care l-am predat vreodată era și cel mai greu de apărat.

Arăta exact cum și-l dorise clientul. Animații care porneau când coborai cu mouse-ul, o galerie care se deschidea peste tot ecranul, un formular care trimitea cererile direct pe email, o hartă, un calendar de programări. Omul a deschis pagina pe telefon, în fața mea, și a zâmbit. Eu mă uitam în altă parte: la lista de pluginuri din panoul de administrare.

Douăzeci și patru. Dintre care unsprezece veniseră odată cu tema, ca pachet.

Nu le alesesem eu. Nu le puteam scoate fără să stric jumătate din ce tocmai îi plăcuse. Și nu știam, pentru niciunul, cine îl scrie, cât de repede îl repară și ce se întâmplă cu el dacă autorul temei se plictisește.

Cum arăta un site livrat de mine

Ani de zile am făcut site-uri pentru clienți, pe WordPress — pe vremea aceea, alegerea implicită pentru un site de prezentare. Foarte rar în PHP scris de mine, de la zero: un site mic nu justifică efortul.

Rețeta era mereu aceeași, și e rețeta pe care o folosește toată lumea: alegi o temă din galerie sau cumperi una pe bani, o potrivești până seamănă cu ce a cerut clientul, adaugi ce lipsește și predai.

Merge. Rezultatul se vede repede, clientul e mulțumit în ziua aceea, iar prețul rămâne cuminte.

Abia peste un an se vede ce ai predat, de fapt — tocmai când nu se mai uită nimeni la site.

De ce sunt greu de apărat tocmai temele frumoase?

Fiindcă o temă frumoasă nu e doar un aspect. E un aspect ținut în picioare de un teanc de pluginuri scrise de autorul temei.

Constructorul de pagini, caruselul de imagini, galeria, formularul, animațiile — toate vin la pachet, iar tema le cere ca să arate așa cum arată în demonstrație. Dacă scoți unul, rămâi cu o pagină ciuntită.

Aici e capcana de arhitectură: pluginurile acelea nu se actualizează în ritmul lor, ci în ritmul temei. Când într-un carusel de imagini apare o vulnerabilitate, cel care l-a scris scoate corecția în câteva zile. Dar tu nu ai caruselul acela — ai copia pe care autorul temei a pus-o în tema lui. Iar corecția ajunge la tine abia când autorul temei scoate o versiune nouă. Dacă o mai scoate.

Între ziua în care problema devine publică și ziua în care tema își scoate actualizarea, site-ul clientului stă cu ușa descuiată. Nu fiindcă a greșit cineva. Fiindcă așa e construit lanțul.

Iar un WordPress cu douăzeci-treizeci de pluginuri și o temă cumpărată nu e un site cu douăzeci-treizeci de riscuri mici. E un site în care fiecare piesă poate deschide ușa pentru toate celelalte, și în care tu, cel care l-ai livrat, nu ai cum să verifici codul niciuneia.

Unde se sparge, de fapt, WordPress?

Datele publice spun același lucru. În raportul Patchstack pentru 2025 au fost înregistrate 11.334 de vulnerabilități noi în ecosistemul WordPress, împărțite astfel:

Unde a fost găsită	Cât din total
Pluginuri	91%
Teme	9%
Nucleul WordPress	6 vulnerabilități în tot anul, toate de prioritate mică

Cifrele nu spun „WordPress e nesigur". Spun ceva mai incomod: nucleul e curat, iar riscul stă aproape în întregime în ce atârnăm noi de el — adică exact în stratul pe care îl alegem, îl cumpărăm și îl instalăm, site după site.

Am încercat disciplina. N-a fost de ajuns.

Soluția la îndemână e să ții lista de pluginuri scurtă și strictă. Am făcut-o, și o recomand în continuare: fără pluginuri abandonate, fără două care fac același lucru, actualizări la zi, nimic instalat „doar să vedem".

Dar disciplina se lovește de un zid pe care nu-l poți muta: pluginurile temei nu sunt opționale. Nu poți ține lista scurtă când unsprezece poziții din ea sunt condiția ca site-ul să arate așa cum l-ai vândut.

Ai de ales între un site frumos pe care nu-l stăpânești și unul pe care îl stăpânești, dar pe care clientul nu-l mai recunoaște.

Am trăit ani de zile între cele două variante. Nu-mi plăcea niciuna.

Dar dacă AI-ul administrează site-ul?

Când au apărut asistenții AI care pot lucra prin MCP — protocolul prin care un model vorbește direct cu o aplicație — am crezut o clipă că am găsit ieșirea.

Există și pentru WordPress: proiectul oficial MCP Adapter, plus câteva pluginuri independente. Legi site-ul de asistent și îi ceri, în cuvinte, să scrie un articol, să schimbe o pagină, să urce o fotografie. Și chiar merge.

Numai că stratul nou stă peste aceeași temelie. Asistentul lucrează prin pluginuri, iar securitatea rămâne exact unde era — în mâna celor douăzeci și patru de bucăți de cod pe care nu le-ai scris tu.

Ba mai mult: acum lanțul are o verigă în plus.

„Motor schimbat" sau fabrică redesenată?

Lecția are o sută de ani și am scris-o pe larg în AI-ul e curentul electric al aplicațiilor.

Curentul electric a ajuns în fabricile americane prin anii 1890, dar câștigurile reale de productivitate s-au văzut abia pe la 1920. Treizeci de ani de diferență. Motivul, arătat de economistul Paul David: la început, fabricile au scos motorul cu aburi și au pus un motor electric în locul lui — restul a rămas neschimbat, cu același arbore comun care învârtea toate mașinile dintr-o hală. Saltul a venit abia când au renunțat la arbore și au pus câte un motor mic la fiecare mașină, ceea ce le-a permis să rearanjeze fabrica după fluxul muncii, nu după poziția arborelui.

Un WordPress cu un plugin de MCP e motorul schimbat. Arborele comun e tot acolo: panoul de administrare, baza de date, stratul de pluginuri, tema care le cere — toate există fiindcă în centrul lor stă un om care dă clic. Asistentul se agață de arborele acela și îl învârte mai repede, dar hala rămâne desenată pentru altcineva.

Întrebarea care schimbă ceva nu e „unde punem un buton cu AI", ci „care e primul pas al fluxului pe care nu mai trebuie să-l facă un om".

Pentru un site de prezentare, răspunsul e neplăcut de simplu: primul pas care dispare e deschiderea panoului de administrare. Dacă locul în care lucrezi devine conversația, panoul nu mai trebuie făcut mai bun. Nu mai trebuie făcut deloc — și odată cu el pică jumătate din stratul pe care nu-l puteai apăra.

De aceea un instrument gândit de la început în jurul asistentului nu e același lucru cu un produs vechi plus AI. Nu e o diferență de funcții, e o diferență de ce mai are voie să existe înăuntru.

Ce am construit în loc

Am scris mini-cms-mcp: un CMS mic pentru site-uri de câteva pagini și un blog, administrat de un asistent AI prin MCP. L-am scris vorbind cu un asistent, nu rând cu rând într-un editor de cod. Și tot vorbind se administrează.

Cifrele, măsurate în ultima versiune:

Ce	Cât
Pachetul complet care se urcă pe găzduire	595 KB, din care 371 KB sunt fonturile temei
Codul propriu-zis, PHP + CSS	sub 220 KB, circa 3.700 de rânduri
Pluginuri, module, biblioteci externe	0
Bază de date	niciuna — conținutul stă în fișiere JSON
Panou de administrare	niciunul
Verificări automate care rulează la fiecare versiune	219

Totul stă pe o singură regulă: AI-ul e singurul editor, dar poate schimba doar conținutul, niciodată codul. Nicio comandă nu scrie fișiere PHP, șabloane, configurare sau jurnal. HTML-ul trece printr-o listă de etichete permise, la scriere și la afișare. Fiecare apel al asistentului e scris într-un jurnal cu lanț de amprente, pe care el îl poate citi, dar nu-l poate modifica.

Codul pe care nu-l scrii nu trebuie actualizat, nu trebuie verificat și nu poate fi exploatat. În două rânduri, aceasta e toată ideea.

Ce nu face

Nu e WordPress și nu vrea să fie. Fără magazin online, fără zeci de autori cu drepturi diferite, fără formulare complicate, fără module de cumpărat. E potrivit pentru zeci sau sute de pagini, nu pentru zeci de mii.

Nu are panou de administrare, deci cine vrea să tragă blocuri cu mouse-ul nu se va împăca cu el. Locul în care lucrezi e conversația.

Nu e un produs cu suport plătit. E o unealtă pe care o folosesc eu, publicată ca să fie de folos și altcuiva, cu codul deschis pe GitHub.

Nu rezolvă site-urile care există deja. Un WordPress cu douăzeci și patru de pluginuri rămâne exact cum e; mini-cms-mcp e o cale pentru site-ul următor, nu o reparație pentru cel de acum.

Întrebări frecvente

De ce nu merge WordPress cu mai puține pluginuri?

Fiindcă disciplina se oprește la tema pe care ai ales-o: pluginurile ei nu sunt opționale, iar aspectul depinde de ele. Dacă tema ta nu aduce pluginuri proprii, un WordPress cu listă scurtă și actualizări la zi rămâne o alegere rezonabilă.

Nu e de ajuns un plugin de AI în WordPress?

Pentru scris, ajută. Pentru productivitate reală, nu: e motorul schimbat într-o hală desenată pentru arborele vechi. Panoul, pluginurile și tema rămân acolo, cu tot cu riscurile pe care le aduc, iar asistentul devine încă o verigă în lanț, nu o simplificare a lui.

Ce se întâmplă cu site-urile pe care le administrez acum?

Rămân cum sunt. Lista scurtă de pluginuri, actualizările la zi și scoaterea celor abandonate sunt tot ce poți face, și chiar ajută. Abordarea din articol e pentru site-ul următor, nu pentru cel de acum.

Unde stă conținutul, dacă nu există bază de date?

În fișiere JSON, într-un dosar blocat din web. Fiecare modificare salvează întâi versiunea anterioară, iar ștergerea mută fișierul între versiuni, deci nimic nu dispare fără urmă. Copia de siguranță e o comandă care aduce tot site-ul pe calculatorul tău.

Dacă AI-ul greșește, ce se strică?

Un text sau o pagină — și amândouă au versiunea dinainte păstrată. Nu poate atinge codul, configurarea sau jurnalul, fiindcă nicio comandă nu scrie așa ceva. Înainte de publicare primești un link de previzualizare care arată pagina exact ca pe site.

Ce găzduire îi trebuie?

Una obișnuită, cu PHP 8.0 și Apache — adică majoritatea pachetelor cu cPanel. Fără Composer, fără bază de date, fără acces SSH, fără sarcini programate.

Cât durează până e pe picioare?

Instalarea are doi pași: o comandă pe calculatorul tău și un zip urcat în cPanel. Am scris drumul întreg, cu capturi reale, în ghidul de instalare.

Ce dispare din munca ta

Lista de pluginuri pe care n-o poți verifica. Actualizările care vin când vrea altcineva. Panoul de administrare în care intri de două ori pe an și nu mai ții minte unde era butonul.

Rămâne o conversație: ceri o pagină, te uiți la previzualizare, spui „publică".

Codul e deschis, pe github.com/paycodero/mini-cms-mcp, și poate fi citit integral într-o după-amiază — ceea ce, pentru mine, e diferența dintre a livra un site și a-l putea apăra. Dacă vrei să vezi de unde vine și cine îl scrie, am povestit pe pagina Despre.

Site-ul acela frumos, cu galerie peste tot ecranul, rulează și azi. L-am predat cu tot cu parole, cu o listă scrisă de mână a pluginurilor și cu rugămintea să mă sune dacă ceva pare ciudat.

M-a sunat. De două ori.

Surse

• Patchstack — State of WordPress Security in 2026 (datele pentru 2025: 11.334 de vulnerabilități noi, 91% în pluginuri, 9% în teme, 6 în nucleu)
• MCP Adapter — proiectul oficial WordPress care expune site-ul unui asistent AI prin MCP
• AI-ul e curentul electric al aplicațiilor — electrificarea fabricilor, arborele comun și cei treizeci de ani de așteptare (după Paul David, 1990)