Ich habe mit Absicht als in diesem Beitrag nicht von den „Top X“-Apps geschrieben und werde auch – so hoffe ich – nicht zu viel Software aufführen, die ihr schon kennt. In jedem Fall möchte ich aber meine Erfahrungen in der Selbstständigkeit schildern und die Apps, die mir dabei helfen.

Es gibt nicht „die“ Apps

Doch genau da ist ja der Knackpunkt. Ich bin kein Ingenieur und habe CAD-Software hin und wieder für den 3D-Druck im Einsatz. Aber mit meiner Selbstständigkeit hat das dann nichts zu tun. Ich beschränke mich also auf Apps und schildere meine Erfahrungen.

Aufgabenverwaltung oder To-Do-Apps

An dieser Stelle folgt einfach gähnende Leere. Denn so sehr ich verstehe, dass es Leute gibt, die Aufgabenverwaltung betreiben, ist das für mich nicht effektiv. Denn Apples Erinnerungen-App ist die einzige Aufgabenverwaltung, die ich nutze, und das auch nur privat. Ich nutze auch Kalender eher sporadisch und auch erst, seit mich Push-Benachrichtigungen darüber informieren. Aktiv setze ich solche Software nicht ein.

Ich musste eine zeitlang beruflich ein Software-Ticketing-System wie Redmine einsetzen. Bei komplexen Projekten erkenne ich dann sogar einen Mehrwert – heute kann man aber Softwareprojekte mit Git und auf Github komfortabler managen. Mein eigenes Business ist nicht derart unüberschaubar und ich gleichzeitig aber so viel interessiert und zerstreut, dass ich am Ende vergessen könnte aktiv in die Aufgabenverwaltung zu blicken. Im Grunde sind Nachrichten und E-Mails meine To-Do-Liste geworden.

Nachrichten und E-Mails

Perfekte Überleitung sozusagen. Ich nutze sowohl Gmail als auch Apple Mail und neben iMessage auch Slack für die berufliche Kommunikation. Audio- und Videotelefonie. Vor Jahren setzten wir auch Skype ein, aber das habe ich als MS Teams, zu dem es nach der Übernahme von Microsoft dann irgendwann wurde, nur noch gebraucht, wenn ein Kunde darauf bestand.

Texteditoren

Ich schreibe viel, selbst Gedichte und Prosa, die ich zur Veröffentlichung bringen möchte oder in Teilen auch schon habe. Aber ich schreibe auch viel fürs Web. Da bieten sich Texteditoren mit Schnittstellen zu weitverbreiteten CMS an.

Ein Editor, den ich empfehlen kann und selbst seit Jahren einsetze, ist Ulysses, den es sowohl für macOS als auch iOS und iPadOS gibt. Was mir bei dem Editor noch fehlt, ist die Unterstützung von „Custom Post Types“ auf WordPress-Systemen. Ansonsten erlaubt Ulysses den Export als PDF, aber auch auf WordPress, Ghost oder Medium. Man kann damit, und das tue ich mittlerweile, ebenfalls Manuskripte anfertigen. Mir gefallen die Schreibziele und hilfreich ist die seit ein, zwei Jahren enthaltene Rechtschreibkontrolle.

Für die Veröffentlichung von Inhalten im iBooks Store kann man auch auf Apples Pages (früher iBooks Author) setzen.

Programmier-Editoren

Ich arbeite hin und wieder auch im Bereich der Web-Programmierung, habe schon WordPress-Installationen und individuelle Themenprogrammierung umgesetzt. In dem Kontext beschäftigte ich mich mit Ruby (on Rails), Python oder PHP und Javascript und als Programmiereditor meiner Wahl nutze ich deshalb Atom, den es kostenlos gibt. Hin und wieder kommt auch Microsofts Visual Studio Code zum Einsatz. Die App ist ebenfalls kostenlos. Ich nutze außerdem Apples Xcode, aber bislang nur für App-Experimente und nicht im beruflichen Sinn.

Zeiterfassung

In meiner Selbstständigkeit ist die Dokumentation meiner Arbeit wichtig. Ich kann auf einem Rechnungsdokument auch notieren, welche Arbeit ich ausgeführt habe. Aber manche Kunden rechnen pro Stunde mit mir ab und also benötigt es ein Tool zur Zeiterfassung. Als ich das erste Mal auf Stundenbasis abrechnen musste, habe ich zunächst nach einer kostenlosen App fürs iPhone gesucht. „My Better Time“ habe ich nach einigem Ausprobieren dann für mich entdeckt und bin der App bis heute treu geblieben. Mittlerweile gibt es die App auch für den Mac und wer mag, kann damit auch Urlaubs-, Feier- oder Krankheitstage festhalten. Der Export der Daten erfolgt in unterschiedliche Formate, wobei die kostenlose Variante im Export eingeschränkt ist.

Mindmapping

Es mag komisch klingen, dass ich Aufgabenverwaltungen nicht nutze, sehr wohl aber Mindmaps. Ich mag es, wenn ich große Themen, auf die ich mich einlasse, visualisieren kann. Das hilft mir, den Überblick zu behalten. Als Software meiner Wahl habe ich dazu MindNode für mich entdeckt. Selbst mit der kostenlosen Variante kann man schon eine Menge anfangen. Vor allem eignet sie sich prima, um auszuprobieren, ob man mit dem Konzept von Mindmaps überhaupt zurechtkommt.

Ich mag Mindmapping auch als kreativen Prozess, habe ihn, ähnlich wie ein paar Schnelllese- und Memorierungstechniken während meiner Studienzeit kennengelernt und viele Bücher dazu gelesen. Eines davon zum Thema „kreative Notizen“ habe ich vor ein paar Jahren sogar mit einem Testbericht bedacht, das Sketchnote-Handbuch von Mike Rohde.

Die leidigen Steuern

Vor Jahren habe ich auch einfach WISO Steuer für den Mac genutzt. Aber die App ist zu träge und in erster Linie für den privaten Gebrauch gedacht und erwähnte ich, dass sie sehr träge ist und mehr oder weniger absolut nicht modern?

Denn es gibt diese neue Kategorie von cloud-gestützten Apps, die einem bei der Buchhaltung helfen wollen und Export-Schnittstellen für den Steuerberater bereithalten, und die man auch auf dem iPhone unterwegs nutzen kann, um Dokumente einzuscannen und zu verarbeiten.

Regelmäßige Leser:innen von Macnotes werden wissen, dass ich den Jahreswechsel 2019/2020 genutzt habe, um eine „neuartige“ Steuersoftware auszuprobieren, mit Datev-Export. Das klappte aber mit mäßigem Erfolg, da es noch viele ungeklärte Sachverhalte gibt, wie ich sogar in einer dem Thema gewidmeten Podcast-Episode festgehalten habe.

Für den Jahreswechsel 2020/2021 habe ich mir vorgenommen einer neuen App eine Chance zu geben. TaxFix heißt sie und vielleicht hört oder lest ihr dann im neuen Jahr, wie sich die Software geschlagen hat. Man soll die Hoffnung ja nicht aufgeben.

Der Beitrag Apps für die Selbstständigkeit 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.

Der Kölner Dom ist ein Gesamtkunstwerk, in den eigenen vier Wänden gibt es immer etwas zu tun und Linkpflege ist ein bisschen von beidem.

Websitebetreiber, oder Papiertiger?

Denn die eigene Webseite sollte jedem am Herzen liegen. Ich kenne Websitebetreiber, bei denen ist eine Website ein Papiertiger. Dort werden in Büroräumen Zahlen auf dem Papier jongliert, um am Ende zu entscheiden, worum es geht.

Ich kenne Leiter von Redaktionen, die sich für teures Geld vom Besitzer der Website einen SEO-Kurs haben bezahlen lassen, weil der es wollte und aber nicht besser wusste. Das sind diese Redaktionen, in den eigentlich niemand Ahnung davon hat, was eigentlich SEO ist, geschweige denn PHP, Ruby, Python oder einfach nur HTML und Javascript bedeuten. Dort wird für teures Geld Expertise von Außen eingekauft und am Ende aber absolut nichts draus gemacht. So kann man sein Geld zum Fenster herauswerfen.

Doch es gibt auch diese Gruppe von Websitebetreibern, die zwar eine Ahnung davon haben, dass es irgendwie so was wie SEO gibt, aber es als zu mühselig empfinden. SEO ist keine Alchemie und trotzdem ein weites Feld, das manche überfordert und demotiviert.

Linkpflege ist wichtig

Linkpflege ist ein Teil der Suchmaschinenoptimierung. Dies ist nicht nur meine Meinung, sondern war schon Ende der 1990er meine Erfahrung. Damals wie heute mache ich mein Ding und versuche nicht, daraus irgendeinen Vorteil zu ziehen, außer meinen eigenen. Will heißen, ich gebe mich nicht als Suchmaschinenoptimierer aus, sondern ich wende meine Ideen an.

Es ist eine einfache Rechnung. Denn Google hat an vielen Stellen über das Thema gesprochen – damals noch Matt Cutts und später über andere Verantwortliche Stellungnahmen abgegeben, um dies zu bestätigen. Die Wartung einer Website ist wichtig. Googles Search Console (früher Webmaster Tools) liefert Anreize, was man warten könnte.

Ich schrieb schon des Öfteren, dass es ein Graus ist und man den Zerfall Woche für Woche erlebt. Ein Link, der vor Jahren noch aktiv war, funktioniert heute nicht mehr. Das wäre noch verschmerzbar. Doch irgendwelche Idioten kaufen alte Domains auf und nutzen die Backlinks, um ihrer Pornoplattform, Casinodreck oder anderen sinnfreien Inhalten zu mehr Geltung zu verhelfen. Die Strategien werden immer subtiler. Doch sobald Google so eine Website erkennt, dann gilt sie als „Bad Neighborhood“ und wirft ein schlechtes Licht auf die eigene Website. Welche Widrigkeiten die Linkpflege mit sich bringt, thematisiere ich im aktuellen Podcast von Macnotes.

Ach ja, und außerdem gibt es vielleicht dort draußen jemanden, der diesem Podcast zu einer Art Podcast verhelfen mag.

In jedem Fall findet Ihr unseren Podcast auf iTunes, Spotify und auch in Googles Podcast-Verzeichnis. Dort könnt Ihr ihn abonnieren, wenn Ihr mögt.

Dieser Artikel enthält Affiliate-Links.

Der Beitrag Sajonaras 7 Minuten #36: Linkpflege ist wichtig … #SEO erschien zuerst auf Macnotes.de.

Ich bin ehrlich. Selbst als Mac-Nutzer verwende ich fast ausschließlich Google Chrome. Safari ist schnell und schneller, aber ich konnte mich noch nicht an die Feinheiten in der Benutzeroberfläche gewöhnen, dass ich öfter als nur „manchmal“ damit arbeite.

Dazu kommt leider, dass Chrome deutlich robuster ist als Safari – nicht etwa, weil der Browser das Problem ist, sondern die vielen Webseiten dort draußen. Selbst WordPress (und dessen Javascript) hat bis heute nicht richtig gelernt mit Safari zusammenzuarbeiten. Ich kenne Anwendungen im professionellen Umfeld, zur Verwaltung von Daten im Finanzbereich und solche, die in Hochschulen zur Kursverwaltung und für die Webseitenpflege als CMS eingesetzt wird, die zum Teil sehr gereizt reagiert, wenn man sie mit Safari am Desktop aufruft. Die Empfehlung lautet immer: Nutzen Sie bitte Chrome, Firefox oder einen anderen Browser.

Auftritt Edge

Wie wäre es mit MS Edge? Denn dieser Browser basiert mittlerweile auch auf Chromium und der Wechsel fällt damit ziemlich einfach. Warum ich nun Wochen nach dem Test immer noch mit Microsofts Browser arbeite und aber trotzdem auch eine gewisse Enttäuschung nicht verbergen kann, das erfahrt Ihr in dieser Ausgabe von Sajonaras 7 Minuten.

Diese und weitere findet Ihr auf iTunes, Spotify und auch in Googles Podcast-Verzeichnis. Dort könnt Ihr ihn abonnieren, wenn Ihr mögt.

Dieser Artikel enthält Affiliate-Links.

Der Beitrag Sajonaras 7 Minuten #31: MS Edge am Mac 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.

Wie behebt man den Fehler 500 bei WordPress und MAMP?

WordPress lässt sich oft bitten. Habt Ihr gerade eine WordPress-Umgebung umgezogen, oder habt Ihr Änderungen an der wp-config.php vorgenommen, dann kann es Euch passieren, dass beim Aufruf einer Webseite auf einmal nichts mehr geht.

Mir ist dieser Fehler nun nach einigen Jahren erneut untergekommen, und statt mir gemerkt zu haben, wie ich ihn behebe, musste ich selbst erst einmal wieder recherchieren. Doch die angebotenen Lösungen waren alle viel zu komplex. Man sollte virtuelle Hosts manipulieren, Einstellungen in den Konfigurationsdateien vornehmen und den Server neu starten. Irgendwann dämmerte es mir aber, und ich erinnerte mich.

WP-Admin funktioniert, Webseite aber nicht: Permalinks sind schuld

Tatsächlich konnte ich mich ohne Weiteres im „Backend“ anmelden, aber eben keine Einzelseite aufrufen, wurde dann immer mit dem Fehler 500 konfrontiert.

In diesem konkreten Fall hilft das Öffnen der Einstellungen von WordPress. Navigiert dort zum Punkt „Permalinks“ und klickt einfach einmal auf „Änderungen speichern“. Et voilà. Es geht wieder.

Diese Vorgehensweise hilft natürlich nur, wenn nichts Ärgeres im Hintergrund nicht so will, wie es soll. Denn es kann auch andere Gründe geben, wieso man diese Fehlermeldung angezeigt bekommt.

Sich an das Problem herantasten

Als Nutzer von MAMP Pro kann man beispielsweise in der PHP-Konfiguration einfach ein Häkchen setzen, um PHP-Fehler auch auf dem Monitor auszugeben. Nutzt man nur MAMP ohne Pro, dann kann man in den Kopf der eigenen Vorlage (meist header.php) folgende Zeilen Code hinzufügen:

// PHP-Fehler ausgeben
   ini_set('display_errors', 1);
   ini_set('display_startup_errors', 1);
   error_reporting(E_ALL);

Aber genau an diesem Punkt wurde ich stutzig. Denn es kam erst gar nicht zur Ausgabe und tatsächlich hatte ich die Konfiguration von WordPress erst verändert, da ich einen neuen Host für die Installation eingerichtet hatte.

Der Beitrag MAMP (PRO) und WordPress: Internal Server Error (500) beheben erschien zuerst auf Macnotes.de.

Stammleser der Webseite wissen es schon, aber hier ist momentan wieder etwas weniger los. Das hing zuletzt auch damit zusammen, dass ich statt zu schreiben wieder mehr programmiert habe. Denn letztlich habe ich ein „große Ziel“ im Blick, das ich ja im November 2019 schon ankündigte, aber später dann auch in einigen Wasserständen erläuterte.

Irgendwann will ich mit Macnotes auf ein eigenes System wechseln und gerne mehr datengestützten Journalismus betreiben. Die Informationen sollen mir und Euch, aber in Zukunft auch anderen Autoren dabei helfen, nicht nur Artikelideen zu entwickeln, sondern auch Fakten zu recherchieren, ohne dabei grundsätzlich zu externen Quellen greifen zu müssen. Letztlich ist nämlich auch ein eigenes Archiv, und können eigene Datenbanken ein Fundus für Informationen sein.

Macnotes auf eine gemeinsame Datenbasis heben

