WordPress 7.0 a apărut pe 20 mai 2026 sub numele de lansare Armstrong, cu șase săptămâni mai târziu decât data din calendarul inițial pentru 2026, și este cea mai importantă versiune de nucleu pentru agenții de la block editor încoace. Titlul este că nucleul poate acum să vorbească cu modele de IA generativă. Detaliul care contează mai mult este că nucleul stabilește și cum ar trebui să vorbească un plugin cu ele, iar asta schimbă discret ce are voie să presupună fiecare plugin despre propriul teritoriu.

Pentru un editor, schimbările vizibile sunt modeste: o Command Palette, un panou mai ordonat, un ecran de gestionare a fonturilor și revizii mai bune. Pentru cine întreține site-uri profesionist, schimbările importante stau sub administrare: un depozit de credențiale în tabelul de opțiuni, un registru al lucrurilor pe care le poate face site-ul și o suprafață REST care le enumeră. Nimic din toate acestea nu este opțional, fiindcă vine cu nucleul, nu cu un plugin ales de cineva.

Aceasta este citirea practicianului. Ce a ajuns cu adevărat, ce a fost retras cu douăsprezece zile înainte de lansare și de ce, ce strică actualizarea și ce nu, și ce îi spuneți unui client care tocmai a citit un titlu despre IA în WordPress.

Merită să actualizați? Da, dar mergeți până la 7.1, nu vă opriți la 7.0. WordPress 7.1 a apărut pe 19 august 2026, iar 7.0 are patru lansări de mentenanță în urmă. Funcțiile de IA rămân inerte până când un administrator salvează o cheie de furnizor în Setări, apoi Connectors, deci actualizarea singură nu trimite nimic din conținutul dumneavoastră nicăieri. Riscul real aici este compatibilitatea obișnuită a pluginurilor și temelor, nu IA.

Ce a livrat de fapt WordPress 7.0

Lansarea poartă numele lui Louis Armstrong, urmând convenția proiectului de a boteza versiunile majore după muzicieni de jazz. Anunțul de lansare creditează peste 875 de contribuitori și peste 420 de îmbunătățiri și corecturi.

Lista celor ajunse este destul de scurtă cât să fie utilă. Nucleul a primit un AI Client, o interfață PHP independentă de furnizor pentru trimiterea de prompturi către modele generative. A primit un ecran Connectors în Setări, unde un administrator păstrează credențialele furnizorului. A primit jumătatea JavaScript a Abilities API, a cărei jumătate PHP apăruse deja în 6.9.

Pe partea editorială există o Command Palette pe Ctrl+K sau Cmd+K, un panou modernizat, o pagină dedicată gestionării fonturilor, parcurgerea vizuală a reviziilor și noile blocuri Heading, Breadcrumbs și Icons, alături de o prezentare în lightbox pentru galerii.

Ce nu a ajuns a fost tocmai funcția în jurul căreia fusese construită întreaga lansare. Editarea colaborativă în timp real a fost eliminată cu douăsprezece zile înainte de lansare. Absența aceasta, și motivul din spatele ei, spun mai multe despre starea actuală a nucleului decât lista de funcții.

De ce s-a mutat data

Lansarea era programată inițial pentru 9 aprilie 2026. A alunecat spre 20 mai fiindcă editarea colaborativă nu era gata, iar proiectul nu voia să o publice în starea aceea. Articolul despre drumul înainte spune explicit că amânarea a existat pentru a lăsa mai mult timp reacțiilor din teste privind implementarea colaborării în timp real, iar ciclul s-a întors în beta păstrând din motive tehnice numerele de versiune ale candidaților de lansare.

Este ceva neobișnuit. O versiune majoră care se întoarce în beta după ce a ajuns la release candidate este un semnal puternic, iar decizia a fost cea corectă.

AI Client: nucleul livrează abstractizarea, nu modelul

Cel mai important fapt arhitectural despre WordPress 7.0 este că nucleul nu include niciun model de IA, nicio cheie API și nicio relație cu vreun furnizor. Nota de dezvoltare despre AI Client afirmă limpede că nucleul WordPress nu include direct niciun furnizor de IA.

Ceea ce livrează nucleul este o interfață PHP coerentă. Un plugin apelează wp_ai_client_prompt(), care întoarce un obiect WP_AI_Client_Prompt_Builder, înlănțuie configurația precum using_temperature() sau using_model_preference() și se încheie cu generate_text() sau generate_image(). Erorile revin ca WP_Error, cererile trec prin transportul HTTP al WordPress, iar totul este legat de sistemul de hookuri.

