Tatsächlich gibt es just heute eine Reihe von Angeboten zu den AirTags selbst, aber auch passendem Zubehör auf Amazon.

• AirTags im Viererpack für nur 89,90 Euro.
• Apple Lederschlüsselanhänger für 35,84 Euro.
• Belkin Schlüsselanhänger-Zubehör für 9,99 Euro.
• Weiteres Zubehör von unterschiedlichen Herstellern ist ebenfalls im Angebot.

Fernab der AirTags gibt es natürlich noch andere Apple-Produkte bei Amazon im Angebot. Darunter auch AirPods Pro mit neuem MagSafe Ladecase zu einem günstigen Kurs und viele andere Dinge mehr. Stöbern lohnt sich, Preise vergleichen natürlich auch.

Dieser Artikel enthält Affiliate-Links.

Der Beitrag Black Friday: AirTags und Zubehör günstig erschien zuerst auf Macnotes.de.

Apple veröffentlichte das neue macOS 11.4 am 24. Mai. Schon Ende April aber veröffentlichte die Firma Jamf einen Hinweis auf eine passende Sicherheitslücke, die im Verlauf des Betatests geschlossen wurde.

Malware im Schlepptau

Das Problem? Eine Sicherheitslücke in Apples Autorisierungssystem für Apps (Transparency Consent and Control, kurz TCC). Hacker machten sich den Fehler zunutze und überarbeiteten eine Mac-Malware namens XCSSET.

Diese konnte dann ungefragt davon profitieren, dass beispielsweise Apps wie Zoom, TeamViewer, Skype, MS Teams und viele andere, vom Nutzer bereits autorisiert wurden. Diesen gewährte man beispielsweise Zugriff auf Dateien, die integrierte Kamera oder aber das Mikrofon. Auf diese Weise konnte die Malware beispielsweise stetig Screenshots von der Benutzeroberfläche erstellen und an Dritte senden. Mitunter wurden so Passwörter kompromittiert und sensible Informationen entwendet.

Schadsoftware aktiv genutzt

Tatsächlich erklären Stuart Ashenbrenner, Jaron Bradley und Ferdous Saljooki, dass sie eine Zunahme der Verwendung von XCSSET entdeckten. Nachdem die Malware auf die neue Schwachstelle angepasst worden war, wurde sie in kurzer Zeit deutlich häufiger genutzt. Es ist sehr wohl davon auszugehen, dass die Schadsoftware, die es in ihrer ursprünglichen Form bereits seit August 2020 gibt, auch Schaden anrichtete.

Entwickler verbreiten die Malware selbst

Wie aber kommt die Malware auf die Rechner der Nutzerinnen und Nutzer? Entwickler selbst verteilen sie, und zwar über die Zuhilfenahme von manipulierten Programmbibliotheken, die beispielsweise über GitHub geteilt werden und dann bei der Einbindung in Xcode zusammen mit der eigentlichen App kompiliert werden.

Dabei versteckt sich die Malware selbst in vermeintlich harmlos wirkenden Scriptdateien unterschiedlicher Syntax (AppleScript, Python, und andere mehr).

Wer also seinen Mac noch nicht auf macOS 11.4 aktualisiert hat, dem empfehlen wir dies nun nachzuholen.

Der Beitrag macOS 11.4: Deshalb sollte man möglichst schnell updaten erschien zuerst auf Macnotes.de.

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.

Genau das wollen wir Euch dann in dieser Ausgabe erklären, und auch, welche Grenzen unser Plug-in weiterhin hat. Die Herangehensweise zeigt vor allem, dass so ein relativ einfaches Projekt mit ein wenig Fantasie und Aufwand zu etwas richtig seriösem aufgebaut werden kann.

Das Plug-in braucht mehr Komfort

Anstatt den Quellcode immer von Hand anzupassen, wenn man neue Schlagwörter hinzufügen möchte, kann man dazu die Datenbank bei WordPress verwenden und entsprechende Formulare. Folgende „Details“ und „Fragen“ gibt es unter anderem zu klären, von denen wir aber nur einige exemplarisch nennen wollen:

• Wie kann ich mit der Datenbank von WordPress kommunizieren?
• Benötige ich eine eigene Tabelle?
• Wie handhabt WordPress Formulare?
• Gibt es Sicherheitsvorkehrungen zu treffen?
• Muss ich mehrere Plug-in-Dateien erstellen?
• Was ist die WordPress-Nonce, und wie kann sie mir in diesem Fall helfen?

Wann benötige ich für mein Plug-in eine eigene Tabelle?

Es ist eine viel diskutierte Frage, ob es sinnvoll sein kann, eine eigene Tabelle für ein WordPress-Plug-in einzurichten. Eines der Schwergewichte unter den WordPress-Plug-ins, Yoast SEO, änderte vor ein paar Monaten seine Einstellung zu der Thematik und migriert seitdem mit jedem Update zunehmend mehr Daten aus WordPress-Tabellen in eigene.

Für mich liegt die Antwort auf der Hand: Ich mache immer eine eigene Tabelle, wenn ich eigene Daten verwenden möchte. Sieht man davon ab, dass WordPress-Tabellen vor allem bei großen Websites sowieso relativ unübersichtlich werden, kann es beim Abfragen von Daten auch Performance-Vorteile bieten. In der Tat ergibt es aber nur wenig Sinn, den Aufwand zu betreiben, wenn man am Ende nur eine Handvoll Datensätze speichern mag. Die lassen sich zur Not auch noch in der WordPress-Tabelle sichern.

Wie kommuniziere ich mit der WordPress-Datenbank?

WordPress hält für Entwickler Befehle zur Verfügung, um mit der Datenbank zu kommunizieren. In Einzelfällen kann es sinnvoll sein, die WordPress-Routinen zu umgehen und mittels PHP oder anderer Scriptsprachen die Kommunikation zur Datenbank auf eigene Faust zu unternehmen. Das ist aber nur in Fällen ratsam, in denen man wirklich viele Datensätze bearbeitet, und an dieser Stelle rede ich von zehntausenden Datensätzen und mehr, die regelmäßig immer wieder abgefragt werden oder aktualisiert werden. Denn zur Wahrheit gehört, dass die WordPress-Datenbank-Engine nicht die schnellste ist.

In Teil 1 wiesen wir bereits auf Befehle wie add_option() (vgl. WordPress Code-Referenz) hin, mit dem sich Daten ohne Weiteres in die Tabelle wp_options von WordPress hinzufügen lassen. Mittels update_option() kann man vorhandene Datensätze aktualisieren, und sie mit delete_option() entsprechend wieder entfernen.

Doch wir wollen nicht die WordPress-Tabelle zumüllen, sondern mit der eigenen Tabelle kommunizieren. Diese funktioniert über die wpdb-Schnittstelle.

Eigene Tabelle für WordPress erstellen

Klar kann man die Tabelle für das eigene Plug-in auch von Hand erstellen, über phpMyAdmin oder eine andere Software, auch am Desktop-Computer. Wer sich auskennt, kann dazu auch einfach die mysql-Schnittstelle auf dem Server mittels Terminal verwenden. Doch bei einem Plug-in geht es ja um die Wiederverwendbarkeit und die Möglichkeit, dass auch andere Nutzer damit arbeiten können.

