Artikel-Schlagworte: „WordPress“

WordPress Upgrade-Mechanismus mit eigenen URLs

Freitag, 10. Dezember 2010

Seit WordPress die automatischen Aktualisierung anbietet habe ich mich gefragt, ob es irgendwie möglich ist Plugins auch von einem anderen Ort als der offiziellen Plugin-DB nachzuladen. Hintergrund: ich habe einige selbst geschriebene Plugins, die ich auf mehreren Seiten einsetze, die ich aber nicht in die Plugin-DB hochladen möchte, weil sie zu speziell (oder trivial) sind. Für solche Fälle wäre es schön Plugins auch von einem eigenen Webspace nachladen zu können. Prinzipiell lässt sich das mit ein paar Dutzend Zeilen PHP bewerkstelligen. Da ich aber weiß das in WordPress die Funktionalität schon vorhanden (und gut getestet) ist, machte ich mich auf die Suche.

In der Datei “wp-admin/includes/class-wp-upgrader.php” wurde ich fündig. Hier gibt es die Basisklasse “WP_Upgrader” und die von abgeleiteten Klassen für Core, Themes und Plugins. Relevant für die Plugin-Updates ist dabei die Funktion “Plugin_Upgrader->upgrade()” Die Steuerung des Update-Prozesses übernimmt der Code aus der Datei “wp-admin/update.php“.

Democode

Aus den Informationen dieser Dateien habe ich mir folgenden Code zusammengestellt, den ich der Einfachheit halber in die functions.php meines Themes eingebunden habe. Der Code erstellt einen Menüpunkt “Einstellungen > PersonalUpdate” der, sobald gedrückt, das Plugin Aksimet neu herunterläd, installiert und ggf. wieder aktiviert. In dem Beispielcode habe ich die offizielle URL des Plugins genutzt, es lässt sich aber jede beliebige andere URL einfügen.

[php highlight="13,18,39"]
class PersonalUpdate {

function __construct() {
add_action(‘admin_menu’, array(&$this,’admin_menu’));
}

function admin_menu() {
add_options_page(‘PersonalUpdate’, ‘PersonalUpdate’, ‘update_plugins’, ‘personal-update-handle’, array(&$this,’admin_submenu’));
}

function admin_submenu() {
$_array = array(
‘package’ => ‘http://downloads.wordpress.org/plugin/akismet.2.5.0.zip’,
‘destination’ => WP_PLUGIN_DIR,
‘clear_destination’ => TRUE,
‘clear_working’ => TRUE,
‘hook_extra’ => array(
‘plugin’ => ‘akismet/akismet.php’
)
);

$result = $this->run_update($_array);
//…
}

function run_update($_array) {
if(!current_user_can(‘update_plugins’)) {
wp_die( __(‘You do not have sufficient permissions to access this page.’) );
}

include_once ABSPATH . ‘wp-admin/includes/class-wp-upgrader.php’;
$upgrader = new Plugin_Upgrader( null );

$is_active = is_plugin_active($_array['hook_extra']['plugin']);

add_filter(‘upgrader_pre_install’, array(&$upgrader, ‘deactivate_plugin_before_upgrade’), 10, 2);
add_filter(‘upgrader_clear_destination’, array(&$upgrader, ‘delete_old_plugin’), 10, 4);

$upgrader->run($_array);

// Cleanup our hooks, incase something else does a upgrade on this connection.
remove_filter(‘upgrader_pre_install’, array(&$upgrader, ‘deactivate_plugin_before_upgrade’));
remove_filter(‘upgrader_clear_destination’, array(&$upgrader, ‘delete_old_plugin’));

if ( ! $upgrader->result || is_wp_error($upgrader->result) ) {
return $upgrader->result;
} else {
if($is_active) {
activate_plugin($_array['hook_extra']['plugin']);//reactivate
}
}
return $upgrader->result;
}
}
$MyPersonalUpdate = new PersonalUpdate();
[/php]

Die eigentliche Hauptarbeit wird durch den Code in Zeile 39 bewerkstelligt. Hier wird ein das Array mit Plugin-Informationen an das Upgrade-Objekt übergeben, welches sich dann um den Rest kümmert. Das Array wird in diesem Fall ab Ziel 12 zusammengebaut. Die wichtigsten Werte sind hierbei “package” (Zeile 13) mit der URL von der die ZIP-Datei geladen werden soll, und “hook_extra > plugin” in dem der Pfad zur Hauptdatei des Plugins steht.