Efectul practic este că autorul unui plugin nu mai scrie un client HTTP, o buclă de reîncercare, un ecran de păstrare a cheii și o pagină de setări pentru fiecare furnizor de modele. Descrie ce vrea, iar nucleul rutează.

Este o reducere reală de cod duplicat. Este totodată o centralizare a încrederii, iar aceasta este partea la care merită să vă gândiți înainte de a porni ceva.

Ce este un connector

Un connector este relația înregistrată dintre site-ul dumneavoastră și un serviciu extern. În 7.0 singurul tip de connector este cel al furnizorilor de IA, iar există trei pluginuri de referință care acoperă Anthropic, Google și OpenAI, fiecare instalat separat.

Nota de dezvoltare despre Connectors API descrie cum se rezolvă credențialele. O cheie poate veni dintr-o variabilă de mediu, dintr-o constantă PHP sau dintr-o setare din baza de date, verificate în această ordine, cu nume de opțiune care urmează tiparul connectors_ai_{$id}_api_key.

Un detaliu merită atenția oricui răspunde de un site. Nota spune că cheile API păstrate în baza de date nu sunt criptate, ci doar mascate în interfață, criptarea fiind consemnată ca lucrare ulterioară. Dacă setați o cheie din ecranul de administrare, ea stă în clar în wp_options, iar fiecare copie de rezervă a acelei baze conține de acum o credențială pentru care se plătește.

Ce înseamnă dacă nu scrieți cod

Pentru proprietarul unui site, schimbarea este mai simplă decât pare. Nimic nu generează, nu rezumă și nu rescrie nimic până când nu sunt adevărate două lucruri: este instalat un plugin de furnizor și cineva a lipit o cheie funcțională în Setări, apoi Connectors.

Până atunci, AI Client este o bibliotecă adormită. Actualizarea la WordPress 7.0 nu vă trimite articolele către un model, nu creează niciun cont nicăieri și nu produce nicio factură.

Ce face, în schimb, este să coboare pragul pentru următorul plugin pe care îl instalați. Un plugin care înainte trebuia să vă ceară o cheie poate găsi acum una deja configurată pe site și o poate folosi. Este comod și este exact lucrul despre care merită scrisă o politică înainte să se întâmple din greșeală.

Abilities API și de ce se schimbă proiectarea pluginurilor

Abilities API este piesa care va conta și peste trei ani, iar în sine nu are nimic de-a face cu IA. Este un registru. Un plugin înregistrează o unitate de funcționalitate cu nume prin wp_register_ability(), în forma namespace/ability-name, cu o descriere lizibilă, JSON Schema pentru intrări și ieșiri, un callback de execuție și un callback de permisiune opțional.

Documentația oficială arată callbackul de permisiune drept o verificare obișnuită de capabilitate, care întoarce de exemplu current_user_can( 'manage_options' ). Acesta este întregul model de securitate și valorează exact cât judecata autorului pluginului.

Odată ce abilities există, alte programe le pot enumera. Unui model i se poate da lista lucrurilor pe care le poate face tocmai acel site, în formă de schemă, iar modelul poate apela una dintre ele. La fel poate și o Command Palette din partea clientului, motiv pentru care jumătatea JavaScript a API-ului a apărut în aceeași versiune cu paleta.

Consecința de proiectare pentru autorii de pluginuri este reală. O funcție accesibilă înainte doar prin propriul ecran de administrare, cu propriul nonce și propriul formular, este acum ceva ce s-ar putea aștepta de la dumneavoastră să expuneți ca ability, cu un contract citibil de mașini. Este altă suprafață de risc și altă povară de documentare.

Ce s-a schimbat în 7.1

WordPress 7.1 a strâns registrul, nu l-a lărgit. Nota de dezvoltare despre abilities în 7.1 adaugă filtrele de validare wp_ability_validate_input și wp_ability_validate_output, o acțiune wp_ability_invoked care se declanșează la începutul execuției și un indicator de metadate public care stabilește dacă o ability poate fi descoperită prin REST la /wp-json/wp-abilities/v1/abilities.

Acea notă poartă și fraza pe care ar trebui să o citească orice autor de plugin de jurnalizare. Hookul de invocare primește intrări brute, nenormalizate, iar dezvoltatorii ar trebui să evite jurnalizarea nediscriminată a intrărilor, fiindcă acestea pot conține credențiale, date personale sau alte informații sensibile.

Colaborarea în timp real și tabelul de care avea nevoie

