Qualcosa sul mio radar in questo momento sono plug-in di terze parti che hanno impostazioni nel Customizer. Quello che raccolgo di amici che sono gli sviluppatori che lavorano su Customizer e cose di front-end all’interno di alcune aziende di plugin, stili globali e stili di blocco non sono ancora sul loro radar. Quindi cosa succede se qualcuno installa Twenty Twenty-Two o un altro tema basato su blocchi? Il menu di amministrazione a sinistra per Customizer non è presente. Il modo più strano per arrivarci è tramite Aspetto> Temi> Personalizzatore. Ma l’aspettativa è che plugin e temi di terze parti debbano spostare le impostazioni. In effetti, sembra più che abbiano bisogno di duplicare le impostazioni in entrambi i posti per un po’.

Anonimo

Per quelli fuori dal giro, mi permetta di fornire un rapido aggiornamento su questo argomento. Quando WordPress 5.9 atterra, ci aspettiamo che venga spedito con il nuovo editor del sito e l’interfaccia degli stili globali. Tuttavia, la maggior parte degli utenti non vedrà questa schermata a meno che non stia eseguendo un tema a blocchi.

Visto che il prossimo Ventidue è anche disponibile con WordPress 5.9 e, a giudicare dalla popolarità dei temi predefiniti del passato, possiamo aspettarci che molte migliaia di utenti verranno trasportati in questo mondo completamente nuovo. Per alcuni, questo potrebbe essere scioccante quanto il lancio dell’editor di blocchi in 5.0.

Quando un tema di blocco è attivo, i collegamenti per accedere al vecchio e familiare personalizzatore scompariranno dall’interfaccia utente. Neanche i widget e le schermate del menu di navigazione saranno presenti. Tuttavia, saranno comunque accessibili se conosci l’URL delle schermate.

Abbiamo appreso per la prima volta che sarebbe stato così l’anno scorso come parte del Rilascio Gutenberg 9.3. C’è anche un questione aperta per garantire che l’editor del sito abbia la parità di funzionalità con alcune impostazioni principali di WordPress.

Va bene che queste funzionalità vengano gradualmente eliminate per gli utenti dei temi a blocchi. Erano tutti tentativi precoci e disparati di creare singoli pezzi di ciò che l’editor del sito consentirà. WordPress sta unendo tutti questi concetti in un’esperienza utente più coerente. È uno standard su cui i contributori possono continuamente eseguire l’iterazione. Non sarà perfetto fin dall’inizio, ma questa prima versione nella piattaforma principale dovrebbe alimentare il feedback necessario per migliorarlo man mano che più utenti iniziano a installare temi a blocchi.

Il problema qui presentato ha più a che fare con il mercato dei plugin. Il personalizzatore è stato inizialmente creato come strumento per le impostazioni del tema ed è stato utilizzato principalmente a tale scopo. Ma molti plugin hanno collegato varie impostazioni ad esso nel corso dei suoi nove anni di storia. Una ricerca per wp_customize nella directory dei plugin vengono visualizzati oltre 1.400 risultati. Il customize_register hook mostra oltre 1.900. Queste non sono necessariamente corrispondenze esatte per quanti plugin effettivamente aggiungono pannelli, sezioni, impostazioni o controlli. Tuttavia, è un indicatore del fatto che molti fanno affidamento su di esso per presentare opzioni agli utenti finali.

Quindi, siamo tornati alla domanda in questione. Cosa succede quando un utente installa un tema a blocchi, come il prossimo Twenty Twenty-Two, mentre utilizza un plug-in che si basa sul personalizzatore?

Dipende.

Alcuni plugin come WooCommerce hanno già posizionato convenientemente un collegamento diretto al loro pannello/sezione di personalizzazione nel menu di amministrazione. Questo non sarà un problema per i loro utenti. Tuttavia, per tutti gli altri, il personalizzatore sembrerà scomparire del tutto.

Nel giro di poche settimane dopo la 5.9, a seconda della rapidità con cui si verifica l’adozione di Twenty Twenty-Two, potremmo vedere migliaia di utenti confusi. Naturalmente, tutto questo potrebbe cambiare nel tempo che precede il rilascio. Tuttavia, questa è una conversazione che deve avvenire ora.

“La preoccupazione qui è per gli utenti finali”, ha detto l’interrogatore anonimo. “Guarderanno gli articoli della knowledge base, le indicazioni nelle impostazioni del plug-in e altro che indica dove cercare le impostazioni”.

Almeno al momento, spetta agli autori dei plugin affrontare questo problema per i propri utenti. Tuttavia, ci sono più percorsi che potrebbero voler seguire.

Il metodo più semplice è seguire l’esempio di WooCommerce. Il plugin controlla il gutenberg_is_fse_theme() condizionale (notare che questo il nome della funzione potrebbe cambiare). Se ritorna true, il plugin aggiunge un collegamento direttamente al suo pannello di personalizzazione.

Il collegamento a un pannello, una sezione o un controllo di personalizzazione è semplice. Gli autori del plugin possono trovare gli URL nel manuale dello sviluppatore. Possono anche solo copia la tecnica il team di WooCommerce impiegato.

Questo è un metodo rapido per garantire che gli utenti non perdano l’accesso alle loro opzioni se gli autori dei plugin non possono apportare modifiche prima che WordPress 5.9 arrivi.

A lungo termine, non è la soluzione ideale. Il personalizzatore sarà in circolazione per molto tempo, ma gli autori di plugin dovranno avere a che fare con due gruppi di utenti: quelli che eseguono sia temi a blocchi che classici.

Poiché ogni plug-in è diverso, le soluzioni dovranno essere diverse. Molti possono semplicemente usare il API delle impostazioni per creare una schermata delle opzioni personalizzate. Se questa è una soluzione praticabile, non importa quale tema sta eseguendo l’utente.

Tuttavia, la realtà potrebbe essere mantenere due sistemi per entrambi i gruppi di utenti. Uno che si integra con il personalizzatore e un altro che inserisce le opzioni nell’editor del sito. Se il plug-in ha funzionalità relative al design, gli utenti del tema del blocco si aspetteranno di vedere le impostazioni nella nuova interfaccia.

Dal punto di vista dei temi, dovrebbero esserci meno problemi. Un tema a blocchi non fa comunque nulla con il personalizzatore. Un problema in sospeso sarebbe la conversione del contenuto iniziale, e c’è un Apri un ticket per portarlo in Modifica sito completo.

Più di ogni altra cosa, mantenere linee di comunicazione aperte con gli utenti aiuterà a facilitare la transizione. Alcuni di questi dovrebbero provenire dal core di WordPress. Tuttavia, molti utenti dovranno ascoltarlo dai loro plugin e sviluppatori di temi. Potrebbe trattarsi di post di blog, knowledgebase o aggiornamenti di tutorial e tenere il passo con il supporto.

Poi c’è la soluzione finale, quella che lo stesso WordPress potrebbe implementare. È anche il percorso di minor resistenza.

WordPress dovrebbe rilevare automaticamente i filtri o le azioni sugli hook relativi alla personalizzazione. Questo dovrebbe attivare un flag “personalizza supporti” e mantenere il menu di amministrazione e i collegamenti della barra degli strumenti alla schermata di personalizzazione. Ciò darebbe agli sviluppatori un po’ di tempo per recuperare il ritardo senza confondere gli utenti nel processo. Potrebbero esserci alcune false flag o integrazioni mancate, ma dovrebbe essere in grado di catturare efficacemente la maggior parte dei casi d’uso.