Ausgabe des Demo-Codes

Wie weiter?

Um aus der Demo-Funktionalität einen praktischen nutzen zu ziehen, könnte man nun eine Erweiterung schreiben, die die gewünschten URLs und Plugin-Pfade zu mehreren Plugins speichert. Per Knopfdruck könnten diese dann jederzeit von einem eigenen Server aktualisiert werden.

Getestet in WordPress 3.0.3



Mit WordPress einen Custom-Post-Type Podcast erstellen

Montag, 22. November 2010

Seit Version 3 unterstützt WordPress “Custom-Post-Types“, d.h. neben Artikeln, Seiten, Links und Anhängen können eigene Inhaltstypen definiert werden. Das hat mindestens zwei Vorteile. Dadurch das diese Inhaltstypen getrennt von Artikeln und Seiten sind muss man in seinen Themes nicht umständliche Konstruktionen entwerfen um z.B. Podcast-Einträge wieder von den Artikeln zu trennen – man hat einfache einen Inhaltstyp Podcast. Außerdem lassen sich für zusätzliche Inhaltstypen eigenständige Eingabemasken erstellen, so dass der Administrator bei der Eingabe dieser Einträge besser angeleitet wird.

Für die Internetseite einer christlichen Gemeinde habe ich die custom-post-type-Funktionalität genutzt um einen Podcast mit den letzten Predigten zu erstellen. Im Großen und Ganzen ist das Erstellen solcher spezifischen Inhaltstypen recht einfach, in der Dokumentation ist die Funktionalität mit Beispielen erklärt. Es gibt jedoch ein paar Ecken an denen es dennoch klemmt, eine möchte ich hier vorstellen.

Basics zu custom-post-types

Um einen Custom-Post-Type, also einen eigenen Inhaltstype, zu erstellen muss die Funktion “register_post_type” verwendet werden. Hiermit habe ich den neuen Podcast-Inhaltstyp von “post” abgeleitet. Außerdem habe ich festgelegt das nur Titel und Editor angezeigt werden sollen. Gute Tutorials zum grundlegenden Erstellen von Custom-Post-Types findet man im Codex, sowie hier und hier.

Um einen Audioplayer auf der Ausgabeseite einzubinden habe ich das Plugin “Audio player” von Martin Laine genutzt. Durch das Plugin lässt sich folgender Shortcode im Editorfeld einbinden. An der Stelle an der dieser Codeschnipsel eingefügt wird, wird im veröffentlichten Eintrag dann ein Audio-Player erscheinen und das Abspielen direkt von der Website ermöglichen.

[ audio:<url>|<title>]

Hinweis: Vorsicht, das Audio-Player-Plugin unterstützt keine Umlaute.

Die Anzeige und Auflistung der Podcast-Einträge lässt sich relativ einfach bewerkstelligen (Tutorial hier). Womit es allerdings Probleme gab war der Podcast-Feed.

Problem mit der RSS-/Podcast-Funktionalität

Wesentlicher Bestandteil eines Podcasts ist die Möglichkeit ihn zu abonnieren und sich auf einem beliebigen Feed-Reader (z.B. IPhone, Google Reader, IPod, …) anhören zu können. Jedesmal wenn ein neuer Podcast-Eintrag veröffentlicht wird bekommen die Abonnenten diesen dann via RSS-Feed sofort zugestellt.

Damit die Einträge in einem RSS-Feed erscheinen habe ich einen Action-Hook in der Anfrage-Funktion genutzt.

[php]
//simple podcast functionality
//podcast avalable under /feed?sermons_podcast=1
function myfeed_request($arg) {
if (isset($arg['feed']) && !empty($_REQUEST['sermons_podcast'])) {
$arg['post_type'] = array(‘sermons’);
}
return $arg;
}
add_filter(‘request’, ‘myfeed_request’);
[/php]

Die Funktion wird bei jeder Anfrage nach Einträgen ausgeführt und ermöglicht es die Anfrageparameter ($arg) zu verändern. Ich überprüfe in der Funktion ob gerade ein Feed angefragt wird. Wurde an die Feed-Url die Variable “sermons_podcast” angehängt, lasse ich nur noch Einträge vom Typ “sermons” ausgeben.

