Come modificare un plugin WordPress senza interrompere il processo di aggiornamento

Probabilmente no.

Il modo consigliato per includere i tuoi miglioramenti nel plugin è: inviare le tue correzioni allo sviluppatore e chiedergli di unirle all'originale. Se le tue modifiche sono personalizzazioni piuttosto personali, questo non accadrà.

Se il plugin è scritto in uno stile OOP rigoroso, puoi creare un secondo plugin che estende solo le classi dall'originale come ti serve (una sorta di plugin figlio). Sfortunatamente, la maggior parte degli sviluppatori di plugin non vede questa necessità e non scrive il proprio codice di conseguenza. Attenzione al problema dell'ordine di caricamento.

Potremmo aiutarti meglio se descrivessi quale plugin vuoi estendere e cosa esattamente vuoi modificare.

Sfortunatamente dipende totalmente dal plugin (o più precisamente, dall'autore del plugin!) Se l'autore ha pensato in modo proattivo e ha creato il plugin in modo da renderlo estensibile, allora sì, puoi creare il TUO plugin che aggiunge funzionalità al plugin esistente.

Tieni presente quanto sottolineato da Toscho - che l'ordine dei plugin è importante (il link è di nuovo qui).

Hook

Il modo più comune per rendere un plugin estensibile è aggiungere hook (action e filter hook) che puoi poi sfruttare con il tuo plugin. Se hai un buon editor di codice (al momento sto usando NetBeans) dovresti fare una ricerca nei file sorgente del plugin per: do_action e apply_filters. Se l'autore del plugin ha fornito questi hook, questo è un modo molto conveniente e semplice per sovrascrivere i valori predefiniti o iniettare il tuo codice.

Funzioni Pluggabili

Se l'autore del plugin è esperto, ma sta utilizzando lo spazio globale per le funzioni del plugin, potrebbe aver racchiuso le funzioni del plugin all'interno di istruzioni condizionali if ( function_exists() ). Perché questo funzioni a tuo vantaggio, devi assicurarti che il tuo plugin venga caricato per primo (il che potrebbe essere una sfida). Tutto quello che devi fare è dichiarare la tua funzione con lo stesso nome esatto all'interno dello stesso namespace e la tua funzione sostituirà quella utilizzata dal plugin.

Estensione

Se l'autore del plugin è un buon programmatore OOP, potrebbe scrivere il codice del plugin in modo abbastanza granulare da essere aperto all'estensione (poiché, come direbbe il GOF, è sicuramente chiuso alle modifiche). Cerca molta granularità nella classe del plugin - ovvero metodi che eseguono compiti piccoli e altamente specifici - che possono essere sovrascritti nella tua classe che estende la classe del plugin. Naturalmente, come menziona Toscho, la classe deve essere progettata in modo tale da poter essere sovrascritta e che la sua implementazione predefinita non si invochi completamente da sola.

Fork o Patch

Se l'autore del plugin utilizza gitHub, o ha aperto il codice sorgente in qualche altro modo, puoi inviare una patch all'autore con le tue modifiche proposte (la tua migliore opzione è modificare il plugin per renderlo PIÙ flessibile o potente senza rimuovere o modificare le funzionalità esistenti), oppure puoi semplicemente scaricare il codice sorgente, modificare l'intestazione del plugin in modo che non venga più aggiornato quando l'autore originale pubblica un aggiornamento, e preferibilmente inviare la tua versione aggiornata all'autore, o come entità separata direttamente a WordPress. Tieni presente che se invii il plugin a WP avrai bisogno di un sito per esso e dovrai essere preparato a supportarlo se altri lo scaricano.

So che è una domanda molto vecchia ma penso di aver trovato la soluzione...

Ho un plugin in cui uno degli sviluppatori di un mio cliente l'ha modificato al limite delle directory e sottodirectory, quando viene aggiornato i file vengono eliminati e il plugin si blocca. Per rendere il plugin originale indipendente da qualsiasi aggiornamento del core, ho spostato i file e le cartelle modificati in un plugin separato in una directory chiamata extension.

Utilizzando il codice trovato su https://gist.github.com/wpsmith/af206df2cf6a38e4e2f0

Ho aggiunto la classe definita da Tarvis Smith in WPS_Extend_Plugin.php e l'ho inclusa nel mio plugin. Utilizzando la classe WPS_Extend_Plugin ho puntato la directory dei file/cartelle estesi alla cartella di destinazione extension. Non ci sono ancora fallimenti, ma non sono sicuro che questo sia il modo giusto per estendere un plugin o meno!

// Richiede la classe WPS_Extend_Plugin
require_once( 'classes/WPS_Extend_Plugin.php' );

// Estende Sitepress Multilingual CMS
new WPS_Extend_Plugin( 'sitepress-multilingual-cms/sitepress.php', __FILE__, '3.9.0', 'CHERRY' );
// Estende AddThis
new WPS_Extend_Plugin( 'extension', __DIR__, '0.1', 'CHERRY' );

Capisco che questa domanda sia molto vecchia ma ho pensato che potrebbe essere utile a qualcuno.

Se ritieni che le modifiche possano aiutare la community, per favore inviale allo sviluppatore. Tuttavia, se le modifiche sono specifiche per la tua installazione, puoi continuare a leggere quanto segue.

Ho avuto questo problema riguardante il trasferimento delle modifiche a una versione aggiornata di un tema. Abbiamo fatto un diff ricorsivo da old_version a modified_old_version e poi applicato la patch creata sulla nuova versione del tema utilizzando lo strumento patch.

Gli strumenti di patch creano file con modifiche che non possono essere applicate automaticamente. Ne abbiamo avuti alcuni, e siamo riusciti facilmente a identificarli e apportare manualmente quelle modifiche.

Durante l'applicazione delle modifiche, devi assicurarti di non cambiare la spaziatura per l'intero file utilizzando funzionalità dell'editor come auto-indentazione, ecc. Cioè, apporta modifiche solo dove necessario. Altrimenti, renderesti solo più lungo il processo di trasferimento delle modifiche in futuro.