Archiv für die Kategorie „WordPress“

atz-welzow.de (Umsetzung)

Samstag, 6. Februar 2010

Das Archäotechnische Zentrum Welzow päsentiert sich seit Anfang diesen Jahres im Internet. Die Umsetzung des Designs als WordPress-Theme erfolgte dabei durch mich.

Ein besonderer Hingucker sind Navigation und Galerieauflistung, die mit JavaScript-Effekten Verfeinerung wurden.



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:



WordPress 2.6 Versionierungssystem

Mittwoch, 16. Juli 2008

Wie bereits angedeutet bringt das neue WordPress 2.6 auch ein eingebautes Versionierungssystem (engl. Revision Management) mit. Zu jedem Artikel und jede Seite bleiben neben der aktuellen gespeicherten Version auch die zurückliegenden Versionen erhalten.

Die Vorteile liegen klar auf der Hand: Datenverlust durch Fehler im Editor oder eigene Schusseligkeit können verhindert werden. Da das Versionierungssystem im Hintergrund arbeitet, bekommt der Anwender unter Umständen gar nichts davon mit. In den Erweiterten Optionen eines Artikels bzw. einer Seite lassen sich die bisher vorhanden Versionen ansehen (“Seitenüberarbeitungen”). Durch einen Klick auf eine der Revisionen lässt sie diese anzeigen. Auch ein Vergleich mit einer anderen Version ist möglich.Vergleich von Revisionen

Nachteile eines solchen Systems sind der erhöhte Speicheraufwand, denn für jede Änderung werden die Daten zu dem Artikel / der Seite komplett gespeichert. Wer den Speicheraufwand minimieren will kann das Versionierungssystem auch abschalten oder die Anzahl der Revisionen einschränken. Auf den WordPress-Entwicklerseiten wird in einem provisorischen Eintrag erklärt wie man das machen kann. Dazu ist es notwendig eine kleine Zeile in die Datei “wp_config.php” einzufügen.

  • define(‘WP_POST_REVISIONS’, FALSE);
    Schaltet das Versionierungssystem aus.
  • define(‘WP_POST_REVISIONS’, 3);
    Lässt nur drei Revisionen zu. Die aktuellsten drei Revisionen bleiben erhalten. Ältere Speicherzustände werden gelöscht.

Eine komfortable Einstellung im Administrationsbereich gibt es leider noch nicht.



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.



Verhängnisvolle Zeichensätze

Freitag, 30. Mai 2008

Schon seit längerer Zeit hatte ich ein Problem mit der Anzeige des TinyMCE im Administrationsbereich des WordPress-Blog meiner Gemeinde. Der WYSIWYG-Editor wurde aus irgendeinem Grund nicht mehr korrekt geladen, so das beim Schreiben neuer Artikel und Seiten nur der HTML-Code sichtbar war. Ich hoffte mit jedem WordPress-Update auf Besserung, allerdings vergeblich.

Schon vor einiger Zeit fand ich heraus das irgendetwas mit der Initialisierung des tinymce nicht stimmte. Mittels des Firefox-Plugins Webdeveloper fand ich heraus das eine JavaScript-Fehler geworfen wurde. “tinymce is not defined” – Ein Hinweis darauf, dass die JavaScript-Variable “tinymce” nicht korrekt initialisiert wurde. Auf verschiedenen Foren erfuhr ich, dass die JavaScript Datei des Editors komprimiert ausgeliefert wird und es dabei bei einigen Servern zu Fehlern kommen kann. Das Problem sollte behoben sein, wenn man in der datei tiny_mce_config.php 'compress' => true auf 'compress' => false setzt. Doch auch nach dieser Änderung stellte sich bei mir keine Besserung ein.

Nun bekam ich allerdings eine andere Fehlermeldung, die mich schließlich zur Lösung des Problems führte.

Einige der JavaScript-Dateien sind dynamisch mit PHP erzeugte Dateien. Bei einer dieser Dateien wurde “Cannot modify header information - headers already sent by (output started at ...” ausgegeben. Dabei handelt es sich um eine PHP-Hinweis das die Manipulation des Headers mittels der header() – Funktion fehlgeschlagen ist, da bereits Zeichen gesandt wurden. Die header() – Funktion wird genutzt um dem Webbrowser klar zu machen, das es sich bei den Dateien die dynamisch erzeugt wurden, um JavaScript-Dateien handelt. Header-Informationen müssen vor allen anderen Daten gesendet werden. Es darf kein einziges Zeichen vorher übertragen werden. Kein Leerzeichen, keine Zeilenumbruch, nichts.

Aber genau das ist passiert und freundlicherweise weist die Fehlermeldung auch gleich darauf hin wo bereits Ausgaben getätigt wurden. Der Fehler fand sich in einem selbst geschriebenen Plugin für WordPress. Bei genauer Untersuchung fand ich jedoch keine Zeichen das vorzeitig gesendet wurde, alles schien ganz normal.

Durch Zufall entdeckte ich in Eclipse den Fehler.

Unter “Byte Order Mark is UTF-8 (BOM)” versteckte sich eine fehlerhafte oder zumindest ungünstige Kodierung der Datei. Die Datei sollte zwar mit UTF-8 kodiert werden, aber Byte Order Mark stellt offensichtlich eine besondere Reihenfolge bei der Kodierung her. Der Fehler entstand durch eine Einstellung in Notepad++, einem Texteditor den ich hin und wieder für kleinere schnelle Änderungen verwende.

Ich kann mich noch erinnern das ich beim Schreiben des Plugins auch auf Notepad++ zurückgegriffen hatte. Dort irritierte mich das unter “Format” die ANSI statt der UTF-8 Kodierung verwendet wurde.

Ich änderte es und dachte mir nichts dabei. Aber eben diese Änderung muss zu den gesendeten Zeichen geführt haben durch die der PHP-Fehler entstand. Nachdem ich wieder auf auf “Kodiere als ANSI” zurückgestellt hatte, funktionierte der TinyMCE anstandslos. Endlich :-) .