Full width mit dem Twenty fourteen Theme in WordPress

Die volle Breite des Twenty fourteen Theme ausnutzen mit max-width über Custom-CSS Plugins.

War euch am Blog etwas aufgefallen? Genauer am Twenty Fourteen Theme von WordPress? Lang hat es mich gestört, und beim Git Artikel dann war es mir zuviel. Da ist ein großer weißer Bereich für die Blogeinträge vorhanden, und dann wird grad mal die Hälfte davon genutzt! Die Artikel sind dadurch eine unnötig lange Wurst, Lädt nicht unbedingt zum lesen ein. Das liegt am CSS des Themes, und zwar genauer an folgendem Eintrag in der style.css :

.site-content .entry-header,
.site-content .entry-content,
.site-content .entry-summary,
.site-content .entry-meta,
.page-content {
    max-width: 474px;
}

Es sind noch andere CSS Styles an diesem Eintrag dran, ich habe sie der Übersicht halber aber nicht angeführt. Nun wäre das CSS schnell angepasst, aber mit dem nächsten Update könnte unsere Anpassung wieder dahin sein. Daher habe ich eines der vorhandenen Plugins zur Ergänzung des CSS Styles für Themes gewählt. Zur Auswahl standen

  • Custom CSS Manager, welches zum Zeitpunkt des Blogeintrags in der Version 1.5.2 vorhanden war. Und
  • Theme Junkie Custom CSS, gerade frisch in Version 0.1.1 veröffentlicht.

Beide liefen ohne Probleme unter der aktuellen WordPress-Version 3.9.2. Ich habe mich schlussendlich für Theme Junkie Custom CSS ob der Vorschaufunktion bei der Anpassung des Themes entschieden. Ein kurzes Snippet wie das dieses

.site-content .entry-header,
.site-content .entry-content,
.site-content .entry-summary,
.site-content .entry-meta, .page-content {
    max-width: 80%;
}

reicht aus und schon gehört die Platzverschwendung der Vergangenheit an.

Greets

Ähnliche Artikel:

Mehrsprachigkeit WordPress Plugins

Aus aktuellem Anlass (Erstellung meines ersten WordPress Plugins GarageSale) habe ich mich auch mit dem Thema Multilingualität und Übersetzungen auseinandergesetzt (Jetzt weiß ich auch woher I18N kommt – 18 Buchstaben zwischen i und n im Wort internationalization ;-)

Grundsätzlich muss die zu übersetzende WordPress Komponente natürlich die Funktionen __(„text“,“domain“) oder _e(„text“,“domain“) verwenden. Siehe hierzu I18N for WordPress Developers.

WordPress stellt für die Übersetzung einige Werkzeuge auf dem Subversion Host bereit. Aber zunächst einmal ein Schritt nach dem Anderen.

Schritt 1 – Download der Tools für Windows

Da ich auf den Clients Windows einsetze habe ich mich dazu entschlossen auch die Entwicklungswerkzeuge für Windows (in meinem Fall noch das gute alte Windows XP aber es sollte keinen Unterschied machen) einzusetzen  und zu beschreiben.

Wir beginnen also mit dem Download von folgenden Komponenten:

Und danach installieren wird zunächst einmal alle 4 Programme mit dem Windows Installer.

Schritt 2 – gettext und php einrichten

Damit die Gettext Werkzeuge funktionieren sollten Sie noch zum Windows Pfad hinzugefügt werden. Dies kann man entwededer dauerhaft machen unter Systemsteuerung -> System -> Erweitert -> Umgebungsvariablen oder aber direkt vor dem Aufruf des Übersetzungswerkzeugs in der Commandshell.

Ich habe gettext einfach in das Standardverzeichnis c:\Programme\GnuWin32 installiert. Da die Utilities im Unterverzeichnis bin liegen muss also der vollständige bin Pfad hinzugefügt werden:

c:\Programme\GnuWin32\bin

Wie gesagt die Alternative lautet, direkt vor dem Aufruf der Übersetzungstools den Pfad in der Commandline mittels set PATH=%PATH%;c:\Programme\GnuWin32\bin hinzufügen.

Analog zu gettext wird dies mit PHP gemacht. Also falls php in das Standard-Verzeichnis c:\Programme\php installiert wird, dann muss dieses ebenfalls zur Umgebungsvariable Path hinzugefügt werden.

Schritt 3 – Entwicklerwerkzeuge von WordPress aus SVN holen

Um mit der Übersetzung zu beginnen benötigt man jetzt die Entwicklerwerkzeuge von WordPress. Diese holt man sich mittels Subversion (in unserem Fall komfortabel mit dem Tool tortoiseSVN) von der Adresse http://i18n.svn.wordpress.org/tools/trunk

Hierzu erstellt man am Besten ein leeres Verzeichnis (z.B. c:\Work\wp-i18n\) und dort drückt man die rechte Maustaste und wählt SVN Checkout. Im darauffolgendem Tortoise Fenster gibt man unter URL of repository http://i18n.svn.wordpress.org/tools/trunk und drückt auf OK.

Schritt 4 – WP i18n tool starten

Nach dem Checkout befinden sich jetzt die WordPress i18n Übersetzungs Tools im Verzeichnis c:\Work\wp-i18n. Wir öffnen nun ein Commandline Fenster und wechseln in diesen Ordner (wichtig, falls oben in Schritt 2 die Methode mit der dauerhaften Pfad Anpassung gewählt wurde, darf ein jetzt bereits schon offenes Commandline Fenster nicht weiterverwendet werden, da sich die Umgebungsvariablen Änderung nicht auf bereits geöffnete Fenster auswirkt!

Eine Eingabe des Kommandos xgettext sollte nun eine Informationszeile auswerfen ebenso wie eine Eingabe des Befehlst php -v. Falls dies nicht funktioniert, nochmal zurück zu Schritt 2 und prüfen ob die Pfade auch wirklich korrekt gesetzt wurden.

Nun kann die Übersetzung eines Plugins gestartet werden. Zu diesem Zweck muss folgendes Kommando ausgeführt werden: php makepot.php wp-plugin <Pfad des WordPress Plugins>

wp-plugin steht hierfür für den Typ des zu übersetzenden Objekts (in diesem Fall ein WordPress Plugin).

In diesem Beispiel übersetze ich mein eigenes Plugin welches sich im Pfad y:\ktzv-fischamend.at\www\wp-content\plugins\garagesale befindet.

Nach dem Fehlerfreien Durchlauf des makepot.php Scripts (zu erkennen an keiner Ausgabe) befindet sich nun eine pot Datei mit dem Namen des Plugins im aktuellen Verzeichnis (in diesem Beispiel garagesale.pot).

Schritt 5 – Mit POEdit die POT Sprach Datei editieren

Nun starten wir das Programm POEdit und öffnen die pot Datei. Um sie zu öffnen muss der Dateityp Filter auf *.* gestellt werden.

Nach dem Laden der pot Datei kann sofort mit dem Übersetzen begonnen werden. In der linken Spalte sind immer die Original (englischen) Begriffe zu sehen und in der rechten Spalte die bereits übersetzten (deutschen) Begriffe. Man wählt einfach den zu übersetzenden Begriff aus und tippt die Übersetzung in das unterste der Eingabefelder.

Vor dem Speichern sollten jetzt noch die Katalog Optionen angepasst werden. Diese finden sich unter dem Menüpunkt Katalog -> Optionen. Wird auf Deutsch übersetzt sollte nicht nur bei Sprache „German“ sondern auch bei Land „GERMANY“ ausgewählt werden (der Ländercode für Deutsch lautet nämlich üblicherweise de_de und nicht de_at, weil man übersetzt üblicherweise nicht extra ins Österreichische – obwohl das sicher witzig wäre ;-)

Nach dem Speichern findet sich dann zusätzlich zur geänderten Quellsprachdatei garagesale.pot (die jetzt auch die deutschen Übersetzungen enthält) eine Datei namens garagesale.mo. Dies ist die Datei, die für WordPress notwendig ist um das Plugin dann in der korrekten Sprache anzuzeigen.

Wie in dem Screenshot zu sehen, muss diese .mo Datei mit dem richtigen Namen in das Plugin Verzeichnis kopiert werden: <PluginName>-<Länder-und-Sprach-Code>.mo (in diesem Beispiel garagesale-de_DE.mo).

Schritt 6 – Hinzugekommene Begriffe und erneute Übersetzung

Wie das so ist, kommt man nach der fertigen Übersetzung drauf, dass man doch noch eine Funktionalität vergessen hat. Zu diesem Zweck muss man natürlich nochmals das makepot.php Script aus Schritt 4 starten. ABER VORSICHT!

Vor dem erneuten Start muss unbedingt die bereits übersetzte .pot Datei umbenannt werden in z.B. garagesale-translated.pot – Das Extraktionsscript überschreibt kommentarlos eine eventuell bereits bestehende <pluginname>.pot Datei!

Nach erneuter Erstellung der garagesale.pot Datei (in der sich nun auch die zusätzlichen, noch nicht übersetzten Begriffe befinden, können nun mit dem gettext Tool msgmerge die beiden .pot Dateien gemerget werden:

msgmerge -N [bereits-übersetzte-pot-Datei.pot] [neu-generierte-pot-datei.pot] > neue-Pot-Datei.pot

Nun befindet sich im aktuellen Verzeichnis eine Datei namens garagesale_new.pot die wieder mit POEdit um die zusätzliche Begriffe ergänzt werden kann und anschließend muss wieder die .mo Datei entsprechend der oben genannten Namenskonvention in das Plugin Verzeichnis kopiert werden.

 

 

Ähnliche Artikel:

Back again – WordPress Plugin deaktivieren ohne WP

Hat man sein Wordpress durch ein Plugin zerschossen und kann es nicht mehr über WP ausschalten, helfen die hier beschriebenen Kniffe beim Plugin deaktivieren.

Wordpress Logo Wir sind wieder da, und wie könnte es anders sein, nicht ganz problemlos. So macht mir ein Plugin am neuen Server Probleme, indem es eine Endlosschleife generiert. Dummerweise bei jedem Login, ein deaktivieren des Plugins über das Backend ist somit nicht möglich.

Es kann schon mal vorkommen, dass man WordPress im Übereifer mit einem Plugin lahmlegt, da braucht man noch nichtmal einen Serverumzug dafür. Drum kurz eine Auflistung der Möglichkeiten die Plugins zu deaktivieren:

wp-content/plugins umbenennen

Die Plugins werden von WordPress im Verzeichnis wp-content/plugins abgelegt. Benennt man dieses Verzeichnis um werden sie beim nächsten Aufruf von WordPress nicht gefunden. WordPress deaktiviert daraufhin alle Plugins und lädt normal. Wird der Ordner wieder zurück umbenannt, sind die Plugins wieder aktiv.

pluginverzeichnis umbenennen

Möchte man nur ein Plugin umbenennen und hat keinen direkten Zugriff zur Datenbank kann man auch nur das Verzeichnis des jeweilgen Plugins umbenennen. Dadurch wird nur dieses Plugin deaktiviert.

alle per SQL Statement

Hat man zugriff auf die Datenbank können alle Plugins per SQL Aufruf deaktiviert werden. Dazu muss man folgendes Statement absetzen. Der Tabellenname wp_options muss natürlich noch angepasst werden.

update wp_options set option_value=’’ where option_name=’active_plugins’

Dadurch wird der bisherige Wert mit nichts (set options_value=’’ – zwei einzelne Anführungszeichen)  ersetzt und alle Plugins sind deaktiviert.

einzelne per SQL Statement

Will man hier nur ein einzelnes Plugin deaktivieren bedarf es schon gezielterer Eingriffe. Ist das vorige Update noch mit einer Holzhammer Methode zu vergleichen muss man den String der unter active_plugins verborgen ist mit einem Skalpell zerlegen um nur ein einzelnes Plugin abzudrehen.

Als erstes holen wir uns den Wert der zur Zeit unter active_plugins gespeichert ist:

select option_value from wp_options where option_name=’active_plugins’;

Dabei bekommen wir beispielhaft folgenden String zurück:

a:3:{i:0;s:25:“plugin-one/plugin-one.php“;i:1;s:25:“plugin-two/plugin-two.php“;i:2;s:29:“plugin-three/plugin-three.php“;}

Der Aufbau des Strings ist wie folgt:

a:3 zeigt an, dass es sich um einen Array mit 3 Elementen handelt. Jedes Element wird über seinen Index gefunden. In unserem Fall a:3 gibt es also drei Elemente mit den Indexwerten 0 bis 2: i:0, i:1 und i:2

Nach jedem Indexwert steht der eigentliche Inhalt des Array. Dabei wird erst noch ein wenig Meta-Information angeliefert. s steht hierbei für String, die Zahl zeigt die Zeichenanzahl des Strings an.

Möchte man nun zum Beispiel plugin-two deaktivieren sind folgende Schritte notwendig:

Zuerst muss man den Array kürzen, aus a:3 wird a:2

Das zu entfernende Plugin muss rausgenommen werden, folgender Textteil wird ausgeschnitten: i:1;s:25:“plugin-two/plugin-two.php“;

Damit das Array nun wieder konsistent ist, müssen final noch die anderen Indexe angepasst werden: i:2 wird zu i:1

Den neuen Gesamt-String stecken wir dann wieder in die Datenbank:

update wp_options set option_value=
’a:3:{i:0;s:25:"plugin-one/plugin-one.php";i:1;s:29:"plugin-three/plugin-three.php";}’
where option_name=’active_plugins’

Und schon ist das einzelne Plugin deaktiviert.

So ich hoffe das hilft!

So long, have fun!

Quelle: http://www.buildblog.de/2009/04/03/wordpress-plugins-manuell-deaktivieren

Ähnliche Artikel: