Come personalizzare un plugin mantenendo la possibilità di aggiornare

Attualmente sto lavorando a un importante aggiornamento di uno dei miei plugin di WordPress.

Il plug-in consente all'utente di scegliere tra diverse skin disponibili. Molto spesso mi viene chiesto di creare una skin personalizzata. Per evitare che questa skin venga cancellata durante l'aggiornamento, devo usare un hook di WordPress per disabilitare gli aggiornamenti automatici per il plugin. Questo ovviamente non è l'ideale in quanto vorrei che fossero ancora in grado di aggiornare il plugin. Il problema è il modo in cui WordPress gestisce gli aggiornamenti: elimina semplicemente la cartella del plug-in e installa la nuova versione. Rimuovendo così i file che in realtà non facevano parte della vecchia versione.

Attualmente l'unico modo per aggirarlo è avere due cartelle skin - una nella cartella plugin e una nella cartella uploads - è davvero l'unico modo in cui posso offrirlo ai miei utenti?

Molti plug-in vengono utilizzati /wp-content/custom-plugin-folder/per archiviare i dati dei plug-in personalizzati (viene in mente WPTouch).

Usa solo le costanti WP_CONTENT_URLe i WP_CONTENT_DIR ^documenti per verificare l'esistenza della tua cartella e recuperare tutte le skin disponibili.

Il seguente articolo, sebbene non direttamente correlato a questa domanda, spiega l'importanza per i plugin / temi di cercare le traduzioni prima nella wp-content/languagescartella prima di caricare i propri .mofile compressi . Vale la pena leggerlo e speriamo che applichi il concetto nella tua prossima versione :)

Caricamento dei file di lingua di WordPress nel modo giusto Vorrei sottolineare che è importante caricare file di lingua utente personalizzati da WP_LANG_DIR prima di caricare i file di lingua forniti con il plug-in . Quando vengono caricati più file mo per lo stesso dominio, verrà utilizzata la prima traduzione trovata. In questo modo i file di lingua forniti dal plugin serviranno da fallback per le stringhe non tradotte dall'utente.
^{http://www.geertdedeckere.be/}

L'altro modo è che le persone aggiungano il proprio sub-plugin. Ad esempio, il codice nel plug-in principale che ottiene le skin potrebbe essere qualcosa del tipo:

function get_available_skins() {
    $skins[] = '/includes/default-skin.css';
    $skins[] = '/includes/2012-skin.css';

    return apply_filters( 'get_available_skins', $skins );
}

Quindi, gli utenti possono creare un plug-in personalizzato accanto al tuo (attivato separatamente in modo da non interferire con il tuo aggiornamento) che procede come segue:

add_filter( 'get_available_skins', 'my_custom_skin' );
function my_custom_skin( $skins ) {
    $skins[] = '/my-custom-skin.css';

    return $skins;
}

Questo è esattamente lo stesso modo in cui WordPress utilizza gli hook per rendersi estensibile. Non reinventare la ruota.

_{(Ovviamente, non so con quale plug-in stai lavorando, come appare una skin personalizzata o come hai cose codificate, quindi dovrai usare il codice sopra semplicemente come modello per come puoi refactare il tuo proprio codice.)}