Como personalizar um plugin, mantendo a capacidade de atualizar

Atualmente, estou trabalhando em uma grande atualização em um dos meus plugins do WordPress.

O plug-in permite que o usuário escolha entre várias skins disponíveis. Muitas vezes me pedem para criar uma capa personalizada. Para impedir que essa capa seja excluída na atualização, tenho que usar um gancho do WordPress para desativar as atualizações automáticas do plug-in. Obviamente, isso não é ideal, pois eu gostaria que eles ainda pudessem atualizar o plugin. O problema é a maneira como o WordPress lida com as atualizações - ele simplesmente exclui a pasta do plug-in e instala a nova versão. Assim, a remoção de arquivos que não faziam parte da versão antiga.

Atualmente, a única maneira de contornar isso é ter duas pastas de skins - uma na pasta de plug-ins e outra na pasta de uploads - é realmente a única maneira de oferecer isso aos meus usuários?

Muitos plug-ins são usados /wp-content/custom-plugin-folder/para armazenar dados personalizados de plug-ins (o WPTouch vem à mente).

Basta usar as constantes WP_CONTENT_URLe o WP_CONTENT_DIR ^Docs para verificar a existência da sua pasta e recuperar as capas disponíveis.

O artigo a seguir, embora não esteja diretamente relacionado a esta pergunta, explica a importância dos plugins / temas procurarem primeiro traduções na wp-content/languagespasta antes de carregar seus próprios .moarquivos compactados . Vale a pena ler e espero que você aplique o conceito no seu próximo lançamento :)

Carregando arquivos de idioma do WordPress da maneira correta , gostaria de salientar que é importante carregar arquivos de idioma de usuário personalizados do WP_LANG_DIR antes de carregar os arquivos de idioma que acompanham o plug-in . Quando vários arquivos mo são carregados para o mesmo domínio, a primeira tradução encontrada será usada. Dessa forma, os arquivos de idioma fornecidos pelo plug-in servirão como um substituto para cadeias não traduzidas pelo usuário.
^{http://www.geertdedeckere.be/}

A outra maneira é fazer com que as pessoas adicionem seu próprio sub-plugin. Por exemplo, o código no seu plug-in principal que obtém as skins pode ser algo como:

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

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

Em seguida, os usuários podem criar um plug-in personalizado que fica ao lado do seu (ativado separadamente para que não interfira na sua atualização) que faz o seguinte:

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

    return $skins;
}

É exatamente da mesma maneira que o WordPress usa ganchos para se tornar extensível. Não reinvente a roda.

_{(Obviamente, não sei com qual plug-in você está trabalhando, com a aparência de uma capa personalizada ou como você codifica as coisas, portanto, você precisará usar o código acima apenas como modelo para refatorar sua próprio código.)}