Premi questo: i tuoi plugin WordPress sono compatibili con la GPL?

Benvenuti a Press This, il podcast della community WordPress di WMR. Ogni episodio presenta ospiti provenienti da tutta la comunità e discussioni sui problemi più grandi che devono affrontare gli sviluppatori di WordPress. Quella che segue è la trascrizione della registrazione originale.

Alimentato da RedCircle

Doc Pop : stai ascoltando Press This, un podcast della community WordPress su WMR. Ogni settimana mettiamo in evidenza i membri della community di WordPress. Sono il tuo ospite, Doc Pop. Supporto la community di WordPress attraverso il mio ruolo in WP Engine e i miei contributi su TorqueMag.io. Puoi iscriverti a Press This su RedCircle, iTunes, Spotify o la tua app di podcasting preferita oppure puoi scaricare gli episodi direttamente da WMR.fm.

Se hai mai contribuito a un progetto open source, sai che è tutta una questione di collaborazione e innovazione, ma c'è una sfida poco conosciuta che molti sviluppatori potrebbero affrontare nel garantire che i loro plugin rimangano dalla parte giusta di GPL, GNU, Licenza pubblica generale. Non è solo una questione di conformità. Si tratta di preservare lo spirito dell'open source.

Quindi oggi abbiamo un ospite speciale, Jeff Paul, il direttore dell'open source di 10up, che condividerà una soluzione rivoluzionaria presentata quest'anno al WordCamp US. Immagina di avere uno strumento che scansiona automaticamente la tua codebase per garantire la compatibilità GPL del tuo plugin, anche se aggiungi nuove funzionalità e dipendenze.

Questo è ciò di cui parleremo oggi. Ma prima di approfondire l'argomento, Jeff, puoi raccontarci la storia delle origini di WordPress?

Jeff Paul : Certo. Non so se ho l'anno esatto. Probabilmente erano i primi anni 2000. Avevo un sito personale che era su un ex CMS, penso che si chiamasse Geeklog. E tra questo e il mio provider di hosting di allora, e chissà quanti altri fattori, c'è stato un collasso dei contenuti nel CMS.

E quindi stavo solo cercando qualcosa con cui sostituirlo in quel momento. Ho trovato WordPress e ha funzionato per ciò di cui avevo bisogno. Sai, non ho intrapreso personalmente la strada della costruzione di un CMS, che sembra essere una buona storia di origine per molte persone. Ma è stato, chiamiamolo, non so, dal '04 al '07, da qualche parte in quell'intervallo, ma non ho superato il limite per contribuire fino al rilascio di WordPress 4.7 quando mi sono unito alla squadra di rilascio lì con Helen Hou-Sandi e Aaron Jorbin. Quindi, ho passato molti anni a consumare il progetto, e solo dopo un bel po' di tempo sono diventato un collaboratore e da allora ho continuato su quella strada. Bene, sai, doppio consumatore e collaboratore a questo punto.

DP : E hai contribuito molto attivamente anche al core di WordPress. 10up mantiene dozzine di plugin nel repository dei plugin, inclusi ElasticPress, Distributor, ClassifAI. Questi sono tutti disponibili nel repository wordpress.org e sono mantenuti su GitHub, pubblicamente e utilizzando pratiche open source.

Conosci molto bene l'argomento in cui approfondiremo. Perché non iniziamo semplicemente con il repository di WordPress, ad esempio il repository dei plugin di WordPress? Raccontaci velocemente, cos'è il repository WordPress e quali sono le regole per poter caricare qualsiasi cosa al suo interno?

JP : Certo. Quindi il repository WordPress è ospitato da WordPress.org, il progetto open source, separato da WordPress.com, separato da qualsiasi altro host nell'ecosistema, separato da società o distributori di plug-in di terze parti. Ed è ciò che è direttamente collegato o legato a ogni installazione di WordPress disponibile. Quando qualcuno è nell'amministratore di WordPress e sta cercando un plugin o un tema, tali ricerche avvengono attraverso il repository di plugin di WordPress.org e il repository di temi, disponibili nell'amministratore di WordPress. E allo stesso modo su WordPress.org. In effetti lì sono disponibili la stessa ricerca, lo stesso contenuto.

