WordPress – Einstellung der Fontsize des Text-Editors

WordPress 3.x (x >= 2) nutzt den MS Consolas Font im Text-Editor. Hier meine ich den Minimal-Editor, in dem man selbst HTML/CSS-Befehle eingeben kann und nicht den Visual Editor..

Der Consolas TTF-Font sieht unter Linux nach meinem Dafürhalten nicht besonders gut aus. Hinzu kommt, dass die von WordPress eingestellte Standard-Font-Größe des Minimal-Editors auf meinen hochauflösenden Laptopschirmen einfach zu klein ist. “Ctrl +” im Browser hilft auch nicht wirklich, da dann alle Bereiche der Seite vergrößert werden und das Editor-Fenster zu klein wird.

Nun weiß man, dass das eine Einstellungssache ist. Aber welches CSS-File muss man editieren ? Für die Style-Vorgaben der generierten Webseiten und auch für die Styles des Visual-Editors gibt es unter dem Menüpunkt Design den Editor, mit dem man die zugehörigen CSS-Dateien online bearbeiten kann. Für die CSS-Files, die das Layout der Admin- oder Redakteurs-Oberfläche steuern, habe ich dagegen keine einfache Bearbeitungsmöglichkeit gefunden.

Zu meiner Überraschung erwies sich eine Suche im Internet bzgl. entsprechender Hinweise als wahre Odyssee. Es gibt zwar Hinweise, aber die meisten sind veraltet. Daher an dieser Stelle ein paar Hinweise:

Die CSS-Steuerung der verschiedenen Seiten und Elemente der Admin-Oberfläche erstreckt sich inzwischen über eine Vielzahl von Dateien, die in folgendem Verzeichnis liegen:

wp-admin/css

Nun möchte man meinen, dass man da was Passendes finden würde. Falsch gedacht !

Ich habe dann in einem Verzweiflungsanfall die CSS-Analyse-Tools von FF benutzt, um den CSS-Klassennamen für das Textarea-Feld im Editor-Bereich zu finden, und mich danach auf die Suche nach Eintragen in CSS-Dateien in mehreren Verzeichnissen gemacht. Fündig wurde ich schließlich in folgendem File :

wp-includes/css/editor.min.css

Vor weiteren Aktionen legt man nun eine Sicherungskopie dieser Datei an. Nun ist dieses File nicht ganz leicht zu editieren, da alle CSS-Anweisungen in eine einzige lange, komprimierte Zeile geschrieben wurden. Manche Editoren mögen die entstehenden Zeilenlängen nicht. Aber man setze z.B. in Kate die erlaubte Zeilenlänge auf 300000 Characters und schon ist man wieder im Spiel. Nun gilt es die Anweisungen für

.wp-editor-container    textarea.wp-editor-area

zu finden. Dort fügt man dann die gewünschte “font-size” und “font-family” hinzu. Und schon sieht der WordPress Text-Editor wieder so gut aus wie in alten Zeiten.

wp_1_600

Andere Alternativen zur Abänderung der CSS-Vorgaben bestehen darin, eine Inline-Style-Vorgabe in die Datei

wp-admin/post.php

beim Textarea-Feld einzufügen. Oder man arbeite mit dem netten Plugin “Add Admin CSS” und gebe dort die Vorgaben für “.wp-editor-container    textarea.wp-editor-area” im gewöhnlichen CSS-Format ein. Letztere Methode hat auch den Vorteil, dass sie evtl. WordPress-Updates überlebt.

Denn eine Abkehr von der aktuellen CSS-Politik und einen Veränderung der Position und Namen der Files, die das Layout steuern, kommt mit Sicherheit eher früher als später. Bis dahin jedenfalls weiter viel Spass beim Bloggen!

Kurzreview Eclipse 4.3 Kepler mit PDT und Aptana

Vor einiger Weile hatte ich mich wegen der miserablen Performance enttäuscht von Eclipse 4.2 Juno mit PDT abgewandt. Besonders bei Benutzung der neuen GTK-Oberfläche tauchten immer wieder lange andauernde 100%-Peaks in der CPU-Belastung von 1 bis 2 CPU-Cores auf. Auf meinem schwachbrüstigen Laptop eine Katastrophe – aber auch auf einem gut ausgestatten Desktop-Rechner eine echte Belastung.

Im besonderen galt dies beim Hin- und Herziehen von Tabs zwischen zwei getrennten parallelen, vertikalen Editor-Bereichen der GUI von Juno. Das Öffnen des Outline-Bereiches machte das System nochmal träger. Die parallel Sicht auf mehrere geöffnete Files sowie den Outline-Bereich benötige ich beim Arbeiten mit vielen Klassenbibliotheken aber immer wieder.

