WordPress 2026. gadā atgriežas pie trim lielajiem laidieniem: sākas 7.0 plānošana, AI klients un admin atsvaidzinājums

WordPress kodola (Core) komanda 2026. gadā, pēc publiski sarežģītā 2025. gada, plāno atgriezties pie klasiskākas dinamikas: trīs major (lielo) versiju laidieniem gada laikā. Par to kļuva zināms pēc kārtējā “Core Committers Check-in” – tikšanās, kurā kodola komiteri un projekta vadība pārrunā prioritātes, laika grafikus un lielos tehniskos virzienus.

Vienā sarunā tika skartas vairākas tēmas, kas izstrādātājiem būs praktiski jūtamas: WordPress 7.0 agrīnā plānošana, admin saskarnes pārkrāsošana (nevis pilna pārbūve), WordPress AI Client kā kandidāts iekļaušanai kodolā un arī jautājums par minimālās PHP versijas paaugstināšanu līdz 7.4.

Svarīga nianse: tikšanās notika pēc Chatham House Rule principa – tas parasti nozīmē, ka informāciju drīkst izmantot, bet nav paredzēts citēt konkrētus runātājus vai piesaistīt izteikumus konkrētām personām.

Kāpēc šis ir pavērsiens: no “viena major 2026. gadā” atpakaļ uz trim

Šī iecere maina agrāko 2025. gada virzienu, kad WordPress izpilddirektore Mary Hubbard publiski paziņoja, ka 2026. gadā plānots tikai viens major laidiens. Toreiz kā iemesls tika minētas “ongoing legal matters” – atsauce uz WP Engine tiesvedību – un arī Automattic lēmums samazināt ieguldījumu WordPress attīstībā, kamēr notiek juridiskā cīņa.

Tagad, balstoties uz Make WordPress Core publicētajām piezīmēm, komiteri runā par nodomu atjaunot trīs laidienu ritmu 2026. gadā.

7.0 mērķis: marts vai aprīlis (un kāpēc ne februāris)

Saskaņā ar Make WordPress Core piezīmēm (tās publicēja kodola komiteris Jonathan Desrosiers), 7.0 tiek mērķēts uz martu vai aprīli.

Februāra laidiens tika izslēgts vairāku praktisku iemeslu dēļ:

• Ja 7.0 laidiens būtu februārī, tad Beta 1 faktiski sanāktu janvāra sākumā, kad daudzi kontributor(i) vēl ir svētku atvaļinājumos.
• Vairākas funkcijas, kas ir izstrādes procesā, vienkārši nebūtu gatavas tik saspringtam grafikam.

Vai major laidienus piesaistīs lielajiem pasākumiem?

Diskusijā parādījās arī ideja par major versiju izlaišanas pieskaņošanu “flagship events” (lielajiem pasākumiem). Konteksts te ir šī gada prakse: WordPress 6.9 iznākšana tika sasaistīta ar State of the Word.

Tomēr komanda atzīmēja, ka šādai koordinācijai ir cena: ceļošana, laika zonas, release squad un kontributor(u) pieejamība var būtiski sarežģīt procesu. Tāpēc pagaidām tā ir iespēja, nevis konkrēts plāns, un tēma ir atzīmēta turpmākai apspriešanai.

Ko 7.0 varētu atnest: funkcijas, kas sākotnēji bija 6.9 tvērumā

Daļa no potenciālajām 7.0 funkcijām ir tās, par kurām iepriekš domāja 6.9 kontekstā. Piezīmēs kā kandidāti minēti:

• Template activation (templeitu aktivizēšana kā funkcija).
• Tabs block (bloks ar cilnēm/tabs).
• Client-side iespējas Abilities API (Abilities API – mehānisms iespēju/spēju definēšanai un izmantošanai) ietvarā.
• Client-side media editing (mediju rediģēšana pārlūkā klienta pusē).

WordPress AI Client: reāls kandidāts iekļaušanai kodolā

Lielākā daļa diskusijas koncentrējās ap WordPress AI Client – vienu no WordPress AI Team definētajiem četriem “Building Blocks” (izstrādes blokiem), un tagad tas tiek vērtēts kā kandidāts iekļaušanai pašā WordPress kodolā.

Svarīgs fakts kontekstam: WordPress AI Client 0.1.0 tika izlaists iepriekšējā nedēļā. Šis klients nodrošina native (WordPress stilā) un provider-agnostic (nepiesiets vienam piegādātājam) veidu, kā spraudņiem un tēmām integrēties ar AI servisiem. Tas pēc būtības adaptē PHP AI Client pie WordPress konvencijām un arhitektūras.

Kas tieši ir WordPress AI Client (un kāpēc izstrādātājam tas interesē)

Ja skaties uz šo kā uz platformas “pamatbibliotēku”, tad ideja ir vienkārša: spraudņiem un tēmām nevajadzētu katram atsevišķi iemūrēt vienu konkrētu AI piegādātāju un viņa SDK. WordPress AI Client mēģina iedot kopīgu slāni, kas palīdz veidot integrācijas standartizēti.

Piezīmēs izcelti konkrēti tehniski aspekti, ko klients jau šobrīd risina:

• Tas izmanto WordPress HTTP API (tātad pieprasījumi uz ārējiem AI servisiem iet caur WordPress standarta mehānismiem).
• Tas centralizē API atslēgas vienā vietā – īpašā “AI Credentials” ekrānā (vienots kredenciāļu pārvaldības punkts).
• Tas palīdz ar modeļu izvēli tā, lai spraudņiem nebūtu jāhardcode konkrēti provider(i) un modeļu nosaukumi.

Tālākajos laidienos (pēc plāna, kas minēts paziņojumā par SDK) paredzēti vēl vairāki paplašinājumi:

• Abilities API atbalsts.
• REST endpoints (REST API galapunkti) darbam ar AI klientu.
• Client-side Prompt Builder (uz klienta pusi vērsts rīks promptu veidošanai).

Kāpēc komiteri redz AI Client vietu tieši Core

Piezīmes argumentē, ka šāda pamata infrastruktūra var motivēt ekosistēmu būvēt uz stabilām pamatlietām (piemēram, Abilities API). Tāpēc “ideālā mājvieta” šim slānim būtu WordPress kodols, jo vairāku savstarpēji saistītu API kombinācija var atvērt daudz jaunu iespēju gan izstrādātājiem, gan vietņu īpašniekiem.

Ierobežojumi: WordPress jāpaliek agnostiskam

Vienlaikus diskusija iezīmē arī robežas. Piezīmēs uzsvērts, ka WordPress vienmēr paliks agnostisks: nav ilgtspējīgi kodolā iekļaut kādu vienu konkrētu AI modeli vai integrēties tikai ar daļu trešo pušu servisu. Tika pieminēts, ka ilgtermiņā potenciāls varētu nākt no jaunām pieejām, piemēram, mašīnmodeļiem vai pārlūka līmeņa modeļiem, bet konkrēts virziens netika izvēlēts.

Pirms lēmuma: skaidri “default WordPress” lietošanas gadījumi

Pirms vispār pieņemt lēmumu par AI Client iekļaušanu kodolā, kontributor(i) vēlas skaidrus use case tieši “default WordPress” kontekstā. Piezīmēs kā piemēri minēti:

• Mediju bibliotēkas meklēšana pēc konkrēta satura/subjekta (piem., atrast attēlus ar noteiktu objektu).
• Jaunumu vēstuļu (newsletter) ģenerēšana, balstoties uz neseno saturu vietnē.

Admin redesign: “svaigs krāsas slānis”, nevis pilna pārbūve

Admin saskarnes pārveide bija vēl viena tēma, un šeit komanda iedeva diezgan skaidru signālu par ambīciju līmeni: tas nebūs pilnīgs “overhaul”, bet drīzāk “fresh coat of paint” – esošā atsvaidzināšana, nevis totāla pārbūve.

