So passen Sie ein Plugin an und behalten gleichzeitig die Möglichkeit zum Upgrade bei

Ich arbeite derzeit an einem wichtigen Update für eines meiner WordPress-Plugins.

Mit dem Plugin kann der Benutzer aus mehreren verfügbaren Skins auswählen. Sehr oft werde ich gebeten, einen benutzerdefinierten Skin zu erstellen. Um zu verhindern, dass dieser Skin beim Upgrade gelöscht wird, muss ich einen WordPress-Hook verwenden, um automatische Updates für das Plugin zu deaktivieren. Dies ist offensichtlich nicht ideal, da ich möchte, dass sie das Plugin weiterhin aktualisieren können. Das Problem ist die Art und Weise, wie WordPress mit Updates umgeht - es löscht einfach den Plugin-Ordner und installiert die neue Version. So entfernen Sie Dateien, die eigentlich nicht Teil der alten Version waren.

Derzeit kann ich mich nur darum kümmern, zwei Skins-Ordner zu haben - einen im Plugin-Ordner und einen im Upload-Ordner. Ist dies wirklich die einzige Möglichkeit, dies meinen Benutzern anzubieten?

Viele Plugins verwenden /wp-content/custom-plugin-folder/zum Speichern angepasster Plugin-Daten (WPTouch fällt mir ein).

Verwenden Sie einfach die Konstanten WP_CONTENT_URLund WP_CONTENT_DIR ^Dokumente , um die Existenz Ihres Ordners zu überprüfen und alle verfügbaren Skins abzurufen.

Der folgende Artikel erklärt, obwohl er nicht direkt mit dieser Frage zusammenhängt, wie wichtig es ist, dass Plugins / Themes zuerst im wp-content/languagesOrdner nach Übersetzungen suchen, bevor sie ihre eigenen verpackten .moDateien laden . Es ist eine Lektüre wert und hoffentlich werden Sie das Konzept in Ihrer nächsten Version anwenden :)

Laden von WordPress-Sprachdateien auf die richtige Weise Ich möchte darauf hinweisen, dass es wichtig ist, benutzerdefinierte Benutzersprachendateien aus WP_LANG_DIR zu laden, bevor Sie die mit dem Plugin gelieferten Sprachdateien laden . Wenn mehrere Mo-Dateien für dieselbe Domain geladen werden, wird die erste gefundene Übersetzung verwendet. Auf diese Weise dienen die vom Plugin bereitgestellten Sprachdateien als Ersatz für Zeichenfolgen, die nicht vom Benutzer übersetzt wurden.
^{http://www.geertdedeckere.be/}

Die andere Möglichkeit besteht darin, dass Benutzer ihr eigenes Sub-Plugin hinzufügen. Zum Beispiel könnte der Code in Ihrem Kern-Plugin, der die Skins erhält, ungefähr so ​​aussehen:

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

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

Anschließend können Benutzer ein benutzerdefiniertes Plugin erstellen, das sich neben Ihrem befindet (separat aktiviert, damit Ihr Update nicht beeinträchtigt wird) und Folgendes ausführt:

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

    return $skins;
}

Dies ist genau die gleiche Art und Weise, wie WordPress Hooks verwendet, um sich erweiterbar zu machen. Das Rad nicht neu erfinden.

_{(Natürlich weiß ich nicht, mit welchem ​​Plugin Sie arbeiten, wie ein benutzerdefinierter Skin aussieht oder wie Sie die Dinge codiert haben. Daher müssen Sie den obigen Code lediglich als Modell für die Umgestaltung Ihres verwenden eigener Code.)}