Soweit so gut, die Einträge sind nun unter “<url>/feed?sermons_podcast=1” verfügbar, damit ein richtiger Podcast daraus wird, müssen die Audiodateien aber in einem bestimmten XML-Element (<enclosure url=”" lenght=”" type=”audio/mpeg” />) des RSS-Feeds angegeben sein.

In normalen Artikeln nimmt WordPress diesen Eintrag selbstständig vor, bei Custom-Post-Types jedoch nicht. Ich musste lange suchen bis ich heraus bekam wie WordPress den Eintrag im RSS-Feed erstellt.

Beim Veröffentlichen eines Artikels überprüft WordPress standardmäßig ob im Eintrag auf eine Multimedia-Datei verlinkt wird. Wenn dem so ist wird ein Eintrag in den benutzerdefinierten Feldern (custom-post-data) des Eintrags hinterlassen, der die URL, die Länge und den Mime-Type der Datei in je einer Zeile enthält.

Bei der Ausgabe des Feeds überprüft WordPress dann ob eine Eintrag “enclosure” in den benutzerdefinierten Feldern hinterlassen wurde und fügt bei Bedarf das XML-Element (siehe oben) ein. Alle gängigen Feed-Reader verstehen das enclosure-Element als abgehangene Datei und binden es mit einem ensprechendem Player ein.

Um die enclosure-Funktionalität auch in den Custom-Post-Types verfügbar zu machen nutzte ich die Standardfunktion und fügte sie beim Speichern von Custom-Post-Types ein.

[php]
/**
* enclosure-fix
* For some reason wordpress dont filter the enclosures out of custom post types and saved them into the meta.
* So we do that in the following lines.
*/
add_action(‘edit_post’, ‘sermons_enclosurefix’);
add_action(‘save_post’, ‘sermons_enclosurefix’);
function sermons_enclosurefix($post_ID) {
global $post;
if($post->post_type==’sermons’) {
do_enclose($post->post_content, $post->ID);
}
}
[/php]

Das dieser umständliche Weg überhaupt nötig ist verwundert mich etwas, denn der Podcasts ist eines der Standardbeispiel für Custom-Post-Types. Vielleicht wird die Funktionalität der Enclosures in Custom-Post-Types im kommenden WordPress 3.1 nachgerüstet.



Galleryhack 1.2.1

Montag, 16. Juni 2008

Nach nicht einmal 2 Tagen nun schon wieder ein Update auf Galleryhack. Ich habe Slimbox 1.63 integriert, da in der bisherigen Version (Slimbox 1.51) ein Anzeigefehler im neuen Opera aufgetreten ist.

Infos und Download der aktuellen Version

UPDATE 2010: ich habe die öffentliche Galleryhack Entwicklung eingestellt.



galleryhack 1.2.0

Samstag, 14. Juni 2008

Mein kleines Plugin zum Modifizieren der Anzeige von WordPress-Galerien liegt in einer neuen Version vor. Galleryhack tauscht die vorgegebene Galerieanzeige durch die Anzeige mit Slimbox (einem Lightbox Clon) aus.

Änderungen:

  • Wichtigste Änderung für Umsteiger von Version 1.0 ist, dass nun die großen Bilder für die Anzeige genutzt werden.
    Wordpress speichert beim Upload von Bildern drei Auflösungen jedes Bildes: das Thumbnail, ein Bild in mittlerer Auflösung und die volle Auflösung. Ich habe den galleryhack von der Anzeige der mittler Auflösung auf die der vollen Auflösung umgestellt. Die Auflösung lässt sich aber mit dem Parameter “targetimage” manuell umstellen, siehe unten.
  • Slimbox ist in Version 1.51 vollständig in galleryhack integriert worden. Das separates Installieren von Lightbox oder Slimbox entfällt dadurch.
  • Das Aussehen der Galerie lässt sich nun sehr leicht anpassen. Man erzeuge sich hierzu eine Kopie der Datei style.css aus dem galleryhack-Verzeichnis und speichere sie unter my_style.css. Dann können alle CSS-Einstellungen beliebig geändert werden ohne das es bei einem Update zu Komplikationen kommen kann.

Infos und Download der aktuellen Version

UPDATE 2010: ich habe die öffentliche Galleryhack Entwicklung eingestellt.