Entsprechend nutzen wir die WordPress-eigenen Mittel, um die Tabelle zu erstellen. Der beste Zeitpunkt dafür ist übrigens beim „Aktivieren“ des Plug-ins. Wie im ersten Teil dieses Tutorials schon beschrieben, trennt WordPress zwischen dem Aktivieren, Deaktivieren und Deinstallieren. Dafür gibt es extra drei passende „Auslöser“, die wir uns zunutze machen können.

In unserem Fall benötigen wir eine Tabelle, die lediglich drei Reihen umfasst, eine fortlaufende Nummerierung (ID), eine Suchphrase (searchstring) und ein Schlagwort (keywordstring). Um in mySQL eine Tabelle mit dieser Struktur einzurichten, benötigt man folgenden Code:

CREATE TABLE XYZ (
		id mediumint(9) NOT NULL AUTO_INCREMENT,
		searchstring varchar(25) NOT NULL,
		keywordstring varchar(25) NOT NULL,
		UNIQUE KEY id (id),
	    UNIQUE KEY searchstring (searchstring)
	) ZEICHENSATZ;

Wir müssen der Tabelle noch einen Namen geben und auch einen Zeichensatz angeben. Da aber durch die Installation von WordPress je nach Konfiguration von WordPress ein Zeichensatz genutzt wird, und wir uns nicht den Kopf darüber zerbrechen wollen, welcher das ist, verwenden wir einfach $wpdb->get_charset_collate() (vgl. WordPress Code-Referenz), um den Zeichensatz abzufragen.

Ja, und auch bei der Namensgebung für die Tabelle, wollen wir uns zumindest an die Gepflogenheiten halten und greifen daher auf das Präfix zurück, das WordPress uns anbietet, und Nutzer bei der Installation individuell einrichten können ($wpdb->prefix). Unsere Tabelle nennen wir dann noch sn_add_keywords, die entsprechend mit dem Präfix von WP ausgestattet wird.

Tabelle bei Plug-in-Aktivierung einrichten

Nun gehen wir davon aus, dass wir die Tabelle beim Aktivieren des Plug-ins einrichten möchten. Wir greifen dazu also auf den register_activation_hook() (vgl. WordPress Code-Referenz) zurück.

Dieser Aufruf hat zwei Parameter. Der erste nennt den Dateinamen des Plug-ins inklusive Pfadangabe. Dafür gibt es glücklicherweise eine Konstante namens __FILE__, die uns die Arbeit erleichtert, wenn wir uns an die Konventionen halten und unser Plug-in auch im Plug-in-Verzeichnis unterbringen. Der zweite Parameter ruft eine Funktion auf, die dann zum Zeitpunkt der Aktivierung des Plug-ins aktiv wird.

Wir erstellen also eine Funktion, die uns die Tabelle erstellt. Die sieht wie folgt aus:

function sn_add_keywords_create_database() {
  global $wpdb;
  $charset_collate = $wpdb->get_charset_collate();
  $table_name = $wpdb->prefix . 'sn_add_keywords';

  $sql = "CREATE TABLE $table_name (
		id mediumint(9) NOT NULL AUTO_INCREMENT,
		searchstring varchar(25) NOT NULL,
		keywordstring varchar(25) NOT NULL,
		UNIQUE KEY id (id),
    UNIQUE KEY searchstring (searchstring)
	) $charset_collate;";

	require_once( ABSPATH . 'wp-admin/includes/upgrade.php' );
	dbDelta( $sql );
}

Die rufen wir dann mit dem passenden Auslöser auf:

register_activation_hook(__FILE__, 'sn_add_keywords_create_database');

Tabelle bei der Deinstallation löschen

Man könnte die Tabelle theoretisch auch beim Deaktivieren schon löschen. Aber das erachten wir für nicht sinnvoll. Bei der Deinstallation eines Plug-ins sollte man aber sehr wohl darauf achten, hinter sich sauberzumachen. Wir setzen in dem Fall den register_uninstall_hook() ein. Der funktioniert analog zum Aktivierungsauslöser und hat die gleichen beiden Parameter. Wir erstellen also eine Funktion, die die Datenbank löscht:

function sn_add_keywords_remove_database() {
  global $wpdb;
  $table_name = $wpdb->prefix . 'sn_add_keywords';
  $sql = "DROP TABLE IF EXISTS $table_name";
  $wpdb->query($sql);
}

Diese rufen wir dann mit dem Auslöser wie folgt auf:

register_uninstall_hook(__FILE__, 'sn_add_keywords_remove_database');

Wie kommuniziert unser Plug-in mit der Datenbank?

Wie man mittels WordPress-Funktionen mit der Datenbank kommuniziert, haben wir schon angeschnitten. Aber damit unser Plug-in, das ebenfalls kann, benötigt es ein Formular.

Zudem können wir an dieser Stelle noch ein paar Sicherheitsvorkehrungen treffen. Anders als bei einem Formular zur Anmeldung beim Newsletter, wollen wir vermutlich nur Personen Schlagworte hinzufügen lassen, denen wir vertrauen. Auch müssen wir sicherstellen, dass in der Datenbank nichts „Bösartiges“ gespeichert wird. Aus diesem Grund nutzen wir die wordpress-eigenen Befehle für die Datenbankkommunikation, weil manche von ihnen bereits Sicherheitsmechanismen enthalten, und wir so ein bisschen beruhigter sein können. Doch, der Reihe nach.

Formular für die Datenbankeingabe erstellen

An dieser Stelle kann man ohne Umschweife zunächst einmal ein einfaches Formular in HTML erstellen. Wir benötigen zwei Eingabefelder für Text, eventuell noch zwei Etiketten und einen Button (oder Link) zum Absenden des Formulars. Der Einfachheit halber – weil es funktioniert, und um schnell erste Ergebnisse zu erhalten – verwenden wir keine spezielle Aktion zum Auslösen, und nutzen die POST-Methode.

Unser HTML-Formular sieht wie folgt aus:

<form method="POST">
	<?php wp_nonce_field('sn_add_keywords', 'sn_add_keywords_nonce', true, true); ?>
    <h2>Neuen Eintrag hinzufügen:</h2>
    <label for="searchstring">Searchstring:</label>
    <input type="text" id="searchstring" name="searchstring" required>
    <label for="keywordstring">Keywordstring:</label>
    <input type="text" id="keywordstring" name="keywordstring" required>
	<?php submit_button('Hinzufügen'); ?>
</form>

Die submit_button()-Funktion stellt WordPress zur Verfügung. In Klammern übergeben wir die Beschriftung für den Button. Der Button erhält dann auch die typischen Klassen, damit er mittels CSS automatisch in der für WordPress typischen Kolorierung und Form erscheint. Wer das individuelle handhaben mag, kann natürlich einen eigenen Button erstellen.

Was ist dieses Nonce, und wieso brauche ich sie?

Im obersten Feld des Formulars erkennt Ihr den Befehl wp_nonce_field(), den WordPress ebenfalls zur Verfügung stellt. Die „Nonce“ (vgl. Wikipedia) ist eine flüchtige Phrase, die zum Zwecke der Authentifizierung erstellt wird.