Per quanto riguarda l'inserimento di qualcosa nell'elenco, il team di revisione dei plugin di wordpress.org ha una serie di linee guida dettagliate su cosa fare e cosa non fare per gli sviluppatori di plugin. E poi c'è un flusso di lavoro di invio effettivo da seguire per eseguire l'invio iniziale al repository dei plugin di wordpress.org. Una volta approvato, verrà creato un repository SVN per il tuo plugin. E, sai, qualsiasi aggiornamento, rilascio, ecc. viene inviato lì a SVN. Ed è lì che attualmente vive e respira tutto ciò che è disponibile per la ricerca su WordPress.org o all'interno dell'amministratore di WordPress.

DP : Una delle prime regole a mio avviso è che qualunque cosa inserisci nel repository di WordPress deve essere conforme alla GPL, inclusi caratteri e immagini, non solo il codice. È corretto?

JP : Esatto. Giusto. Quindi, letteralmente, la prima regola del team dei plugin è che i plugin nella loro interezza devono essere compatibili con GPL. Questa è la stessa licenza seguita da WordPress e, come hai detto, il codice, le immagini e le librerie di terze parti devono essere tutte compatibili con GPL. Non deve necessariamente essere la licenza effettiva, sai, GPLv2, ce ne sono altre compatibili con GPL, ma sì, caratteri, immagini, librerie di terze parti, dipendenze, tutto ciò che deve essere compatibile con GPL e non solo il codice che scrive uno sviluppatore di plugin, giusto? Anche tutte le altre cose devono essere compatibili con GPL.

DP : E giusto per non far aspettare gli ascoltatori, potremmo semplicemente lanciarci. Il tuo discorso riguardava come verificare la compatibilità GPL utilizzando le azioni GitHub. Puoi guidarci attraverso questo processo?

JP : Sì, quindi questo deriva un po' dal mio ruolo di direttore dell'open source presso 10Up. Forse non è qualcosa di cui un plug-in di tutti i giorni, autore di un singolo plug-in o anche di più plug-in, potrebbe essere a conoscenza o infastidirlo. Ma penso che a un certo punto mi sono svegliato quasi letteralmente nel mezzo della notte pensando: "Non so se so per certo che tu conosci, tutte le immagini, tutte le dipendenze di terze parti, tutti i caratteri , eccetera, sono compatibili con GPL e stiamo cercando di trovare un modo su larga scala per noi di 10up dove abbiamo, come hai detto tu, dozzine di plugin disponibili nel repository wordpress.org o anche su GitHub. La fonte lì.

Non volevo dover affrontare tutto questo con un pettine a denti fini e dover controllare eventuali dipendenze upstream che stavamo utilizzando per i plugin e capire, sai, come vengono concessi in licenza. Potrebbe essere una seccatura per un singolo plugin, per non parlare di più. E attraverso alcune ricerche online, ho identificato che c'erano alcuni strumenti, alcune azioni GitHub che potevano essere utilizzate per aiutare ad automatizzare in modo efficace quel processo in modo che, sai, non solo una singola scansione una tantum di un repository per dire, sì, sei compatibile o no, non lo sei, ma continua la scansione in modo che eventuali future correzioni di bug, miglioramenti, eccetera, che potrebbero aggiungere una nuova dipendenza o forse aumentare una dipendenza nel tuo plugin che forse ha cambiato il modo in cui qualcosa era con licenza, essere in grado di controllare tutto ciò in corso e fare quel tipo di primo passaggio era qualcosa che stavo cercando di capire in modo che non diventasse solo un processo manuale e intensivo e una specie di incubo continuo per garantire che , quella compatibilità.

Quindi sì, voglio dire, penso che la preoccupazione iniziale che avevo era che non lo sapevo: non avevo modo di sapere che alcune funzionalità che aggiungiamo, se includiamo una nuova dipendenza, fossero compatibili con GPL , e poi ci siamo resi conto che avrebbe potuto esserci uno scenario ancora peggiore in cui avevamo plugin che erano stati rilasciati, ripetuti che presentavano già incompatibilità all'interno del loro software.

E quindi quello era il primo problema che volevo provare a risolvere. Quella prima scansione iniziale, giusto? I nostri plugin individuali e tutti quelli supportati da 10up sono veramente compatibili con la licenza che abbiamo dichiarato? E, si spera, incrociamo le dita che lo fossero. E poi, sai, da lì, quel controllo continuo per assicurarsi che i futuri PR, siano essi del mio team e della pratica open source di 10up, in generale con altri 10upers che contribuiscono ai progetti, o semplicemente chiunque nella comunità, assicurando che questi mantenessero la licenza che abbiamo dichiarato nei plugin stessi.

DP : E giusto per chiarire qui, se non l'avessi fatto, se avessi scoperto attraverso questo, che c'era, uh, qualche dipendenza esistente o qualcosa lì dentro che, che non era conforme, è la ramificazione in un certo senso, vergogna dal comunità o esiste un danno punitivo che potresti subire per non aver seguito le regole?

JP : Quindi non sono un avvocato, giusto? Quindi, sai, non ho il cappello da avvocato per dare questo commento, quindi, sai, non è un valido consiglio legale, ma l'approccio che ho adottato mentre stavo eseguendo queste scansioni sui nostri plugin, perché ancora una volta, non l'ho fatto sai, in realtà ero piuttosto nervoso nel gestire tutto questo, quali sarebbero stati i risultati.

Il mio piano era che se avessi scoperto che c'era un plugin che utilizzava qualcosa che non era compatibile con GPL, l'approccio migliore sarebbe stato quello di rimuovere quella dipendenza, sostituirla con qualcos'altro, risolverlo efficacemente, qualunque fosse il problema era e rilasciare rapidamente una nuova versione, giusto?

Non c'era molto che sentivo si potesse fare per ciò che era già stato pubblicato e diffuso. Dal mio punto di vista, nulla di tutto ciò sarebbe stato fatto in modo da cercare intenzionalmente di eludere la licenza. sarebbe stato semplicemente, ad un certo punto, un errore umano, in qualche modo simile a un problema di sicurezza che viene segnalato all'autore del plugin. Ad esempio, l'approccio migliore è quello di lavorare su una riparazione e ottenere rapidamente un rilascio in modo che le persone che rimangono aggiornate sui plugin siano in quello stato più sicuro, che si tratti di un problema di sicurezza o, in questo caso, di un problema di licenza. Certamente, se ci fosse un plugin che generasse entrate in modo significativo, e se forse ci fossero ragioni per dimostrare che era un errore noto avere qualcosa senza licenza, a parte, non credo che qualcuno nel settore lo sta facendo apposta, ma penso che gli unici che sarebbero potenzialmente a rischio legale sarebbero quelli che generano entrate in modo significativo, e questo sarebbe un obiettivo per la licenza.

Quindi sì, penso che per farla breve, se qualcuno esegue una scansione e trova un problema nel codice base esistente, penso che l'approccio migliore sia davvero quello di rilasciare una versione, una versione aggiornata, sai, chiamandola nel registro delle modifiche, indicare nelle note di rilascio cosa è stato cambiato e perché, sii trasparente al riguardo. Ma a quel punto, penso che sia davvero il meglio che un autore di plugin possa fare in quel caso. Fortunatamente per i plugin di 10up, non ci siamo imbattuti in questo scenario. Fortunatamente, tutto era compatibile e spero che la grande maggioranza delle persone che hanno intrapreso questa strada, impostando un po' di automazione per dare loro quel livello di comfort, vivessero un'esperienza simile.

Potrebbe essere un'attesa un po' nervosa e ansiosa per un paio di secondi o un minuto prima che le azioni GitHub vengano eseguite. Ma, sai, una volta dimostrato che tutto passa, penso che la maggior parte delle persone probabilmente finirebbe in quello stato.

DP : A proposito di metterci a nostro agio, faremo una breve pausa. Quindi sedetevi e rilassatevi, e torneremo dopo la breve pausa pubblicitaria con un'altra intervista con Jeff Paul, il direttore delle iniziative open source di 10up, su come mantenere i vostri plugin conformi alla GPL. Restate sintonizzati per saperne di più dopo questa breve pausa.

DP : Bentornati a Press This, un podcast della community di WordPress. Sono Doc. Sto parlando con Jeff Paul dell'utilizzo delle azioni GitHub per assicurarmi che il tuo codice e i tuoi plugin siano conformi alla GPL. Prima della pausa, abbiamo approfondito un po' l'argomento e abbiamo parlato delle conseguenze se non si è pienamente conformi. E immagino di voler tornare su questa cosa specifica. Esistono azioni GitHub che chiunque può creare. Ma Jeff, nel tuo discorso al WordCamp hai menzionato che usi l'azione ufficiale di GitHub, penso, con alcune piccole modifiche. Puoi dirci qual è il nome dell'azione che le persone dovrebbero cercare per poterlo fare?

JP : Certo. Si tratta di un'azione di revisione delle dipendenze. Quindi GitHub.com, azioni di barra, dipendenza da barra, revisione del trattino, azione del trattino. Si spera che la trascrizione lo indichi correttamente. Se c'è qualche problema nel trovarlo, ho delle note a riguardo sul mio sito, in un post che copre il discorso. Quindi, ci sono collegamenti disponibili, ma se cerchi un'azione di revisione delle dipendenze nel mercato delle azioni di GitHub, si spera che troverai quello ufficiale che ho usato e che fa molto di più che controllare semplicemente le dipendenze dei plugin. Verificherà più che semplici licenze. Può anche verificare la presenza di vulnerabilità e altre cose nelle dipendenze del plugin. Ma l'unica cosa per cui lo uso, la cosa principale per cui lo uso, è controllare le licenze non valide nelle dipendenze all'interno dei nostri plugin.

DP : E questa è un'azione in cui puoi impostare il tipo di GPL che vuoi seguire. Puoi includere una licenza e verificarla. E c'è anche la possibilità, se mantieni, diciamo, dozzine di plugin, di poter comunque ottenere la stessa cosa. Puoi avere tutti questi plugin che mantieni ancora in quella directory, quindi non devi andare e aggiornarlo ogni volta, giusto?

JP : Esatto. Sì. Vedo che hai assistito al mio discorso al WordCamp US, complimenti a te per essere tra il pubblico, sveglio e in ascolto, o l'hai catturato su YouTube o WordPress.tv, ma sì, ci sono una specie di due flussi standard che mi aspetterei gente da seguire qui.

Uno, un autore di plugin che è responsabile di uno o un numero molto piccolo di plugin, o qualcuno che ne ha di più su una scala uno a n, ha tanti plugin che supporta. Quindi, per le persone che ne hanno solo una, l'azione GitHub, come l'hai definita, può effettivamente all'interno di quel file del flusso di lavoro in cui stai effettivamente chiamando l'azione di revisione delle dipendenze e facendola scansionare attraverso il tuo repository, ci sono due variabili ambientali o parametri che puoi fornire. La prima azione è consentire le licenze e il corollario è negare le licenze. Non puoi fare entrambe le cose allo stesso tempo. e l'approccio che ho adottato è stato quello di utilizzare le licenze consentite invece delle licenze negate. Il pensiero c'era... preferirei che mi dimenticassi di includere una licenza compatibile con GPL nell'elenco delle licenze consentite e otterrei effettivamente un falso positivo, giusto? Ad esempio, ottenere una dipendenza contrassegnata come non compatibile con le mie licenze perché la sua licenza era semplicemente qualcosa che ho dimenticato di aggiungere all'elenco, invece se utilizzo l'elenco delle licenze negate e ho dimenticato di negare una licenza che non desidero, allora ciò potrebbe significavano che una dipendenza sarebbe passata e non sarebbe stata rilevata da questo controllo.

Quindi, la mia raccomandazione estremamente forte è di seguire l'elenco delle licenze consentite. E nel caso in cui qualcuno mantenga un singolo plug-in, è necessario utilizzare semplicemente quel parametro e quell'elenco di licenze nei file del flusso di lavoro. Quindi, per 10up, per i nostri plugin, questa è la directory GitHub punto e lì la sottodirectory dei flussi di lavoro. E poi abbiamo il flusso di lavoro di revisione delle dipendenze che richiama l'azione di revisione delle dipendenze, ha l'elenco delle licenze consentite, puoi visualizzare la mia presentazione sul mio sito o trovare la conferenza online e vedere l'elenco delle licenze che abbiamo. Puoi anche esplorare uno qualsiasi dei repository di 10up su GitHub e vedere le licenze che esploriamo.

I nostri file di flusso di lavoro sono abbastanza ben documentati e in un certo senso spiegano come siamo arrivati ​​a identificare quelle che ritenevamo fossero licenze compatibili con i nostri plugin. Quindi le persone sarebbero benvenute a utilizzare l'elenco che abbiamo, sarebbero benvenute a utilizzare un sottoinsieme di quell'elenco, sarebbero benvenute a fare le proprie ricerche, forse per sentirsi a proprio agio. Ma abbiamo svolto ricerche piuttosto approfondite per assicurarci che ciò che stavamo utilizzando nel nostro elenco di licenze consentite fosse effettivamente compatibile con ciò che dichiariamo. E praticamente per impostazione predefinita per 10up, utilizziamo GPLv2 o successiva, quindi tutte le licenze che elenchiamo sono compatibili con GPLv2, in particolare.

Questo è, ancora una volta, il caso dell'autore del plugin con un singolo plugin che sta mantenendo. Come hai detto, nel caso in cui qualcuno ne abbia più di una, più, puoi avere un file di politica di licenza separato che contenga effettivamente tutte quelle licenze dichiarate al suo interno. E poi fai riferimento a quel file di configurazione, a quel file dei criteri di licenza, nel flusso di lavoro dei tuoi plugin, in modo che, come hai detto, a quel punto hai davvero solo un posto in cui devi mantenere l'elenco delle licenze compatibili. Se dovesse esserci, sai, una nuova licenza open source approvata dall'iniziativa che risulta essere compatibile con GPLv2 per noi, giusto? Se ne arriva uno nuovo sulla scena, allora potrebbe essere aggiunto all'elenco, o forse se uno deve essere rimosso per qualsiasi motivo, non è necessario farlo in dozzine di luoghi. Lo fai in un'unica posizione, quindi tutti i file del flusso di lavoro che fanno riferimento a quella configurazione vengono aggiornati immediatamente, utilizzando il nuovo elenco di licenze.

DP : È tutto automatizzato, quindi se qualcuno esegue una richiesta pull, lo fa solo per te. Giusto?

JP : Esatto, esatto. Pertanto, quando creiamo i file del flusso di lavoro nei nostri repository, abbiamo un trigger su una richiesta pull. Quindi, potresti anche impostarlo per l'esecuzione secondo una pianificazione CRON, potresti farlo funzionare settimanalmente o mensilmente, ma in realtà, una volta eseguita la prima esecuzione, esegui la scansione dell'intera base di codice delle dipendenze e sta davvero andando in avanti, devi davvero solo controllare quelle richieste pull che stanno arrivando, probabilmente potresti anche controllare i singoli commit se non stai utilizzando un sistema abbastanza rigido per richiedere PR su qualunque siano i tuoi rami predefiniti o stabili per i tuoi plugin.

Quindi, potrebbero esserci ulteriori trigger che le persone potrebbero voler utilizzare. Per 10up, tendiamo a richiedere in modo abbastanza rigoroso ai PR di sviluppare rami e trunk in modo da poter utilizzare questa azione in modo affidabile e sapere che qualsiasi modifica alle dipendenze che ne introduce una nuova o aumenta una versione che cambia la licenza verrà catturata da questo . Quindi sì, usiamo, pernotiamo o attiviamo le richieste pull, ma a seconda di quanto siano rigorose le persone, potresti, forse, controllare i commit individuali su un ramo specifico, o anche eseguire un programma giornaliero, settimanale, mensile, semplicemente avere quel conforto sapendo che il tuo codice è ancora valido, che non ci sono licenze incompatibili con, in questo caso, GPLv2 per 10up.

DP : Faremo un'altra breve pausa qui. Quando torneremo, concluderemo la nostra conversazione con Jeff Paul sulle licenze GPL e magari riprenderemo qualcosa di cui non abbiamo parlato prima. Quindi restate sintonizzati per saperne di più dopo questa breve pausa.

DP : Bentornati a Press This, un podcast della community di WordPress. Stiamo concludendo lo spettacolo e cambieremo un po' il ritmo. Ultimamente si è parlato del processo di revisione del repository dei plugin e, semplicemente affermando che lo è, è un po' più lento rispetto al passato.

Alcune persone dicono di sapere che ci vogliono mesi per far revisionare qualcosa, dove penso di aver visto il picco a forse quattro settimane nella maggior parte dei miei anni in WordPress. Quindi, Jeff, so che hanno parlato di alcuni cambiamenti che potrebbero apportare a questo. Puoi dirci a cosa sta lavorando il team adesso?

JP : Certo. Sì. E io, sai, amplifico quello che hai detto. Penso che storicamente ho visto che tutte le cose che ho inviato sono durate meno di due settimane e sono state molto più veloci di quanto viene solitamente riportato. E mancano circa 88 giorni o qualcosa di sfortunato per tutti i soggetti coinvolti.