Doch damit wir überhaupt so weit kommen, müssen die vorhandenen Artikel auf eine gemeinsame Datenbasis kommen. Daran arbeite ich – immer noch und auch noch eine ganze Weile. Letztlich ist Macnotes nämlich mittlerweile bald 40.000 Texte schwer und die stammen aus teilweise ganz unterschiedlichen Webseiten und Übernahmen von Webseiten.

Von der Idee zum WordPress-Plug-in

Wer sich im Detail für die im Podcast angesprochenen Texte interessiert, dem verlinke ich sie gerne: von der Idee zum WordPress-Plug-in #1 und #2.

Ihr könnt in den kommenden Wochen und Monaten auch mit weiteren Beiträgen zur Plug-in-Entwicklung für WordPress rechnen, die neben der Kommunikation mit der Datenbank auch Hinweise auf die Entwicklung einer eigenen API umfassen. Letztlich ist das Thema einfach zu spannend, um nicht darüber zu schreiben.

Ja, und dann folgt wieder der übliche Hinweis, dass Ihr den Podcast sowohl auf iTunes als auch auf Spotify abonnieren könnt.

Dieser Artikel enthält Affiliate-Links.

Der Beitrag Sajonaras 7 Minuten #16: Von der Idee zum WordPress-Plug-in 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.

Warum? Es wäre zu einfach, zu sagen, weil wir es können. Es gibt viel einleuchtendere Gründe:

• Weil diese Aufgabe so oft ausgeführt wird, dass sich der Aufwand lohnt.
• Da wir nicht ständig den Quellcode anpassen wollten, um wieder eine Option hinzuzufügen, sondern dies unmittelbar erledigen zu können.
• Weil es durchaus Spaß macht, je öfter man sich einer Herausforderung stellt und man am Ende sogar noch etwas lernt.
• Da ein Plug-in am Ende wartungsfreundlicher ist, und auch unabhängig von einem Thema genutzt werden kann.
• Weil das Plug-in vielleicht sogar so interessant ist, dass man es anderen Leuten zur Verfügung stellen kann, die das gleiche Problem lösen wollen.

Automatisierung tut not

Regelmäßige Macnotes-Leser wissen, dass wir im Hintergrund versuchen, trotz WordPress eine Datenbasis aufzubauen, mit der wir irgendwann dann den nächsten Schritt wagen können. Bis dahin wird es aber noch eine Weile dauern. Anfang Januar erwähnte ich im Wasserstand #19, dass wir bei der Überarbeitung das Jahr 2009 abgeschlossen haben. Mittlerweile bin ich sogar schon beim Februar 2010 angelangt.

Doch diese Überarbeitung ist so langwierig, und vor allem so repetitiv. Immer, wenn Aufgaben sich wiederholen, lohnt es sich, nach einer Automatisierung derselben zu suchen.

Die Idee: Schlagwörter automatisch hinzufügen

Wenn ich schreibe Schlagwörter, dann meine ich eigentlich sogar einen eigenen Typus, der bei uns intern „Keywords“ genannt wird. Wir haben zusätzlich zu den öffentlichen Schlagwörtern, für die es auch Archive gibt, nämlich interner Schlüsselwörter im Einsatz, die nicht für Nutzer und Suchmaschinen einsehbar sind, die uns aber erlauben, semantische Filter an manchen Stellen auf der Webseite einzusetzen, beispielsweise wenn es darum geht, „ähnliche Artikel“ anzuzeigen.

Nun ist die Situation, die ich bei Macnotes vorfand aber unbefriedigend. Denn es gab und gibt auch immer noch mehr als zehntausend öffentlich sichtbare Schlagwörter. Ich gehe bei der Überarbeitung chronologisch vor, Artikel für Artikel, da wir über die Jahre mehr als ein halbes Dutzend Webseiten (Macnotes, iPhone-Notes, Apfelmagazin, Blog4i, u. a. m.) zusammengeführt haben. Es gab inhaltlich doppelte Beiträge, die müssen zusammengeführt werden, und neu verlinkt. Ich könnte auch mit der Dampfhammer-Methode alle Beiträge und deren Schlagworte automatisch anpassen oder löschen. Nur dann fehlten mir auf einen Schlag zehntausende Endpunkt für Google. Stattdessen arbeite ich diese Stück für Stück ab und füge dann auch Weiterleitungen hinzu, damit die Suchmaschine nicht ganz im Dunkeln tappt.

Wie kann man die Idee umsetzen?

Wenn ich in den vielen Jahren Computerei etwas gelernt habe, dann, dass es nicht schadet, sich die eigene Idee einmal vor Augen zu führen.

Gerade Laien bekommen so ein besseres Gefühl dafür, was alles zu tun ist. In der Informatikausbildung nennt man solchen Output gerne auch mal Pseudocode. Strukturierte Notizen reichen aber vollkommen aus, um dann die einzelnen Teile auszuarbeiten.

Wenn ich also Schlagworte automatisch ersetzen will, dann muss ich mir Gedanken machen, darüber …

• … wann das geschehen soll,
• … welche Schlagwörter das sein sollen,
• … womit ich sie vergleichen kann, um zu entscheiden, ob sie automatisch hinzugefügt werden.

Ich könnte mir noch mehr Fragen stellen. Aber ungefähr so beginnt dann ein Brainstorming und kann man versuchen, Antworten zu finden.

1. Schritt: direkt im Artikel

Meine erste Idee war, ich könnte, „wenn ich als Administrator eingeloggt bin“, und nur dann, eine Funktion aufrufen, die dann die Schlagwörter hinzufügt.

Ich gehe dann gerne hin, und füge in der Datei footer.php ersten Quellcode hinzu und erzeuge eine Ausgabe. Natürlich mache ich das nicht live auf Macnotes, sondern in meiner Entwicklungsumgebung am heimischen Computer. Ich setze für die WordPress-Entwicklung gerne MAMP ein. Das hat sich bewährt und ist relativ pflegeleicht (funktioniert auch unter macOS Big Sur und auf Apple Silicon).

Da ich gerade einen Artikel überarbeitete, stoppte ich die Arbeit daran und dachte. Dieser kann als Startpunkt für die Funktion dienen. Also suchte ich nach einem Merkmal, das relativ eindeutig zuordenbar ist. Im Titel sehr vieler „Notizen“-Beiträge auf Macnotes kommt die Phrase „Notizen vom“ vor. Wenn ich 1000 Mal in Zukunft so ein Schlagwort automatisch hinzufüge, und vielleicht zwei, dreimal daneben liege, dann ist es einfacher, dreimal das Schlagwort wieder zu entfernen.

Überschrift mit Phrase vergleichen, Ergebnis als Arbeitsauftrag

Also verglich ich im Quellcode den Inhalt vom Titel mit der Phrase „Notizen vom“ und gab dann etwas aus. Die Notiz würde in etwa lauten:

Wenn der Titel "Notizen vom" enthält, dann füge das Keyword "Notizen (MN)" hinzu, aber nur, wenn es noch nicht vorhanden ist.

Ja und dann kann man sich bereits an die Arbeit machen. Wer noch Laie ist, der kann anhand dieser Anweisung auch Google oder eine andere Suchmaschine bemühen, beispielsweise danach, wie man an den „Titel“ eines Beitrags in WordPress gelangt, oder wie man in PHP innerhalb einer Zeichenkette (String) nach einer Phrase (Substring) sucht. So kommt man dann von A nach B und hangelt sich immer weiter.

Wer schon mehr Erfahrung hat, wird Anlaufstellen kennen, oder eben direkt losprogrammieren. Der erste Code sieht dann in etwa wie folgt aus:

if(strpos($post->post_title, 'Notizen vom') !== false) {
 echo 'An dieser Stelle muss dann die Funktion arbeiten.';
}

Die PHP-Funktion strpos wird gerne verwendet, um eine Gelingensbedingung zu erzeugen. Sie liefert entweder eine Zahl zurück, oder false, wenn die gesuchte Zeichenkette nicht vorhanden ist. Das ist prima, denn uns interessiert nur, ob es vorkommt. Also müssen wir umgekehrt fragen, ob beim Vergleich mit dem Titel „nicht false“ zurückgegeben wird.

Überprüfen, ob das Schlagwort vorhanden ist

Nun müssen wir noch überprüfen, ob der Beitrag nicht eventuell schon das Keyword „Notizen (MN)“ nutzt. WordPress bietet dazu bereits eine Funktion an namens has_term() (vgl. WordPress Code-Referenz).

Wir fügen also dem Code von oben noch etwas hinzu:

