WordPress-Suche beschleunigen

Derzeit entwickle ich für Macnotes ein neues Thema, das ausschließlich AMP nutzt, damit die Website für den Google-Bot, und andere sowohl auf dem Desktop als auch am Smartphone oder Tablet die gleichen Resultate liefert. Diese Konsistenz soll auf Dauer dafür sorgen, dass ich Änderungen an der Website besser mit Erfolgen bei Google in Einklang bringen kann.

In meiner lokalen Entwicklungsumgebung ist mir neulich aufgefallen, wie langsam die Suche ist, und also habe ich mich daran begeben, die Ursache zu finden, und die Suche letzten Endes zu beschleunigen. Ein Plug-in, das Euch dabei behilflich sein kann, ist „Query Monitor“ von John Blackbourn. Ihr solltet es aber vor allem in Entwicklungsumgebungen einsetzen, weil es seinerseits einige Ressourcen nutzt und so die Seite selbst verlangsamen kann.

Tablepress-Ergebnisse verlangsamen die Suche ungemein

Query Monitor (QM) zeigt Euch unter anderem PHP-Fehler an, es fängt aber auch die Datenbankabfragen ab und stellt fest, wie lange sie dauern. Ihr könnt auf diese Weise auch die Abfragen nachverfolgen und so über ein Datenbank-Tool wie Sequel Ace noch einmal nachstellen.

Dabei habe ich zum Beispiel rausgefunden, dass WordPress mit installiertem Tablepress folgende Abfrage startet, wenn Ihr nach „iphone 12“ sucht:

