Cómo personalizar un complemento manteniendo la capacidad de actualizar

Actualmente estoy trabajando en una actualización importante de uno de mis complementos de WordPress.

El complemento permite al usuario elegir entre varias máscaras disponibles. Muy a menudo me piden que cree una máscara personalizada. Para evitar que esta máscara se elimine en la actualización, tengo que usar un enlace de WordPress para deshabilitar las actualizaciones automáticas del complemento. Obviamente, esto no es ideal, ya que me gustaría que todavía puedan actualizar el complemento. El problema es la forma en que WordPress maneja las actualizaciones: simplemente elimina la carpeta del complemento e instala la nueva versión. Por lo tanto, eliminar archivos que no eran realmente parte de la versión anterior.

Actualmente, la única forma de evitarlo es tener dos carpetas de máscaras, una en la carpeta de complementos y otra en la carpeta de cargas, ¿es realmente esta la única forma en que puedo ofrecer esto a mis usuarios?

Muchos complementos se utilizan /wp-content/custom-plugin-folder/para almacenar datos de complementos personalizados (me viene a la mente WPTouch).

Solo use las constantes WP_CONTENT_URLy los WP_CONTENT_DIR ^Documentos para verificar la existencia de su carpeta y recuperar cualquier aspecto disponible.

El siguiente artículo, aunque no está directamente relacionado con esta Pregunta, explica la importancia de que los complementos / temas busquen las traducciones primero en la wp-content/languagescarpeta antes de cargar sus propios .moarchivos empaquetados . Vale la pena leerlo y esperamos que aplique el concepto en su próximo lanzamiento :)

Carga de archivos de idioma de WordPress de la manera correcta Me gustaría señalar que es importante cargar archivos de idioma de usuario personalizados desde WP_LANG_DIR antes de cargar los archivos de idioma que se envían con el complemento . Cuando se cargan varios archivos mo para el mismo dominio, se utilizará la primera traducción encontrada. De esta forma, los archivos de idioma proporcionados por el complemento servirán de respaldo para las cadenas que el usuario no traduzca.
^{http://www.geertdedeckere.be/}

La otra forma es hacer que la gente agregue su propio sub-complemento. Por ejemplo, el código en su complemento principal que obtiene las máscaras podría ser algo como:

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

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

Luego, los usuarios pueden crear un complemento personalizado que se encuentre junto al suyo (activado por separado para que no interfiera con su actualización) que haga lo siguiente:

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

    return $skins;
}

Esta es exactamente la misma forma en que WordPress usa ganchos para hacerse extensible. No reinventes la rueda.

_{(Obviamente, no sé con qué complemento está trabajando, cómo se ve una máscara personalizada o cómo tiene las cosas codificadas, por lo que tendrá que usar el código anterior simplemente como un modelo de cómo puede refactorizar su código propio)}