if(strpos($post->post_title, 'Notizen vom') !== false) {
	if(has_term('Notizen (MN)') {
	echo 'es gibt das Keyword schon.';
} else {
	echo 'jetzt müssen wir das Schlagwort hinzufügen.';
}
}

Schlagwort hinzufügen

Wir müssen uns nun also Gedanken machen, wie wir das Schlagwort an der Stelle hinzufügen. Auch dafür bietet WordPress eine Methode an: wp_set_post_terms() (vgl. WordPress Code-Referenz).

Abermals passen wir dann den Code von oben weiter an.

if(strpos($post->post_title, 'Notizen vom') !== false) {
	if(has_term('Notizen (MN)') {
	echo 'es gibt das Keyword schon.';
} else {
	wp_set_post_terms($post->ID, 'Notizen (MN)', 'keywords', true);
	echo 'wir haben das Schlagwort hinzugefügt.';
}
}

2. Schritt: Abstrahieren nicht vergessen

Jetzt haben wir doch alles erreicht, was wir wollten, und können uns wieder anderen Dingen zuwenden?

Nicht ganz. Denn wir wollen ja zum Beispiel auch zwei oder mehr Schlagworte anpassen. Zunächst bedeutet das, dass wir den Code von oben weiter umbauen müssen. Doch zunächst sollten wir uns wieder ein paar Gedanken darüber machen, wie man das machen kann.

Der unmittelbarste Zugang wäre vermutlich, denn Quellcode einfach zu kopieren, und einfach nur die Vergleichsphrase im Titel zu finden und dazu das passende Schlagwort. Aber man kann das auch eleganter lösen:

Übergebe ein Array mit allen möglichen Schlagworten. Vergleiche und ersetze für alle diese.

Also dann ans Werk. Aus einem Schlagwort hab ich kurzerhand erst einmal zwei gemacht, und diese zu einem Array ($tags[]) hinzugefügt. Dann muss ich natürlich noch eine Funktion suchen, die mir erlaubt, für jedes Element im Array etwas auszuführen. Da hält PHP dann die foreach-Schleife bereit.

$tags = [
	"Notizen vom" => "Notizen (MN)",
	"Windows 7" => "Windows 7"
  ];
  foreach ($tags as $title => $keyword) {
    if(strpos($post->post_title, $title) !== false){
      if ( has_term($keyword, 'keywords') ) {
        echo ( '<p>Es gibt das Keyword "'.$keyword.'" schon.</p>' );
      } else {
        wp_set_post_terms( $post->ID, $keyword, 'keywords', true );
        echo ( '<p>Wir haben das Keyword "'.$keyword.'" hinzugefügt.');
      }
    }
  }

3. Schritt: Noch weiter abstrahieren, Plug-in entsteht

Das letzte Stück Quellcode war doch eigentlich ganz prima? Ja, ich hätte einfach in der Footer-Datei bei neuen Schlagworten, die mir einfallen, diese ergänzen können, die Datei auf den Server hochladen, und weiterarbeiten können.

Aber auch das ist nur ein fauler Kompromiss. Denn viel besser wäre es ja, wenn man direkt in WordPress beliebig viele Schlagworte hinzufügen könnte, die man auf diese Weise ergänzen wollte.

Vorüberlegungen

An dieser Stelle lohnt es abermals, ein paar Vorüberlegungen zu machen. Fragen, die man sich stellen kann, lauten:

• Wie kann ich die Daten getrennt vom Code bearbeiten?
• Welche Möglichkeiten habe ich, um mit Daten zu interagieren?

Auch das sind nur zwei von vielen Fragen, mit denen man sich an der Stelle beschäftigen könnte. Mir ist zum Beispiel in den Sinn gekommen, eine Text-Datei oder eine CSV-Datei zu nutzen, um darüber die Daten zu ergänzen. Aber dann hätte ich auch das Problem, diese immer wieder zu ergänzen, und hochladen zu müssen.

Als Nächstes fällt einem dann eine Tabelle ein. WordPress nutzt MySQL und bietet sogar Funktionen, um sowohl Tabellen zu erstellen, als auch Daten darin zu ändern.

Nur dann benötige ich ja irgendeine Möglichkeit, die Daten online hinzuzufügen. Ich könnte natürlich eine separate HTML/PHP-Seite erstellen, die ich aufrufe, und der ich es erlaube, mit der Datenbank zu kommunizieren. An dieser Stelle reifte dann der Gedanke, dass ich auch gleich ein Plug-in für WordPress entwickeln könnte. Das hat nämlich auch den Vorteil, dass ich die Funktionalität nicht verliere, sollte ich mal das Theme für Macnotes anpassen.

WordPress-Plug-ins erstellen, aber wie?

Ich hatte vor Jahren schon mal ein Plug-in für WordPress erstellt. Aber wie das eben so ist, wenn man sich nicht so sehr mit der Materie auseinandersetzt, dann muss man sich erst wieder einarbeiten. Eine Anlaufstelle ist natürlich WordPress’ eigenes Handbuch für die Plug-in-Entwicklung. Das ist aber so strukturiert, dass man viel hin- und hernavigiert und mit sehr vielen komplexen Dingen konfrontiert wird.

Einfacher geht es, wenn man in der Suchmaschine seines Vertrauens nach Alternativen Ausschau hält. Das können auch teilweise sehr alte Beiträge von Smashing Magazine (9+ Jahre) oder von Frank Bültge (14+ Jahre) sein. Selbst wenn manche der Hinweise darin heute nicht mehr aktuell sein „sollten“, dann bekommt man nämlich Anhaltspunkte, wie die Dinge zusammenpassen und kann sich von dort aus weiterhangeln.

Was braucht man für ein WordPress-Plug-in?

Das einfachste WordPress-Plug-in, das man herstellen kann, besteht aus einer einzelnen Datei, die man einfach in das Plug-in-Verzeichnis von WordPress kopiert (besser aber in einen Unterordner). „So einfach“ ist das tatsächlich.

Diese Plug-in-Datei enthält im Kopf ein paar Kommentare, die WordPress dann ausliest und in der Administrationsoberfläche anzeigt.

/**
* Plugin Name: SN Add Keywords
* Plugin URI: https://sajonara.info
* Description: This plugin automatically adds keywords to the database, if they are found in the headline and not already implemented.
* Version: 0.0.2
* Author: Alexander Trust
* Author URI: https://sajonara.info
* License: GPL2
*/

Eine PHP-Datei, die nur diese Information enthält und sonst nichts, ist auf dem Papier auch schon ein „nutzloses“ Plug-in. WordPress zeigt es dann an, und man kann es aktivieren.

Plug-ins wollen aufgerufen werden

Angenommen, wir hätten den bereits fertigen Quellcode von davor in unsere Plug-in-Datei kopiert, hätte auch dieser funktioniert, WordPress beim Aktivieren allerdings eine Fehlermeldung ausgegeben. Das liegt nicht zuletzt daran, dass WordPress gerne möchte, dass Plug-ins und deren Funktionen „aufgerufen“ werden sollen.

Dazu stellt WordPress zwei Kategorien an Aufrufen zur Verfügung:

• Hooks
• Filter

Die Filter sollen vor allem dazu genutzt werden, um Inhalte zu verändern. Entsprechend gibt es für Filter (add_filter()) Parameter, die beispielsweise den Titel (the_title) oder den Text (the_content) betreffen. Es gibt noch viele weitere Endpunkte, an denen man einen Filter ausführen könnte.

Doch wir wollen ja nicht den Text verändern, sondern Schlagworte hinzufügen, und also sind die „Hooks“ (add_hook()) vielleicht eher für unsere Zwecke geeignet.

Was wir dann also machen können, um WordPress zufriedenzustellen, ist unseren Code von davor in eine Funktion integrieren, und diese mittels eines Action-Hooks aufzurufen.

add_action('wp_footer', 'sn_add_keywords');

function sn_add_keywords() {
 /* Unser Quellcode von zuvor. */
}

Drei Zustände eines Plug-ins

WordPress erkennt insgesamt drei Zustände eines Plug-ins, und kann, beim Eintreten derselben aktiv werden.

• Beim Aktivieren,
• beim Deaktivieren
• und beim Deinstallieren.

Warum erzähle ich Euch das? Nun, weil es durchaus hilfreich sein kann, nicht nur an sich selbst zu denken, sondern auch an andere. Und an dieser Stelle erreicht dann die ursprüngliche Idee bereits eine interessante Komplexität.

Ich sagte ja, es wäre prima, wenn man eine Tabelle hätte, in die man dann die Schlagwörter hinzufügen kann. Das Aktivieren des Plug-ins eignet sich in diesem Fall dazu, die Tabelle anzulegen. Auch dafür hält WordPress dann Befehle bereit.

Ich finde aber, dass dieser Beitrag schon lang genug geworden ist, und habe mich deshalb dazu entschieden, noch einen zweiten Teil herauszubringen, in dem ich dann erkläre, wie man die Tabelle anlegt, sie mit ersten Daten füllt, und wieso es hilfreich sein kann, die Versionsnummer des eigenen Plug-ins ebenfalls in der Datenbank von WordPress zu speichern. Außerdem widme ich mich dann auch den anderen beiden Zuständen von Plug-ins. Nicht zuletzt wollt Ihr ja sicherstellen, dass Euer Plug-in, wenn man es deinstalliert, die Daten ordentlich löscht. Und über das Erstellen einer „Webseite“ für das Plug-in in der Administrationsoberfläche von WordPress haben wir auch noch nicht gesprochen.

Freut Euch also dann auf den zweiten Teil, der vermutlich nicht ewig auf sich warten lassen wird.

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

Immer mal wieder gibt es Gelegenheiten, sich selbst und die eigenen Vorurteile zu hinterfragen. In den 1990ern „programmierte“ ich bereits eigene Webseiten, zuletzt half ich einem Kunden bei der Migration von Joomla zu WordPress. Auf Macnotes nutzen wir derzeit selbst noch WordPress, programmieren aber mit Server-Side-Swift ein eigene Version der Webseite für die mittelfristige Zukunft, nicht zuletzt weil wir mit WordPress aus diversen Gründen nicht zufrieden sind. Es liegt also auf den ersten Blick ziemlich fern, sich die sogenannte „Homepage von der Stange“ anzusehen.

Erste Webador Erfahrungen

Aber gerade deswegen sollte man es vielleicht trotzdem tun. Ich hatte nun jedenfalls die Gelegenheit mir den Webador Homepage-Baukasten anzusehen und konnte damit eine Website erstellen.

Homepage kostenlos erstellen

Der Anbieter aus den Niederlanden hat vor kurzem sein Geschäft erweitert und bietet nun auch Kunden in Deutschland seine Dienstleistungen an, samt deutschsprachigem Support, sogar kostenlos.

Das heißt jedenfalls jeder kann zunächst einmal gratis eine eigene Webseite erstellen. Die ist dann über eine Webador-Adresse im Netz erreichbar. Wer eine eigene Domain anbinden will, kann das auch tun. Mehr dazu später.

Drei Klicks zum ersten Erfolg

Zunächst einmal wählt man aus, welche Art von Homepage man haben möchte: Website, Webshop oder Blog. Wer beispielsweise eine Adresse im Internet für seinen Handwerksbetrieb oder seine Arztpraxis sucht, und sich aber nicht mit der Technik auseinandersetzen möchte, kann dies mit wenig Zeitaufwand tun.

Im zweiten Schritt gibt man bereits den Titel der Webseite an und kann dann eine E-Mail-Adresse und ein Passwort hinterlegen. Damit hat man den Registrierungsprozess abgeschlossen und ist bereits voll im Gange.

Das Design von der Stange?

Bereits im nächsten Schritt kann man sich für eine Designvorlage entscheiden. Die lässt sich übrigens im Nachhinein jederzeit anpassen. In jedem Fall stehen dutzende unterschiedlicher Themen zur Wahl, die man außerdem in puncto Farbe und Layout noch den eigenen Wünschen anpassen kann. Darüber hinaus arbeitet der Anbieter daran, immer neue Designs bereitzustellen.

An dieser Stelle wird man dann gebeten, sich zu entscheiden, ob man gratis mitmachen möchte, oder sich für einen der vorhandenen Account-Typen entscheiden mag. Momentan ist auch das kostenlos möglich, denn sowohl der Pro-Account mit 1 Domain oder der Business-Account mit 2 Domains werden in den ersten drei Monaten mit 0 Euro berechnet. Ihr könntet also nach belieben alle Funktionen auf Herz und Nieren überprüfen.

Drei Pakete bei Webador

An dieser Stelle kann ich kurz erläutern, welche Pakete es gibt:

• Free: für Webseite oder Blog mit Webador-Adresse.
• Pro: eine Domain, Webshop mit zehn Produkten und ein E-Mail-Postfach.
• Business: zwei Domains, Webshop (unbegrenzt) und ein XL-E-Mail-Postfach.

Der Homepage-Baukasten im Einsatz

Hat man diese Entscheidung für ein Paket getroffen, wird man direkt zum Homepage-Baukasten weitergeleitet. Dieser ist ähnlich aufgebaut wie eine Desktop-App. In der linken Seitenleiste gibt es diverse Elemente für Titel, Text, Bild, Formulare, Buttons, Galerien, und viele weitere. Zu Beginn wird man auch in die Bedienung der Oberfläche eingeführt.

Man kann über eine Navigation am oberen Bildrand außerdem zur Verwaltung der Seiten wechseln, oder zum Design. Auch kann man dort den „Webshop“ verwalten. Wer womöglich in der Corona-Zeit angefangen hat, sich selbst neu zu erfinden und auf einmal Kissen anfertigt oder Holzschnitzereien, für den ist über ein Produkt wie Webador ein einfacher Weg in die Selbständigkeit gegeben. Natürlich darf man dann nicht vergessen, beim Amtsgericht des Vertrauens noch ein Gewerbe anzumelden, damit auch der Fiskus zufriedengestellt wird.

Fügt man eine neue Seite hinzu oder verwaltet man vorhandene, kann man an dieser Stelle auch Metadaten für die Suchmaschine eintragen, entscheiden, ob die Seite überhaupt indexiert werden soll und sogar, ob die Inhalte womöglich mittels Passwort geschützt werden sollen.

Mittels Drag-and-Drop kann man die Hierarchie der Seiten festlegen und passt so auch automatisch die Navigation auf der Webseite an. Im Prinzip ist alles selbsterklärend und zur Not kann man sich neugierig durchklicken.

Man bearbeitet die eigene Seite quasi „offline“ und es gibt oben rechts in der Oberfläche den Button zum „Veröffentlichen“.

Design für Desktop und Smartphone

Einsteiger im Bereich Webseiten hören vielleicht gerne, dass die Designs von Webador allesamt auch auf dem Smartphone funktionieren. Man kann bei der Designauswahl und -bearbeitung zwischen der Vorschau auf dem Desktop und dem Smartphone hin und her wechseln.

Online-Shop mit Webador

Wie weiter oben schon angedeutet, gibt es für viele Leute mit dem Webador-Baukasten auch die Möglichkeit, einen eigenen Onlineshop einzurichten. Das ist insofern ganz hilfreich, wenn man zwar ein Talent hat, das aber nicht zwangsläufig im Design von Webseiten liegt, sondern meinetwegen im Einkochen von Marmelade oder im „Upcycling“ von Möbeln.

Die Shop-Schnittstelle von Webador bietet eine Produktverwaltung und erlaubt die Abwicklung von Bestellungen, auf einfache Art und Weise. Vor allem für den Einstieg in eine potenzielle Selbständigkeit ist das ein Plus. Benötigt man hinterher weitere Möglichkeiten, kann man sich immer noch damit auseinandersetzen. Denn nicht jeder will in die Höhle der Löwen oder ist ein Mark Zuckerberg mit einem Businessplan in der Tasche, für den man Risikokapital erhält.

Verbesserungspotenzial bei der Lokalisierung

Man merkt Webador noch an, dass der Anbieter aus den Niederlanden stammt. Denn in der Lokalisierung wirkt das Angebot an manchen Stellen noch etwas unrund. Beispielsweise würde hierzulande wohl niemand „Folgender Schritt“ zur Aufforderung sagen, doch „weiter“ zu klicken, und das obwohl es nicht falsch ist.

Fazit

Etwas möglichst einfach zu gestalten, oder aber möglichst viele Möglichkeiten anzubieten, ist eine Herausforderung, vor der viele Dienstleister im Netz stehen. Deswegen ist schon der erste Kontakt wichtig. Webador hält den Anmeldeprozess kurz, erlaubt schon zu diesem Zeitpunkt die Auseinandersetzung mit der eigenen Webseite. Dadurch, dass man das Design auch hinterher ändern kann, ist selbst wankelmütigen Personen geholfen, die öfter mal was Neues suchen.

Doch Webador hat natürlich auch Grenzen. Die gibt es, wenn man beispielsweise eine Community aufbauen wollte, oder umfangreiche Websites mit „Big Data“ und dutzenden von Funktionen anbieten wollte. Ein zweites Wikipedia kann man mit Webador nicht bauen. Trotzdem kann man ein Produkt wie dieses empfehlen, aber eben nicht jedem. Technisch affine Personen gehen eh ihren eigenen Weg, aber wenn man seine Inhalte oder Produkte schnell ins Netz bringen möchte, dann kann man das mit Webador tun. Und die kostenlose Variante ist zudem geeignet, um schnell einmal Ideen durchzuspielen.

Der Beitrag Webador im Test: Websites erstellen mit dem Baukasten, geht das? erschien zuerst auf Macnotes.de.