Dietro i nuovi pacchetti Project Lead, il team di revisione dei temi lancia la soluzione per gli avvisi dell'amministratore

Come parte del piano del team di revisione dei temi di WordPress per frenare gli avvisi di amministrazione invadenti, il team ha reso pubblica la versione 1.0 del suo pacchetto di avvisi di amministrazione. Il nuovo pacchetto fornisce un'API standard per consentire agli autori di temi di visualizzare gli avvisi dell'amministratore.

Ari Stathopoulos ha assunto la guida del progetto sui pacchetti alla fine di agosto. Stathopoulos è il principale sviluppatore e creatore dell'apprezzato framework di personalizzazione Kirki, che attualmente ha oltre 300.000 installazioni attive come plug-in. Tuttavia, il framework è disponibile anche come moduli separati che gli autori di temi possono raggruppare all'interno dei loro temi.

Il pacchetto Avvisi di amministrazione è il terzo pacchetto prodotto dal team e il primo guidato da Stathopoulos.

L'aggiunta di un avviso di amministrazione di base in WordPress è relativamente facile per la maggior parte degli sviluppatori. Tuttavia, la gestione di funzionalità come le azioni irricevibili persistenti è più complessa. Il pacchetto Avvisi per l'amministratore lo gestisce immediatamente.

Alcune opzioni per il pacchetto includono la possibilità di:

• Imposta un titolo e un messaggio.
• Seleziona un tipo che aggiunge nella classe dell'interfaccia utente appropriata (informazioni, successo, avviso, errore).
• Scegli su quali schermate di amministrazione viene visualizzato l'avviso.
• Limita il messaggio in base alla capacità dell'utente in modo che non venga visualizzato per tutti gli utenti.

Lo screenshot sopra mostra un esempio di output di avviso dell'amministratore di base per i quattro tipi disponibili. L'azione di eliminazione è gestita da JavaScript e funziona senza ricaricare la pagina. Una volta respinti, gli utenti non vedranno più l'avviso.

"Penso che la cosa più difficile sia stata decidere quanto volevamo che fosse restrittivo", ha detto Stathopoulos delle sfide nella creazione di questo pacchetto. Il pacchetto limita gli autori del tema a elementi di paragrafo, collegamento, grassetto e corsivo nella versione 1.0. Non lascia molto spazio alla sperimentazione, ma l'obiettivo è la standardizzazione. Più elementi sono consentiti, più è probabile che lo strumento non risolva il problema del team di mantenere gli avvisi dell'amministratore discreti.

Le notifiche utente sono un problema complesso

WordPress non fornisce un'API formale per le notifiche degli utenti. Tuttavia, fornisce un insieme standard di classi CSS e un hook per allegare avvisi. Il Codex contiene anche alcuni esempi di buone pratiche. La mancanza di un'API formale ha lasciato gli autori di temi e plugin sui propri dispositivi. Gli utenti hanno sofferto a causa di implementazioni estremamente diverse e di problemi comuni come annunci non riconoscibili.

Tim Hengeveld ha proposto un'API del Centro di notifica su Trac nel 2018. Il ticket ha una discussione sana e continua e alcune proposte dell'interfaccia utente. La proposta è ancora contrassegnata come "In attesa di revisione" ed è improbabile che venga spedita prima di WordPress 5.4 o versioni successive.

Attualmente, molti plugin e temi utilizzano anche gli avvisi dell'amministratore per l'onboarding degli utenti, che è un problema separato che necessita di una soluzione. C'è un ticket di 4 anni che parla dell'onboarding dei nuovi utenti di WordPress, ma non c'è molto movimento per risolvere questo problema per plugin e temi.

Sebbene il pacchetto di TRT non affronti tutti i problemi associati alle notifiche degli utenti, aiuta a limitare alcuni dei danni a breve termine.

Altri pacchetti in lavorazione

Altri pacchetti sono attualmente in fase di creazione e altri sono in fase di pianificazione.

L'obiettivo del progetto generale è fornire agli autori dei temi moduli drop-in che possono raggruppare con i loro temi. I pacchetti sono tutti scritti in PHP 5.6+ nella speranza di spingere gli autori dei temi verso pratiche di codifica più moderne (relativamente parlando, dal momento che PHP 7.4 sarà rilasciato quest'anno). Aiuterà anche a semplificare il processo di revisione se più autori di temi adottano i pacchetti anziché creare tutto internamente.

"Se creiamo pacchetti per le cose più richieste, speriamo di consentire alle persone di creare temi di qualità più facilmente", ha spiegato Stathopoulos. "Penso ai pacchetti come elementi costitutivi per i temi".

Stathopoulos sta lavorando a un controllo di personalizzazione per la selezione di un colore con trasparenza alfa, che potrebbe essere rilasciato già la prossima settimana. Fornirà agli utenti del tema un maggiore controllo su come appaiono i loro colori per i temi che lo implementano.

"Dopo aver creato le basi, voglio concentrarmi sui pacchetti che migliorerebbero la salute e la privacy nei temi, due aree in cui i temi non sono all'altezza", ha affermato. "Aiuterebbe molte persone, e questo è in definitiva il nostro obiettivo".

Negli ultimi anni gli autori di temi si sono abituati a installare pacchetti JavaScript e CSS tramite NPM. Tuttavia, il loro uso di Composer come gestore delle dipendenze PHP è in ritardo. In parte, ciò potrebbe essere dovuto alla precedente riluttanza di WordPress a modificare la sua versione minima di PHP. Molti pacchetti disponibili su Packagist, il repository principale di Composer, non funzionano con le versioni precedenti di PHP. Il recente passaggio di WordPress a PHP 5.6+ e i piani per passare a 7+ in futuro potrebbero spingere più autori di temi a prendere in considerazione la gestione delle dipendenze PHP.

Il TRT ha un account Packagist e ha reso tutti i suoi pacchetti installabili tramite Composer.

Nessun obbligo di utilizzare ancora i pacchetti

Non ci sono piani attuali per TRT per iniziare a richiedere l'uso di questi pacchetti per funzionalità specifiche, ma alcuni membri del team hanno proposto di farlo.

"Ci sono valide ragioni per imporre l'uso di questi pacchetti, ma non può accadere dall'oggi al domani", ha affermato Stathopoulos. “Vogliamo che i temi nel repository abbiano degli standard, non può essere il selvaggio west. La qualità del codice deve migliorare. Questi pacchetti sono un modo per semplificare la vita alle persone e, in definitiva, per far risparmiare tempo a tutti".

Stathopoulos è aperto agli autori di temi che creano implementazioni personalizzate se possono migliorare ciò che il team ha creato, ma preferisce che gli autori "discutano le loro idee nel repository del pacchetto e inviino una richiesta pull in modo che l'intera comunità possa trarne beneficio".

Il coinvolgimento degli autori dei temi è un'area in cui il team ha lottato. Contribuire ai pacchetti potrebbe avvantaggiare l'intera comunità. "La maggior parte delle persone non li conosce nemmeno poiché non sono elencati da nessuna parte", ha affermato Stathopoulos. "Gli autori dei temi attualmente devono cercarli e per cercarli qualcuno deve dire loro che esistono (cosa che non accade)." Uno dei passaggi successivi sarebbe ottenere i pacchetti elencati nella documentazione di TRT.

Lavorare insieme su caratteristiche tematiche comuni potrebbe fornire un ponte tra autori e revisori del tema, consentendo loro di risolvere i problemi insieme.

Nota: l'autore di questo articolo è stato coinvolto nella proposta iniziale dei pacchetti di temi e uno sviluppatore nelle sue versioni iniziali del pacchetto.