Es half keine Herumdoktern an den Speichereinstellungen für die JVM. Genausowenig half eine Umstellung auf die klassische Eclipse GUI. Daneben gab es auch immer wieder seltsame Probleme mit einer parallelen Installation von Aptana und PDT 3.1/3.2. Die Content Assist Vorschläge wurden entweder gar nicht oder nicht immer vollständig angezeigt. Die Schwierigkeiten waren sowohl bei Einsatz von Suns JVM für Java 7 als auch von OpenJDK 1.7 gegeben. Alles unter Opensuse 12.2 und 12.3 (64 Bit).

Für meine PHP-Entwicklungsarbeiten griff ich aus diesen Gründen bis gestern immer noch auf Eclipse 3.7 “Indigo” zurück.

Nun ist Eclipse in der Version 4.3 unter dem Namen “Kepler” erschienen. Daher habe ich gestern erneut einen Anlauf mit dieser aktuellen Eclipse-Version und dem zugehörigen PDT 3.2 plus Aptana Studio 3 unternommen. Und diesmal wurde ich nicht entäuscht:

Alles funktioniert wie es soll und das wirklich performant. Allerdings musste ich meine unter Indigo aufgebauten Workspaces unter Rückgriff auf vorhandene SVN-Repositories komplett neu aufbauen. Erst danach lief alle fehlerfrei.

eclipse_kepler_1_600

An den Standard Speichereinstellungen habe ich nichts verändert. Die “eclipse.ini” sieht daher wie folgt aus:

-startup
plugins/org.eclipse.equinox.launcher_1.3.0.v20130327-1440.jar
–launcher.library
plugins/org.eclipse.equinox.launcher.gtk.linux.x86_64_1.1.200.v20130521-0416
-product
org.eclipse.epp.package.standard.product
–launcher.defaultAction
openFile
-showsplash
org.eclipse.platform
–launcher.XXMaxPermSize
256m
–launcher.defaultAction
openFile
–launcher.appendVmargs
-vmargs
-Dosgi.requiredJavaVersion=1.6
-XX:MaxPermSize=256m
-Xms40m
-Xmx512m

Es gab und gibt nach bislang 12 Stunden Arbeit keinerlei Hänger und keine Peaks in der CPU zu bemängeln! Das Arbeiten mit mehreren parallel angezeigten Editor- und GUI-Bereichen läuft sehr flüssig. Das Verschieben von Tabs für geöffnete Dateien zwischen zwei Darstellungsbereichen führt zwar zu einer kurzfristigen Belastung mehrerer CPU-Kerne – aber eben wirklich nur sehr kurzzeitig und das ist nicht als Bremse für das Arbeiten wahrnehmbar. Auch die Build-Operation für Projekte laufen mit angemessener Geschwindigkeit.

Aptana lässt sich parallel zu PDT einsetzen. Man kann zwischen den verschiedenen “Natures” entsprechend “facettierter” Projekte nach Lust und Laune hin- und herschalten. Die Content-Assists-Hinweise kommen entsprechend. Ich nutze z.T. den Aptana-Editor, um HTML-Code in TPL-Files für die Template-Engines Pear-ITX oder Smarty zu bearbeiten. Ich schätze dabei die browser-bezogenen Content Assist Hinweise. Aber auch der Wechsel zum normalen WST-HTML-Editor mit dessen Content-Assists-Fähigkeiten für HTML- und CSS-Vorschlägen klappt einwandfrei.

Aptanas PHP-Unterstützung benutze ich in der Regel nicht und
habe ich daher nicht wirklich getestet. Ein kurzes Umschalten auf die Aptana Editoren und Aptanas Content Assist für PHP zeigte mir aber keine unerwarteten Probleme.

Die SVN-Anbindung über Subversive und die Polarion-Konnektoren lief wie erwartet. Ein Gleiches gilt für MyLyn

Kurzum:
Für PHP-Projekte stellt Eclipse 4.3 “Kepler” endlich eine ernsthafte, weil funktionierende und performante “Eclipse 4.x”-Alternative zu Indigo dar. Ich kann den Umstieg wirklich empfehlen.

Ein kleiner Wermutstropfen
Schade irgendwie, dass es der HTML-“Web Page Editor” bisher nicht in die “WTP 3.5” -Repositories von Kepler geschafft zu haben scheint. Aber eine Installation aus den WTP 3.3.2 Ressourcen scheint keine größere Probleme zu machen.