Die Werkzeugleiste des Editors in WordPress ist ja nicht unbedingt nach jedermanns Geschmack. Einige Schaltflächen mag man als überflüssig empfinden; andere oft benötigte HTML-Elemente werden gar nicht als Button angeboten. Glücklicherweise gibt es Hilfe in Form von Plugins, mit denen man diese Toolbar anpassen oder auch völlig ummodeln kann. Das leistungsfähigste Plugin, das ich finden konnte, ist AddQuicktag von Frank Bültge. Denn hiermit lassen sich nicht nur neue Elemente hinzufügen und sortieren, sondern sogar die standardmäßig vorgegebenen entfernen. Und das alles über eine sehr einfach zu bedienende Oberfläche.
Archiv der Kategorie: Webentwicklung
Den visuellen Editor in WordPress loswerden
Der Editor im WordPress-Backend lässt sich ja zwischen visueller und HTML-Ansicht umstellen. Benötigt man die visuelle WYSIWYG-Ansicht nicht, lässt sie sich in den Benutzereinstellungen deaktivieren. So handhabe ich es in meinen eigenen Blogs, in denen nur ich selber schreibe.
Was aber, wenn man ein Blog für mehrere Autoren anbietet oder eins für einen Kunden erstellt? Nicht alle der im WYSIWYG-Editor angebotenen zusätzlichen Möglichkeiten sind sinnvoll einsetzbar. Zum Beispiel könnte ein Autor unpassende Textfarben einstellen. Aber durch eine Zeile Code in der Datei functions.php im Theme-Ordner kann man diesen visuellen Editor deaktivieren.
Hier steht, wie es geht: www.guru-20.info.
WordPress: Verschiedene Templates und Sidebars für Seiten
Für mich ist WordPress immer noch am ehesten ein Blogsystem. Wenn also das Hauptaugenmerk eines Webauftrittes nicht auf einem Blog- oder Newsbereich liegt, sondern hohe Flexibilität in den Seitenlayouts gefragt ist, würde ich WordPress eher nicht einsetzen.
Für eine bestimmte Kundin standen die News stark im Vordergrund, weswegen ich WordPress wählte. Allerdings gibt es auch eine ganze Anzahl »statischer« Seiten (pages), die jedoch nicht alle gleich aufgebaut sind. Manche haben einen vollformatigen Inhaltsbereich, andere eine Seitenleiste (sidebar). Innerhalb des Gestaltungsthemas (theme) muss es also verschiedene Seitenvorlagen (templates) geben. Darüber hinaus müssen die Seitenleisten je nach Seite unterschiedliche Inhalte tragen.
Das in WordPress umzusetzen, war eine neue Anforderung für mich. In meinem anderen Lieblings-System, concrete5, ist so etwas super-leicht umzusetzen, aber auch in WordPress geht es ganz gut, wenn man erst einmal weiß, wie. Die Lösung fand ich auf drei Websites, und zwar so gut erklärt, dass ich mir die Mühe spare, alles mit eigenen Worten wiederzugeben. Hier sind die Quellen:
Templates für Seiten (Pages) in WordPress
[WordPress] Mehrere Sidebars nutzen
{WordPress} Unterschiedliche Inhalte in der Sidebar anziegen
Warum ich kein Typo3 verwende
Warum ich kein Typo3 verwende, ist eigentlich in wenigen Worten erklärt, auch wenn mir Typo3-Freaks wahrscheinlich gern den Kopf abreißen würden: Ich habe weder Zeit noch Lust, mich ein halbes Jahr lang einzuarbeiten, um das System zu verstehen und ein Theme selber erstellen zu können. Und ich möchte ein so unintuitiv bedienbares System auch meinen Kunden nicht zumuten.
Natürlich muss man sich auch mit WordPress und concrete5, meinen Lieblings-Systemen, ein wenig näher befassen, um gut damit arbeiten zu können. Aber wenn man fit in HTML und CSS ist und PHP halbwegs versteht, kann man schon nach einigen Tagen eigene Themes bauen. Es gibt bei beiden Content-Management-Systemen keine Template-Sprache, alles lässt sich mit purem PHP steuern.
Aber, na gut … Warum einfach, wenn es auch umständlich geht! Und die ganzen Typo3-Agenturen können sich auf die Schulter klopfen, so ein kompliziertes Zeug bestens zu verstehen. Und können dem Kunden eine Menge Geld abknöpfen, weil Typo3 ja das absolute Enterprise-CMS ist. Und natürlich ist auch ein Kunde, der einen eher kleinen Webauftritt mit fünf Seiten plus Kontaktformular braucht, mit Typo3 bestens beraten. Jo.
Tomato Cart 2.0 Alpha 4: Installation hängt bei Beispieldaten
Inzwischen ist das Shopsystem Tomato Cart, ein osCommerce-Fork, für mich gestorben. Es gab einfach zu viele Probleme. Was ich als ein viel besseres Open-Source-Shop-System empfinde, gerade für den deutschen Markt, ist modified eCommerce. Jedenfalls, ich habe zuletzt noch Tomato Cart 2.0 in der Alpha-Version 4 ausprobiert. Die Zweier-Version wird, wenn sie fertig entwickelt ist (eine komplette Neuentwicklung), vermutlich besser als die Einser-Produktlinie funktionieren, aber Alpha 4 nervte mich schon, als die Installation an dem Punkt hängen blieb, wo die Beispieldaten installiert werden sollen. Immerhin fand ich eine Lösung, die ich hier gern noch präsentieren möchte.
Zu bearbeiten ist folgende Datei: /install/applications/controllers/setting.php. Man löscht folgenden Code (ab Programmzeile 97):
//import sample data
if ($sample == 'on') {
//import sample sql data
$this->import_sample_sql();
//copy sample data
toc_copy('samples/images', '../images');
//resize images
$this->resize_product_images();
}
Und noch diesen Code (ab Programmzeile 141):
/**
* Import sample sql data
*
* @access private
* @return boolean
*/
private function import_sample_sql() {
//get database configuration from session
$config = $this->session->userdata('db_config');
//connect to database
$this->load->database($config);
//database is connected
if ($this->db) {
$sql_data = $this->load->file(realpath(dirname(__FILE__) . '/../../../') . '/install/tomatocart_sample_data.sql', TRUE);
$sql_data = str_replace('`toc_', '`' . $config['dbprefix'], $sql_data);
//split sql data with ;
$statements = preg_split("/;[\r\n]/", $sql_data) ;
//execute the sql statement
foreach ($statements as $statement) {
$this->db->query($statement);
}
return TRUE;
}
return FALSE;
}
Dann hat man zwar keine Beispieldaten (die ich sowieso überflüssig finde, weil man sie mühsam vor Inbetriebnahme des Shops wieder löschen muss), aber immerhin läuft die Installation auf diese Weise flüssig durch.
Wenn WordPress im Wartungsmodus hängen bleibt
Ist mir gerade passiert: drei Plugins waren in WordPress zu aktualisieren, was normalerweise glatt über die Bühne geht. Diesmal jedoch blieb WordPress im Wartungsmodus hängen und ich konnte das Backend nicht mehr bedienen. Zum Glück fand ich schnell eine sehr einfache Lösung, und zwar im Blog von Ansas Meyer: WordPress Wartungsmodus manuell beenden. Vielen Dank für den Tipp!
concrete5: Wenn im Composer Eingabefelder fehlen (Teil 2)
Kürzlich hatte ich beschrieben, wie man fehlende Eingabefelder im Composer für die Blogartikel-Texte nachrüsten kann.
Ich hatte geschrieben, dass man sich ins Dashboard einloggt, zu den Seitentypen navigiert und im Seitentyp blog_entry die gewünschten Blöcke als Platzhalter einfügt. Nur leider fehlte eine Winzigkeit: Man muss, während man sich im Bearbeitungsmodus befindet, im Kontextmenü des eingefügten Blocks noch Composer-Einstellungen wählen.
Im daraufhin erscheinenden Bearbeitungs-Fenster setzt man dann ein Häkchen bei Block in Composer einbinden. Erst dann erscheint solch ein Bereich auch im Composer.
Das wirkt zunächst einmal alles ein bisschen umständlich. Es wird aber einleuchtend, wenn man bedenkt, dass sich die in einem Theme (Gestaltungsthema) enthalten Seitenvorlagen sehr flexibel durch den Webentwickler für den Kunden programmieren lassen und somit das System gar nicht wissen kann, welche Block-Platzhalter überhaupt im Composer zur Verfügung gestellt werden sollen und wie der Webentwickler sie genannt hat. Dennoch wäre es sicherlich eine gute Idee, wenn die concrete5-Programmierer die beiden Standard-Platzhalter Main und Blog Post More, falls vorhanden, im Composer auswählbar machen würden oder so was. So steht man als Anwender und/oder Webdesigner nicht wie der Ochs vorm Berg. Und wie man an den Fragen in den Foren erkennen kann, bin ich beileibe nicht der einzige »Ochse«.
concrete5: Wenn im Composer Eingabefelder fehlen
Der Composer im CMS concrete5 ist dafür da, auf besonders einfache Art neue Seiten oder Blogartikel zu erstellen. Andere Möglichkeiten sind, in der Verwaltung den Seitenbaum aufzurufen und dort eine neue Seite anzulegen; oder man geht direkt auf die Seite, zu welcher eine Unterseite erstellt werden soll. Der Composer soll einem diese langen Wege ersparen. Außerdem kann man ganz gut Seiten vorbereiten, ohne sie gleich veröffentlichen zu müssen; anders gesagt, es lassen sich Entwürfe speichern.
Ich muss gestehen, dass ich früher nie verstand, was dieser Composer überhaupt sollte. Aber es wurden bei mir auch nie irgendwelche Editoren oder Eingabebereiche für die zu erstellenden Texte angezeigt.
Ich begann zwar bald zu ahnen, dass da vielleicht in den Einstellungen etwas nicht stimmen konnte, ging der Sache aber nicht weiter nach. Kürzlich ließ mir das Thema aber endlich doch keine Ruhe mehr, und ich ging auf die Suche nach einer Lösung. Diese Lösung lautet: Man loggt sich ins Dashboard ein, geht zu Verwaltung > Seiten & Themes > Seitentypen, dort zu Blog Entry > Standards und fügt hier schon einmal Inhaltsblöcke ein. Am besten gibt man kurze Platzhalter-Texte als Hinweise ein.
Quelle: concrete5.org/community/forums/
Nachtrag: Ein letzter Handgriff fehlt noch, wie ich feststellen musste! Er wird in Teil 2 beschrieben.
concrete5: Datum von Blogartikeln
Das CMS concrete5 speichert in der Datenbank die Angabe, wann ein Blogartikel erstellt wurde. Das dem Blogbesucher angezeigte Datum lässt sich allerdings ändern – und nach diesen öffentlichen Daten wird die Artikelliste auch sortiert, falls man eine chronologische Sortierung im Seitenlisten-Block eingestellt hat.
Wie aber lässt sich im Seitentyp blog_entry.php einstellen, dass eben diese Datumsangabe angezeigt werden soll? Indem man die Methode getCollectionDatePublic statt getCollectionDateAdded benutzt, etwa folgendermaßen:
<?php
global $u;
echo t(
'%1$s',
$c->getCollectionDatePublic(DATE_APP_GENERIC_MDY_FULL)
);
?>
Quelle: concrete5.org/community/forums/
Limit Login Attempts: selbst ausgesperrt
Blogs, die auf dem wohl verbreitetsten Blogsystem WordPress laufen, sind natürlich äußerst beliebte Ziele von Crackern. Bots versuchen, durch wiederholtes Ausprobieren von Benutzernamen und Passwörtern in die Systeme einzudringen. Diese Brute-Force-Attacken sind weit verbreitet.
Es gibt verschiedene Möglichkeiten, sich zu schützen, die ich in diesem Rahmen nicht alle besprechen möchte. Sicherlich fängt der Schutz damit an, dass man keinen Benutzer admin im System hat und natürlich keine Passwörter wie password oder 1234 benutzt.
Ein bekanntes und beliebtes, wenn auch inzwischen veraltetes Plugin ist Limit Login Attempts, das eben diese Brute-Force-Attacken abzuwehren versucht. Wie es das macht, beschreibt Vladimir Simović in seinem Blog perun.net.
Dumm nur, wenn man sich selbst ausschließt. Es ist peinlich, aber ich muss zugeben: mir ist das gestern passiert. Irgendwie habe ich wohl drei- oder viermal ein altes, nicht mehr gültiges Passwort eingegeben, und schon kam ich nicht mehr ins Backend hinein. Vladimir empfiehlt, entweder die Zeitsperre abzuwarten oder eine andere IP-Adresse zu verwenden. Dazu müsste man im Falle eines DSL-Modems die Internet-Verbindung trennen und sich neu einloggen. Im Falle eines DSL-Routers müsste man vermutlich den Router neu starten, um eine andere IP zu erhalten, oder?
Ich schlage eine weitere Möglichkeit vor. Sie setzt allerdings voraus, dass man Zugriff auf die WordPress-Datenbank hat, und den hat man nur bei einem selbst gehosteten WordPress-Blog, nicht aber bei einem Blog auf wordpress.com. Außerdem eignet sich diese Methode auch nur für versierte Anwender. Und zwar löscht man einen Eintrag in der Datenbank (zum Beispiel über phpMyAdmin, falls der Webhoster es zur Verfügung stellt oder man es selbst installiert hat).
Im Detail: Tabelle wp_options, Feld option_name, Eintrag limit_login_lockouts, Feld option_value, und hier den Eintrag aus <MEMO> löschen.
Allerdings gibt es Plugins mit weiteren Möglichkeiten, sein WordPress-Blog sicher zu machen. Mehrere werden auf t3n.de vorgestellt. Welche man einsetzen will, mag jeder für sich entscheiden.