Šis precizējums nāk pēc iepriekšējām sarunām (jūlija ceturkšņa tikšanās), kur tika apspriests, kā vispār testēt redesign virzienu: kā eksperimentu Gutenberg spraudnī vai arī kā atsevišķu “MP7” spraudni. Nosaukums ir apzināta atsauce uz MP6 – 2013. gada “feature as a plugin” pieeju, kas pēc tam būtiski ietekmēja WordPress 3.8 admin redesign.

Admin redesign ir daļa no Gutenberg roadmap Phase 3: Collaboration. Darbs šajā virzienā sākās 2023. gadā, kad Gutenberg Lead Architect Matías Ventura publiski izklāstīja redzējumu par admin pieredzes modernizēšanu, un vēlāk 2023. gada State of the Word laikā tika demonstrēti jauni izkārtojumi.

Interesanti, ka agrīns admin redesign priekšskatījums sākotnēji bija plānots līdz ar WordPress 6.9, bet septembrī, kad tika atjaunināta roadmap, tas tika nolikts malā ar formulējumu, ka tas “no longer planned based on the current state of work.”

Šobrīd joprojām nav konkrēta grafika, kad atjaunotais admin varētu nonākt līdz lietotājiem. Pēdējā lielā vizuālā atsvaidzināšana WordPress admin pusē bija vairāk nekā pirms desmit gadiem – WordPress 3.8 laidienā.

Minimālās PHP versijas celšana līdz 7.4: argumenti “par”, bet bez lēmuma

Tikšanās laikā komanda izskatīja arī “compelling reasons” minimālās atbalstītās PHP versijas paaugstināšanai uz PHP 7.4. Šeit nebija gala lēmuma, bet argumentācija ir svarīga, jo tā tieši ietekmē spraudņu/tēmu autorus un hostingu realitāti.

Diskusijas centrā bija praktiskie ierobežojumi:

• Vecāku PHP versiju atbalsts liek WordPress uzturēt saderības slāņus, kas palielina koda “bloat” un bremzē izstrādes tempu.
• PHP 7.4 palīdzētu virzīt kodu uz konsekventāku tipēšanu, kas atvieglo gan izstrādātāju ikdienu, gan arī AI sistēmām (piem., statiskai analīzei, ģenerēšanai, refaktoringa asistēšanai) saprast kodu un struktūru.
• Daudzi trešo pušu AI SDK jau prasa jaunākas PHP versijas; turēt minimālo prasību pārāk zemu nozīmē praktiski aizslēgt durvis uz daļu integrāciju.

Vienlaikus saruna tika rāmēta kā līdzsvara meklējumi starp progresu un lietotāju bāzes noturēšanu: ideja nav “atstāt kādu aiz borta”, bet saprast, kā virzīties uz priekšu ar minimāli sāpīgu pāreju. Tikšanās laikā lēmums netika pieņemts.

Kas sekos tālāk: konkrētie “next steps” pēc tikšanās

Pēc sesijas Jonathan Desrosiers piezīmēs uzskaitīja vairākus turpmākos darbus, kas palīdzēs šo virzienu pārvērst konkrētā plānā:

• Izvirzīt priekšlikumu par atvērtākiem un daļēji atvērtiem tikšanās formātiem.
• Publicēt 2026. gada laidienu grafiku.
• Apstiprināt mērķētās 7.0 funkcijas un, iespējams, arī 7.1 tvērumu.
• Novērtēt, vai major laidienu saskaņošana ar klātienes pasākumiem ir praktiski realizējama.

Kopsavilkums: ko šis nozīmē WordPress izstrādātājiem 2026. gadā

Īsā versija: WordPress 2026. gadā atkal plāno dzīvot aktīvākā major laidienu ritmā, ar 7.0 kā pirmo lielo pieturas punktu pavasarī (marts/aprīlis). Tehniskajā dienaskārtībā vienlaikus ir gan platformas pamatu nostiprināšana (AI Client kā kopīgs slānis, Abilities API virziens), gan UX līmeņa darbs (admin atsvaidzināšana), gan arī ilgstošais sāpju punkts – minimālās PHP versijas jautājums. Lēmumi vēl nav “iecementēti”, bet virzieni ir skaidri iezīmēti.