WordPress bietet dieses System ebenfalls an. Es ist sehr hilfreich, wenn man die Kommunikation mit der Datenbank nur authentifizierten Nutzern zu ermöglichen. Denn die Nonce wird beim Aufruf erzeugt und ist dann nur in der Session des Nutzers gültig. Würde jemand, der gar nicht mit WordPress eingeloggt ist, versuchen die Funktion auszuführen, scheiterte die Kommunikation daran, dass er nicht die korrekte „Nonce“ dafür hat.

Wir werden dann die erstellte Nonce noch überprüfen, bevor wir tatsächlich in die Datenbank schreiben.

Formular-Daten in die Datenbank schreiben

Nun müssen wir uns also noch darum kümmern, die im Formular eingegebenen Daten beim Klick auf den Button in die Datenbank zu speichern. Wie machen wir das?

Zum einen haben wir ja geschrieben, dass die Daten mittels POST-Methode übergeben werden. Sie sind dann entsprechend über die POST-Variablen auslesbar. Mit dem Nonce-Field erzeugt WordPress aber noch ein unsichtbares Feld mit dem Authentifizierungstoken. Auch der ist dann als POST-Variable abfragbar und lässt sich so vergleichen.

Für das Schreiben in die Datenbank, kann man entweder ein eigenes QUERY and $wpdb übergeben, oder wir nutzen den von WordPress implementierten $wpdb->insert()-Befehl.

if(is_admin() && (isset($_POST['sn_add_keywords_nonce']) || wp_verify_nonce($_POST['sn_add_keywords_nonce'], 'sn_add_keywords'))) {
	global $wpdb;
	$table_name = $wpdb->prefix . 'sn_add_keywords';
	$newdata = array(
        'searchstring' => sanitize_text_field($_POST['searchstring']),
        'keywordstring' => sanitize_text_field($_POST['keywordstring']),
      );
    $wpdb->insert($table_name, $newdata, '%s');
    wp_safe_redirect(esc_url(admin_url('admin.php?page=sn_add_keywords%2Fsnak.php')));
}
exit();

Über den Befehl wp_safe_redirect() leiten wir nach dem Absenden den Benutzer wieder zurück zur Ausgangsseite. Diese Vorgehensweise hat übrigens einen Nachteil, den wir in Kauf nehmen, der aber für ein frei verfügbares Plug-in ausgebessert werden sollte, zum Beispiel, indem man AJAX verwendet.

Zuletzt stellen wir über den exit()-Befehl sicher, dass wirklich alle POST-Variablen nach dem Abschluss gelöscht werden. So wird das Formular geleert und auch eine neue Nonce erstellt.

Das Plug-in, wie wir es verwenden sieht bei uns dann übrigens derzeit so aus.

Was wir nicht erzählt haben?

Auch dieser Beitrag ist schon wieder ziemlich lang geworden. Deshalb haben wir einige Details geschlabbert. Darunter:

• Denn in unserem Plug-in haben wir beispielsweise bei der Aktivierung auch eine Versionsnummer übergeben. Die können wir dann bei einem Update vergleichen und nutzen, um so Änderungen an der Datenbank vorzunehmen.
• Wir haben aber auch unterschlagen, dass wir unsere Tabelle beim Aktivieren bereits mit ein paar Datensätzen ausgestattet haben. Ich finde es immer schöner, wenn man zumindest ein paar Anhaltspunkte hat.
• Es kann außerdem sinnvoll sein, die Daten nicht zu löschen, oder dies dem Nutzer zur Wahl zu stellen. Um so eine Option haben wir uns bislang nicht gekümmert.
• WordPress hält auch Alternativen zu den „Auslösern“ bereit. So kann man Dateien namens uninstall.php oder activation.php erstellen. Deren Inhalte werden dann automatisch ausgeführt.
• Wie Ihr auf dem Screenshot erkennen könnt, geben wir die vorhandenen Datensätze auch im WordPress-Administrationsportal aus. Wie wir das gemacht haben, haben wir an dieser Stelle ebenso geschlabbert.
• Nicht thematisiert haben wir den Prozess, wie man ein Plug-in bei WordPress einreicht. Vielleicht kommt das in einem anderen Beitrag einmal zur Sprache, oder Ihr findet es bis dahin selbst heraus.
• Spannend ist auch, wie man bereits vorhandene Daten wieder löscht, oder überarbeitet.
• Der Quellcode hier enthält auch kein CSS und gibt ganz grundsätzlich nicht das komplette Plug-in wieder, wie wir es verwenden. Zum Zwecke des Tutorials habe ich diesen angepasst, damit er allgemein verständlicher wird.

Tatsächlich ist diese „Idee“, aus der erst eine Handvoll Quellcode wurde, in unserem Fall mittlerweile auf fünf Dateien mit rund 250 Zeilen Quellcode angewachsen (Kommentare inklusive).

Wenn jemand von Euch Fragen zu diesem Projekt hat, kann er uns gerne auf den üblichen Kanälen anschreiben.

Der Beitrag Von der Idee zum WordPress-Plug-in: Schlagwörter automatisch hinzufügen #2 erschien zuerst auf Macnotes.de.

Marco Dengel machte sich die Mühe mit der Scriptable-App ein Widget anzufertigen, das den Restbestand an Klopapier in einem DM-Drogeriemarkt anzeigt. Möglich macht dies eine Produkt-API, an der man die Verfügbarkeit abfragen kann.

Ihr benötigt dafür in jedem Fall ein iPhone, iPad oder einen iPod touch mit iOS 14 oder neuer und die App Scriptable in Version 1.5 oder neuer.

Quellcode in die Scriptable-App eintragen

Marco Dengel stellt den Quellcode freundlicherweise auf Github bereit. Diesen Quellcode müsst Ihr lediglich in die Scriptable-App am iPhone eingeben.

Was ist Scriptable?

Scriptable ist eine App, die Euch ermöglich mittels Javascript Aufgaben am iPhone (oder andernorts) auszuführen. Ihr könnt Euch dann zum Beispiel über Benachrichtigungen informieren lassen, wenn Euer Webserver nicht erreichbar ist, oder wenn, wie in diesem Fall, bei DM das Klopapier knapp wird.

Wie werden die Daten abgefragt?

DM stellt dazu offenbar eine API bereit und diese fragt Dengel in seinem Code mittels JSON-Objekt ab, wertet die Informationen aus und gibt sie über das Widget aus.

Widget installieren

Ihr geht folgendermaßen vor, wenn Ihr das Klopapier-Widget installieren möchtet:

