Întrebați barmanul: ce se întâmplă cu personalizatorul când o temă bloc este activă?

Ceva pe radarul meu în acest moment sunt pluginuri terță parte care au setări în Customizer. Ceea ce am adunat despre prieteni care sunt dezvoltatorii care lucrează la Customizer și chestii de front-end în cadrul câtorva companii de pluginuri, stilurile globale și stilurile de bloc nu sunt încă pe radar. Deci, ce se întâmplă dacă cineva instalează Twenty Twenty-Two sau o altă temă bazată pe blocuri? Meniul de administrator din stânga pentru Customizer nu este acolo. Modul neplăcut de a ajunge acolo este prin Aspect > Teme > Personalizare. Dar așteptarea este că pluginurile și temele terțelor părți trebuie să mute setările. De fapt, acest lucru pare mai degrabă că trebuie să dubleze setările în ambele locuri pentru o perioadă.

Anonim

Pentru cei care nu sunt la curent, permiteți-mi să ofer o reîmprospătare rapidă pe acest subiect. Când WordPress 5.9 aterizează, ne așteptăm să fie livrat cu noul editor de site și interfață globală de stiluri. Cu toate acestea, majoritatea utilizatorilor nu vor vedea acest ecran decât dacă rulează o temă de blocare.

Având în vedere că viitorul Twenty Twenty-Two se livrează și cu WordPress 5.9 și judecând popularitatea temelor implicite din trecut, ne putem aștepta că multe mii de utilizatori vor fi transportați în această lume cu totul nouă. Pentru unii, acest lucru ar putea fi la fel de șocant precum lansarea editorului de blocuri în 5.0.

Când o temă de blocare este activă, linkurile pentru a accesa vechiul și familiarul personalizare vor dispărea din interfața cu utilizatorul. Nici widget-urile și ecranele meniului de navigare nu vor fi prezente. Cu toate acestea, acestea vor fi în continuare accesibile dacă cunoașteți adresa URL a ecranelor.

Am aflat pentru prima dată că acest lucru va fi cazul anul trecut, ca parte a lansării Gutenberg 9.3. Există, de asemenea, o problemă deschisă pentru a se asigura că editorul site-ului are paritatea funcțiilor cu unele setări de bază ale WordPress.

Este în regulă că aceste funcții sunt eliminate treptat pentru utilizatorii de teme bloc. Toate au fost încercări timpurii, disparate, de a crea piese individuale din ceea ce va permite editorul site-ului. WordPress reunește toate aceste concepte într-o experiență de utilizator mai coerentă. Este un standard pe care contribuitorii pot repeta continuu. Nu va fi perfect din start, dar această primă versiune din platforma de bază ar trebui să alimenteze feedback-ul necesar pentru a o îmbunătăți, pe măsură ce mai mulți utilizatori încep să instaleze teme de bloc.

Problema prezentată aici are mai mult de-a face cu piața pluginurilor. Personalizatorul a fost creat inițial ca instrument de setări ale temelor și a fost folosit în primul rând în acest scop. Dar, multe plugin-uri au legat diverse setări de-a lungul istoriei sale de nouă ani. O căutare pentru wp_customize în directorul de pluginuri atrage peste 1.400 de rezultate. Cârligul customize_register afișează peste 1.900. Acestea nu sunt neapărat potriviri exacte pentru câte plugin-uri adaugă de fapt panouri, secțiuni, setări sau comenzi. Cu toate acestea, este un indicator că mulți se bazează pe acesta pentru a prezenta opțiuni utilizatorilor finali.

Așadar, revenim la întrebarea în discuție. Ce se întâmplă când un utilizator instalează o temă blocată, cum ar fi viitorul Twenty Twenty-Two, în timp ce folosește un plugin care se bazează pe personalizarea?

Depinde.

Unele plugin-uri precum WooCommerce au plasat deja în mod convenabil un link direct către panoul/secțiunea lor de personalizare în meniul de administrare. Aceasta nu va fi o problemă pentru utilizatorii lor. Cu toate acestea, pentru toți ceilalți, personalizarea va părea să dispară complet.

