Ci sono stati molti riferimenti ai “plugin canonici” dal 2009 ad oggi, specialmente al WordCamps di Matt, ma non abbiamo pubblicato nulla di ufficiale sull’idea, né abbiamo fatto molti progressi oltre le discussioni su quanto sarebbe fantastico essere avere plugin canonici e quanto sarebbe bello per la comunità.
Cos’è un plugin Canonico di WordPress, o un Canonical Plugins.
Questa è una delle tante cose di cui il core commit team ha parlato negli ultimi giorni e tutti concordano sul fatto che dobbiamo dare la priorità a questo aspetto del progetto prima piuttosto che dopo. Quindi, ecco una descrizione di altissimo livello di come stiamo attualmente pensando ai plugin canonici, che vorremmo utilizzare per avviare una discussione comunitaria mirata sull’argomento.
I plug-in canonici sarebbero plug-in sviluppati dalla comunità (più sviluppatori, non solo una persona) e rispondono alle richieste di funzionalità più popolari con un’esecuzione superlativa. Questi plugin sarebbero GPL e risiedono nel repository di WordPress.org e sarebbero sviluppati in stretta connessione con il core di WordPress. Ci sarebbe una relazione molto forte tra il core e questi plug-in che garantisse che a) il codice del plug-in fosse sicuro e il miglior esempio possibile di standard di codifica e b) che le nuove versioni di WordPress sarebbero state testate rispetto a questi plug-in prima del rilascio su garantire la compatibilità. Ci sarebbe una schermata all’interno della sezione Plugin dell’amministratore di WordPress per presentare questi plug-in canonici come una sorta di garanzia a scelta dell’editore o verificata. Questi plugin sarebbero una vera estensione del core WordPress in termini di compatibilità,
Canonical Plugin e WordCamp 2022. L’appello di Matt Mullenweg.
Durante la giornata dei collaboratori di WordCamp US questo fine settimana, Matt Mullenweg ha pubblicato un rinnovato invito ai team Make di WordPress ad adottare un approccio basato sui plug-in durante lo sviluppo di nuove funzionalità per il core. Ha fatto rivivere la nozione di plug-in canonici, introdotta per la prima volta nella comunità di WordPress nel 2009 come mezzo per fornire funzionalità opzionali agli utenti con un livello di sicurezza più elevato rispetto ai normali plug-in:
I plug-in canonici sarebbero plug-in sviluppati dalla comunità (più sviluppatori, non solo una persona) e rispondono alle richieste di funzionalità più popolari con un’esecuzione superlativa. Questi plugin sarebbero GPL e risiedono nel repository di WordPress.org e sarebbero sviluppati in stretta connessione con il core di WordPress. Ci sarebbe una relazione molto forte tra il core e questi plug-in che garantisse che a) il codice del plug-in fosse sicuro e il miglior esempio possibile di standard di codifica e b) che le nuove versioni di WordPress sarebbero state testate rispetto a questi plug-in prima del rilascio su garantire la compatibilità. Ci sarebbe una schermata all’interno della sezione Plugin dell’amministratore di WordPress per presentare questi plug-in canonici come una sorta di garanzia a scelta dell’editore o verificata. Questi plugin sarebbero una vera estensione del core WordPress in termini di compatibilità,
Jen Mylo
La directory dei plug-in di WordPress è a un solo plug-in dal superamento di 60.000 (al momento della pubblicazione). Contrariamente all’idea dei plugin canonici, la directory ufficiale è ancora come il selvaggio west in termini di ciò che gli utenti possono aspettarsi dagli autori di plugin. Mullenweg ha citato diversi scenari di plug-in che non sono ideali per gli utenti, come un plug-in controllato da una singola azienda e in evoluzione verso una versione pro o la rimozione di funzionalità precedentemente gratuite e l’inserimento di un aggiornamento.
I plugin canonici hanno lo scopo di fornire un’alternativa affidabile ai plugin in cui le motivazioni degli autori potrebbero non mettere gli utenti al primo posto. Fornisce inoltre una strada per i contributori principali per dimostrare la domanda di funzionalità che desiderano ottenere in WordPress. Alcuni progetti come MP6, Gutenberg e l’API REST hanno portato questo percorso nel core.
Stiamo raggiungendo un punto in cui il core deve essere più editoriale e dire ‘no’ alle funzionalità che arrivano ad hoc come a volte fanno, e la mia speranza è che più team Make utilizzino questa come un’opportunità per influenzare il futuro di WordPress attraverso un approccio plug-first che offre loro il lusso di cicli di sviluppo e rilascio più rapidi (invece di tre volte all’anno), meno spese generali di revisione e un percorso per entrare nel core se il plug-in diventa un successo travolgente,
ha affermato Mullenweg.
Sono molto consapevole del fatto che quando le persone mirano ad avere qualcosa nel core, un ‘no’ o un ‘non ora’ può essere frustrante e talvolta creare una pressione artificiale per inserire qualcosa prima che sia pronto, come credo sia successo con l’API REST in WP 4.4.
In un post correlato che ha ispirato la rinnovata discussione sui plugin canonici, Mullenweg ha soppesato la controversa proposta WebP per impostazione predefinita che aveva recentemente ricevuto nuove obiezioni dagli sviluppatori principali di WordPress. I contributori hanno lavorato febbrilmente per rivedere il loro approccio in tempo per 6.1.
Mullenweg ha raccomandato queste nuove funzionalità come un ottimo candidato per il percorso del plug-in canonico, suggerendo che avrebbe concesso più tempo per la maturazione dell’ecosistema attorno a WebP:
Sono interessato a supportare nuovi formati e migliorare le prestazioni, ma penso che questa modifica inviata per impostazione predefinita agli utenti quando eseguono l’aggiornamento a 6.1 sia molto per ora, anche con alcune delle interazioni goffe che i sistemi operativi hanno ancora attorno a webp (e HEIC! ) File.
Sono felice che il supporto per il lavoro per i file webp e HEIC rimanga nel core, poiché dovremmo essere liberali in ciò che accettiamo e lavoriamo, ma non con la modifica per convertire tutto in webp quando vengono caricati i JPEG.
Il team Performance prevede di discuterne nella chat programmata di domani. Non è ancora chiaro se i recenti tentativi di WebP per impostazione predefinita verranno indirizzati allo stato di plug-in canonico o se parte di esso potrebbe ancora arrivare alla versione 6.1.
Le risposte alla richiesta di plug-in più canonici sono state contrastanti, poiché alcuni hanno immediatamente riconosciuto il maggiore onere per i manutentori di questi plug-in.
“WP ha solo bisogno di superare la sua avversione per le funzionalità opzionali“, ha detto lo sviluppatore di WordPress Jon Brown.
Funzioni che possono essere abilitate/disabilitate. “Decisioni non opzioni” è un ottimo ethos quando si tratta di mantenere le cose semplici per gli utenti, ma sembra essere stato buttato fuori dalla finestra con Gutenberg UX e trasformato in assioma quando si discute di aggiungere opzioni banalmente semplici alla pagina delle impostazioni.
Il collaboratore sponsorizzato da iThemes Timothy Jacobs ha affermato di non essere necessariamente favorevole all’aggiunta di più opzioni a Core, ma pensa che i plugin canonici potrebbero essere presentati in modo simile alle opzioni.
Ciò non significa che l’interfaccia utente debba semplicemente cercare nella directory dei plugin qualcosa che desideri”, ha detto Jacobs. “I plugin canonici potrebbero essere esposti forse in un’interfaccia utente ‘simile alle impostazioni’. Penso che i metodi di importazione siano un po’ nascosti nel menu Strumenti, ma forse qualcosa del genere.
Il collaboratore principale Torsten Landsiedel ha affermato che la differenza tra plug-in canonici e plug- in di funzionalità non è chiara. La distinzione potrebbe essere che i plugin canonici includono quelli che potrebbero non appartenere mai al core ma sono comunque importanti per gli utenti.
Sembra che il plug-in ‘WordPress importer’ possa essere un plug-in canonico. Non sono sicuro che questo sia un buon esempio per un plugin *fiorente*. Non supporta le immagini in primo piano, lotta con quantità elevate di post/media, ecc. L’utile plug-in Health Check lotta con le persone scomparse che aiutano.
ha affermato Landsiedel.
Come possiamo evitare che quei plugin (qualunque si chiami) non ottengano abbastanza contributori? Penso che un importatore sia uno strumento cruciale, ma non necessario nel core (posso installarlo se ne ho bisogno, va bene) – ma dovrebbe funzionare e al momento non funziona bene. Ma non vedo molto interesse da parte della comunità di sviluppatori per aiutare a risolvere questo problema (forse perché usano WP CLI e non si preoccupano di questo plugin?)
Il collaboratore principale di WordPress Colin Stewart ha affermato che, sebbene concordi che le funzionalità in quanto plug-in sono utili per le nuove funzionalità, richiede “una metrica molto migliore del” successo travolgente “per l’inclusione nel core.”
Alcune funzionalità sono importanti per la stabilità e proteggono gli utenti da problemi che causano loro mal di testa più volte durante la vita del loro sito Web, ma non sono qualcosa che gli utenti potrebbero pensare di cercare nel repository dei plug-in o di installarli a vista. Il rollback è una funzionalità del genere, così come l’integrità del sito, l’esportazione/cancellazione della privacy e così via.
ha affermato Stewart.
“Un processo decisionale formale per le proposte sarebbe incredibilmente utile. Questo argomento sta venendo fuori regolarmente ora“.
Mullenweg ha offerto quasi due dozzine di idee per plugin canonici che i team Make potrebbero prendere in considerazione e ha suggerito che i team stessi potrebbero probabilmente trovare idee migliori. Immaginare tutte queste nuove funzionalità in gioco, sarebbe come una rinascita dell’innovazione nell’amministrazione. Questa è una prospettiva entusiasmante che potrebbe avvantaggiare gli utenti di WordPress purché i plug-in siano presentati in modo tale da essere facili da adottare. I primi commentatori dell’idea sollevano legittime preoccupazioni sulla mancanza di manutentori, poiché la storia mostra che il supporto per alcuni dei plugin canonici esistenti è alquanto irregolare.
Spero che accenda una discussione durante il giorno del contributore e oltre su come possiamo utilizzare meglio i plugin per aumentare la velocità di evoluzione di WordPress, mantenere il core leggero, veloce e supponente, e farlo dicendo ‘sì’ a più idee e sperimentazioni
ha detto Mullenweg.
