Matt Mullenweg reînnoiește Push pentru pluginuri canonice

În timpul zilei colaboratorilor WordCamp US din acest weekend, Matt Mullenweg a publicat un apel reînnoit pentru ca echipele WordPress Make să adopte o abordare bazată pe plugin-uri atunci când dezvoltă noi funcții pentru core. El a reînviat noțiunea de pluginuri canonice, introdusă pentru prima dată în comunitatea WordPress în 2009, ca mijloc de a furniza funcții opționale utilizatorilor cu un nivel mai ridicat de încredere decât pluginurile obișnuite:

Pluginurile canonice ar fi plugin-uri care sunt dezvoltate în comunitate (mai mulți dezvoltatori, nu doar o persoană) și se adresează celor mai populare solicitări de funcționalități cu o execuție superlativă. Aceste plugin-uri ar fi GPL și ar trăi în depozitul WordPress.org și ar fi dezvoltate în strânsă legătură cu nucleul WordPress. Ar exista o relație foarte strânsă între core și aceste plugin-uri, care ar asigura că a) codul pluginului va fi sigur și cel mai bun exemplu posibil de standarde de codare și b) că noile versiuni de WordPress vor fi testate împotriva acestor plugin-uri înainte de lansarea către asigura compatibilitatea. Ar exista un ecran în secțiunea Plugin-uri a administratorului WordPress pentru a prezenta aceste plugin-uri canonice ca un fel de alegere a editorului sau garanție verificată. Aceste plugin-uri ar fi o adevărată extensie a WordPress de bază în ceea ce privește compatibilitatea, securitatea și suportul.

Jen Mylo – Pluginuri canonice (Spune ce?)

Directorul de pluginuri WordPress este la doar un plugin de a depăși 60.000 (la momentul publicării). Spre deosebire de ideea de pluginuri canonice, directorul oficial este încă ca vestul sălbatic în ceea ce privește ceea ce se pot aștepta utilizatorii de la autorii de pluginuri. Mullenweg a citat mai multe scenarii de plugin care nu sunt ideale pentru utilizatori – cum ar fi un plugin controlat de o singură companie și care evoluează pentru a merge mai mult către o versiune pro sau eliminarea funcționalităților gratuite anterior și plasarea acesteia în spatele unui upgrade.

Pluginurile canonice sunt menite să ofere o alternativă de încredere la pluginuri în care motivațiile autorilor nu pot pune utilizatorii pe primul loc. Oferă, de asemenea, o cale pentru contributorii de bază pentru a demonstra cererea de funcții pe care doresc să le aterizeze în WordPress. Câteva proiecte precum MP6, Gutenberg și API-ul REST au luat această cale în bază.

„Ajungem într-un punct în care nucleul trebuie să fie mai editorial și să spunem „nu” funcțiilor care vin la fel de ad-hoc așa cum fac uneori, iar speranța mea este ca mai multe echipe să folosească acest lucru ca o oportunitate de a influența viitorul WordPress prin o abordare bazată pe plugin, care le oferă luxul unor cicluri de dezvoltare și lansare mai rapide (în loc de trei ori pe an), mai puține cheltuieli generale de revizuire și cale de a intra în nucleu dacă pluginul devine un succes fulgerător”, a spus Mullenweg.

„Sunt foarte conștient că atunci când oamenii își propun să aibă ceva în bază, un „nu” sau „nu acum” poate fi frustrant și, uneori, poate crea presiune artificială pentru a introduce ceva înainte de a fi gata, așa cum cred că sa întâmplat cu API-ul REST în WP 4.4.”

Într-o postare conexă care a inspirat discuția reînnoită despre pluginurile canonice, Mullenweg a analizat controversata propunere WebP implicită care a primit recent noi obiecții de la dezvoltatorii principali WordPress. Colaboratorii au lucrat cu febrilitate pentru a-și revizui abordarea la timp pentru 6.1.

Mullenweg a recomandat aceste noi funcții ca un candidat principal pentru calea pluginului canonic, sugerând că ar oferi mai mult timp pentru ca ecosistemul din jurul WebP să se maturizeze:

Sunt interesat să susțin noile formate și să îmbunătățesc performanța, dar cred că această schimbare este impusă în mod implicit utilizatorilor atunci când fac upgrade la 6.1 este mult pentru moment, inclusiv cu unele dintre interacțiunile greoaie pe care le au sistemele de operare în jurul webp (și HEIC! ) fișiere.

Mă bucur că sprijinul pentru ca fișierele webp și HEIC să rămână în nucleu, deoarece ar trebui să fim liberali în ceea ce acceptăm și cu care lucrăm, dar nu cu schimbarea de a converti totul în webp atunci când sunt încărcate JPEG.