Editarea colaborativă se sprijină pe Yjs, un tip de date replicat fără conflicte, cu o abstractizare pentru furnizorii de sincronizare. Nucleul include implicit un furnizor bazat pe interogare HTTP, ales în locul WebSocket fiindcă funcționează la orice găzduire, iar pluginurile pot schimba transportul printr-un filtru.

Problema nu a fost niciodată algoritmul de îmbinare. A fost locul în care stăteau datele de sincronizare. Implementarea inițială le păstra în post meta, alegerea evidentă în WordPress și cea greșită pentru date care se schimbă de mai multe ori pe secundă.

Scrierile în post meta declanșează invalidarea memoriei cache. Cu editorul deschis, datele de sincronizare se scriau continuu, deci fiecare scriere golea interogările din cache pentru articolul respectiv. În practică, o singură persoană care edita o pagină putea ține memoria cache persistentă de obiecte a site-ului într-o golire continuă pe toată durata sesiunii.

Este o lecție generală bună despre post meta. Sunt un depozit cheie valoare legat de ciclul de viață al memoriei cache a conținutului de care atârnă și sunt potrivite pentru atribute care se schimbă odată cu articolul. Nu sunt un spațiu de lucru pentru stări de frecvență mare.

Soluția măsurată și decizia

Contribuitorii au testat strategii de stocare în opt medii de găzduire. Analiza de performanță a concluzionat că un tabel dedicat sprijinit pe tranzienți era cu circa 52% mai rapid decât implementarea existentă, iar un tabel dedicat simplu cu circa 37% mai rapid. Cu o memorie cache persistentă de obiecte prezentă, ambele strategii cu tranzienți coborau la o singură interogare de bază de date pentru fiecare trimitere.

A fost ales tabelul propriu cu tranzienți. Apoi, în aceeași zi, funcția a fost retrasă.

Anunțul de eliminare invocă îngrijorări privind suprafața expusă, condițiile de cursă, încărcarea serverului, eficiența memoriei și erorile recurente găsite prin fuzz testing și spune că decizia a fost luată pentru a livra utilizatorilor un WordPress 7.0 stabil și de încredere.

Unde se află lucrurile acum

Nu a apărut nici în 7.1. Ghidul de teren pentru 7.1 precizează că editarea colaborativă în timp real a primit testare și reacții ample în ciclul WordPress 7.1, dar că nu este activată în versiunea finală.

Notes, funcția înrudită dar distinctă pentru comentarii la nivel de bloc, a apărut și a fost îmbunătățită în 7.1 cu formatare de text îmbogățit și mențiuni cu @. Dacă un client cere editare simultană în stil Google Docs în WordPress, răspunsul onest astăzi este că Notes acoperă fluxul de revizuire, iar scrisul simultan tot nu se află în nucleu.

Modificările din administrare și tichetele pe care le generează

Două schimbări vor produce solicitări de asistență și niciuna nu este o eroare.

Command Palette pe Ctrl+K sau Cmd+K este cu adevărat rapidă odată învățată, dar Ctrl+K este scurtătura pentru inserarea unui link în multe editoare, iar unii utilizatori vor raporta că inserarea de linkuri s-a stricat. Nu s-a stricat; contextul focalizării decide care handler câștigă.

Panoul modernizat este chestiunea mai mare. Orice client al cărui personal a fost instruit pe capturi de ecran are acum material de instruire depășit, iar orice plugin care injecta marcaj în ecranele de administrare presupunând anumite clase sau o anumită structură DOM poate arăta ciudat. Este o problemă cosmetică, nu funcțională, dar apare chiar în ziua actualizării, pe fiecare site, pentru fiecare utilizator, ceea ce o face partea cea mai vizibilă a lansării pentru cei care nu sunt dezvoltatori.

Alocați o oră pentru fiecare client pentru o notă scurtă scrisă, cu capturi noi, înainte de a actualiza ceva. Costă mai puțin decât aceeași explicație dată de cincisprezece ori pe e-mail.

Întrebarea de compatibilitate care contează cu adevărat

Numerotarea versiunii sugerează o lansare care rupe lucruri. Cerințele PHP spun altceva. Așa cum stabilește clarificarea privind suportul PHP, versiunea minimă de PHP acceptată este 7.4 începând cu WordPress 7.0, iar versiunea minimă recomandată rămâne 8.3. Suportul pentru PHP 7.2 și 7.3 a fost abandonat în această lansare.