1. Öffnet die passende Github-Seite auf Eurem iPhone.
2. Klickt dann auf die „RAW“-Anzeige. Markiert und kopiert den Text. Wenn Euer Mac und iPhone oder iPad neu genug sind, könnt Ihr den Quellcode auch am Mac in die geteilte Zwischenablage kopieren und dann trotzdem am iOS-Gerät einfügen.
3. Öffnet Scriptable.
4. Tippt dort auf das Plus-Symbol und fügt ein Script hinzu.
5. Kopiert dann den Quellcode in das Editorfenster.
6. Gebt dem Kind noch einen Namen und speichert es.
7. Öffnet dann Euren Home-Bildschirm am iPhone oder iPad. Haltet dort ein Programm-Icon länger gedrückt, bis der Dialog erscheint, in dem Ihr „Home-Bildschirm bearbeiten“ auswählen könnt.
8. Tippt nun auf das Plus-Symbol oben links, um ein Widget hinzuzufügen. Scrollt ein wenig herunter, um Scriptable auswählen zu können und fügt ein Widget hinzu.
9. Solange die Icons noch am Wackeln sind, tippt auf das neue Widget. Ihr könnt nun Einstellungen vornehmen, bspw. das Script auswählen, als Ausführart „Run Script“ und als Parameter müsst Ihr die ID des Ladengeschäfts Eurer Wahl angeben.
10. Fertig!

Wie finde ich die ID meines DM-Ladengeschäfts?

Öffnet den „Store Finder“ auf der Webseite von DM. Tippt dann in der Ergebnisliste auf „weitere Details“. Während die Übersichtskarte sich verändert, passt DM aber auch die URL an. In der URL seht Ihr dann die ID Eures Ladengeschäfts.

Beispiel: Ein DM bei uns in der Nähe hat die ID 2764, die sich aus dem URL https://www.dm.de/store/de-2764/niederzier/rurbenden-2 ergibt.

Wie korrekt ist die Anzeige?

Marco Dengel hat in seinem Script alle Klopapier-Sorten fest programmiert, filtert aber das „feuchte“ Klopapier heraus. Wenn Ihr ein wenig Ahnung von Javascript habt, oder zumindest der englischen Sprache mächtig seid, könnt Ihr das Script schnell so anpassen, dass ein anderes Produkt abgefragt wird, Babywindeln vielleicht, oder Tofu, oder nur eine spezielle Sorte Klopapier.

Ist das nicht illegal?

DM stellt die API bereit, entsprechend ist es nicht illegal sie abzufragen. Aber vermutlich hat der Drogeriemarkt-Betreiber die API nicht für diese Zwecke erdacht. Sollte es DM irgendwann zu viel Datenaufkommen sein, könnte der Anbieter sich entscheiden, die API nur noch privat mit passenden Schlüsseln anzubieten. Dann wäre das Widget hinfällig. Aber solange können wir uns daran erfreuen.

Vielen Dank an Marco Dengel für diese sinnvolle Verwendung von modernster Technik. ;)

Klopapier per Terminal abfragen

Um eine Abfrage einfach per Terminal in Windows, macOS oder Linux zu starten, reicht der folgende Befehl:

curl -s "https://products.dm.de/store-availability/DE/availability?dans=595420,708997,137425,28171,485698,799358,863567,452740,610544,846857,709006,452753,879536,452744,485695,853483,594080,504606,593761,525943,842480,535981,127048,524535&storeNumbers=2764" | jq '[.storeAvailabilities[][0].stockLevel] | add'

Ihr müsst ganz am Ende natürlich auch die Store-ID anpassen. Amüsant ist, wenn Nutzer dies nun noch automatisieren und regelmäßig den Stand diverser Ladengeschäfte abfragen.

Der Beitrag Gibt es noch Klopapier bei DM? Widget fürs iPhone weiß Rat erschien zuerst auf Macnotes.de.

Wichtig ist zu erwähnen. Es gibt in der Regel mehrere Möglichkeiten, das Ziel zu erreichen. Zum Beispiel könntet Ihr einfach die vorhandenen CSS-Klassen nutzen und denen zusätzliche Einheiten und Werte zuordnen.

Doch vielleicht arbeitet Ihr mit einem CSS-Framework, das regelmäßig aktualisiert wird, und möchtet einfach von dessen Stilvorlagen profitieren.

Tablepress eine CSS-Klasse hinzufügen

Wir verwenden momentan das CSS-Framework Bulma. Dort gibt es unter anderem die Klasse „table“ für Tabellen. Tablepress aber nutzt seine eigene Klasse „tablepress“. Die Recherche nach Lösungen, wie man eine weitere Klasse hinzufügen kann, lieferte nur unzureichende Ergebnisse. Deshalb war es an der Zeit, selbst aktiv zu werden. Wir präsentieren Euch in der Folge gleich zwei mögliche Lösungen.

Der einfache Weg: Javascript

Ich habe in den letzten Monaten Javascript zu schätzen gelernt.² Über die Konsole im Browser kann man nämlich direkt mit der Webseite interagieren und kann auf einfachste Weise schnell Änderungen vornehmen.

So auch in diesem Fall. Ihr sucht also einfach nach dem Element, das Ihr verändern wollt. Da Tablepress die Klasse „tablepress“ seinen Tabellen hinzufügt, habt Ihr es einfach, denn über document.getElementsByClassName('tablepress') könnt Ihr die Tabelle im Text finden. Auf diese Weise erreicht Ihr eine HTML-Kollektion, denn es sind ja in der Regel noch Inhalte in der Tabelle. Mit [0] wählt Ihr, vergleichbar wie bei einem Array, das erste Resultat aus. Das könnte man auch in einer Variable speichern, muss man aber nicht, sondern kann es direkt „manipulieren“.

Javascript erlaubt Euch dazu mit classList auf die vorhandenen Klassen zuzugreifen und über add() könnt Ihr direkt eine oder mehrere Klassen hinzufügen. Das sieht dann wie folgt aus:

document.getElementsByClassName('tablepress')[0].classList.add('table');

Ressourcen schonen

Wir sind aber noch nicht am Ende. Denn ich lagere solchen Javascript-Code meist in den Footer aus, damit er das Laden der Seite nicht blockiert. Doch Ihr könnt auch noch abfragen, ob der Text überhaupt eine solche Tabelle enthält. Dafür stellt WordPress ja die Funktion (vgl. WordPress-Codex) has_shortcode() zur Verfügung. Ihr ladet also den obigen Code nur dann, wenn der Nutzer überhaupt eine Tabelle sieht. Damit wird er auf anderen Seiten ohne Tabelle gar nicht erst geladen. Und weil Tabellen auch nicht auf Archiv-Seiten oder der Startseite und in Suchergebnissen gezeigt werden, eignet sich noch eine weitere Funktion (Conditional Tag) namens is_singular() (vgl. WordPress-Codex). is_singular() berücksichtigt im Vergleich zu is_single() auch Seiten und eben nicht nur Beiträge. Da wir auf Seiten auch Tabellen von Tablepress einsetzen, ist das in dem Fall sinnvoll.

Die komplette Integration sieht dann am Ende wie folgt aus:

<?php if (is_singular()) {
if(has_shortcode( $post->post_content, 'table')) { ?>
<script>
	document.getElementsByClassName('tablepress')[0].classList.add('table');
</script>
<?php }
} ?>

Warum ist dies der „einfachere“ Weg? Nun, weil ich das binnen weniger Minuten in der Konsole des Browsers ausprobieren kann und so direkt zum Ziel komme.

Veränderungen am Quellcode kann man so sehr einfach vornehmen und austüfteln.

Einschränkungen (und Lösung): Mehr als eine Tabelle