Echipa de performanță intenționează să discute acest lucru în chat-ul programat pentru mâine. Nu este clar încă dacă eforturile recente ale WebP vor fi trecute la statutul de plugin canonic sau dacă o parte din acesta poate ajunge în continuare în 6.1.

Răspunsurile la apelul pentru mai multe plugin-uri canonice au fost mixte, deoarece unii au recunoscut imediat sarcina crescută pentru întreținerii acestor plugin-uri.

„WP trebuie doar să treacă peste aversiunea față de caracteristicile opționale”, a spus dezvoltatorul WordPress Jon Brown. „Funcții care pot fi activate/dezactivate. „Deciziile nu opțiuni” este un etos grozav atunci când este vorba de a menține lucrurile simple pentru utilizatori, dar pare să fi fost aruncat pe fereastră cu Gutenberg UX și s-a transformat în axiomă atunci când discutăm despre adăugarea unor opțiuni trivial simple la pagina de setări.”

Contribuitorul sponsorizat de iThemes, Timothy Jacobs, a spus că nu este neapărat în sprijinul adăugării mai multor opțiuni la Core, dar consideră că pluginurile canonice ar putea fi prezentate într-un mod similar cu opțiunile.

„Asta nu înseamnă că interfața de utilizare trebuie doar să caute prin directorul de pluginuri ceva ce doriți”, a spus Jacobs. „Pluginurile canonice ar putea fi expuse poate într-o interfață de utilizare „asemănătoare setărilor”. Cred că metodele de import sunt puțin ascunse în meniul Instrumente, dar ceva de genul ăsta poate.”

Contribuitorul principal Torsten Landsiedel a spus că diferența dintre pluginurile canonice și pluginurile de caracteristici nu este clară. Distincția poate fi aceea că pluginurile canonice le includ pe cele care s-ar putea să nu aparțină niciodată de bază, dar sunt încă importante pentru utilizatori.

„Se pare că pluginul „Importator WordPress” ar putea fi un plugin canonic”, a spus Landsiedel. „Nu sunt sigur dacă acesta este un exemplu bun pentru un plugin *înfloritor*. Nu acceptă imaginile prezentate, se luptă cu cantități mari de postări/media etc.

„Plugin-ul util Health Check se luptă cu oamenii dispăruți să ajute.

„Cum putem împiedica aceste plugin-uri (indiferent cum se numesc) să nu primească suficienți colaboratori? Cred că un importator este un instrument crucial, dar nici nu este necesar în nucleu (pot să-l instalez dacă am nevoie, e în regulă) – dar ar trebui să funcționeze și în acest moment nu funcționează bine. Dar nu văd prea mult interes din partea comunității dezvoltatorilor pentru a ajuta la rezolvarea acestui lucru (poate pentru că folosesc WP CLI și nu le pasă de acest plugin?)”

Colin Stewart, colaboratorul principal al WordPress, a spus că, deși este de acord cu funcțiile, deoarece pluginurile sunt mai întâi utile pentru funcții noi, necesită „o metrică mult mai bună decât „succesul fugitiv”, pentru includerea în core.

„Unele funcții sunt importante pentru stabilitate și protejează utilizatorii de probleme care le dau bătăi de cap de mai multe ori pe parcursul vieții site-ului lor, dar nu sunt ceva ce utilizatorii ar putea gândi să caute în depozitul de pluginuri sau să instaleze la vedere”, a spus Stewart. „Rollback este o astfel de caracteristică, la fel ca Site Health, Privacy Export/Erase și altele.

„Un proces formal de luare a deciziilor pentru propuneri ar fi incredibil de util. Acest subiect apare în mod regulat acum.”

Mullenweg a oferit aproape două duzini de idei pentru pluginuri canonice pe care echipele Make le-ar putea lua în considerare și a sugerat că echipele însele ar putea veni cu idei mai bune. Imaginând toate aceste noi funcții în joc, ar fi ca o renaștere a inovației în administrator. Aceasta este o perspectivă interesantă de care ar putea beneficia utilizatorii WordPress, atâta timp cât pluginurile sunt prezentate în așa fel încât să fie ușor de adoptat. Primii care au comentat ideea ridică preocupări legitime cu privire la lipsa de întreținere, deoarece istoria arată că suportul pentru unele dintre pluginurile canonice existente este oarecum neregulat.

„Sper că va declanșa discuții în ziua colaboratorilor și nu numai cu privire la modul în care putem utiliza mai bine pluginurile pentru a crește viteza de evoluție pentru WordPress, pentru a menține miezul de bază, rapid și avizat, și facem acest lucru în timp ce spunem „da” la mai multe idei și experimente, ” a spus Mullenweg.