Aggiornato il: 28-04-2021 22:45
Il problema, di natura squisitamente tecnica, sarebbe relativo non tanto agli sviluppatori (per cui la differenza “operativa” tra framework e plugin potrebbe sembrare davvero minima) quanto all’utente finale, per il quale le opzioni extra offerte tipicamente dai framework – più a largo spettro rispetto a quelle, localizzate, dei plugin – potrebbero non dare un’esperienza ottimale di uso. Il motivo di questa scelta sembra essere legato a razionalizzare le dipendenze di WordPress, ed evitare possibili riscritture o conflitti all’interno delle varie personalizzazioni.
Tale scelta è importante dal punto di vista generale, in quanto mette in chiaro la differenza tra plugin e framework, un aspetto molto poco considerato o del tutto trascurato dai programmatori: il numero di plugin che introducono caratteristiche da framework è notevole, e ci sono anche tantissimi theme che lo fanno. Questi ultimi, si scrive nel comunicato ufficiale, servono a fornire funzionalità estese – tra cui estendere e potenziare possibilità tipiche degli ambienti di programmazione avanzati, come quella di poter includere un gestore di dipendenze come Composer (sono quindi più che altro da developer puri), mentre i primi danno più semplicemente delle possibilità di interazione all’utente (e sono più immediati in tal senso, in quanto offrono quasi sempre un’ennesima interfaccia con cui poter interagire).
L’indicazione non vale, comunque, in modo retroattivo: i plugin con framework integrati già presenti nella cartella https://it.wordpress.org/plugins/ potranno continuare ad esistere all’interno della cartella. Non ne potranno essere caricati di nuovi, piuttosto, e questo nella speranza di limitare una cattiva abitudine di programmazione e mantenere una certa pulizia all’interno del celebre repository.
Photo by planetlight