In dem hier gegebenen Beispiel gehen wir davon aus, dass man nur eine Tabelle nutzt. Wer sich ein wenig mit Javascript auskennt, kann aber auch die Vorkommnisse mehrerer Tabellen berücksichtigen und dann mit einer Schleife die Klasse in allen hinzufügen. Das Ergebnis der „Suche“ ist eine „HTMLCollection“, also kein Array. Doch weil diese Element sich ähneln, hält Javascript eine Funktion Array.from() bereit, um so eine Sammlung in ein Array zu verwandeln. Auf diese kann man dann eine forEach-Schleife anwenden. Der Vollständigkeit halber präsentieren wir auch diesen Code:

<?php if (is_singular()) {
if(has_shortcode( $post->post_content, 'table')) { ?>
<script>
var tables = document.getElementsByClassName('tablepress');
Array.from(tables).forEach(addClass);
function addClass(table) {
	table.classList.add('dodoBingo');
}
</script>
<?php }
} ?>

Der nicht viel schwierigere Weg: PHP

„Schwieriger“ ist in diesem Zusammenhang vermutlich das falsche Attribut. Denn es war eher „aufwändiger“ an die Lösung mittels PHP zu gelangen.

Der Dampfhammer wäre gewesen, den $content zu manipulieren. Aber es gibt andere Mittel und Wege, die auch ein wenig den Entdeckergeist wecken können. WordPress bietet sogenannter „Hooks“ und „Filter“ (vgl. WordPress-Codex). Plugin-Entwickler, gerade von komplexeren Plugins, machen von diesen ebenfalls Gebrauch, um unterschiedliche Situationen zu kreieren. Sie selbst nutzen dann diese Hooks und Filter, um die Ausführung des Plugins zu manipulieren, je nachdem, was der Nutzer eingegeben hat. Blöderweise sind diese Hooks und Filter der Plugins aber kaum wirklich durch die Entwickler dokumentiert.

Entdeckungsreise im Quellcode

Bei Tablepress sieht der Entwickler einige Anwendungen vor und beschreibt diese aber nicht. Er gibt ein paar Beispiele und erklärt ansonsten, dass der „Quellcode viele davon enthielte“.

Also öffnen wir ein Terminal und schauen uns an, ob denn nicht eventuell sogar ein Filter dabei ist, der die Ausgabe nach unseren Wünschen verändern kann. Dazu eignet sich z. B. der Befehl grep. Wir navigieren also ins Plugin-Verzeichnis.³ Da wir nicht wissen, in welcher Datei die Filter enthalten sind, und das Plugin aber Unterverzeichnisse hat probieren wir es mit grep -r 'apply_filters' .. Der Parameter „r“ steht für „rekursiv“ und arbeitet auch alle Unterverzeichnisse ab. Der „Punkt“ am Ende sagt der Funktion, dass sie in dem aktuellen Verzeichnis starten soll.

Tatsächlich spuckt die Suche einige Ergebnisse aus. Voran steht immer auch der Dateiname und das etwaige Verzeichnis. Tablepress verfügt also über einen Filter (im Bild markiert), den wir gebrauchen können. Scheinbar gibt es einen Filter namens tablepress_table_css_classes.

Ich habe dann die Datei „class-render.php“ geöffnet und nach der betroffenen Zeile gesucht. In deren Umfeld habe ich geschaut, wie der Entwickler den Filter selbst einsetzt. Man stellt dann schnell fest, dass er ein „Array“ mit Klassennamen konstruiert und dieses übergibt. Das ist ganz wichtig. Denn damit der Filter unsere Eingabe versteht, müssen wir sie auch als Array übergeben. Gesagt, getan.

Der Quellcode kommt in die functions.php und wir können uns die Abfrage sparen, ob der Text auch den Shortcode enthält. Tatsächlich würde, wenn wir so weit sind, die Tabelle schon gerendert sein, und wir können dann nichts mehr (außer eben mit Javascript) verändern. Wir greifen mit einem add_filter() (vgl. WordPress-Codex) zu einem früheren Zeitpunkt der Ausführung ein und fügen die Klasse wie folgt hinzu.

add_filter( 'tablepress_table_css_classes', function($css){
  $css[] = "table";
  return $css;
});

Der Einfachheit halber haben wir eine anonyme Funktion genutzt, die als Rückgabewert ein Array hat.

Apply und Add gehören zusammen

Die Entdeckungsreise haben wir nach apply_filters() unternommen. Denn damit wird im Plugin etwas verändert. Doch so eine Funktion hat eben das Gegenstück add_filter(). Damit übergebt Ihr quasi dem Filter etwas, das er berücksichtigen soll. Tatsächlich nutzt Tablepress selbst den tablepress_table_css_classes Filter nirgendwo selbst aktiv, aber es hat sich eben an dieser Stelle „erweiterbar“ gemacht.

Klassen zu Tablepress hinzufügen

Auf die oben beschriebenen Weisen könnt Ihr nun Klassen zu Tablepress hinzufügen, wahlweise mit ein bisschen Javascript, oder eben direkt mit PHP. Mit Javascript leistet der Browser die Arbeit, mit PHP der Server.

Solltet Ihr komplexere Änderungen vornehmen wollen, empfiehlt es sich, dies in jedem Fall mit PHP zu machen. Aber für „Kleinigkeiten“ ist Javascript auf die Schnelle immer geeignet. Vor allem könnt Ihr es auch als Übergangslösung einsetzen, bis Ihr die andere fertigstellen könnt. Ein „Hotfix“ sozusagen.

1. Langfristig wollen wir ein eigenes System von Apps im Web und auf Smartphones und Desktops sowohl für Nutzer als auch Autoren etablieren. ↩︎
2. Lustig aber wahr, denn 1998 registrierte ich meine erste Domain und schon Mitte der 90er baute ich eigene Webseiten auf Geocities. Trotzdem brauchte es 25 Jahre, ehe ich die Einfachheit erkannte, schnell Ergebnisse zu erzielen. ↩︎
3. Ich habe vergessen zu erwähnen, dass ich eine lokale WordPress-Installation nutze, um die Webseite zu entwickeln. ↩︎

Der Beitrag WordPress: CSS-Klasse zu Tablepress hinzufügen (mit Javascript oder PHP) erschien zuerst auf Macnotes.de.

Denn letzten Sonntag hab ich das Gröbste für einen Kundenauftrag erledigt und widme mich seitdem auch einem neuen Layout/Theme für Macnotes. Natürlich mache ich damit auf den ersten Blick tolle Fortschritte. Denn man hat „schnell mal“ was zusammengeschustert. Mir kommt es aber auch aufs Detail an und es gibt genügend Fallstricke, die über Wohl und Wehe entscheiden können.

Ich bin jedenfalls froh, dass ich Euch aktuell zeigen kann, was ich in der kurzen Zeit seit vergangenen Sonntag auf die Beine gestellt habe.

Neues Design in mehreren Phasen

