Artikel-Schlagworte: „Programmierung“

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.



Automatisierter DNG-Workflow mittels Batchverarbeitung unter Windows

Montag, 19. April 2010

Ob Hobby- oder Berufsfotograf, früher oder später müssen alle Bilder von der Kamera auf den Computer. Jeder hat da so seinen eigenen Workflow. Und umso mehr Bilder man produziert um so länger dauert dieser Workflow. Ganz besonders dann, wenn man mit RAW-Dateien arbeitet und für den Import aufgrund von “Sonderwünschen” mehrere Programme nacheinander benutzt. Eine Lösung ist hier die Batchverarbeitung von Komandozeilenbefehlen, um den Workflow zu automatisieren. Batch-Dateien enthalten Kommandozeilenbefehle und führen sie nacheinander aus. Ich möchte an dieser Stelle ein Batch-Script vorstellen, welches ich mir vor einiger Zeit geschrieben habe, um meinen Workflow zu vereinfachen. (weiterlesen …)



Kleine Anpassungen im WordPress Editor

Donnerstag, 21. Januar 2010

Bei meinen bisherigen Anpassungen von WordPress habe ich meist einen weiten Bogen um den grafischen Editor, den TinyMCE, gemacht. Für die meisten Belange ist dieser WYSIWYG-Editor völlig ausreichend. Und an manchen Stellen bietet er mir (bzw. vor allem meinen Kunden) bereits zu viele Möglichkeiten. Anpassungen an dieser Komponente sind schwierig, aufgrund der Komplexität der Einbindung. Außerdem ist bei mir immer im Hinterkopf, dass sich die Hooks, über die man Anpassungen vornehmen kann, jederzeit ändern können.

Daran hat sich auch nichts geändert. Allerdings setze ich in letzter Zeit deutlich mehr Systeme mit WordPress um. D.h. auch, dass ich mehr Schulungen durchführen muss. Und die Probleme und Verständnisschwierigkeiten die der TinyMCE manchmal hervorruft kosten dann natürlich auch Zeit.

Zwei Änderungen wurden daher notwendig:

  1. Das Ausblenden von “Adresse”, “Monospace”, “Überschrift 1″ und “Überschrift 2″ aus dem Format Auswahlfeld (formatselect).
    Ziel ist es dem Benutzer die Möglichkeit der Formatierung zu erlauben, allerdings nur so, dass es ins Gesamtdesign und den Seitenaufbau passt.
  2. Einige Formatierung der Vorschau des WYSIWYG-Editors.
    Der Benutzer soll eine genauere Rückmeldung bekommen mit welcher Formatierung er gearbeitet hat und wie der Text auf der Seite aussieht.

Hier eine Vorschau auf das Ergebnis:

Bitte anklicken zum Vergrößern

Die Änderungen werden ausschließlich mit CSS abgewickelt. Zum Einbinden des CSS-Codes ist aber natürlich PHP notwendig. Da ich nicht jede kleine Anpassung in ein Plugin packen will, und kein Fan von Sammel-Plugins bin, kommt der PHP-Code in die functions.php des aktuellen WordPress-Themes. Die beiden benötigten CSS-Dateien kommen ebenfalls ins aktuelle Theme-Verzeichnis. Wer es anders machen will kann es gern tun.

So wird’s gemacht:

Folgender Code bindet die CSS-Datei für die Button-Leiste (oder besser für den gesamten Admin-Bereich) ein:

function tm_CustomAdminCSS() {
    echo '<link rel="stylesheet" href="'
         . get_bloginfo('template_directory')
         . '/my_admin.css" type="text/css" media="all" />
';
}
add_action('admin_head', 'tm_CustomAdminCSS');

Über den Hook “admin_head” wird die Datei “my_admin.css” eingebunden in der nun alle CSS-Anpassungen gesammelt werden die für den Administrationsbereich gelten sollen. Da ich lediglich ein paar Einträge aus dem MCE entfernen und die anderen Einträge formatieren will, sieht meine Datei so aus:

.mce_pre,
.mce_address,
.mce_h1,
.mce_h2 {
    display: none;
}
#menu_content_content_formatselect_menu_tbl .mceMenuItemTitle {
    display: none;
}
#menu_content_content_formatselect_menu_tbl .mceText {
    font-size: 1.3em;
    font-weight: normal;
}
#menu_content_content_formatselect_menu_tbl .mce_h4 .mceText,
#menu_content_content_formatselect_menu_tbl .mce_h5 .mceText,
#menu_content_content_formatselect_menu_tbl .mce_h6 .mceText {
    color: #97bf0d;
    font-weight: bold;
}

Der TinyMCE arbeitet intern mit einem iframe, in dem er Benutzer ein grafisches Editorfeld vorgauckelt. Um für dieses iframe CSS-Daten zu übergeben ist folgender PHP-Code nötig:

function tm_custom_tinymce_css($wp) {
    $wp .= ',' . get_bloginfo('template_directory')
               . '/advanced_tinymce.css';
    return trim($wp, ' ,');
}
add_filter( 'mce_css', 'tm_custom_tinymce_css');

Das WYSIWYG-Fenster erhält seine CSS-Daten gepackt. Mit dem Filter “mce_css” kann an das PHP-Script, welches die CSS-Dateien packt, eine weitere Datei angehangen werden.

Die CSS-Datei “advanced_tinymce.css” enthält folgenden Code:

* {
    font-family: Arial,sans-serif;
}
h3 {
    font-size: 1.4em;
    font-weight: normal;
    margin-bottom: 0em;
}
h4,h5,h6 {
    color: #97bf0d;
    font-size: 1.3em;
    margin-bottom: 0em;
}

Die Standartschrift wird auf Arial gesetzt und die Formatierung der Überschriften wird angepasst. Da die CSS-Datei lediglich angehangen wird, bleiben alle sonstigen Formatierungen erhalten. Damit die Änderungen aktiv werden muss der Browsercache geleert werden.

Fazit

Mit wenigen Zeilen PHP- und CSS-Code lässt sich bereits einiges Erreichen. Da die Anpassungen nicht im Kern des Systems vorgenommen werden, sondern per Hooks und Filtern, überleben sie auch das nächste Update. Erst wenn sich die Hooks oder die angesteuerten CSS-Klassen ändern, kommt es zu Problemen. Aber das kommt zum Glück nicht alle Tage vor.

Quellen & Links: