WordPress 7.1 e programat să ajungă la lansare generală pe 19 august 2026, în ultima zi a WordCamp US din Phoenix, Arizona — a doua versiune majoră a anului, după 7.0 „Armstrong”, condusă de data aceasta de Anne McCarthy. La momentul scrierii acestui articol, versiunea se află încă în etapa de beta, cu Beta 4 deja publicată și Release Candidate 1 programat pentru 5 august.
Spre deosebire de WordPress 7.0, care a adus schimbări vizibile imediat — dashboard redesenat, Command Palette, AI nativ —, 7.1 se concentrează mai mult pe rafinarea experienței de editare și pe o schimbare de infrastructură cu impact mai puțin vizibil pentru utilizatorul obișnuit, dar semnificativ pentru oricine dezvoltă teme sau plugin-uri.
Schimbarea de infrastructură: trecerea completă la React 19
Cel mai important element „din culise” al acestei versiuni e migrarea completă de la React 18 la React 19, framework-ul JavaScript pe care se bazează întregul editor de blocuri. Pentru un software care rulează pe peste 40% din internet, un salt de framework de această amploare nu e o simplă chestiune de întreținere tehnică — atinge editorul de blocuri, mii de plugin-uri, și orice temă care se bazează pe funcționalități moderne de editare.
Pentru utilizatorul final, această schimbare va fi, în cel mai bun caz, invizibilă — editorul ar trebui să funcționeze la fel, poate ceva mai eficient. Pentru dezvoltatori, însă, e exact genul de schimbare care poate scoate la iveală incompatibilități neanticipate în cod care depindea de comportamente specifice React 18, motiv pentru care echipa a alocat un ciclu extins de testare beta pentru această versiune.
De ce contează un salt de framework în sine: React 19 schimbă modul în care componentele gestionează stările interne, introduce noi convenții pentru gestionarea formularelor și acțiunilor asincrone, și elimină unele API-uri considerate depășite în React 18. Pentru un plugin construit corect, respectând convențiile standard, tranziția ar trebui să fie transparentă. Pentru cod mai vechi, scris înainte ca aceste convenții să fie stabile, sau care depinde de comportamente nedocumentate ale versiunii anterioare, tranziția poate scoate la iveală erori subtile — un buton care nu mai răspunde corect la click, un formular care nu-și mai păstrează starea între interacțiuni, sau o previzualizare care nu se actualizează instant cum ar trebui.
Editorul iframat, obligatoriu pentru temele bazate pe blocuri
O altă schimbare tehnică semnificativă: editorul iframat (izolat într-un cadru separat, similar cu felul în care funcționează un video încorporat pe o pagină) devine obligatoriu pentru toate temele bazate pe blocuri, nu doar opțional cum era anterior. Această izolare ajută la o previzualizare mai fidelă a modului în care arată efectiv conținutul pe site, dar poate afecta teme sau plugin-uri care depindeau de acces direct la contextul global al paginii din editor, în afara acelui cadru izolat.
Dacă administrezi un site cu o temă puternic personalizată sau cu plugin-uri de editor mai vechi, acest aspect specific merită verificat prioritar în faza de testare, alături de compatibilitatea React 19.
Feature-ul principal, vizibil pentru toată lumea: stiluri responsive direct în editor
Elementul cel mai probabil să atragă atenția majorității utilizatorilor: stilurile responsive și stările interactive — hover, focus, active — devin controale native ale editorului, în loc să necesite CSS personalizat scris manual. Practic, poți defini cum arată un buton la trecerea mouse-ului peste el, sau cum se comportă un element pe ecran mic față de unul mare, direct din interfața vizuală a editorului, fără să deschizi un editor de cod.
Pentru cineva care administrează singur un site, fără cunoștințe de CSS, această schimbare elimină o barieră reală — anterior, orice ajustare de tip „vreau ca acest buton să se schimbe de culoare la hover” cerea fie cunoștințe tehnice, fie un plugin suplimentar. Pentru dezvoltatori, funcționalitatea reduce nevoia de cod personalizat pentru cazuri comune de stilizare, deși codul personalizat rămâne, desigur, opțiunea pentru orice necesită control mai fin.
Blocuri noi: Playlist și Tabs, cu Table of Contents pe fir
Două blocuri noi sunt confirmate deja în versiunile beta: Playlist, pentru afișarea unei liste de fișiere media redabile secvențial, și Tabs, pentru organizarea conținutului în file navigabile — util pentru pagini cu informație structurată pe categorii (de exemplu, specificații tehnice separate de recenzii, pe o pagină de produs). Foaia de parcurs a versiunii menționează și un bloc de Table of Contents (cuprins automat), deși statutul lui exact în beta rămâne de confirmat până la lansarea finală — funcționalitățile aflate încă în testare pot fi ajustate sau amânate.
Îmbunătățiri de editare, mai puțin spectaculoase dar utile zilnic
Aplicarea globală a stilurilor, cu control mai fin
Aplicarea unei modificări locale de stil la nivel global nu mai e o acțiune „totul sau nimic”. Opțiunea „Apply globally” din inspectorul de blocuri deschide acum un pas de revizuire rapidă, permițându-ți să alegi exact ce stiluri modificate se aplică global, păstrând restul ca suprascrieri locale — util pentru cineva care a experimentat cu stiluri pe un singur bloc și vrea să păstreze doar unele dintre acele modificări la nivelul întregului site.
Corecții pentru încărcarea fișierelor media
Câteva probleme frecvente, dar frustrante, primesc rezolvare: încărcarea fișierelor GIF animate lungi nu se mai blochează, imaginile rotite prin metadate EXIF (informația de orientare salvată automat de camere și telefoane) se procesează acum corect, iar încărcarea unei singure imagini HEIC în Safari nu mai creează, din greșeală, două intrări separate în biblioteca media.
Tooltip-uri cu nume și informații suplimentare
O îmbunătățire mică de interfață: elemente ale editorului primesc tooltip-uri (indicii vizuale la trecerea mouse-ului) cu nume și informații suplimentare, făcând interfața puțin mai ușor de navigat pentru cineva mai puțin familiarizat cu toate funcționalitățile disponibile.
Un fir invizibil de continuitate: legătura cu patch-ul de securitate wp2shell
Un detaliu de cronologie interesant pentru cine a urmărit povestea vulnerabilității wp2shell: Beta 2 a ciclului 7.1 a fost lansată pe 17 iulie 2026, exact ca parte a lansării de urgență 7.0.2 — patch-ul care corecta CVE-2026-63030 și CVE-2026-60137. Practic, cele două cicluri de dezvoltare — corecția de securitate urgentă pentru 7.0 și dezvoltarea normală a versiunii 7.1 — s-au suprapus temporar, echipa reușind să livreze ambele fără să întârzie vizibil vreuna dintre ele. Un exemplu concret al modului în care un proiect de dimensiunea WordPress gestionează simultan atât urgențele de securitate, cât și dezvoltarea planificată pe termen lung.
Progresul infrastructurii AI din nucleu
Continuând direcția stabilită în WordPress 7.0, care a introdus Connectors API pentru integrarea cu furnizori AI externi, 7.1 aduce un „flag unificat de expunere publică” pentru „Abilities” — componentele de bază ale infrastructurii AI din nucleu, care permit plugin-urilor să declare și să folosească funcționalități AI standardizate. E o modificare tehnică, orientată către dezvoltatori care construiesc integrări AI peste WordPress, nu ceva vizibil direct pentru utilizatorul final — dar confirmă că direcția stabilită în 7.0 continuă să se dezvolte constant, versiune după versiune, nu a fost un experiment izolat.
Optimizare de performanță: încărcare speculativă mai agresivă, condiționat
O schimbare tehnică de performanță merită menționată: valoarea implicită pentru încărcarea speculativă (o tehnică prin care browserul „ghicește” și pre-încarcă pagini pe care utilizatorul e probabil să le acceseze în continuare, bazat pe unde mișcă mouse-ul sau ce linkuri sunt vizibile) se mută de la nivelul „conservator” la „moderat”, dar doar atunci când sistemul detectează că site-ul are deja cache activ. E o decizie prudentă — încărcarea speculativă mai agresivă pe un site fără cache ar putea suprasolicita inutil serverul, dar pe un site deja optimizat cu cache configurat corect, poate îmbunătăți suplimentar viteza percepută de navigare.
Revenirea la trei versiuni majore pe an
Calendarul din 2026 marchează o revenire notabilă: după un an anterior încetinit la doar două versiuni majore, echipa de bază WordPress a decis să reia ritmul tradițional de trei lansări majore anual, propus inițial de contributorul Jonathan Desrosiers și publicat pe blogul oficial Make WordPress Core încă din decembrie 2025. Argumentul din spatele deciziei: sincronizarea cu evenimentele flagship ale comunității oferă un termen limită natural, motivant, și o oportunitate de a celebra fiecare lansare alături de contributorii reuniți fizic la acele evenimente, nu doar printr-un anunț online izolat.
Pentru cineva care administrează site-uri WordPress pe termen lung, acest ritm de trei lansări pe an, cu intervale de aproximativ patru luni între ele, oferă un cadru previzibil de planificare — poți anticipa aproximativ când urmează următoarea versiune majoră, fără să fii surprins de un anunț neașteptat, și poți programa din timp ferestrele de testare pe staging în jurul acestor date cunoscute.
Cum se compară 7.1 cu 7.0, în linii mari
Dacă WordPress 7.0 „Armstrong” a fost o versiune orientată spre schimbări vizibile imediat — un dashboard nou, o paletă de comenzi, integrare AI nouă în nucleu —, WordPress 7.1 pare construită pe o filozofie diferită: rafinarea experienței existente, corectarea fricțiunilor reale identificate de utilizatori, și pregătirea unei fundații tehnice (React 19, editor iframat obligatoriu) pentru dezvoltări viitoare, mai degrabă decât introducerea unui val nou de funcționalități spectaculoase.
Nu e neapărat o versiune „mai puțin importantă” — dimpotrivă, genul de muncă de fundație pe care o conține 7.1 e adesea mai greu de executat corect decât adăugarea unei funcționalități noi vizibile, tocmai pentru că riscă să introducă regresii subtile în funcționalități deja folosite de milioane de site-uri. Dar din perspectiva unui proprietar de site obișnuit, impactul zilnic imediat va fi probabil mai discret decât cel resimțit la trecerea la 7.0.
Calendarul complet, pentru cine vrea să planifice din timp
Beta 1 a apărut pe 15 iulie, urmată de betele săptămânale prin tot iulie. Release Candidate 1 e programat pentru 5 august, RC2 pentru 12 august, un „dry run” (repetiție finală de lansare) pe 18 august, și lansarea propriu-zisă pe 19 august 2026, coincizând cu ultima zi a WordCamp US. Acest calendar face parte dintr-un plan mai amplu pentru 2026 — trei versiuni majore, sincronizate deliberat cu evenimentele majore ale comunității: 7.0 la WordCamp Asia în aprilie, 7.1 la WordCamp US în august, și 7.2 programat pentru decembrie, alături de evenimentul anual State of the Word.
Recomandarea de testare, adaptată acestei versiuni specifice
Dacă administrezi plugin-uri sau o temă puternic personalizată, perioada actuală — încă în beta, înainte de RC1 — e fereastra ideală pentru testare și pentru raportarea eventualelor incompatibilități, în special legate de schimbarea la editorul iframat obligatoriu, cea mai probabilă sursă de fricțiune pentru cod personalizat mai vechi.
Pentru site-uri obișnuite, fără dezvoltare personalizată complexă, recomandarea rămâne cea standard pentru orice actualizare majoră: așteaptă o săptămână sau două după lansarea generală, lasă dezvoltatorii de plugin-uri să publice actualizări de compatibilitate, apoi testează pe un mediu de staging înainte de a aplica pe site-ul live. Excepția: un site complet nou, cu puține plugin-uri active, unde nu există niciun motiv real să pornești pe o versiune mai veche.
Pentru testare directă, ai la dispoziție trei opțiuni: pluginul WordPress Beta Tester, cu canalul „Bleeding edge” activat; comanda WP-CLI `wp core update –version=7.1-beta4` (sau `7.1-RC1`, odată ce devine disponibilă pe 5 august); sau o instanță temporară în WordPress Playground, fără nicio instalare locală necesară — util pentru un test rapid, fără riscul de a afecta un site real.
Ce înseamnă asta, concret, pentru magazinele WooCommerce
Pentru cine administrează un magazin WooCommerce, merită reținut că versiunea recentă 11.0 a fost dezvoltată și lansată tocmai în perioada de tranziție dintre WordPress 7.0 și 7.1 — o coincidență de calendar care, deși nu creează probleme cunoscute direct, întărește recomandarea generală de testare atentă pe staging pentru orice combinație de actualizări majore aplicate în succesiune apropiată, mai ales pe un magazin cu volum activ de tranzacții.
Ce facem noi pentru clienții noștri
Pentru toate site-urile din pachetele noastre de administrare, urmărim activ ciclul de dezvoltare al fiecărei versiuni majore WordPress, nu doar anunțul final de lansare — inclusiv testarea versiunilor beta și RC pentru site-urile cu dezvoltare personalizată, exact genul de precauție care prinde din timp incompatibilități precum cele legate de editorul iframat sau migrarea la React 19, înainte ca acestea să devină probleme vizibile pe site-ul live al unui client.
Toate pachetele noastre de administrare WordPress includ testarea controlată a actualizărilor majore, cu o fereastră de observare adaptată complexității fiecărui site. De la 49 €/lună.
Vrei să știi dacă site-ul tău, sau plugin-urile personalizate pe care le folosești, ar putea fi afectate de schimbările din WordPress 7.1? Cere auditul gratuit — verificăm concret, fără obligații.