Entsprechend werde ich aber trotzdem die Kirche zunächst im Dorf lassen und versuchen die Funktionalität von Macnotes jetzt nachzubauen, und aber den Schnickschnack für später übrig zu lassen. Beispielsweise möchte ich mittels Javascript Inhaltsverzeichnisse implementieren, wo dies angebracht erscheint, oder aber auch eine eigene Bildergalerie und womöglich auch ein Glossar etablieren. Das muss aber noch ein wenig warten.

Die neue Startseite

Stand heute habe ich die neue Startseite bereits „fertig“. Es fehlen dort im Prinzip Änderungen im Detail.

Die neue Startseite wird allerdings ein wenig von allem enthalten. Also aus bestimmten Kategorien die Inhalte bereitstellen. Sie erhält dafür keine Seiten-Navigation zum Blättern. Denn meines Erachtens ist sie dafür nicht gedacht.

Sehr wohl möchte ich aber mittelfristig auch die Usability erhöhen und habe damit bereits begonnen. Denn jeder Abschnitt der Startseite enthält eine Navigation, über die man zu den Abschnitten springen kann. Ein kleines Detail ist, dass das Pfeil-Symbol immer auch in die Richtung zeigt, in der sich der Bereich befindet (und selbstredend ist der sichtbare Bereich nicht gleichzeitig Teil der Navigation).

Sieht man mal vom Bild ab, das in meiner Entwicklungsumgebung fehlt, bin ich derzeit damit ganz zufrieden.

Die neue Artikelseite

Die neue Artikelseite zeigt, dass man ein Design nicht einfach so aus der Taufe heben kann. Sie gefällt mir noch nicht (ganz). Abstände und Details passen irgendwie noch nicht zusammen und wirken noch unrund. Aber zumindest kann sie sich trotzdem sehen lassen.

In der Seitenleiste gibt es zugehörige Firmen, Events, Plattformen, Personen und Produkte, wenn denn welche ausgewählt sind. Die Event-Seiten beispielsweise enthalten ihrerseits Links zu Nachrichten über das Event. So könnt Ihr dann bei der kommenden WWDC 2021 schon alle Meldungen an einer Stelle abrufen.

Am unteren Ende gibt es eine Vor- und Zurück-Navigation und außerdem „ähnliche Nachrichten“. Diese sind „hausgemacht“. Denn ich habe für WordPress und auch auf Macnotes schon vor Jahren eine zusätzliche Taxonomie eingerichtet, die jedoch unsichtbar ist. Ich frage dann Beiträge ab, die über gleiche „Keywords“ verfügen und gebe sie aber außerdem per Zufall wieder. Auf diese Weise möchte ich sowohl die Themenzugehörigkeit sicherstellen als auch die Neugier von Euch befriedigen. Denn vielleicht gibt es ja noch etwas zu lesen, das Ihr noch nicht kennt. Und also werden bei einem Seitenabruf regelmäßig neue ähnliche Beiträge angezeigt. Wie ich das technisch umgesetzt habe, darüber werde ich Euch auch „später“ (alias irgendwann und nicht heute) noch informieren, sodass Ihr das auf Euren Webseiten womöglich nachmachen könnt.

Auch hier fehlen bei meiner lokalen Installation einige Bilder, aber das soll Euch nicht weiter stören, weil es, wenn das neue Design live geht, anders sein wird.

Das neue Archiv

Auch für das/die Archiv(e) habe ich bereits angefangen ein neues Design anzulegen. Natürlich bekommen außerdem die Archive eine Seitennavigation. Denn dort macht sie Sinn.

Beim Überfahren der Bilder nutze ich CSS-Effekte, die ich leider im Standbild nicht wiedergeben kann. Aber auch das ist etwas, das ich Euch „später“ noch im Detail vorstelle, damit Ihr es eventuell auf Eurer Webseite nachmachen könnt.

Wenn ich allerdings „Effekte“ benutze oder Funktionen umsetze, dann möchte ich diese mit möglichst wenig Ressourcen am Browser einrichten. Umso dankbarer bin ich, dass es mittlerweile auch CSS-Effekte und -Animationen gibt. Also ich mit dem Web Ende der 1990er anfing lauteten die HTML-Befehle noch ganz anders und steckte Javascript noch in den Kinderschuhen. Heute ist vieles wesentlich eingängiger als damals. Doch meine Devise lautet: Ich werde keine Javascript-Bibliothek installieren, nur weil es womöglich einfacher ist. Sieht man davon ab, dass WordPress von Haus aus JQuery lädt, nutze ich für meinen Alltag sogenanntes „Vanilla Javascript“, für das man keine zusätzlichen Dinge laden muss.

Was noch fehlt

Hier und da muss ich auf jeden Fall noch am Kontrast schrauben. Ich bin selbst rot-grün-fehlsichtig. Entsprechend sind mir manche Farbkombinationen leider ein Dorn im Auge und muss ich entsprechend nachbessern. Es ist auch nicht ausgeschlossen, dass ich im Zuge der Arbeiten die Schriftarten noch auswechsle.

In jedem Fall werden ich versuchen sie lokal auf dem Webserver abzulegen, damit auch in diesem Fall keine Kommunikation mit fremden Server stattfinden muss.

Macnotes hab ich im November 2019 gekauft, wie ich es vorgefunden habe. Entsprechend gibt es noch super viel zu tun. Aber es kommt jetzt wieder ein wenig mehr Fahrt in die ganze Geschichte, selbst wenn es „noch“ nicht danach ausschaut.

Was schon da ist: Responsivität

Ja und in einer Angelegenheit habe ich aber auf ein Framework gesetzt, und zwar ein CSS-Framework. Dabei wollte ich vor allem eines, das nicht zu viele Features bietet und von Haus aus eher einen kleinen „Fußabdruck“ hinterlässt. Mit Bulma denke ich, hab ich eine gute Alternative gefunden. Denn ich habe in der Vergangenheit auch mit anderen, deutlich größeren Frameworks gearbeitet, wie beispielsweise Bootstrap, Foundation oder Materialize. Ausprobieren möchte ich irgendwann auch noch Tailwind. Aber wenn man Fortschritte erzielen möchte, dann muss man Entscheidungen treffen, und also fiel die Wahl auf Bulma, weil es mir nicht ganz fremd war und ich die überschaubare Größe schätze.

In jedem Fall habe ich auch die „Responsivität“ im Blick. Ein Thema in diesem Zusammenhang sind natürlich auch die Überschriften oder Typographie im Allgemeinen. Denn es gibt zwar Lösungen, aber die sind entweder sehr komplex oder eben begrenzt einsatzfähig. Wie ich dieses Problem gelöst habe, werde ich auch an anderer Stelle explizit breittreten. ;)

So in etwa sieht dann das neue Macnotes auf dem iPhone aus: Also zumindest, wenn Google Euch keine AMP-Version liefert.

Mittelfristig möchten wir auch dafür eine eigenständige Lösung anbieten. Aber vermutlich macht es da mehr Sinn, gleich ein eigenes CMS zu programmieren, was durchaus auf unserem Schmierzettel als Idee vermerkt ist.

Falls Euch das Thema langweilt, habt Ihr hoffentlich nicht zu viel von dem Beitrag gelesen. Ansonsten sind wir auch gerne offen für Feedback schon zu diesem frühen Zeitpunkt, damit wir das neue Macnotes schon in der Entwicklungsphase optimieren können. Das ist auch der Grund, warum ich diesen Wasserstand loswerden wollte.

Der Beitrag Wasserstand #16: Es geht wieder weiter erschien zuerst auf Macnotes.de.

Wir wollten – ich möchte mit Macnotes eigentlich jeden Tag immer weiter sein, als wir es tatsächlich sind.

Tun, was man tun muss

Doch es gibt eben diese finanziellen Zwänge, die es notwendig machen, dass wir unsere Ideen in dem Maße verfolgen, wie es das Portmonee zulässt. Im November 2019 investierten wir einen ganzen Batzen unseres privaten Kapitals, um die Webseite aufzukaufen.

Wir wollten und wollen die Dinge anders machen. Das haben wir mehrfach artikuliert. Wir verzichten auf die große Werbung, aber im Umkehrschluss ist Macnotes – Stand heute – absolut nicht wirtschaftlich. Amazon wollte uns nicht im Affiliate-Programm, darüber hinaus ist AdSense ein Schatten seiner selbst und gibt es viele Aufräumarbeiten. Unter dem Strich kommt so im Monat meist nur ein niedriger dreistelliger Betrag zusammen.

Das ist „noch“ egal, denn wir sind in der Lage, unser Geld „anderswo“ zu verdienen. Tatsächlich portiere ich selbst aktuell ein uraltes Joomla 1.5 auf ein WordPress und benötige dafür viel PHP, Javascript und habe sogar ein eigenes Importscript in Ruby geschrieben, nachdem ich Zugriff auf die MySQL-Datenbank des Kunden erhielt. Diese Arbeit hält Macnotes natürlich auch auf, vor allem im Tagesgeschäft. Aber diese Arbeit bringt Macnotes auch etwas. Denn manche der Dinge, die ich für meine Kunden erledige, kann ich in Zukunft auch für Macnotes verwenden.

Gefährlich genug

Vielleicht kennt ihr die Situation, wenn man sich intensiv mit einer Sache befasst und am Ende so viel Know-how hat, dass man eigene, kreative Ideen entwickelt. Ganz gleich, ob’s ums Kochen, Basteln oder Programmieren geht. Genau das passierte mir unter anderem während meiner Arbeit an dem Joomla-Projekt für den Kunden. Denn ich musste mich sehr viel mit Javascript abgeben und weil ich aber nicht auf ein Framework vertrauen wollte, habe ich mit purem Javascript sehr sehr viele Lösungen gesucht und die allermeisten davon auch umgesetzt. Ob es um ein Akkordeon-Menü geht, ein rekursives Formular oder Register für ein Glossar.

Am Ende wollte ich aus einer Laune heraus einen eigenen einfachen Textersetzungsbefehl von TextExpander für die „Wayback Machine“ ausbauen. Dabei herausgekommen ist ein ausgewachsenes Formular in HTML und Javascript, mit dem ich mit der API des Internetarchivs interagiere. Dazu verbinde ich das Formular, empfange das Ergebnis als JSON-Objekt und verarbeite es dann. Wenn ich dann die Daten eintrage und den Button klicke, kopiert mir die „App“ (hust) das Ergebnis in die Zwischenablage. Damit habe ich gerade bei der Arbeit mit Macnotes eine riesige Erleichterung erlebt. Denn viele der Links von früher gibt es so heute nicht mehr.

Und weil ich ein Spielkind bin, aber auch Herausforderungen liebe, habe ich gar nicht lang darüber nachgedacht, sondern das Formular mittels CSS-Framework in Form gebracht. Außer mir hätte es bis dahin eigentlich niemand gesehen, doch nun zeige ich Euch das Ergebnis zumindest im Screenshot.

Ich möchte mittelfristig auch den Quellcode auf Github veröffentlichen und womöglich sogar ein WordPress-Plug-in daraus machen. Aber das sind Nebenkriegsschauplätze, die vielleicht auch nie zur Vollendung kommen. So ehrlich muss ich zu mir selbst sein. Denn ich habe jeden Tag mehr Ideen als der Tag Stunden.

Informationen sammeln und aufbereiten

Ich arbeite daran, Macnotes noch in diesem Jahr ein neues Layout zu verpassen. Allerdings ist der langfristige Plan vor allen Dingen, die Webseite mit Informationen auszurüsten. Teilweise tue ich das schon jetzt, selbst wenn es momentan noch „sch…“ ausschaut. Beispielsweise habe ich auf Seiten zu Veranstaltungen wie der WWDC 2008 die passenden Nachrichtenmeldungen dazu untergebracht. Das sieht dann wie folgt aus:

Taxonomien und Post Types

Gerne hätte ich auch schon früher Infos zu besonderen Themen eingebunden, beispielsweise zu Schlagwörtern wie „Coronavirus“. Da ich aber die alten „Schlagwörter“ offline nehme und eine und mehrere neue Taxonomien einrichte, möchte ich das Pferd nicht von hinten aufzäumen. Denn erst einmal braucht die Seite ein neues Layout, bevor ich anfange die Inhalte passend aufzubereiten.

Bei dem eingangs angesprochenen Kundenprojekt beispielsweise habe ich, ähnlich wie ich nur „reines“ Javascript einsetzen wollte, auch möglichst versucht, auf WordPress-Plug-ins zu verzichten. So habe ich am Ende selbst die Eingabeoberfläche für einen Custom Post Type mit Metaboxen erstellt und dann mittels Javascript dem Nutzer die Möglichkeit bereitgestellt, neue Felder „on the fly“ hinzuzufügen. Dabei musste ich einmal mehr feststellen, dass WordPress doch leider so ein Umstandskasten ist. Ich verstehe nicht, warum das System Metadaten als „serialisierte Objekte“ speichert, anstatt von echten JSON-Objekten oder alternativ Arrays. Aber irgendwas werden sich die Entwickler schon dabei gedacht haben.

Diese ganzen Erkenntnisse möchte ich auf Macnotes irgendwann auch mit Euch teilen, wahrscheinlich in Form von Tutorials, wie Ihr gewisse Dinge nachbauen könnt. Denn es gibt eine Menge Dinge, die ich gelernt habe, nicht nur was PHP oder Javascript angeht, sondern auch Ruby, SEO, CSS und so fort.

Von Stöckchen auf Retro-Steinchen

Ein Thema, das Ihr auf Macnotes „irgendwann“ auch vermehrt erleben werdet, ist das Thema Retro. Denn ich habe auch da vieles ausprobiert und zum Beispiel einen Basic-Interpreter für den Mac wie QB64 ausprobiert, einige eigene Programme dafür geschrieben.

Nur Retro heißt bei mir nicht nur Theorie, sondern auch Praxis. Die elektronische Bucht, wie Wolfgang Rudolph sie oft nennt, bescherte mir zuletzt beispielsweise einen Atari 1040 STF samt Monochrom-Monitor, aber auch einen C64C samt 5,25 Zoll Disketten-Laufwerk.

Ich denke, dass einige von Euch diese Leidenschaft für die Nostalgie teilen und letztlich kann man aus der Beschäftigung mit der Vergangenheit auch für die Zukunft lernen. Dass ich übrigens keinen Amiga ersteigert habe, liegt nur zum Teil an mir. Ich hatte es vor, aber die Preise gingen regelmäßig durch die Decke. Aber ich liege auf der Lauer und hätte nichts dagegen, wenn ich dann auch irgendwann einen Amiga in meine Sammlung aufnehmen kann. Denn alte DOS-PCs besitze ich schon zu Genüge.

Das Schöne ist auch immer wieder, wie man das Alte mit dem Neuen verbinden kann. Denn es gibt ja da diese Arduinos und Raspberrys, mit denen man alte Retro-Konsolen beleben kann, oder eben die Heimautomatisierung steuern. Auch darüber möchte ich schreiben.

Weiter, immer weiter

Nun habe ich Euch wieder ein wenig den Mund wässrig gemacht, kann aber leider noch nichts liefern. Ich muss erst das erwähnte Projekt beenden, bevor ich wieder mehr Zeit in Macnotes investieren kann. Dass ich mir trotzdem die Nächte für das Projekt um die Ohren schlage zeigt mir selbst, dass ich ein klein wenig verrückt bin, aber eben auch voll hinter dem Projekt stehe. Denn gegenüber dem letzten Wasserstand habe ich vorgestern einen Haken unter die Beiträge aus Juli 2008 gemacht.

Wenn zwischendrin außerdem noch Tests wie der zum Magic Keyboard fürs iPad Pro abfallen, und Apple weiter fleißig neue Produkte veröffentlicht, dann bin ich guter Dinge, dass wir uns gemeinsam auf die erste digitale WWDC 2020 im Juni freuen können. Es bleibt spannend!

Der Beitrag Wasserstand #12: PHP, Javascript und viel Arbeit erschien zuerst auf Macnotes.de.

Im März 2008 überarbeiteten die damaligen Besitzer von Macnotes die Webseite. Sie führten eine Rubrik ein, die Kurznachrichten bedient. Die tauchten im Layout gar nicht direkt in der Hauptsortierung auf. Vielmehr gab es damals eine Seitenleiste, in der die Kurznachrichten auftauchten.

Darüber, dass ich diesen Thin Content einfach lösche und auf die Qualitätssicherungsseite weiterleite, schrieb ich schon im letzten Wasserstand. Doch der war mehr ein Gedächtnisprotokoll und ich hatte gerade keinen Screenshot zur Hand. Da ich nun im Mai 2008 auf weitere „dünne“ Inhalte treffe, hab ich mir gedacht, dokumentiere ich doch einfach, wie dünn diese Inhalte tatsächlich sind.

Thin Content wirklich sehr dünn

Im Screenshot könnt Ihr gleich drei Sätze sehen. Der Link hinter dem Wort Apple geschieht automatisch, mit Hilfe eines Plug-ins, das Stefan Keller und ich vor Jahren entwickelten. Manchmal, wenn Inhalte ein bisschen zu kurz geraten sind, gehe ich bei meiner Aufarbeitung auch hin, und besuche die alten Quellen und schreibe neue Informationen in die Beiträge. Ja, das kostet Zeit. Doch in Fällen wie diesem im Beispiel mache ich mir die Mühe nicht. Mir liegt keine Quelle vor und die Suche danach würde am Ende mein primäres Ziel viel zu weit verzögern.

Letztlich möchte ich alle über 35.000 Beiträge bei Macnotes auf eine gemeinsame Datenbasis packen, bevor wir mit der Webseite anfangen „ganz andere“ Dinge anzustellen. Bis dahin müsst Ihr Euch leider ein wenig gedulden.

Dubletten seit 2008 an der Tagesordnung

Auch über Dubletten schrieb ich im letzten Wasserstand. Im März und April 2008 gab es „ein paar“. Doch im Mai gab es deutlich mehr. Denn im Mai gab es auch vielmehr Inhalte auf iPhonenotes, einer Webseite von Andre S., die zu einem späteren Zeitpunkt in Macnotes aufging.

Manche der Inhalte von iPhonenotes behalte ich, andere führe ich mit Inhalten von Macnotes zusammen. Ich hoffe natürlich auch, dass unter dem Strich viel wertiger Content übrig bleibt. Letztlich kümmerte sich damals niemand darum und umso wichtiger ist es, dass man endlich Ordnung schafft. Wenn Ihr regelmäßig den Wasserstand lest, kommen Euch diese Zeilen bald schon wie ein Mantra vor.

Deshalb möchte ich die Neugierigen von Euch nochmal darauf hinweisen, ab und an einen Blick auf die Seiten-Navigation am unteren Rand der Startseite zu werfen. Dort sind zumindest alle „Artikel“ (ohne Seiten, Firmen, Events, Produkte und weitere Landingpages) enthalten. Die Zahl schwankt seit November 2019, als wir Macnotes übernahmen. Und im nächsten Wasserstand muss ich vielleicht schon schreiben, dass wir nur noch „beinahe“ 35.000 Texte auf Macnotes anbieten. Denn wir produzieren zwar auch neuen Content, aber bei der Überarbeitung der alten Beiträge fällt eben auch viel weg. Entsprechend gibt es Wochen, in denen wir mehr alte Artikel löschen als wir neue schreiben.

Ideen für die Zukunft

Wir haben uns außerdem für ein CSS-Framework entschieden, das wir beim Re-Design der Webseite einsetzen wollen. Es lautet auf den Namen Bulma. Ihr müsst wissen, dass wir mittelfristig neben dem Design auch neue Funktionen zur Webseite hinzufügen möchten. Wenn dabei beispielsweise Plug-ins für WordPress oder Scripte anfallen sollten, dann möchten wir den Quellcode natürlich mit Euch teilen, damit auch Ihr etwas davon habt.

Es gab damals mal einen Event-Kalender. Den fanden auch wir ganz toll. Mal schauen, ob das Ding irgendwann ein Revival erlebt. Im Forum gab es außerdem die Möglichkeit für Nutzer, RSS-Feeds anderer Webseiten in eine individualisierte Nachrichten-Übersicht zu packen. Ebenfalls interessant. Ein Problem bei diesen Community-Funktionen ist halt der Datenschutz. Wenn wir Daten erheben und zwar mit eigenen Programmen, müssen wir diese auch so gestalten, dass sie der DSGVO genügen. Das beschleunigt die Entwicklung jedenfalls nicht.

Wir wollen mittelfristig aber auch die Verbindung der Webseite zu Social Networks ausweiten, wir planen eigene Lösungen fürs Affiliate-Marketing und wollen Datenbanken mit Tipps, Tests und mehr aufbauen. Wenn Ihr außerdem Ideen für die Zukunft von Macnotes habt, lasst es uns wissen.

Bei alldem dürft Ihr nicht vergessen, dass momentan quasi nur anderthalb Personen an Macnotes arbeiten.

Für diejenigen, die trotz Yulia Karneval feiern: Viel Spaß dabei. Den anderen, zu denen auch wir gehören, wünschen wir mindestens genauso jecke Tage. ;)

Der Beitrag Wasserstand #7: Thin Content, Dubletten und Ideen für die Zukunft von Macnotes erschien zuerst auf Macnotes.de.