Penso che ci sia stato un certo turnover in quella squadra. Alcune conoscenze senior molto esperte sono andate perse. E le persone che sono gentilmente intervenute per aiutare a riempire quel vuoto, penso che stiano ancora arrivando al punto in cui possono avere lo stesso tipo di produttività nell'elaborazione dei plugin e nella revisione di quegli invii iniziali. E stanno lavorando per provare ad automatizzarne una parte. Quindi alcune delle cose in cui, sai, i computer sono migliori degli umani forse non lo sono, forse come eseguire gli standard di codifica di WordPress e affinare dove vengono segnalati errori davvero critici, giusto? Invece di dover esaminare ed elaborare queste cose da parte di un essere umano, avere un controllo dei plugin che funziona e controlla le cose che possono essere automatizzate e aiutare il team di revisione dei plugin a fare una breve pausa iniziale, le cose che vengono automatizzate passano? Se è così, allora, ok, tuffati nella tua revisione umana e accelera le cose. Se sono state segnalate cose, essendo di natura automatizzata che non passano, allora è, penso, una risposta più rapida allo sviluppatore del plugin di, ehi, abbiamo identificato queste cose iniziali nella nostra scansione, sai, per favore, risolvile e quindi inviare un file zip aggiornato, per rimettere le cose in carreggiata.

Quindi so che stanno lavorando per aggiungere un po' di automazione, penso che più possono fare per aiutarli in quel percorso, meglio è, solo perché a questo punto, con oltre mille plugin, il backlog è lungo, e ancora , non aiutare nessuno lì. Quindi sì, stanno lavorando sulle automazioni. So che vogliono fare di più, e penso che se questa è un'area in cui qualcuno è particolarmente dotato per le automazioni e vuole contribuire, penso che il team di revisione dei plugin vorrebbe avere un aiuto su questo fronte. Quindi sicuramente contatta Slack se è così.

DP : E a proposito di contattare, se le persone hanno domande, sul tuo discorso che hai tenuto a WordCampUS, o solo su alcuni dei progetti su cui 10uP sta lavorando nello spazio open source, qual è il modo migliore con cui le persone possono contattarti ?

JP : Certo. Quindi il mio sito web è jeffpaul.com. Ho la mia presentazione lassù, se cerchi semplicemente GPL, probabilmente sarà in ogni caso uno dei primi post. Altrimenti, la mia email è [email protetta] , la mia email di lavoro, ehm, e poi praticamente tutti i social network. WordPress.org, GitHub, Twitter, barra X e io sono @Jeff Paul, e potrete trovarmi tutti sui social network in questo modo.

DP : Allo stesso modo, se gli ascoltatori vogliono trovare esempi del lavoro di 10uP su GitHub, presumo che sia solo 10up su GitHub?

JP : Esatto, sì, github.com/10up. Tutti i repository dei nostri plugin sono pubblici. Il nostro team segue da vicino i nuovi problemi e le PR. Vengono tutti convogliati nel nostro canale Slack, quindi qualsiasi cosa, qualsiasi domanda che la gente ha, qualsiasi discussione, si apre lì. Il nostro team dovrebbe essere abbastanza reattivo a questi, ma in caso contrario, sai, contattandomi su WordPress Slack, su Twitter via e-mail, ognuno di questi funziona. Sono sempre felice di chattare sull'open source con le persone della comunità.

DP : Beh, grazie mille per esserti unito a noi oggi, Jeff, è stato davvero fantastico parlare con te e ho imparato molto sulle azioni che GitHub ha per le richieste pull e sull'automazione di quell'esperienza. È molto utile.

Se ti sei perso l'episodio di Press This della scorsa settimana, abbiamo parlato con Carmen Johnson dei passaggi che puoi eseguire per preparare il tuo sito alla fine del ciclo di vita di MySQL 5.7 e di come prepararti per MySQL 8. Quindi è davvero un bell'episodio possiamo dare un'occhiata e ne abbiamo molti altri. Puoi trovarli su TorqueMag.io se vuoi trovare versioni trascritte. Grazie per aver ascoltato Press This, un podcast della community WordPress su WMR. Puoi seguire le nostre avventure su Twitter, su Torque Mag.

Puoi iscriverti a Press This su RedCircle, iTunes, Spotify o la tua app di podcasting preferita oppure puoi scaricare gli episodi direttamente da WMR.fm. Sono il tuo ospite, dottor Popular. Sostengo la community di WordPress attraverso il mio ruolo presso WP Engine e adoro mettere in luce i membri di quella community ogni settimana su PressThis.