SELECT SQL_CALC_FOUND_ROWS wp_posts.ID
FROM wp_posts
WHERE 1=1
AND (((wp_posts.post_title LIKE '%iphone%')
OR (wp_posts.post_excerpt LIKE '%iphone%')
OR (wp_posts.post_content LIKE '%iphone%')
OR (wp_posts.post_content REGEXP '[table “” not found /]

?)(9|10|11|13|14|44|45|50)([]"' /])'))
AND ((wp_posts.post_title LIKE '%12%')
OR (wp_posts.post_excerpt LIKE '%12%')
OR (wp_posts.post_content LIKE '%12%')
OR (wp_posts.post_content REGEXP '[table “” not found /]

?)(1|2|3|5|7|10|11|13|14|17|19|20|21|23|30|32|39|41|43|44|47|50|51|55|57|58|59|60)([]"' /])')))
AND wp_posts.post_type IN ('post', 'page', 'attachment', 'buch', 'event', 'firma', 'person', 'plattform', 'produkt')
AND (wp_posts.post_status = 'publish')
ORDER BY (CASE
WHEN wp_posts.post_title LIKE '%iphone 12%'
THEN 1
WHEN wp_posts.post_title LIKE '%iphone%'
AND wp_posts.post_title LIKE '%12%'
THEN 2
WHEN wp_posts.post_title LIKE '%iphone%'
OR wp_posts.post_title LIKE '%12%'
THEN 3
WHEN wp_posts.post_excerpt LIKE '%iphone 12%'
THEN 4
WHEN wp_posts.post_content LIKE '%iphone 12%'
THEN 5
ELSE 6 END), wp_posts.post_date DESC
LIMIT 0, 10; 

Mal abgesehen von generell ziemlich vielen Zeilen, fallen sofort zwei ins Auge, nämlich die mit dem „REGEXP“. Das sind Suchabfragen, die explizit von Tablepress stammen.

Ja und dann habe ich einfach mal ausprobiert, wie lange die Suche mit und ohne diese Zeilen dauert. In der Entwicklungsumgebung waren das 13,7 Sekunden mit Tablepress-Ergebnissen versus 1,39 Sekunden ohne. Es würde zwar auf dem Webserver wegen mehr RAM und Ressourcen, etc. nicht dermaßen auseinander driften, aber es ist trotzdem ein unnötiger Ballast.

Denn ich nutze Tabellen nur innerhalb von Texten und in den Texten selber kommen die Suchwörter „hoffentlich“ auch vor. Also habe ich mich entschieden, WordPress nicht mehr die Tablepress-Tabellen zu durchsuchen.

Ihr fügt dazu folgenden Befehl in die „functions.php“ ein:

add_filter( 'tablepress_wp_search_integration', '__return_false' );

Unnötige Bestandteile entfernen

Tablepress ist aber nicht das Einzige, das ich aus der Suche entferne. Ihr selbst könnt Euch überlegen, welche Beitragstypen (Post Type) Bestandteil der Suche sein sollen. Wenn Ihr beispielsweise für einen „Custom Post Type“ gar kein Archiv habt und stattdessen die Inhalte dahinter mehr wie in einem Glossar nutzt, kann es sich auch lohnen, diese aus der Suche zu entfernen.

Ebenfalls macht es in meinen Augen zum Beispiel keinen Sinn, die „Attachments“ durchsuchen zu lassen. Ich nutze Bilder, PDFs oder Audiodateien und Videos ebenfalls innerhalb von Beiträgen, und entsprechend kann ich sie aus der Suche rausfiltern.

Das könnt Ihr wie folgt tun:

 add_action( 'init', 'sn_exclude_from_search_results' );
function sn_exclude_from_search_results() {
	global $wp_post_types;
	$wp_post_types['attachment']->exclude_from_search = true;
}

Suchwörter hervorheben

Noch etwas finde ich persönlich sehr hilfreich, und zwar das optische Hervorheben von Suchwörtern. So kann man den Kontext um das Gesuchte schneller in den Blick nehmen. Dazu ist natürlich ein bisschen CSS notwendig. Also füge ich entsprechend eine Klasse zu den Suchworten hinzu. Das klappt folgendermaßen:

function sn_highlight_title() {
  $title = get_the_title();
  $keys = implode('|', explode(' ', get_search_query()));
  $title = preg_replace('/(' . $keys .')/iu', '<strong class="search-highlight">

Der Beitrag WordPress: Die Suche und Suchergebnisse optimieren erschien zuerst auf Macnotes.de.

Worum geht es?

Stellt Euch vor, Ihr habt eine Idee für eine Funktion oder am Ende des Tages sogar eine Klasse. Nehmen wir an, Ihr wollt eine Funktion programmieren, die Euch egal in welchem Kontext das passende Bild in Form eines Arrays mit Bildinformationen zurückgibt.

Die Funktion gibt Euch diese Bilddaten sowohl auf der Startseite, als auch in den Archiven und aber auch in einzelnen Beiträgen oder Seiten zurück und Ihr könntet Sie außerdem für viele andere Zwecke nutzen, in denen es immer um Bilder geht. Grob also in etwa:

function my_img() {
…
return $img;
}

Normalerweise verzweifelt man irgendwann daran, dass es viel zu viele Ausnahmen gibt. Denn im Umfeld von WordPress gibt es diverse Funktionen, eine für Artikelbilder (the_post_thumbnail()), eine für Avatare, eine ganz andere, falls Bilder in Form von Metadaten an „Custom Post Types“ angehängt wurden (get_post_meta()), und so fort. Und wenn man die Bilder dann nicht im Rahmen des normalen „Loop“ von WordPress abgreift, sondern mit einem persönlichen Query, dann bekommt man es ohnehin mit einem anderen Ergebnis zu tun (wp_get_attachment_img_src()). Mal hat man dann mit Objekten zu tun, mal mit Arrays, mal mit bloßen Zeichenketten, in denen der URL des Bildes enthalten ist, aber nicht viel mehr.

Ist es nicht nervig, dass man dann überall einen anderen Ansatz für die Entwicklung des eigenen WordPress-Themes benötigt?

Für Waffengleichheit sorgen

Wie bekommt man all diese unterschiedlichen Ergebnisse sortiert? Ganz einfach. Indem man für Ordnung sorgt!

Die Absicht hinter einer eigenen Funktion oder sogar einer Klasse ist ja, dass man sie „immer gleich“ nutzen kann. Mithilfe von Parametern kann man dann noch entscheiden, welcher Code ausgegeben werden soll.

Im Laufe der Arbeit müsst Ihr dann einfach mal einen Schritt zurücktreten und schauen, wo überhaupt Gemeinsamkeiten bestehen. Eine WordPressfunktion wie get_the_post_thumbnail() liefert Euch am Ende des Tages einen fertigen HTML-Tag zurück. Für ein Bild, das als Metadaten zu einem Custom Post Type gespeichert wurde, erhaltet Ihr über get_post_meta() die URL zurück, aber keinen fertigen HTML-Tag. Über wp_get_attachment_img_src() gibt es ein Array, das neben der URL auch die Daten für Breite und Höhe enthält.

Wenn Ihr wollt, dass Ihr Eure Funktion immer auf die gleiche Art verwenden könnt, beispielsweise eine ID des Bildes angebt und dann aber ein Array mit URL, Breite und Höhe zurückbekommt, damit Ihr in Eurem Template dann den HTML-Tag selbst erstellen könnt, müsst Ihr einen gemeinsamen Nenner suchen.

Und was ist beispielsweise für den Fall, dass es gar kein Artikelbild gibt? Ja, auch dann müsst Ihr eben ein Array erstellen, das ein Standardbild als URL enthält, und Angaben für dessen Breite und Höhe.

So eine Funktion könnte unvollständigerweise wie folgt ausschauen:

function my_img($id, $standort) {
	switch($standort) {
		case 'Startseite':
			$img = wp_get_attachment_src($id);
			$my_img = [
				'width' => $img[1],
				'height' => $img[2],
				'url' => $img[0]
			];
			break;
		case 'CPT':
			$img = get_post_meta(…);
			$my_img = [
				'width' => 1920,
				'height' => 1080,
				'url' => $img
			];
	}
	// für den Fall, dass noch gar kein Bild-Array erstellt wurde, müssen wir noch eines hinzufügen.

	if(!isset($my_img)) {
		$my_img = [
			'width' = 1920,
			'height' = 1080,
			'url' = 'Adresse zum Standardbild'
		];
	}
	return $my_img;
} 

Der obige Code ist nicht auf Fehler geprüft, da ich gerade nur einen Texteditor zur Hand habe. Aber mir kam eben gerade jetzt die Idee zu diesem Artikel.

Die Funktion liefert Euch also theoretisch „in jedem Fall“ ein Array mit URL, Breite und Höhe zurück. Auf diese Weise könnt Ihr sie dann immer auf die gleiche Weise verwenden.

Nicht dem Chaos nachgeben

Denn es passiert viel zu schnell, dass man sich mit einer Situation zufriedengibt, in der man sagt, ach komm, an dieser Stelle geht es nun mal nicht, weil da hab ich keine ID vom Bild, sondern nur eine vom Kommentar, und brauche aber den Avatar. Ja, genau dann muss man vorab für Waffengleichheit sorgen.

Das kann man entweder „vorher“, also außerhalb der Funktion. Das ist zu begrüßen. Denn eine Funktion sollte tatsächlich nur eine Aufgabe haben und die immer gleich ausführen. Man könnte es theoretisch auch innerhalb der Funktion, aber das würde die Funktion unnötig aufblähen.

Wenn man also eine ID von einem Kommentar hat und aber die ID des zugehörigen Avatar-Bildes benötigt, muss man im Vorfeld erst mit den vorhandenen Daten diese ID rausfinden. Auch dafür könnte man wieder eine eigene Funktion erstellen, wenn es nicht womöglich auch schon eine bei WordPress gibt. Da ist dann im Fall von WordPress die Code Reference eine gute Anlaufstelle.

Ich habe persönlich eine Weile gebraucht, bis ich vor Jahren irgendwann gemerkt habe, dass es mir hilft, wenn ich in meinen Funktionen für Waffengleichheit sorge, statt ständig neuen Code zu schreiben, oder aber dutzende Ausnahmen zu schaffen.

Denn wenn Ihr wisst, dass Ihr die Funktion my_img() verwendet und immer auf die gleiche Weise verwenden könnt, habt Ihr beim Durchsehen des Quellcodes wesentlich mehr Überblick und ärgert Euch nicht, dass WordPress in dem Kontext mal so programmiert werden will und in einer anderen Situation aber anders. Ihr könnt dann ruhigen Gewissens Eure Vorlagen entwerfen und müsst nur einmal auf die Animositäten von WordPress Rücksicht nehmen, aber eben nicht immer wieder aufs Neue.

Ihr schafft dann einmal „Ordnung“ und könnt Euch immer darauf verlassen, dass Ihr ein korrektes Ergebnis erhaltet, mit dem Ihr arbeiten könnt.

Weitere Beispiele

Die thematisierte Bild-Funktion ist nur ein Beispiel von vielen.

Ich reduziere, wenn ich mit WordPress arbeite, mittlerweile meine Abfragen auf ein Minimum. So kann man eine QUERY nur IDs als Ergebnis zurückgeben lassen, statt vollständige Artikel samt aller Metadaten. Ich bekomme dann ein Array mit IDs zurück und kann es überall sinnvoll einsetzen, egal ob auf der Startseite, in Archiven, oder wo immer ich es möchte.

Statt womöglich mehrere Male einen QUERY zum Beispiel im Template für die Startseite zu nutzen, habe ich mir einfach eine eigene my_query()-Funktion geschrieben. Auch die hat den Vorteil, dass ich immer weiß, was ich am Ende bekomme. Ich kann mittels Parameter den QUERY auf Artikel einer anderen Kategorie steuern. Aber ich kann auch Fälle berücksichtigen, in denen ich vielleicht ähnliche Artikel über Metadaten abfragen möchte. All das kann ich vorab einrichten, sodass ich am Ende bei my_guery() immer die IDs von Artikeln erhalte, mit denen ich weiterarbeiten kann.

Was geht rein, was soll raus

„Früher“ ™ hab ich eigentlich nie darüber nachgedacht, was ich mit Funktionen erreichen möchte. Also grob schon, aber nie im Detail.

Vor Jahren war der Anspruch eigentlich, ein wenig Arbeit zu erleichtern. Das ist er heute zwar immer noch. Doch wenn man sich darauf besinnt, zu prüfen, welche Daten in eine Funktion hineingehen und welche am Ende herauskommen, kann man sogar noch weitere Optimierungen vornehmen.

Zu viele Parameter sind ein „Zeichen“!

Wenn ich beispielsweise merke, dass ich noch einen, und noch einen Parameter brauche und am Ende eine Funktion habe, die zwar alles tut, was sie soll, aber ich womöglich 10, 12 unterschiedliche Parameter brauchen könnte, dann ist das auch nicht im Sinne des Erfinders. Dann ist es eher Zeit, sich vor Augen zu führen, dass ich mit weiteren Funktionen besser bedient bin, um am Ende wieder den Normalzustand herzustellen.

Will heißen: Wenn ich sage, in eine Funktion gehen IDs von Bildern rein und kommen Arrays mit Bildinformationen raus, dann sollte ich diese Funktion nicht damit belasten, aus möglicherweise Artikel-IDs noch Bild-IDs zu extrahieren. Für derartige Fälle kann ich mir lieber einfallen lassen, eine get_my_img_ID()-Funktion zu schreiben, die mir die benötigte Bild-ID liefert, mit der ich meine my_img()-Funktion füttern kann.

Eine Zeichenkette ist eine Zeichenkette, ist eine Zeichenkette?

An dieser Stelle möchte ich zum Ausklang noch ein etwas anderes Beispiel aufführen. Vielleicht kennen manche von Euch die WordPress-Funktion wp_remote_get(), wenn nicht, dann könnt Ihr dessen Funktionsweise in der Code Reference von WordPress nachlesen.

Die Funktion liefert ein Array zurück, das neben den Verbindungsdaten aus dem „Header“ auch den „Body“, also die eigentliche Webseite als Zeichenkette zurückgibt. Wenn Ihr aber am Ende des Tages etwas Anderes benötigt, oder nur Teile davon, dann könnt Ihr natürlich auch hier für Waffengleichheit sorgen, indem Ihr mit einer Funktion das Ergebnis bearbeitet, bis es Euren Bedürfnissen entspricht. Ich habe diese Funktion auch mal verwendet, um URLs von Bildern zu erhalten. Natürlich musste ich dann den Quellcode entsprechend „parsen“.

Einen hab ich noch …

Daran anschließen möchte ich noch einen Hinweis, der prima zum Stichwort Parsen passt. Es gibt ein mächtiges Werkzeug zum Parsen von Dokumenten, das sind die regulären Ausdrücke. Damit kann man tolle Sachen machen, allerdings benötigen reguläre Ausdrücke (REGEX) auch eine gewisse Einarbeitungszeit.

Doch wenn Ihr spontan tatsächlich gewisse „Elemente“ einer HTML-Seite extrahieren oder bearbeiten möchtet, sagen wir alle Bilder, oder alle Links, dann eignet sich dafür auch die PHP-Klasse DOMDocument relativ gut. Wer schon mal mit Javascript programmiert hat, der wird diese Klasse zu schätzen wissen. Denn sie bietet ähnliche Angriffspunkte wie das auch in Javascript genutzte „Document Object Model“ (DOM) und ist aus diesem Grund leichter zugänglich als reguläre Ausdrücke.

Ihr sucht nach einem Anwendungszweck? Ihr könntet mit Javascript, unter manchen Umständen auch mit CSS, gewisse Links kennzeichnen. Aber wenn der Nutzer Javascript ausschaltet, dann ist auch die Kennzeichnung futsch und mit CSS seid Ihr nicht so flexibel. Also könntet Ihr dann den $content von WordPress mit DOMDocument bearbeiten. Damit Ihr am Ende aber nicht weiteren HTML-Tags oder unnötigen Ballast erhaltet, gibt es mittlerweile in PHP passende Parameter, um das zu unterbinden. Für die Funktion „loadHTML“ gibt es nämlich mittlerweile die Parameter LIBXML_HTML_NOIMPLIED und LIBXML_HTML_NODEFDTD. Mehr dazu findet Ihr in der PHP-Dokumentation.

function manipulate_my_content() {
	global $post
	$content = $post->post_content;
	$document = new DOMDocument();
	$document->loadHTML($content, LIBXML_HTML_NOIMPLIED | LIBXML_HTML_NODEFDTD);
	// links extrahieren oder dergleichen geht dann ganz einfach mit:
	$links = $document->getElementsByTagName('a');
	// irgendwas mit den Links anfangen
	…
	// den manipulierten Inhalt speichern und wieder zurückgeben
	return $document->saveHTML();
}

Diese Ansätze, die ich in dem Beitrag erwähnt habe, helfen mir dabei, Waffengleichheit zu erzielen, und mich bei der Arbeit mit WordPress ein wenig voranzubringen.

Vielleicht helfen Sie Euch ja ebenso. Interessant findet Ihr dann womöglich auch die Beiträge:

• „Von der Idee zum WordPress-Plug-in #1“ und
• „Von der Idee zum WordPress-Plug-in #2“.

Der Beitrag Wie man bei der WordPress-Programmierung für Waffengleichheit sorgt erschien zuerst auf Macnotes.de.

Einen ganzen Artikel hat Burnett der Veröffentlichung von 10 Millionen Passwörtern und Logins gewidmet. Burnett, der mehrere Bücher über IT-Sicherheit bei Sams und Syngress veröffentlicht hat, äußert darin die Sorge, die Strafverfolgungsbehörden in den USA könnten ihn dafür einsperren. Er begründet, warum seiner Meinung nach die Veröffentlichung der Daten zu Forschungszwecken relevant ist und erläutert die Gesetzeslage in den USA, die sein Vorgehen offenbar unter Strafe stellt. Laut Burnett sollen die Logins und Passwörter allesamt nicht mehr aktiv genutzt werden, weshalb sie „im Prinzip“ keine direkte Bedrohung darstellen. Das zu überprüfen ist aber nicht realistisch möglich, weshalb man es als eine Schutzbehauptung ansehen muss.

„Ultimately, to the best of my knowledge these passwords are no longer be valid and I have taken extraordinary measures to make this data ineffective in targeting particular users or organizations.“
Mark Burnett

10 Millionen Passwörter durchsuchen

Burnett verteilt ein Archiv als Torrent-Download von knapp 90 MByte, das in einer simplen Textdatei von knapp 200 MByte resultiert. Nutzer sollten nicht versuchen die Textdatei mit irgendwelchen Editoren zu öffnen, um darin zu suchen. Das strapaziert die meisten Editoren über. Wer sich die Datei bloß angucken möchte, der kann das natürlich im Editor tun.
Das Suchen erledigt man aber besser mit Hilfe der Kommandozeile / des Terminals. Dabei lautet die einfachste Formel: grep SUCHWORT DATEI. Wer wissen möchte, in welcher Zeile des Dokuments das Ergebnis gefunden wurde fügt einfach den Parameter „-n“ hinzu, also: grep -n SUCHWORT DATEI.

Da der Grep-Befehl auch einen regulären Ausdruck (REGEX) als Suchwort akzeptiert, kann man sehr komplexe Suchen durchführen.

Keine E-Mail-Adressen

Burnett schreibt, er habe die Daten sorgsam ausgewählt. Das bedeutet auch, dass keine E-Mail-Adressen in dem Datensatz enthalten sind, und dass außerdem nicht ersichtlich ist, auf welchen Plattformen oder in welchem Kontext die Logins und Passwörter genutzt wurden. Durch die Beschaffenheit der Datei ist zudem mit Grep zunächst keine Unterscheidung zwischen Login oder Passwort als Suchbegriff möglich. Dadurch, dass jedoch der Abstand zwischen Login und Passwort immer derselbe ist, könnte man den Datensatz bearbeiten und in ein anderes Format übertragen, sogar für eine tabellarische Ansicht überarbeiten.

In jedem Fall hat Burnett mit der Veröffentlichung einigen Script-Kiddies die Liste der Passwörter ihrer Brute-Force-Tools aufgefüllt.

Der Beitrag IT-Spezialist hat 10 Millionen Passwörter und Logins veröffentlicht erschien zuerst auf Macnotes.de.

Chmod

Wer sich Zugriffsrechte von Dateien auf unixoiden Betriebssystemen (etwa Linux oder Mac OS X) noch nie merken konnte, dem könnte das kleine App Chmod helfen. Es bietet, ohne großes Aufsehen zu erregen, die Möglichkeit, die Zugriffsrechte einzustellen. Dabei hat der Anwender zwei Möglichkeiten: Entweder, er setzt die Haken wie er es braucht, oder er verschiebt die Zahlen, um eine Kombination zu testen. Mehr Optionen bietet die App nicht, aber gefallen hat uns eben dies. Da das Programm kostenlos ist, sollte es sich jeder, der mal mit Dateien hantieren möchte, ansehen.

PHP CheatSheet

Für 79 Cent bekommt ihr hier ein App, das auf den Namen PHP CheatSheet hört und eine gute Übersicht über PHP bietet. Es ist eine Erklärung mit Beispielen enthalten, wie einfache Sprachkonstrukte, beispielsweise Schleifen oder Bedingungen, zu verwenden sind. Dazu gibt es eine Erklärung zu allen Datentypen, die PHP mitbringt. Des Weiteren findet sich in der durchsuchbaren Datenbank eine Liste aller PHP-eigenen Funktionen, die nach Anwendung gruppiert ist (etwa Array-Funktionen und Bilder-Funktionen). Diese zeigt jedoch nur den Namen der Funktion an sowie eine kurze Beschreibung, was der Sinn der Funktion ist. Leider fehlen hier sowohl Rückgabewerte als auch die Parameterliste. Damit deklassiert sich das App zum Nachschlagewerk für Anfänger, wobei gerade diesen eine detailliertere Erklärung wichtig wäre. Wesentlich besser, dafür etwas unübersichtlicher, ist da die PHP Reference (siehe nächster Punkt).

PHP Ref

Die PHP Ref-App bietet für ebenfalls 79 Cent die komplette Dokumentation von der Webseite php.net. Diese wird nicht live aus dem Internet abgefragt, sondern befindet sich lokal auf dem iPhone oder iPod. Der Anwender kann entweder in den Funktionen stöbern oder per Suchfunktion nach dem Namen einer Funktion suchen. Angezeigt wird dann die vollständige Erklärung der Funktion inkl. Beispielen und Sonderfällen, wie es auch bei php.net der Fall ist. Für die Anzeige sorgt WebKit, deshalb ist es möglich, iPhone-typisch zu zoomen oder das Querformat zu nutzen. Da die Dokumentation von der PHP-Webseite stammt, sind auch Querverweise enthalten, die auf verwandte Funktionen verweisen. Weniger hat uns gefallen, dass die Funktionen alphabetisch aufgelistet werden und nicht nach Art gruppiert werden wie bei CheatSheet. Ebenso wird besonders Kennern der PHP-Webseite auffallen, dass die Suchfunktion keinerlei Toleranz erlaubt. Sucht man auf der PHP-Seite beispielsweise „inarray“, findet sie „in_array“ und leitet trotz ungenauem Namen korrekt weiter. Dass die App das nicht tut, ist aber aufgrund der Live-Suche während der Eingabe in den meisten Fällen zu verschmerzen.

CSS CheatSheet

CSS CheatSheet bietet für 79 Cent eine umfangreiche Sammlung von Elementen, die in CSS-Deklarationen zum Einsatz kommen können. Erklärt sind daneben, ähnlich dem PHP CheatSheet, Basics der Sprache, etwa die möglichen Einheiten oder die Definitionen einer Farbe. Besonders gut ist dabei die Liste für gültige Werte ausgefallen. Außerdem gibt es für fast jedes Element ein Beispiel. Die Datenbank umfasst jedoch nur CSS2-Attribute – in der Praxis finden CSS3-Deklarationen aber eher selten Anwendung, weil gängige Browser wie der Internet Explorer, schon CSS2 nur mit Mühen verstehen.

RegEx CheatSheet

Abermals 79 Cent kostet das CheatSheet für reguläre Ausdrücke. Darin findet sich eine Dokumentation für reguläre Ausdrücke in verschiedenen Interpretationen. Dazu gehören nicht nur die Meta-Zeichen (etwa der Punkt für ein beliebiges Zeichen), sondern ebenfalls Modifiers, mit denen sich das Verhalten der RegEx beeinflussen lässt. Die App wartet zusätzlich mit Erklärungen für die einzelnen Sprachen auf, in denen RegEx genutzt werden kann. Zu den Features gesellt sich neben einer Reihe von Beispielen komplexerer Ausdrücke, beispielsweise für die Überprüfung einer gültigen E-Mail-Adresse. Hier zeigt das Programm zudem, was gefunden wird und was nicht.

Hervorzuheben ist das JavaScript-Feld am Ende jeder Seite, mit dessen Hilfe ein Ausdruck auf einen Text angewandt werden kann, um zu überprüfen, ob er funktioniert. Leider muss ein Ausdruck immer neu eingegeben werden, eine Kopieren und Einfügen-Funktion für die Erklärungen fehlt.

iCheatSheet

Das mit 1,59 Euro teuerste Cheat-Sheet ist der Rundumschlag unter den IT-Referenzen. Diese App beinhaltet eine Vielzahl von Erläuterungen, die im Umgang mit Programmierung oder Administration gebraucht werden könnten. Dazu gehören etwa Google-Befehle, Emoticons (die in Chats oft zum Einsatz kommen), HTML-Befehle, .htaccess-Optionen, MySQL-Erklärungen, VIM-Befehle und viele andere mehr. Die App glänzt jedoch nur durch ihren Umfang. Eine Suchfunktion fehlt komplett und die Inhalte wirken zum Teil eingescannt. Eine Ansicht im Querformat gibt es nicht. Dennoch halten wir das Programm für nützlich, denn für den Preis von knapp zwei anderen Cheat-Sheets bekommt der Anwender eine wirklich große Zahl von Sheets an die Hand, die zwar (optisch) nicht wirklich schön sind, aber im Wesentlichen durch ihren Inhalt überzeugen. Jedoch ist iCheatSheet oftmals nicht so ausführlich, wie es andere Nachschlagewerke sind.

Alle diese Anwendungen haben leider ein Laster gemein: Sie sind allesamt nur in englischer Sprache verfügbar. Darüber haben wir bei der Bewertung jedoch hinweg gesehen, denn in der Praxis zeigt sich, dass (Web-)Entwickler der englischen Sprache mächtig sein sollten. Wer das nicht ist, für den sind die Programme aber leider eher nicht nützlich.

Der Beitrag Nachschlagewerke für Web-Entwickler auf dem iPhone erschien zuerst auf Macnotes.de.