Clarificarea a retras și vechea etichetă beta pentru versiunile mai noi de PHP și consemnează suportul complet pentru PHP 8.5 în WordPress 6.9 și 7.0.

Distanța dintre acceptat și rezonabil este esența. PHP 7.4 a ajuns la finalul vieții în noiembrie 2022, deci un site care abia trece de minim rulează pe un interpretor care nu a mai primit corecții de securitate de aproape patru ani. Dacă găzduirea dumneavoastră este încă pe 7.4 în 2026, versiunea de WordPress nu este cea mai urgentă problemă.

Ruperile urmează în practică un tipar previzibil. Pluginurile abandonate cedează primele, mai ales orice manipulează DOM-ul administrării sau iframeul editorului. Temele personalizate cu stil de administrare scris de mână arată greșit. Constructorii de pagini care își aduc propriile pachete React sunt sursa obișnuită a paginilor albe în editor și tot ei sunt de obicei cei mai rapizi la corecturi.

O procedură concretă de actualizare

Pregătiți un mediu de staging. Clonați producția, inclusiv baza de date, într-un mediu care nu poate fi indexat și care nu trimite e-mailuri. Nimic din ce urmează nu merită făcut pe un site aflat în funcțiune.

Consemnați starea inițială. Notați versiunea PHP, lista pluginurilor și a temelor cu versiuni și versiunea curentă de WordPress. Faceți capturi ale celor două sau trei ecrane de administrare pe care clientul le folosește zilnic.

Actualizați mai întâi doar WordPress. Lăsați pluginurile și temele neatinse, apoi parcurgeți partea publică, editorul de articole, editorul de site, finalizarea comenzii WooCommerce dacă există și orice ecran de administrare personalizat. O defecțiune aici aparține nucleului sau unei extensii incompatibile, iar separarea ei de o actualizare de plugin este întregul motiv al acestei ordini.

Apoi actualizați pluginurile în loturi mici, retestând între loturi, ca o regresie să aibă o listă scurtă de suspecți.

Verificați jurnalele de erori în loc să priviți paginile. Notificările PHP dintr-un apel învechit nu se afișează întotdeauna vizibil și umplu în tăcere un jurnal luni la rând.

Lăsați gol ecranul Connectors. Livrați actualizarea fără niciun furnizor de IA configurat și tratați activarea ca pe o schimbare separată și deliberată, cu aprobarea ei. Lista noastră de verificare pentru securizarea WordPress acoperă controalele din jur, iar ghidul de audit al performanței acoperă ce trebuie măsurat după aceea.

Guvernanță: ce are voie să facă un connector

Iată întrebarea pe care o creează stratul de abilities și la care niciun autor de plugin nu poate răspunde în locul dumneavoastră. Un plugin terț poate înregistra o ability care citește fișe de clienți, exportă utilizatori sau modifică conținut publicat, iar un model cu acces la registru o poate apela. Callbackul de permisiune este o verificare de capabilitate, deci modelul acționează cu drepturile persoanei autentificate.

Dacă persoana aceea este administrator, modelul poate face lucruri de administrator. Nu este un defect al proiectării, ci proiectarea funcționând așa cum este documentată. Înseamnă însă că decizia privind ce connectors există pe un site este o decizie de protecție a datelor, nu o preferință de IT.

Conținutul dintr-un CMS este rareori doar text de marketing. Comentariile, formularele trimise, datele comenzilor și profilurile utilizatorilor sunt date cu caracter personal, iar trimiterea lor către un model extern este o prelucrare pe care trebuie să o puteți justifica. Ghidul ICO privind IA și protecția datelor stabilește așteptările de responsabilitate și transparență, inclusiv protecția datelor începând cu proiectarea.

Minimul practic pentru un site de client este o politică scurtă și scrisă: ce connectors sunt permise, cine poate adăuga unul, ce abilities sunt expuse public prin REST și care este poziția privind păstrarea datelor la furnizor. Scrieți-o înainte ca cineva să lipească o cheie, fiindcă după aceea devine un raport de incident, nu o politică.

Ce urmează

WordPress 7.1 a sosit pe 19 august 2026 cu controale de stil adaptive în Global Styles, o bară de administrare persistentă între editoare, o fereastră modală adevărată pentru editarea media, blocurile Playlist și Tabs și îmbunătățirile la Notes deja menționate. A încheiat totodată trecerea la un editor de articole într-un iframe, inclusiv pentru site-urile care înregistrează casete meta clasice, iar aceasta este schimbarea cu cele mai mari șanse să dea în vileag un plugin vechi.

WordPress 7.2 este planificat ca ultima versiune majoră a anului 2026. Pagina lansării 7.2 plasează versiunea finală în intervalul 8 până la 10 decembrie 2026, cu beta din a doua parte a lunii octombrie. Calendarul acela este planificat, nu livrat, iar proiectul a mutat deja o dată de lansare majoră anul acesta.

Editarea colaborativă rămâne candidatul evident pentru o versiune viitoare, dar a ratat deja două, iar nimeni nu ar trebui să promită unui client o dată pentru ea.

Ce se schimbă din punct de vedere comercial

Se schimbă trei discuții cu clientul și doar una dintre ele este despre IA.

Prima este discuția despre actualizare. WordPress 7.0 și 7.1 merită facturate ca actualizare gestionată, cu o trecere prin staging, fiindcă editorul din iframe și noua administrare chiar scot la iveală extensiile vechi. Vânzarea ei ca pachet cu preț fix și plan de testare scris este mai onestă și mai profitabilă decât absorbirea într-un abonament și descoperirea unui constructor de pagini stricat la ora șase seara.

A doua este guvernanța. Politica privind connectors, revizuirea abilities și gestionarea credențialelor sunt muncă de consultanță facturabilă care nu exista înainte de mai 2026 și se potrivesc unei agenții mult mai bine decât unei echipe interne de marketing.

A treia este munca de construcție. AI Client elimină jumătatea plictisitoare din construirea unei funcții de IA într-un site, ceea ce scade prețul instalației și ridică valoarea faptului de a ști ce merită construit. Dacă puneți asta în balanță cu o dezvoltare la comandă, comparația noastră între WordPress și dezvoltarea personalizată arată unde cade de obicei linia, iar notele noastre despre tarifele dezvoltatorilor WordPress arată cât ar trebui să coste munca.

Mecanik se ocupă de actualizările de versiune ale nucleului, de guvernanța connectors și de lucrul la funcțiile de IA ca parte din serviciile noastre de dezvoltare WordPress și de integrare a IA. Tiparul pe care îl vedem este constant: actualizarea în sine este de rutină, iar surprizele costisitoare vin din extensii pe care nimeni nu le-a revizuit de trei ani.

Întrebări frecvente

Când a apărut WordPress 7.0 și de ce a fost amânat? WordPress 7.0, cu numele de lansare Armstrong, a apărut pe 20 mai 2026, cu șase săptămâni după data de 9 aprilie din calendarul inițial. Amânarea a servit rezolvării reacțiilor din teste privind implementarea editării colaborative în timp real, iar ciclul s-a întors în beta după ce ajunsese la release candidate. Editarea colaborativă a fost în cele din urmă eliminată din lansare pe 8 mai 2026.

Trimite WordPress 7.0 conținutul meu către un furnizor de IA? Nu. Nucleul include un AI Client, dar niciun furnizor de IA, niciun model și nicio cheie API. Nimic nu este trimis nicăieri până când un administrator nu instalează un plugin de furnizor și nu salvează o credențială funcțională în Setări, apoi Connectors. Până atunci, AI Client este o bibliotecă adormită, care nu costă nimic și nu transmite nimic.

La ce folosește Abilities API? Este un registru care permite unui plugin să declare o unitate de funcționalitate cu nume, cu intrări și ieșiri în JSON Schema, un callback de permisiune și un callback de execuție. Alte programe, inclusiv modelele de IA și Command Palette, pot apoi enumera ce poate face un site și pot apela funcția. Jumătatea PHP a apărut în WordPress 6.9, iar cea JavaScript în 7.0.

Ce versiune de PHP cere WordPress 7.0? Versiunea minimă acceptată este PHP 7.4 începând cu WordPress 7.0, care a renunțat la suportul pentru PHP 7.2 și 7.3. Versiunea minimă recomandată rămâne PHP 8.3. Fiindcă PHP 7.4 a ajuns la finalul vieții în noiembrie 2022, oprirea la minim înseamnă un interpretor fără suport, așa că tratați 8.3 sau mai nou drept cerința reală.

Este disponibilă deja editarea colaborativă în timp real? Nu în nucleu. A fost eliminată din WordPress 7.0 cu douăsprezece zile înainte de lansare, din cauza îngrijorărilor privind condițiile de cursă, încărcarea serverului și eficiența memoriei, iar în WordPress 7.1 nu este activată. Funcția separată Notes, care permite comentarii la nivel de bloc cu mențiuni, a apărut și acoperă fluxurile de revizuire, nu scrisul simultan.