Indice dei contenuti dell'articolo:
Il recente conflitto tra WordPress e WP Engine ha catturato l’attenzione della comunità di sviluppo WordPress a livello globale. Al centro della controversia vi è il plugin Advanced Custom Fields (ACF), uno strumento fondamentale per la personalizzazione delle pagine di modifica di WordPress. Questo post esaminerà i dettagli della vicenda, analizzando il contesto, le motivazioni alla base dell’azione di WordPress e le implicazioni più ampie per la comunità di sviluppatori e utenti di WordPress.
La Nascita del Conflitto tra WordPress e WP Engine
La controversia è emersa nel contesto di una disputa legale tra Matt Mullenweg, fondatore di WordPress e CEO di Automattic, e WP Engine, un importante fornitore di servizi di hosting per WordPress. Il centro della disputa sembra ruotare attorno a una serie di azioni legali reciproche, accuse di branding confuso e rivendicazioni di diritti sul marchio “WordPress”.
Matt Mullenweg ha criticato pubblicamente WP Engine in un post sul suo blog, definendo l’azienda come “un cancro per WordPress”. Tra le critiche sollevate vi era la mancanza di supporto per la cronologia delle revisioni e una gestione che, a detta di Mullenweg, poteva confondere gli utenti, facendo credere loro che WP Engine fosse ufficialmente affiliata a WordPress.
Un aspetto cruciale della controversia è stata la minaccia da parte di Mullenweg di intraprendere un’azione legale se WP Engine non avesse pagato per ottenere una licenza per l’uso del marchio WordPress. WP Engine, a sua volta, ha risposto con le proprie lettere di diffida, accentuando ulteriormente la tensione tra le parti.
La Fork di Advanced Custom Fields e la Nascita di Secure Custom Fields
Al centro di questa disputa c’è il plugin Advanced Custom Fields (ACF), un’estensione fondamentale per l’ecosistema WordPress che ha avuto un impatto enorme sulla capacità degli sviluppatori di personalizzare la piattaforma. ACF è stato sviluppato da Elliot Condon e lanciato per la prima volta nel 2011 come uno strumento per estendere la flessibilità di WordPress, permettendo agli sviluppatori di aggiungere campi personalizzati alle pagine di modifica di WordPress. Questo ha trasformato il modo in cui gli utenti e gli sviluppatori gestiscono i contenuti all’interno di WordPress, offrendo un livello di controllo molto maggiore sui dati e sulle informazioni visualizzate sui loro siti.
Cos’è ACF e Perché è Importante
ACF si distingue per la sua semplicità d’uso e per la sua capacità di ampliare notevolmente le funzioni native di WordPress, consentendo agli sviluppatori di creare facilmente campi personalizzati per tipi di post, pagine e tassonomie. Prima dell’avvento di ACF, WordPress già supportava i “custom fields” nativamente, ma l’interfaccia e le funzioni disponibili erano limitate e non particolarmente intuitive per la maggior parte degli utenti. ACF ha colmato questa lacuna, fornendo una soluzione più robusta e user-friendly, rendendo facile l’aggiunta di campi quali:
- Testo
- Textarea
- Immagini
- File
- Selettori di date
- Dropdown
- Ripetitori di campi (repeater fields)
Questi campi personalizzati possono essere utilizzati in qualsiasi parte del sito, dal backend all’interfaccia utente. L’adozione di ACF ha permesso ai proprietari di siti web, agli sviluppatori e ai designer di WordPress di costruire soluzioni estremamente personalizzate senza dover scrivere codice complesso. Questo ha reso ACF uno strumento chiave per agenzie digitali, freelance e aziende di sviluppo che necessitavano di flessibilità e personalizzazione senza dover reinventare la ruota.
Il Successo di ACF e il Ruolo di WP Engine
Negli anni, ACF ha visto una crescita esponenziale e ha attirato una comunità devota di sviluppatori e utenti. La semplicità con cui consente di personalizzare WordPress ha fatto sì che diventasse uno dei plugin più utilizzati e amati, tanto da portare alla nascita di una versione “Pro”, con funzionalità aggiuntive come campi ripetitori e gallerie di immagini avanzate. L’importanza di ACF per gli sviluppatori non può essere sottovalutata, poiché ha aperto nuove possibilità di sviluppo e design per siti web complessi, incluse soluzioni avanzate di e-commerce, portali di contenuti e piattaforme di gestione dati.
Nel 2022, WP Engine ha acquisito ACF insieme ad altri plugin popolari, come WP Migrate e WP Offload Media, portando con sé l’esperienza maturata nel settore dell’hosting WordPress premium. L’acquisizione ha segnato un passaggio strategico importante per WP Engine, che ha consolidato la sua posizione come leader non solo nell’hosting, ma anche nella gestione di plugin fondamentali per l’ecosistema di WordPress. Tuttavia, questo ha anche portato a una nuova dimensione nel conflitto tra WP Engine e WordPress, alimentato da preoccupazioni legate alla concorrenza commerciale.
L’Intervento di WordPress: La Creazione di Secure Custom Fields
Con il peggiorare delle tensioni legali tra Matt Mullenweg e WP Engine, WordPress ha deciso di intervenire direttamente su ACF, una mossa che ha sorpreso molti nella comunità. Mullenweg ha annunciato la creazione di una fork del plugin ACF, chiamata Secure Custom Fields, giustificando l’azione come un passo necessario per rimuovere riferimenti commerciali dal plugin e risolvere presunti problemi di sicurezza. Nonostante non siano stati forniti dettagli precisi sui problemi di sicurezza individuati, Mullenweg ha fatto riferimento al “Punto 18” delle linee guida del repository di plugin di WordPress, che concede a WordPress.org il potere di rimuovere o modificare un plugin senza il consenso dello sviluppatore in caso di preoccupazioni legate alla sicurezza o all’interesse pubblico.
Secondo Mullenweg, WP Engine stava utilizzando ACF come un’opportunità per promuovere ulteriori vendite, in contrasto con i principi di WordPress, che prediligono un approccio meno commerciale. Sebbene le motivazioni riguardanti la sicurezza non siano state chiaramente esplicitate, è evidente che WordPress voleva limitare l’influenza commerciale che WP Engine esercitava attraverso il plugin. Questo intervento ha quindi portato alla nascita di Secure Custom Fields, una versione alternativa del plugin, gestita direttamente da WordPress e senza scopi commerciali.
Di seguito la traduzione del comunicato ufficiale di Matt Mullenweg :
A nome del team di sicurezza di WordPress, annuncio che stiamo invocando il punto 18 delle linee guida del plugin directory e stiamo creando un fork di Advanced Custom Fields (ACF) in un nuovo plugin, Secure Custom Fields (SCF). SCF è stato aggiornato per rimuovere le promozioni commerciali e correggere un problema di sicurezza.
Il 3 ottobre, il team di ACF ha annunciato che gli aggiornamenti del plugin ACF saranno disponibili direttamente dal loro sito web. Questo è stato comunicato anche tramite un avviso di supporto nel forum di WordPress.org il 5 ottobre. I siti che hanno seguito le istruzioni del team di ACF su “Come aggiornare ACF” continueranno a ricevere aggiornamenti direttamente da WP Engine. Il 1° ottobre 2024, WP Engine ha anche implementato una propria soluzione per aggiornamenti e installazioni di plugin e temi sui siti dei propri clienti, sostituendo il servizio di aggiornamento di WordPress.org.
I siti che continuano a utilizzare il servizio di aggiornamento di WordPress.org e non hanno scelto di passare agli aggiornamenti di ACF da WP Engine possono cliccare per aggiornare e passare a Secure Custom Fields. Nei casi in cui i siti hanno abilitato gli aggiornamenti automatici dei plugin tramite WordPress.org, questo processo di aggiornamento li trasferirà automaticamente da Advanced Custom Fields a Secure Custom Fields.
Questo aggiornamento è il più minimale possibile per risolvere il problema di sicurezza. D’ora in avanti, Secure Custom Fields sarà un plugin non commerciale, e se qualche sviluppatore desidera partecipare al suo mantenimento e miglioramento, è invitato a contattarci.
Situazioni simili si sono verificate in passato, ma non a questa scala. Si tratta di una situazione rara e insolita causata dagli attacchi legali di WP Engine, e non prevediamo che accada con altri plugin.
WP Engine ha pubblicato istruzioni su come utilizzare la loro versione di Advanced Custom Fields che utilizza il loro server di aggiornamento, quindi avete questa opzione, anche se il team di sicurezza di WordPress non la raccomanda fino a quando non verranno risolti i problemi di sicurezza. Potete disinstallare Advanced Custom Fields e attivare Secure Custom Fields dalla directory dei plugin senza problemi.
Ci sono anche altre notizie separate, ma non direttamente correlate: Jason Bahl ha lasciato WP Engine per lavorare con Automattic e renderà WPGraphQL un plugin canonico della comunità. Ci aspettiamo che altri lo seguiranno.
La Reazione di WP Engine
WP Engine non ha tardato a rispondere a questa decisione. Il team di ACF ha espresso il proprio disappunto sui social media, sostenendo che WordPress aveva “forzatamente e unilateralmente” sottratto il controllo del plugin senza il loro consenso, cosa che, a loro dire, non era mai accaduta nei 21 anni di storia di WordPress.
Questa dichiarazione ha suscitato reazioni contrastanti all’interno della comunità di WordPress, con alcuni sviluppatori che hanno messo in discussione la legittimità dell’azione di WordPress, mentre altri hanno sostenuto che, data la natura open source della piattaforma, era nei diritti di WordPress prendere questa decisione per il bene della sicurezza pubblica.
Anche in questo caso ecco la traduzione in italiano del comunicato di WP Engine e nello specifico del team Advanced Custom Fields:
Siamo profondamente rattristati e sconvolti dalle azioni di Matt Mullenweg di questa mattina, che ha appropriato il plugin Advanced Custom Fields, che il nostro team ACF sviluppa attivamente per la comunità WordPress dal 2011.
Advanced Custom Fields è un plugin sofisticato con oltre 200.000 righe di codice, che continuiamo a sviluppare, migliorare, supportare e in cui investiamo per soddisfare le esigenze dei nostri utenti su WordPress. Negli ultimi due anni, da quando ci siamo uniti a WP Engine, abbiamo rilasciato oltre 15 aggiornamenti e aggiunto funzionalità significative al plugin gratuito, migliorando costantemente le prestazioni e le nostre pratiche di sicurezza e test per garantire un livello “enterprise” che i nostri utenti meritano.
Il cambiamento nella nostra distribuzione pubblicata, e sotto il nostro “slug” che identifica univocamente il plugin ACF e il codice su cui i nostri utenti fanno affidamento nel repository di WordPress.org, è incoerente con i valori e i principi dell’open source. Il cambiamento apportato da Mullenweg viene utilizzato in modo malevolo per aggiornare milioni di installazioni esistenti di ACF con codice non approvato e non fidato dal team di Advanced Custom Fields.
Siamo in grado di proteggere direttamente i clienti di WP Engine, Flywheel hosting e ACF PRO: voi non siete impattati e non dovete intraprendere alcuna azione. Continuerete a ricevere le ultime innovazioni e aggiornamenti dagli esperti del team ACF. Il codice di ACF su wordpress.org non è più controllato dal team ACF.
Se avete un sito gestito altrove utilizzando la versione gratuita di ACF, per ottenere aggiornamenti autentici di ACF dovete effettuare un download una tantum della versione 6.3.8 tramite advancedcustomfields.com per rimanere sicuri in futuro. Dopo questo download una tantum, sarete in grado di aggiornare come di consueto tramite il pannello di amministrazione di WordPress.
Potete seguire lo stesso processo se il vostro sito è già stato aggiornato al plugin modificato “Secure Custom Fields”, per tornare a una versione autentica di ACF.
Le azioni di Mullenweg sono estremamente preoccupanti e rappresentano un grave rischio di sconvolgere e danneggiare irreparabilmente l’intero ecosistema WordPress. Il suo tentativo di prendere unilateralmente il controllo di questa piattaforma aperta, su cui noi e molti altri sviluppatori di plugin e collaboratori ci siamo affidati nello spirito di condivisione dei plugin per tutti, fornisce ulteriori prove del suo serio abuso di fiducia, dei numerosi conflitti di interesse e della violazione delle promesse di apertura e integrità all’interno della comunità.
L’Impatto per gli utenti di ACF
Uno degli aspetti più controversi di questa vicenda riguarda il modo in cui gli utenti del plugin ACF saranno impattati. Con WordPress che ha preso il controllo di ACF e creato Secure Custom Fields, gli utenti dovranno scegliere tra due versioni del plugin: quella originale, mantenuta da WP Engine, e la nuova versione forkata gestita da WordPress.
Per gli utenti della versione gratuita di ACF, WP Engine ha rilasciato una soluzione temporanea che consente di scaricare manualmente l’ultima versione del plugin originale (6.3.8) dal sito di ACF. Tuttavia, gli utenti della versione Pro continueranno a ricevere aggiornamenti direttamente da WP Engine, creando una potenziale divisione tra chi utilizza la versione gratuita e chi usa la versione a pagamento.
Le Implicazioni per la Comunità WordPress
Questo evento ha aperto un dibattito importante nella comunità di WordPress su diversi temi, tra cui la governance dei plugin, il ruolo degli sviluppatori commerciali e la protezione degli utenti. Uno degli aspetti più discussi è se WordPress dovrebbe avere il potere di prendere decisioni unilaterali riguardo ai plugin sviluppati da terze parti, in particolare quando si tratta di sviluppatori commerciali come WP Engine.
Da un lato, l’azione di WordPress può essere vista come una mossa necessaria per proteggere gli utenti da potenziali vulnerabilità di sicurezza e per preservare la filosofia open source della piattaforma. In questo senso, l’eliminazione delle vendite aggiuntive all’interno di un plugin gratuito può essere interpretata come un tentativo di garantire un’esperienza utente coerente e trasparente, priva di spinte commerciali che potrebbero distorcere l’approccio libero e collaborativo su cui WordPress è stato costruito. La decisione di creare un fork di ACF sotto il nome “Secure Custom Fields” potrebbe essere giustificata, secondo WordPress, dalla necessità di fornire un plugin sicuro, senza legami commerciali, che possa essere gestito e mantenuto dalla comunità.
Dall’altro lato, però, molti sviluppatori vedono questa azione come immotivata e politicamente motivata. La percezione è che si tratti di un tentativo di boicottare WP Engine, soprattutto in seguito al conflitto riguardante la richiesta di una royalty dell’8% del fatturato come pagamento per continuare a mantenere il plugin ACF all’interno del repository ufficiale di WordPress. Questo evento solleva preoccupazioni non solo per WP Engine, ma anche per l’intera comunità di sviluppatori. Molti si domandano se questo tipo di intervento da parte di WordPress possa costituire un precedente per futuri casi di interferenza, soprattutto quando sono coinvolti plugin o sviluppatori che hanno interessi commerciali.
La principale preoccupazione di chi critica questa mossa è che WordPress potrebbe iniziare a esercitare un controllo eccessivo su come i plugin sono gestiti, distribuiti e commercializzati all’interno della piattaforma. Se da un lato la protezione della sicurezza e l’adesione ai principi open source sono fondamentali, dall’altro c’è il timore che la libertà degli sviluppatori di innovare, monetizzare e distribuire i propri prodotti possa essere compromessa. La comunità si chiede se tali interventi possano trasformarsi in una forma di controllo centralizzato, minando l’indipendenza su cui WordPress ha costruito la sua reputazione. Se WordPress può intervenire unilateralmente in un caso come quello di ACF, potrebbe farlo di nuovo, introducendo incertezza per gli sviluppatori che basano il proprio lavoro su questa piattaforma.
Conclusioni
La disputa tra WordPress e WP Engine riguardante ACF rappresenta un momento cruciale per l’intero ecosistema WordPress, con implicazioni che vanno ben oltre la gestione di un singolo plugin. La decisione di WordPress di forzare una fork del plugin ACF, creando Secure Custom Fields, apre una serie di questioni fondamentali legate alla governance della piattaforma, alla sicurezza e ai diritti degli sviluppatori. Tuttavia, la portata di questa azione va considerata anche alla luce delle potenziali conseguenze per altri attori commerciali che operano all’interno dell’ecosistema WordPress.
WP Engine non è solo uno sviluppatore di plugin, ma un vero e proprio Big Player nel settore dell’hosting WordPress, con una posizione di rilievo che potrebbe aver attirato l’attenzione di Automattic per la sua crescente influenza e le controversie legali. Questa presa di controllo del plugin ACF da parte di WordPress potrebbe rappresentare un precedente per altre situazioni simili in futuro, e altri attori commerciali potrebbero trovarsi in una posizione vulnerabile se dovessero entrare in conflitto con WordPress o Automattic.
Prendiamo, ad esempio, plugin di grande rilevanza commerciale come WP Rocket, un plugin di ottimizzazione della cache ampiamente utilizzato, oppure Elementor, il popolare page builder che ha costruito un intero ecosistema di prodotti e servizi intorno a WordPress. Elementor stesso offre una soluzione di hosting denominata Elementor Hosting, che potrebbe essere percepita come un potenziale concorrente per i servizi di hosting di Automattic, come WordPress.com, WP VIP e Pressable, meno noto ma comunque una parte strategica del portafoglio hosting di Automattic.
Se WordPress decidesse di applicare lo stesso trattamento riservato a WP Engine ad altre aziende, si potrebbe arrivare a una situazione in cui Automattic e WordPress.org utilizzino il proprio potere per intervenire su plugin e servizi commerciali percepiti come minacce competitive. La stessa Elementor potrebbe essere vista come un concorrente diretto per i page builder integrati in WordPress e per i servizi di hosting di Automattic. Lo stesso vale per WP Rocket, che potrebbe un giorno trovarsi a fronteggiare una simile “forcatura” o altre azioni che limitino il suo potenziale commerciale.
Il problema più grande è che questo tipo di azioni unilaterali rischia di scoraggiare l’innovazione e creare una cultura di incertezza tra gli sviluppatori di plugin e le aziende che costruiscono servizi attorno all’ecosistema WordPress. La percezione che WordPress possa prendere il controllo di progetti di successo senza il consenso degli sviluppatori mette in discussione la fiducia di chi, fino a oggi, ha contribuito a rendere la piattaforma così versatile e popolare. Se queste decisioni venissero applicate in modo più ampio, potrebbero destabilizzare l’ecosistema WordPress, portando a un conflitto tra la comunità open source e le aziende che costruiscono il loro business sulla piattaforma.
È quindi fondamentale che la comunità di WordPress rifletta attentamente su questi sviluppi. Non si tratta solo di proteggere la piattaforma e i suoi utenti da potenziali problemi di sicurezza, ma anche di preservare i principi dell’open source, in cui la collaborazione e l’innovazione devono essere sostenute senza che ci sia il rischio di interferenze commerciali. Se la governance di WordPress diventa troppo centralizzata, si potrebbe creare un ambiente in cui solo gli attori affiliati a Automattic siano liberi di operare senza preoccupazioni, limitando la libertà di innovazione per altri sviluppatori e aziende.
Attenderemo i prossimi mesi per comprendere quanto questa azione sia stata dannosa per l’intero ecosistema e comunità WordPress, senza dimenticare di seguire la vicenda legale tra WP Engine ed Automattic, alla luce di quello che sembra a tutti gli effetti un tentativo di estorsione da parte di Automattic ai danni di WP Engine.