În câteva săptămâni după 5.9, în funcție de cât de rapidă are loc în special adoptarea lui Twenty Twenty-Two, am putea privi mii de utilizatori confuzi. Desigur, toate acestea s-ar putea schimba în timpul premergător lansării. Cu toate acestea, aceasta este o conversație care trebuie să aibă loc acum.

„Preocuparea aici este pentru utilizatorii finali”, a spus persoana anonimă. „Ei vor analiza articole din baza de cunoștințe, instrucțiuni în setările pluginului și multe altele care indică unde să caute setările.”

Cel puțin în acest moment, sarcina este a autorilor de pluginuri de a aborda acest lucru pentru propriii lor utilizatori. Cu toate acestea, există mai multe căi pe care ar putea dori să meargă.

Cea mai simplă metodă este să urmați exemplul WooCommerce. Pluginul verifică condiționalul gutenberg_is_fse_theme() (rețineți că numele acestei funcții se poate modifica). Dacă returnează true , pluginul adaugă un link direct la panoul său de personalizare.

Conectarea la un panou de personalizare, secțiune sau control este simplă. Autorii pluginurilor pot găsi adresele URL în manualul dezvoltatorului. De asemenea, pot copia doar tehnica folosită de echipa WooCommerce.

Aceasta este o metodă rapidă pentru a vă asigura că utilizatorii nu pierd accesul la opțiunile lor dacă autorii pluginurilor nu pot face modificări înainte de aterizarea WordPress 5.9.

Pe termen lung, nu este soluția ideală. Personalizatorul va exista pentru o perioadă lungă de timp, dar autorii de pluginuri vor trebui să se ocupe de două seturi de utilizatori: cei care rulează atât teme bloc, cât și teme clasice.

Deoarece fiecare plugin este diferit, soluțiile vor trebui să fie diferite. Mulți pot folosi pur și simplu API-ul Setări pentru a crea un ecran cu opțiuni personalizate. Dacă aceasta este o soluție viabilă, nu va conta ce tema rulează utilizatorul.

Cu toate acestea, realitatea ar putea fi menținerea a două sisteme pentru ambele seturi de utilizatori. Unul care se integrează cu personalizarea și altul care trage opțiuni în editorul site-ului. Dacă pluginul are caracteristici legate de design, utilizatorii de teme bloc se vor aștepta să vadă setări în noua interfață.

În ceea ce privește tematica, ar trebui să existe mai puține probleme. Oricum, o temă bloc nu face nimic cu personalizarea. O problemă importantă ar fi conversia conținutului de pornire și există un bilet deschis pentru a aduce asta la editarea completă a site-ului.

Mai mult decât orice, păstrarea liniilor deschise de comunicare cu utilizatorii va ajuta la ușurarea tranziției. O parte din acestea ar trebui să provină de la WordPress de bază. Cu toate acestea, mulți utilizatori vor trebui să o audă de la dezvoltatorii lor de pluginuri și teme. Acestea pot fi postări pe blog, baze de cunoștințe sau actualizări ale tutorialelor și ținerea pasului cu asistența.

Apoi, există soluția finală, una pe care WordPress însuși ar putea-o implementa. Este, de asemenea, calea celei mai mici rezistențe.

WordPress ar trebui să detecteze automat filtrele sau acțiunile pe cârlige legate de personalizare. Acest lucru ar trebui să declanșeze un semnalizator „personalizare suporturi” și să mențină meniul de administrare și legăturile barei de instrumente către ecranul de personalizare. Acest lucru le-ar oferi dezvoltatorilor ceva timp pentru a ajunge din urmă fără a deruta utilizatorii în acest proces. S-ar putea să existe câteva semnale false sau integrări ratate, dar ar trebui să poată surprinde în mod eficient majoritatea cazurilor de utilizare.