Zielsetzung » Werbe-Markt.de Internas aus 2017

Ohne halbwegs konkrete, realistische, messbare und zeitlich terminierte Zielvorgaben wird das nichts mit der Migration. Als ordentlicher Programmierer neige ich bei meinen eigenen Projekten zum Gold Plating, d.h., ich investiere lieber unzählbare Stunden in Features die subjektiv spannend sind, aber niemals angefordert geschweige denn spezifiziert wurden. Ein selbst auferlegter, konkreter Fahrplan ist daher unerlässlich.

Wem übrigens das A in der eigenwilligen Interpretation der SMART-Zielsetzung fehlt: Das Ergebnis muss für Kunden mit beispielsweise Anspruch auf Software-Downloads und mich zufriedenstellend sein.

Admin-Menü

So geeignet WordPress für die Veröffentlichung von Inhalten auf der Website sein mag, stelle ich doch mit Ernüchterung fest, dass es so gut wie keine meiner geliebten Admin-Funktionalitäten mitbringt. Mein altes Admin-Menü Marke Eigenbau ist selbstverständlich auch nicht strikt nach den Idealen objektorientierter Programmierung entwickelt (WordPress ja aber wohl auch nicht), so dass eine Portierbarkeit einzelner Module unmöglich ist und alles von Grund auf neu zu programmieren ist.

Hat da jemand Plugins geschrien? Halten wir das doch mal gleich als Regel fest:

Gibt es ein gut gepflegtes Plugin, das genau die Lösung für die Anforderungen bietet, werde ich es gerne verwenden.

Nicht zu verwenden gedenke ich Plugins, die

1. Kompatibilitätsprobleme bei WordPress-Updates vermuten lassen
2. einen monströsen Funktionsumfang haben, von dem maximal die Hälfte der Erfüllung der Anforderungen dient
3. zur Anforderungserfüllung individueller Anpassung oder Erweiterung bedürfen oder
4. ihren Zweck nicht ohne umfangreiche Änderungen am Theme erfüllen.

In dem Fall schreibe ich das Plugin lieber selbst. Auch bei sensiblen Kundendaten, z.B. wenn es um Zahlungsschnittstellen geht, halte ich eine Eigenentwicklung für sicherer und vertrauenswürdiger.

Suchfunktion

In jedem Admin-Menüpunkt habe ich das gleiche universelle Suchformular. Es ermöglicht den schnellen Zugriff auf:

• Kundendaten
• Rechnungen
• User-Accounts
• Update-Codes
  Update-Codes ist das historisch bei Werbe-Markt.de verwendete Synonym für Lizenzschlüssel.

Task-Manager

Der Task-Manager ist das Admin-Modul, mit dem ich jeden Tag arbeite. Das Ding brauche ich auch in WordPress – vielleicht nicht mit jedem Schnickschnack, aber mit den elementaren Funktionen:

• Tasks haben
  • einen Namen
  • eine Priorität (1-5)
  • mindestens einen Unterpunkt
  • Meta-Angaben: Wer hat den Task wann erstellt?
  • einen Status: offen/erledigt
  • eine Bearbeitungszeit, die sich aus der Summe der Bearbeitungszeit der Unterpunkte errechnet
• Tasks entstehen
  • durch manuelles Anlegen durch einen Mitarbeiter
  • automatisch durch die Benachrichtigung seitens eines Payment-Gateway-Anbieters oder
  • automatisch zeitgesteuert wiederkehrend, z.B. für jährliche Leistungen und Abrechnungen
• Tasks sind
  • entweder einem Mitarbeiter zugeordnet
  • oder in einem Pool unzugeordneter Tasks
• Mitarbeiter können
  • nicht zugeordnete Tasks übernehmen
  • ihnen zugeordnete Tasks an andere Mitarbeiter abtreten
• Tasks sind optional einem Kunden und ggf. zusätzlich einem Produkt zugeordnet. In diesem Fall bestehen Schnittstellen zu anderen Modulen wie der Rechnungserstellung oder der Download-Bereitstellung.
• Task-Unterpunkte haben
  • einen Namen
  • einen durch die Farben schwarz, grün oder rot dargestellten Status
  • eine Bearbeitungszeit
  • ein Play-Icon, das den JavaScript-Timer für die Bearbeitungszeit aktiviert (das ist die Funktion, dank der ich Geld für Nahrung bekomme)
• Standardmäßig angezeigt werden nur aktive Tasks. Selbstverständlich gibt es jedoch eine komplette History und Suchfunktion.

Das war’s für’s Erste. Gold-Plating-Alarm: Der Task-Manager drängt sich förmlich auf, Schnittstellen zum Kunden-Account zu bieten. Nice to have wäre:

• Kunden können
  • Arbeitszeiten und Stati einzelner Unterpunkte live einsehen
  • Unterpunkte erstellen
  • den Status von Unterpunkten aktualisieren

Ich habe nicht vor, auch nur 1 Minute für die Recherche nach einem fertigen Task-Manager-Plugin aufzuwenden. Das werde ich selbst programmieren.

Im Übrigen muss keine Datenübernahme erfolgen. Ich kann mich nicht entsinnen, wann ich zuletzt die Task-History bemüht hätte. Sollte es dennoch nötig sein, greife ich auf das lokale Backup zu.

Rechnungen

Da ich mit den Arbeitszeiten aus dem Task-Manager im Kaufland nicht bezahlen kann, bedarf es des Umwegs über Rechnungen und entsprechende Zahlungsflüsse. Die Rechnungen selbst sind relativ schlank. Es ist das Drumherum, was den Aufwand verursachen wird:

• Rechnungen haben
  • eine unikäre, fortlaufende Rechnungsnummer
  • ein Bestelldatum
  • ein Rechnungsdatum
  • einen Status
    • offen
    • bezahlt
    • Teilzahlung erfolgt
    • storniert
    • 1-3 Erinnerungen und Mahnungen
    • Inkasso
  • Platz für rein interne Notizen
  • Optionen zum automatischen Versand von Erinnerungen:
    • keine Erinnerung senden
    • Erinnerungen senden mit
      • Option, vom Kauf zurückzutreten
      • Verweis auf das Inkasso
• Rechnungen sind
  • einem Kunden zugeordnet
  • mittels der Rechnungsnummer und einer Zahlen-Buchstaben-Kombination auch ohne Kunden-Account über https abrufbar. Das ist zwar nicht wesentlich unsicherer als die allseits übliche Übermittlung via E-Mail-Anhang. Trotzdem ist der Verzicht auf dieses ohnehin selten genutzte Feature erwägenswert.
• Rechnungen enthalten
  • ein Leistungsdatum, das gesetzeskonform in der übermittelten Rechnung aufgeführt ist
  • Kundendaten (Die offensichtliche Verletzung der zweiten Normalform der Datenbank-Normalisierung ist gewollt. Geänderte Kundendaten dürfen schließlich nicht eine bereits übermittelte Rechnung verändern.)
    • Anrede
    • Name (für die Ansprache des Kunden)
    • E-Mail-Adresse
    • Firma (optional)
    • Vorname
    • Nachname
    • Straße
    • Zusatz (optional)
    • PLZ
    • Ort
    • Land
      Die aktuelle Lösung mit der Auswahlmöglichkeit aus 20 Ländern und freier Texteingabe für den Fall, dass das Empfänger-Land nicht in der Liste steht, gefällt mir nicht. Alle erdenklichen Empfänger-Länder sollten auswählbar sein.
  • Lieferanschrift (falls postalischer Versand erforderlich) umfasst die bei Kundendaten genannten Felder von Firma bis Land.
  • Um das Rechnungs-Modul als Plugin anbieten zu können, werden mindestens noch eine Angabe für z.B. den Bundesstaat und für eine lokale Steuernummer erforderlich sein.
  • Bruttogesamtbetrag
  • angewandter Mehrwertsteuersatz
  • Website des Kunden (nur im Falle, dass eine bestellte Leistung domainbezogen erbracht wird)
  • ob es sich um einen gewerblichen oder privaten Kunden handelt
• Rechnungen sind verknüpft mit
  • Kunden-Accounts (immer, auch wenn der Kunde keine Login-Daten hat)
  • Leistungen (=die Rechnungspositionen)
    • Leistungen sind ihrerseits verknüpft mit
      • einem Kunden-Account (Diese Verknüpfung ist überflüssig. Im Sinne der Normalverteilung kann sie zu Lasten eines zusätzlichen JOINs aufgelöst werden.)
      • einem Produkt (außer Versandkosten immer)
      • einem Task-Unterpunkt (optional)
    • Leistungen haben
      • eine Anzahl
      • einen Preis
  • einem Angebot (sofern der Rechnung ein individuell übermitteltes Angebot vorausging)
  • Erinnerungs- und Mahnungsverlauf
    • Der Verlauf enthält lediglich das Datum der letzten Übermittlung.
  • Payment-Gateway-Benachrichtigungen (derzeit nur SOFORT Überweisung)
    • Transaktionsnummer
    • Betrag
    • Vermerk (falls eine Buchung nicht akzeptiert wird)
    • Zeitstempel
    • Rohdaten
  • Zahlungsverlauf
    • Betrag
    • Zeitstempel
    • Zahlart
    • Rechnungsstatus zu diesem Zeitpunkt
  • Vermerke für Stornorechnungen (nur bei Stornorechnungen)
• Rechnungen entstehen bei
  • Bestellung durch Kunden
  • manuelles Anlegen im Admin-Menü
    • in beiden Fällen:
      • Zuordnung zu bestehendem Kunden-Account oder Neuanlegen eines Kunden-Accounts
      • Automatische Mehrwertsteuersatzermittlung anhand des Landes, der Angabe, ob die Bestellung privaten oder gewerblichen Zwecken dient und ggf. Validierung der UstId-Nr.
  • Stornierung von Rechnungen im Admin-Menü
    • Stornorechnungen können sich über
      • den Gesamtbetrag der ursprünglichen Rechnung oder
      • nur einen Teilbetrag belaufen.
• Der Rechnungsstatus ändert sich durch
  • Benachrichtigung durch eine Zahlungsschnittstelle
  • automatischer Versand von Erinnerungen oder Mahnungen
  • manuelle Zahlungseingangsbestätigung im Admin-Menü
  • Storno im Admin-Menü
  • Übermittlung der Daten an die Inkassoagentur
• Events bei vollständiger Begleichung:
  • Lizenzcode-Generierung und -Speicherung (bei Software-Produkt)
  • Anlegen des Werbekontingents (bei Werbekampagnen-Buchung)
  • Automatische Generierung eines Tasks (falls anderweitige Leistung zu erbringen ist)
• E-Mail-Versand
  • Bestätigung des Bestelleingangs mit Rechnung und Widerrufsbelehrung (jeweils im PDF-Format) im Anhang bei Rechnungserstellung
    Je nach bestelltem Produkt oder Umsatzsteuerstatus des Kunden werden Textbausteine automatisch, bei Anlegen der Rechnung im Admin-Menü durch manuelle Auswahl in die E-Mail eingefügt.
  • Zahlungserinnerungen und Mahnungen unter Berücksichtigung der Optionen Rücktritt und Inkasso
  • Bestätigung einer Teilzahlung und Bitte um Begleichung des Restbetrages
  • Bestätigung der vollständigen Zahlung
    • bei ausstehender Leistung: Hinweise zur Leistungserbringung, z.B.
      • Bitte um Hinterlegung der Daten für eine Werbekampagne
      • Übermittlung von Lizenzcodes, Links zum Download
  • bei Stornierung:
    • Bestätigung der Rücküberweisung
    • Bestätigung der Entbindung von Zahlungsverpflichtung oder
    • Bitte um Mitteilung der Bankdaten für Rücküberweisung

Gutschriften

Obwohl sie mit den Rechnungen nicht viel zu tun haben, gibt es einen Unter-Menüpunkt Gutschriften.  In diesem gibt es eine Eingabemaske sowie ein Archiv der eingegebenen Daten, die da sind:

• Zeitstempel
• Bruttogesamtbetrag
• Mehrwertsteuersatz
• Art der Gutschrift, z.B. Werbeeinnahmen
• Vermerk, z.B. Google AdSense

Wofür die Speicherung von Gutschriften dient, wird aus dem nächsten Unter-Menüpunkt des Rechnungs-Moduls, Statistik, ersichtlich.

Statistik

Den Unter-Menüpunkt Statistik rufe ich auf, wenn ich meiner guten Laune einen Dämpfer verpassen möchte. Er zeigt anhand der Zahlungen und Gutschriften errechnete Summen gruppiert nach Mehrwertsteuersatz, Monat, Quartal und Art der Einnahmen, z.B. Werbung. Dabei fällt auf, dass ich meinen 2011 gefassten Entschluss, die Arbeitsstunden bei dennoch steigendem Umsatz zu reduzieren und mehr auf Werbeeinnahmen und fertige Produkte mit automatisierter Verkaufsabwicklung zu setzen in zweierlei Hinsicht verfehlt habe:

1. Der Umsatz ist zurückgegangen.
2. Die Anzahl Arbeitsstunden hat sich verdoppelt.

Sofern entsprechende Daten vorliegen, geht aus der Statistik auf optisch ansprechende Art auch die Veränderung (in meinem Fall: Der Rückgang) des Umsatzes im Vergleich zum jeweiligen Vormonat und dem Vorjahreszeitraum hervor. Anhand der vorliegenden Daten für das laufende Jahr wird auch eine Hochrechnung des zu erwartenden Gesamtjahresumsatzes präsentiert.

Keine Frage: Selbst wenn es ein Plugin gäbe, das diesen Funktionsumfang aufweist – bis ich mich in die Schnittstellen zu Task-Manager etc. eingearbeitet habe, habe ich es 3mal selbst programmiert. Selbstverständlich müssen sämtliche Bestandsdaten übernommen werden.

Downloads

Der Admin-Menüpunkt Download ermöglicht das Anlegen, Aktualisieren und Löschen von 4 Arten zum Herunterladen bereitgestellter oder per E-Mail anforderbarer Dateien:

1. Kostenlose Testversionen
2. Lizenzierte Versionen
3. Updates
4. Kunden

• Die 3 erstgenannten sind
  • gruppiert nach Software-Produkten mit beliebig vielen Downloads pro Software.
• Kostenlose Testversionen haben zudem
  • ein Ablaufdatum, anhand dessen allerdings nicht die Download-Möglichkeit abgeschaltet wird. Das Datum dient lediglich der Information. Die Gültigkeitsdauer ist in der Software selbst hinterlegt.
• Kunden-Downloads enthalten
  • einen Code, der den Download auch ohne Login ermöglicht
  • den Namen der Datei
  • die ID des Ihnen zugeordneten Kunden
  • die ID eines User-Accounts (optional und überflüssig, da die Zuordnung zum Account auch über die Account-Kunde-Korrelation erfolgen kann)
  • Bereitstellungsdatum
  • Gültigkeitsdatum
  • Download-Zähler
  • Beschreibung mit z.B. Hinweisen zur Verwendung der Datei
• Der Backend-Bereich des Download-Moduls bietet für alle Download-Arten die Möglichkeit:
  • des Datei-Uploads
  • der Komprimierung als zip und/oder gzip
  • der Konvertierung von zip nach gzip und vice versa
  • Download-Statistiken visualisiert mit der Google Chart API

Um die Notwendigkeit zur Migration des Download-Moduls beurteilen zu können, muss ich das Admin-Menü gedanklich kurz verlassen. Der Download für den Nutzer gestaltet sich aktuell so:

• Kostenlose Testversionen
  • Der Interessent fordert unter Angabe seiner E-Mail-Adresse einen zur einmaligen Verwendung gültigen Download-Link an. Dieses Prozedere sollte die Serverauslastung durch insbesondere den Zugriff von Bots auf die Download-Pakete minimieren, ist aber nicht gerade nutzerfreundlich.
• Lizenzierte Versionen und Updates
  • Kunden erhalten die gewünschte Version durch Angabe ihrer E-Mail-Adresse und des Update-Codes via E-Mail-Anhang.
    Hintergrund dieses auch etwas umständlichen Verfahrens war, das Risiko des nicht-authorisierten Zugriffs durch Brute Force Attacken oder fahrlässigen Umgang mit Download-Links zu minimieren.
• Kunden
  • Der Download wird im Admin-Menü manuell angelegt und automatisch eine E-Mail an den Kunden gesandt, die den Download-Link enthält.
    Der Download über https ist sicherer als die Übermittlung von Dateien per E-Mail-Anhang.Komprimierte Dateien muss ich zudem nur in einem Format hochladen. Das jeweils andere (zip/gzip) wird automatisch generiert und der Kunde hat freie Wahl.

Lösungsansätze:

• Kostenlose Testversionen
  • Aufgrund der Konsolidierung der Software-Produktpalette und des hohen Wartungsaufwands für die Bereitstellung kostenloser Testversionen ist aktuell ungewiss, welche Software zukünftig überhaupt als Free Trial verfügbar sein wird. Als Übergangslösung kann die Verlinkung extern gehosteter Downloads, z.B. im heise Software-Verzeichnis dienen, obgleich sowohl der Verweis auf eine externe Seite als auch der in puncto Usability nicht gerade vorbildliche Download-Vorgang bei heise gegen einen dauerhaften Einsatz der Lösung sprechen.
• Lizenzierte Versionen und Updates
  • Bestandskunden können die Software manuell per E-Mail anfordern. In den meisten Fällen lade ich die benötigte Version ohnehin direkt auf den Webspace des Kunden.
  • Die automatisierte Bereitstellung der Downloads für Neukunden ist ein Muss. Dafür benötigte ich allerdings kein Admin-Modul Download, sondern genügt die Möglichkeit des Uploads in der Produkt-Verwaltung. Die Generierung des Download-Links etc. erfolgt ohnehin im Modul zur Bestellabwicklung.
• Kunden
  • Kundenspezifische Dateien über eine sichere Verbindung zum Download bereitzustellen ist mein eigener Anspruch. Ähnlich wie – zugespitzt – ganz Deutschland über das Ausspionieren des privaten E-Mail-Verkehrs jammert, aber niemand 3 Minuten für die Installation von PGP bzw. Enigmail investieren möchte, hat niemals ein Kunde den unsicheren Transfer von Dateien via E-Mail-Anhang kritisiert.

Ergo: Ein Admin-Modul Downloads benötige ich in der neuen Website zumindest anfänglich nicht. Sowohl Funktionalität als auch gespeicherte Daten sind nicht Bestandteil der Migration.

Accounts

Der Admin-Menüpunkt Account-Verwaltung dient in erster Linie informativen Zwecken. Die beiden einzigen im Backend sinnvollen und auch weiterhin benötigten Aktionen sind:

1. Account löschen
2. Nachbildung des Login-Bereichs, damit vom Account-Inhaber gemeldete Probleme im Login-Bereich unkompliziert über das Admin-Menü nachvollziehbar sind.

Auch hier ist der vorweggreifende Blick über den Tellerrand des Admin-Menüs sinnvoll. Die User-Funktionen in Zusammenhang mit Werbe-Markt.de sind vor allem die obligatorischen:

• Registrierung
• Aktivierung
• Löschung
• Passwort-Recovery
• Login
• Passwort-Änderung
• Hinzufügen weiterer E-Mail-Adressen zum Account

Welchen Mehrwert für den Nutzer bietet ein Werbe-Markt.de-Account dann überhaupt? Neben dem unkomplizierteren Zugriff auf Downloads sind Accounts praktisch eine Zentrale für den Zugriff auf alle dem Account zugeordneten Informationen, die einzeln aber auch ohne Login abrufbar sind. Diese Informationen und zugehörige Aktionen sind im Einzelnen:

• Werbekampagnen-Verwaltung
• Verwaltung der Newsletter-Abonnements
• Rechnungsarchiv
• Software-Lizenzverwaltung
• Übersicht freigeschalteter Funktionsweiterungen zu Software und Bestellmöglichkeit nicht freigeschalteter AddOns
  Zum Punkt Funktionsweiterungen werde ich später noch kommen und entscheiden müssen, inwieweit es diese nach der Migration überhaupt noch geben wird. Vorab:
  Die domaingebundene Freischaltung von Zusatzfunktionen und insbesondere die Vorhaltung der Dateien für unterschiedliche PHP-Versionen etc. ist ein Heidenaufwand. Aus Entwicklersicht ist es zudem sehr frustrierend, aufwendig programmierte Funktionalität aus einem Software-Produkt wieder zu entfernen.
  Aus Kundensicht ist es jedoch äußerst beliebt, eine Software mit Grundfunktionalitäten zum günstigen Preis zu erwerben und sukzessive nach individuellem Bedarf zu erweitern.

Die einzigen, nicht ohne Account verfügbaren Funktionalitäten sind unter der Überschrift Community zusammengefasst:

• Profil anlegen, d.h.
  • Profil-Typ Organisation oder Person auswählen, wobei kein funktionaler Unterschied besteht, sondern die Angabe lediglich der korrekten Auszeichnung mit schema.org dient.
  • Öffentlich angezeigter Name
  • Ort
  • Website
  • Foto oder Firmenlogo
• Kommentare
  Auf einer Vielzahl von Seiten ist die Kommentarfunktion aktiv, um öffentlich Fragen zu stellen oder Feedback zu geben. Dabei ist auch eine Bewertung des Artikels durch Sternchen möglich und es können Antworten auf Kommentare gegeben werden.
• Rezensionen
  Rezensionen sind technisch betrachtet Kommentare, nur dass Sie sich logischerweise nicht auf Artikel, sondern auf Produkte beziehen und nur von Autoren verfasst werden können, denen ein Erwerb des zu rezensierenden Produkts oder Dienstleistung zuzuordnen ist.

Mit der Neugestaltung des Login-Bereichs werde ich mich in Kürze noch einmal auseinandersetzen. Den Admin-Menüpunkt Accounts benötige ich in seiner jetzigen Form nicht. Zu migrieren ist daher lediglich der Datenbestand von 1.420 Werbe-Markt.de-Accounts.

Kommentare & Rezensionen

Die jeweils 6 Kommentare bzw. Rezensionen werde ich mit Sicherheit händisch in WordPress einpflegen. Die Admin-Menüpunkte erlauben die Freischaltung, Bearbeitung und Löschung der Inhalte, dienen also primär der Kontrolle und der Information über neue Inhalte, auf die ggf. eine Antwort zu verfassen ist. Das ist nichts, was WordPress nicht auch könnte, weshalb keine neuen Funktionalitäten zu schaffen sind.

Nachrichten

Mit dem Nachrichten-Modul kann ich ohne großen Aufwand die Headlines kurzer Informationen auf die Startseite posten. Ein Link führt dann zum eigentlichen Artikel. Die News finden sich auch vollautomatisch, kategorisiert in einem RSS-Feed.

Diese 3 Sätze lesen sich schon sehr nach einer ganz knappen Zusammenfassung dessen, was WordPress macht. Funktionalitäten sind daher nicht zu übertragen, wohl aber die Inhalte der 103 seit 2003 verfassten News-Beiträge.

Bevor ich es vergesse und damit das Kapitel nicht zu kurz wird: Während ich mir bei vielen zu migrierenden Inhalten noch unschlüssig bin, ob sie als Posts oder Seiten in WordPress fungieren sollen, ist es bei den News ganz eindeutig: Sie werden als Beiträge das Archiv aufblähen.

Briefe

Damit hatten Sie nicht gerechnet, oder? Was normale Menschen mit einem Briefkopf oder einer Vorlage im Textverarbeitungsprogramm ihrer Wahl (also Word) umsetzen, hat der Webentwickler online. Die Funktionsweise ist einfach und komfortabel:

• Archiv aller verfassten Briefe mit
  • Stichwortsuche
  • Zeitraumsuche
• Ein Brief hat folgende Daten:
  • Empfänger (freie Texteingabe für Name und Anschrift)
  • Betreff
  • Text
  • Interne Vermerke zum jeweiligen Brief
• Funktionen:
  • Brief verfassen mit o.g. Daten
  • Automatische Übernahme der Emfängeradresse durch Angabe einer
    • Kunden-Nr.
    • Rechnungs-Nr.
  • Ersetzen in der Eingabemaske verwendeter Platzhalter durch Grafiken, um eine eingescannte Unterschrift im PDF-Dokument darzustellen
  • Automatischer Zeilen- und Seitennumbruch mit Zähler (Seite 1 von x, …)
  • Einfügen von Kopf- und Fußbereichen auf jeder Seite
  • Generierung und Ausgabe des Briefes im PDF-Format

Was sich nach relativ großem Funktionsumfang liest, ist eigentlich recht schnell programmiert, solange man es hart codiert und auf eine PHP-Klasse mit einfach anzusprechenden Methoden zur PDF-Generierung zurückgreift.

Die Übernahme bereits angelegter Briefe ist nicht erforderlich. Ich kann mich nicht entsinnen, jemals im Archiv geblättert zu haben. Alle generierten Briefe wurden zugestellt und liegen mir in Backups weiterhin vor. Das Modul selbst ist teilweise ganz hilfreich, die Umsetzung der Funktionen in WordPress hat jedoch niedrige Priorität und ist für den Relaunch  zunächst nicht erforderlich. Darum kann ich mich kümmern, wenn irgendeine Behörde ein Schriftstück von mir wünscht oder ein Bewerbungsschreiben dankend abzulehnen ist, weil es hier keine Jobs gibt und niemals auch nur mit einer Silbe an irgendeiner Stelle erwähnt wurde, hier wären Anstellungen zu vergeben.

Kunden

Das klingt sehr aufregend und nach dem Herzstück des Ganzen – ist es aber nicht. Das Kunden-Modul erlaubt die

• Einsicht und Bearbeitung von
  • Rechnungsdaten, d.h. Name, Anschrift und Gewerbestatus wie unter Rechnungen beschrieben
  • Kontaktdaten, d.h. ebenfalls wie oben beschrieben und bei Bestellungen angegeben:
    • E-Mail-Adresse
    • Telefon
    • Website
  • Bestellte Produkte einschließlich freigegebener Funktionsweiterungen
• Zusammenlegung mit einem anderen Kundenkonto
  Da ich praktisch nur noch mit Stammkunden zu tun habe, kommt das kaum noch vor. Aber in früheren Zeiten, als noch Verkäufe über die Website generiert wurden, war es nicht unüblich, dass ein und der selbe Kunde binnen weniger Wochen 3 Bestellungen mit 3 unterschiedlichen E-Mail-Adressen vornahm und somit 3 Kundenkonten erstellt wurden.
• Angabe des für den Kunden gültigen Stundensatzes.
  Rein prophylaktisch: Nur, weil selbstverständlich die technische Möglichkeit zur Angabe eines individuellen Stundensatzes besteht, heißt das nicht, dass die aktuell für alle gültigen 45,- EUR zzgl. Mwst. verhandelbar wären.

Kunden entstehen durch:

• Anlegen eines Angebots im Admin-Menü
  Der Begriff Kunde ist dabei etwas irreführend. Tatsächlich geht es natürlich nur um die Erfassung der Kundendaten. In der Datenbank ist ein Kunden jedoch ein Kunde – egal, ob er Produkte bestellt hat oder nicht.
• Rechnungsgenerierung im Admin-Menü
  Durch Eintragung der Rechnungsdaten für einen noch nicht existenten Kunden wird bei Generierung der Rechnung automatisch ein Kundenkonto mit angelegt.
• Erstbestellung durch Kunden
  Die Eingabemaske unterscheidet sich natürlich von der im Admin-Menü. Die Funktion selbst ist jedoch mit der Rechnungsgenerierung für Neukunden im Admin-Menü identisch.
• Bestellung von Bestandskunden ohne Login
  Dies ist der oben genannte und die Funktion Zusammenlegung mit einem anderen Kundenkonto erforderlich machende Fall.

Da die Aufzählung vollständig ist, ist auch klar, dass es keine Möglichkeit gibt, ein Kundenkonto explizit manuell anzulegen. Wozu auch? Dass das Kunden-Modul eine Schnittstelle zum Anlegen eines Kunden anbietet, die von oben genannten Funktionsbereichen angesprochen wird, ist absolut ausreichend.

Das Kunden-Modul ist auch für das Ergebnis bzw. ein Teilergebnis der oben genannten Suchfunktion verantwortlich. Dieser Auszug aus der Kundenverwaltung zeigt mir 3 Links, die ich durchaus häufig verwende (zumindest die ersten beiden) und die mit 3 anderen Admin-Modulen verknüpft sind:

1. Rechnung
   Eine Rechnung für bzw. an den jeweiligen Kunden generieren. In der Eingabemaske stehen bereits sämtliche erforderlichen Daten. Ich muss nur noch die Leistung und das Leistungsdatum eintragen sowie ggf. einen individuellen Vermerk.
2. Angebot
   Äquivalent zur Rechnung kann ich über diesen Link ein mit den Kundendaten vorausgefülltes, individuelles Angebot für den Kunden erstellen.
3. Download
   Dies ist eine Verknüpfung zum oben beschriebenen Download-Modul, das Dateien für den ausgewählten Kunden zum Herunterladen bereitstellt.

Die zusätzliche Anzeige, ob der Kunde auch über ein Werbe-Markt.de-Account verfügt, ermöglicht, schnell festzustellen und z.B. während eines Telefonats zu erwähnen, wie ein Kunde am schnellsten zu seinem Download gelangt. Unbedingt erforderlich ist diese Information jedoch nicht.

Selbstverständlich sind sämtliche Kundendaten zu migrieren. Da ich den Stundensatz bei zukünftigen Änderungen sukzessive, d.h. über einen Zeitraum von mehreren Wochen für einen Kunden nach dem anderen anpassen möchte, ist die Anpassungsmöglichkeit des Stundensatzes weiterhin erforderlich. (Ich kann ja nicht während laufender Projekte plötzlich den Stundensatz erhöhen.) Die Links zu Rechnung, Angebot und Download sind sehr hilfreich und sind ebenfalls ein Must-have für die neue Version. Hingegen benötige ich tatsächlich keine Einsicht oder Bearbeitungsoptionen für die Kundendaten selbst. Da das Kunden-Modul jedoch auf der WordPress-Benutzerverwaltung basieren wird, werden diese Funktionalitäten obligatorisch vorhanden sein.

Angebote

Das Admin-Modul Angebote ist dem Rechnungs-Modul derart ähnlich, dass der Entwickler beim Schreiben unwillkürlich schon an den Namen der gemeinsamen Parent-Class nachdenken muss (vielleicht irgendwas mit Contracts).  Datenerfassung und -umfang, Zuordnung von Leistungen und PDF-Generierung sind praktisch identisch, weshalb ich nur kurz die Unterschiede aufzähle.

Angebote haben im Gegensatz zu Rechnungen

• ein Ablaufdatum
• die Titulierung Angebot statt Rechnung
• keine Mahnstufen (wohl aber die Erinnerungsoption)
• einen Link zur Bestellung gemäß Angebot
• Bestell- statt Rechnungsstatus

Das war’s. Die funktionale Migration des Angebots-Moduls ist also mit der Anpassung des Rechnungs-Moduls schon zum größten Teil fertig. Alle Funktionen sind auch in der neuen Version erforderlich. Die Übernahme bestehender Angebotsdaten ist nicht nötig.

Linkpartner

Das klingt so anrüchig oder gar verboten. Tatsächlich ist die Verknüpfung von Inhalten aber doch der Hauptzweck des WWW.  Auf der vorliegenden Website geht es in erster Linie darum, dass Download-Portale, in denen die auf Werbe-Markt.de angebotene Software eingetragen ist, meist einen Gegenlink erwarten.

Da ich diesen Admin-Menüpunkt nur alle x Jahre mal aufrufe und mir für die mehr als 10 Jahre alte technische Realisierung erst einmal den Scriptcode ansehen müsste, beschränke ich mich auf eine oberflächliche Skizzierung der Funktionsweise:

Für jeden Linkpartner trage ich Name und E-Mail-Adresse des Ansprechpartners ein, den auf meiner Seite einzubindenden HTML-Code, die Seite, in deren rechter Seitenleiste der Link erscheinen soll sowie die URL der Seite, auf der der Link zu meiner Seite eingebunden sein sollte. Zu jedem Eintrag gibt es einen Prüfen-Button, der den Quellcode der angegebenen URL auf Vorhandensein des Links auf meine Seite kontrolliert und das entsprechende Ergebnis ausgibt.

Was machen wir damit? Klar ist: Bestehende Links müssen auf Aktualität geprüft und übernommen werden. Die zentrale Verwaltung von Linkpartnerschaften ist fast der einzige Weg, sollte ich mich in einigen Jahren mal wieder um den ein oder anderen Linktausch bemühen bzw. wieder häufiger jemand an mich herantreten. Andererseits gefällt mir die unflexible Anzeige der Links in der Seitenleiste nicht. Ich muss flexibel Links an praktisch jeder Stelle einer Seite anbringen können. Chic wären dabei data-Attribute wie data-partnerlink, um bei manuellem Einfügen des Links dessen Existenz zumindest automatisiert erkennen zu können. Jedoch wird nicht jeder Linkpartner ein data-partnerlink-Attribut in seinem <a>-Tag sehen wollen.

Link-Einbindung und -Verwaltung müssen daher separat erfolgen. Der doppelte Aufwand ist vertretbar, da es sich um eine äußerst selten genutzte Funktion handelt. Bleiben noch die Datenhaltung und die Linkchecker-Funktionalität. Das wäre zwar schnell programmiert, aber es müsste doch mit dem Teufel zugehen, sollte es hierfür kein brauchbares Plugin geben.

Profile

Welche Daten ein Profil erfasst, hatte ich schon unter Accounts vorweggenommen. Das zugehörige Admin-Modul ist deshalb eigenständig, weil Profile geprüft werden müssen, Accounts hingegen nicht. Zudem gibt es die Möglichkeit, Profile zu löschen, zugehörige Accounts aber beizubehalten.

Das sind auch schon die einzigen beiden Aktionen in diesem Admin-Modul. Da ich schon bei den Accounts entschieden habe, diesen Admin-Menüpunkt nicht zu benötigen, gilt das für die Profile, die ja praktisch nur ein optionaler Unterbereich der Accounts sind, ebenso.

Die 16 (einschließlich meines eigenen) Profile sind inklusive hochgeladener Fotos zu übernehmen, was jedoch keines aufwendigen Scripts zur Daten-Transformation bedarf. Die überschaubare Anzahl an Datensätzen legt das händische Einpflegen nahe. Die Prüffunktion ist bei der entsprechenden Erweiterung der Benutzerverwaltung zu berücksichtigen.

Newsletter

Das Admin-Modul Newsletter ist in zwei wesentliche Teilbereiche gegliedert.

Verwaltung auswählbarer Newsletter-Abonnements

Newsletter-Abonnements sind untergliedert in die Themenbereiche

• Allgemein
• Softwarespezifisch, d.h. jede angebotene Software repräsentiert einen Themenbereich

In der hierarchischen Ebene unterhalb dieser Hauptthemen können beliebig viele Unterthemenbereiche angelegt werden, z.B. unterhalb einer Software die Kategorien Updates und Neue Funktionen. Neben jedem vorhandenen Unterthemenbereich steht die Anzahl Abonnenten. Hauptthemen können nicht abonniert werden und dienen lediglich der strukturierten Darstellung in Front- und Backend, sowie, um Kunden oder Interessenten einer Software ein Abonnement der für Sie relevanten Newsletter empfehlen zu können. Die Erwähnung dieser Schnittstelle hatte ich bei den Modulen Rechnungen und Downloads natürlich übersehen.

Newsletterversand

Die eigentliche Funktionalität ist wenig überraschend und geht schon aus der Überschrift hervor. Unter Verwendung von Versandvorlagen und Platzhaltern für z.B. Abmelden-Links sind folgende Angaben erforderlich:

• Absender-Name
• Absender-E-Mail
• Auswahl des Empfängerkreises gemäß o.g. Unterthema
• Betreff
• E-Mail-Text im Textformat
• E-Mail-Text im HTML-Format

Newsletter werden via SMTP als Multipart-Messages versandt. So unglaubwürdig es klingen mag: Ich gehe nicht davon aus, ein Plugin zu finden, das diese von annähernd jedem Website-Betreiber genutzte Mitteilungsmethode ohne individuelle Anpassungen oder Fixes unterstützt. Meiner Erfahrung nach ist es schon schwer genug, ein Plugin rein für den SMTP-Versand zu finden, bei dem nicht noch Bugs zu beheben wären.

Wer besucht schon eine Website und füllt ein Formular aus mit dem einzigen Zweck, einen Newsletter zu abonnieren? Die Schnittstellen zu anderen E-Mails sind daher sehr wichtig und würden bei Verwendung eines Plugins einen großen Aufwand für die Anpassung erfordern.

Ich werde daher auf jeden Fall ein eigenes Plugin entwickeln, ggf. sogar hart codiert und nur für den Eigenbedarf. Bestehende Newsletter-Abonnements sind selbstredend zu migrieren.

Warenkörbe

Keine Sorge: Vollkommen anonymisiert zeigt mir das Admin-Modul Warenkörbe, welche Produkte in den vergangenen 90 Tagen von Interessenten ihrem Warenkorb hinzugefügt wurden. Ich schreibe deshalb Interessenten und nicht Kunden, weil die mittels Tortendiagramm grafisch ansprechend aufbereitete Statistik mir verrät, dass die Conversion Rate 0,00% beträgt.

Wer irgendwann einmal mit Marketing zu tun hatte, wird sich jetzt an den Kopf fassen, aber: Ich benötige weder das Modul noch die bestehenden Daten.

Seiten-Verwaltung

Das Modul ist nicht einmal mehr im aktuellen Admin-Menü verlinkt, weil ich Seiten nur lokal erstellt und dann hochgeladen habe – die letzte aber auch vor x Jahren. Kurz gesagt: Die Seiten-Verwaltung wird durch WordPress ersetzt.

Was ich bei der Gelegenheit anmerken muss: Asche auf das Haupt des Webentwicklers – ich nutze tatsächlich die visuelle Oberfläche zum Erstellen des Beitrags. Und schon jetzt, ganz ohne eigens definierte CSS-Klassen kommt es des öfteren vor, dass ich in die Code-Ansicht wechseln muss, um zum Beispiel <code>-Tags einzufügen oder Links mit title-Attributen zu versehen. Gerade letzteres ist ja wohl ein absolutes Unding für die beliebteste Blog-Software oder CMS. Ich werde den Editor also entsprechend konfigurieren müssen und dabei gleich meine handvoll individuellen CSS-Klassen mit unterbringen.

Zwischenfazit

Über Struktur und Methodik dieser Mixtur aus Anforderungsanalyse und -spezifikation mit partieller Zielformulierung und teilweiser Vorwegnahme der Realisierungswege lässt sich sicher streiten. Die Feststellung, welche Funktionen und Daten im Adminbereich zu übernehmen sind, ist jedenfalls abgeschlossen. Gleichzeitig sind wir auch schon mit dem Thema Migration des Datenbestands (genauer: der Datenbank) durch, denn alle für den Betrieb von Website und Service nötigen Datensätze hingen mit dem Admin-Menü zusammen.

Da es im Frontend eine größere Rollen spielen wird und ich es für das Admin-Menü noch gar nicht erwähnt habe – die Anforderung an das Layout des Backends lautet schlicht: So schlank wie möglich. Oberste Priorität hat die Umsetzung der Funktionen. Das Layout wird sich zunächst in das von WordPress eingliedern und sobald ich die Zeit finde, werde ich mit Ausblenden und Deaktivieren beschäftigt sein. Angefangen damit, dass ich keinerlei Sinn im Dashboard sehe über die Menü einklappen-Funktion, bei der mir immer noch genauso viele unschöne Icons angezeigt werden nur ohne Text bis hin zu Beitragsformaten wie Bild oder Zitat, die ich niemals zu verwenden gedenke.

Frontend-Funktionen

Wenn es Login-Bereiche für unterschiedliche Benutzerrollen gibt, müssen wir zunächst einmal klären, was das Frontend ist. Mit Frontend meine ich alles außerhalb des ausführlich beschriebenen Admin-Menüs, also einschließlich der nur Kunden, Newsletter-Abonnenten, Account-Inhabern etc. zugänglichen Bereiche.

Mit Funktionen meine ich die technischen Grundlagen für alles, was eine Interaktion zwischen Anwender und Website ermöglicht, wobei z.B. ein Aufklapp-Menü keine Funktion, sondern dem Layout zuzuordnen ist. Funktionen gehen meist mit dem Abruf und der Speicherung von Daten einher und/oder sprechen Schnittstellen an.

Kommentare und Rezensionen

Das Thema Kommentare ist schnell abgehandelt. Die native WordPress-Funktion lässt aktuell keine semantische Auszeichnung mit schema.org-Mikrodaten erkennen und das unsägliche Wirrwarr mit nicht änderbaren Benutzernamen, erforderlichen Spitznamen, realem Namen und Auswahl, was als öffentlicher Name fungieren soll, muss abgeschaltet werden. Dazu mehr an anderer Stelle. Wichtig ist, dass als Verfasser öffentlich der reale Name bzw. Firmenname dargestellt wird. Zumindest für die Mikrodaten-Auszeichnung wäre es doch verwunderlich, sollte es kein Plugin geben, das die nativen WordPress-Funktionen abdeckt.

Selbiges gilt für die Sternchen-Bewertung, mit der auf der obersten Hierarchie-Ebene der Beitrag benotet wird und bei Antworten auf Kommentare der Kommentar.

Rezensionen hatte ich in Zusammenhang mit dem entsprechenden Admin-Menüpunkt beschrieben. Hier muss ich eine Lösung finden, wonach Rezensionen den Funktions- und Datenumfang von Kommentaren erben und um die Schnittstellenabfrage, ob der Autor das zu rezensierende Produkt erworben hat sowie um die entsprechende Zuordnung zum Produkt erweitern. Auch Rezensionen sind semantisch auszuzeichnen und zwar in leicht abgewandelter Form gegenüber Kommentaren. Diese Ableitung von der Kommentarfunktion wird in jedem Fall selbst zu entwickeln sein.

Webseite als PDF exportieren

Handbücher zur Software im PDF-Format wurden durch Transformation der Support-Center-Inhalte von HTML nach PDF mittels einer entsprechenden PHP-Klasse erstellt. Somit lägen praktisch alle Webseiten im Bereich Support auch einzeln als PDF vor, sofern sie gespeichert worden wären. Tatsächlich wurden sie das nicht und stand keine einzige Webseite zum Export im PDF-Format zur Verfügung. Deshalb werde ich mich im unwahrscheinlichen Fall von Langeweile zwar mal nach einem Plugin umsehen. De facto ist jedoch kein PDF-Export einzelner Webseiten nötig.

Videos zu Webseiten

Das ist noch unnötiger und war bisher genauso wenig aktiv wie der PDF-Export. Angedacht war ursprünglich, Seiteninhalte mit Unterstützung von Screencasts in audiovisueller Form anzubieten. Ein Video-Icon, mit dem das Video in einem mit Highslide realisierten Modal öffnet, ist zukünftig nicht mehr erforderlich. Videos zu einzelnen Webseiten (tatsächlich gibt es schon 1 oder 2) können auch in der Webseite selbst eingebunden werden.

Merkzettel

Davon abgesehen, dass das Icon aktuell mit keinem Click-Event verknüpft zu sein scheint, war dies eine durchaus nützliche Funktion für den Anwender. Ähnlich der Lesezeichen-Funktion im Browser konnten einzelne Seiten cookie-basiert durch einen einzigen Klick dem persönlichen Merkzettel hinzugefügt werden und durch 2 Klicks später wieder aufgerufen werden. Die Merkzettel-Funktion wird entweder mit einem fertigen Plugin realisiert oder es wird sie nicht mehr geben.

Anbindung sozialer Netzwerke

Die Anbindung sogenannter sozialer Netzwerke beschränkte sich bisher auf eine selbst entwickelte 2-Klick-Lösung für die Schnittstelle von AddThis (inzwischen eingestellter Dienst) und das Google Authorship markup.

Was tun? Kein Mensch braucht diesen sozialen Blödsinn. Die Anbindung erfüllt allerdings den Selbstzweck, dass Kunden, die sich ganz im Sinne von Me-too dazu genötigt fühlen, irgendwas mit Facebook auf der Seite haben zu müssen, sehen können, dass der Webentwickler ihres Vertrauens auch so etwas hat. Und wenn wir uns schon zur Facebook-, Google- und Twitter-Schlampe machen, dann auch richtig. Äquivalent dazu: Wenn wir schon mal das Sprachniveau auf das bei sozialen Netzwerken übliche senken, dann ebenfalls richtig: Eine Verknüpfung zu Seiten oder den für die Schnittstellen-Entwicklung ohnehin schon vorhandenen Accounts könnte automatisiert irgendwelchen Müll an Pinnwände oder ähnliches rotzen.

Bleiben wir aber zunächst bei den reinen Frontend-Funktionalitäten: AddThis möchte ich aufgrund der fehlenden Transparenz und Kontrolle nicht mehr auf der Seite haben. Mit Sicherheit wird es ein Plugin geben, dass die wichtigsten bzw. populärsten sozialen Netzwerke oder Bookmarking-Dienste unterstützt. Bzgl. des Google Authorship markup ist Google meinem Kenntnisstand nach zur Einsicht gelangt, dass es – genau wie das gesamte GooglePlus-Projekt – völlig sinnfrei und ohne jeglichen Mehrwert für den Anwender ist. Als langjährige Google-Bitch werde ich dazu natürlich noch einmal kurz recherchieren, wenn ich mich wieder beruhigt habe. Aber aller Wahrscheinlichkeit nach wird diese Verknüpfung entfernt.

Warenkorb

Selbstverständlich ist der Warenkorb mit den verfügbaren Produkten und dem Prozess des Bestellens verknüpft. Tatsächlich ist er aber technisch betrachtet nicht viel anders als der oben genannte Merkzettel und kann durchaus als eigenständiges Modul betrachtet werden. Als solches wäre der Einsatz eines reinen Warenkorb-Plugins denkbar. Sollte sich hierzu keine geeignete Lösung finden, sind es zugegebenermaßen aber auch nur ein paar Codezeilen, mit denen ein Warenkorb-Modul alternativ selbst entwickelt ist.

Live-Suche

Der Teilbegriff Live rührt daher, dass die Suche beim Eintippen des Suchbegriffs via XHR ausgeführt wird. Das ist absolut unnötig und diente in erster Linie auch nur zu Demonstration, um Kunden dazu anzuregen, selbst das Bedürfnis nach einer solchen Live-Suche auf der eigenen Website zu haben.

Die Filter-Kriterien nach Bereich (Software, Support, …) und nach Software waren da schon sinnvoller und es wäre wünschenswert, gäbe es ein Plugin zur entsprechenden Erweiterung der nativen WordPress-Suchfunktion. Mindestens aber muss aus dem Suchergebnis hervorgehen, aus welchem Bereich (Kategorie) der jeweilige Treffer stammt. Idealerweise werden die Suchergebnisse gruppiert nach Kategorie präsentiert.

Die zusätzlichen Suchoptionen Exakter Ausdruck, Alle Wörter, Eines der Wörter wären 100%ig mit einem Plugin umsetzbar, halte ich aber für unnötig. Das gilt ebenso für den seinerzeit mühevoll programmierten Cache für die Treffer zu häufigen Suchanfragen und die Unterteilung in Top-Ergebnisse und weitere Ergebnisse.

Standardmäßig zeigt WordPress in den Suchergebnisse immer das Default-Exzerpt von Seiten oder Beiträgen. Das ist unter dem Umstand ganz sinnvoll, wenn der Anwender einen relativ allgemeinen Suchbegriff eingegeben hat. Je spezieller der Suchbegriff, desto sinnvoller ist es allerdings, in jedem Fall den Ausschnitt des Treffers anzuzeigen, der den Suchbegriff enthält und diesen natürlich auch (farblich) markiert darzustellen. Für ein diesen Zweck erfüllendes, fertig verfügbares Plugin wäre ich daher sehr dankbar.

Die letzte Teilfunktion der Suche ist etwas kompliziert zu erklären und noch komplexer zu programmieren: Es geht um die Autovervollständigung (oder auch: Suggest) bei der Eingabe eines Suchbegriffs. Als Datenquelle für die Vorschläge fungieren sowohl Meta-Keywords von Webseiten, als auch von Anwendern vorangegangen eingegebene Suchbegriffe, die zu mindestens einem Treffer führten. Theoretisch würde letztgenannte Datenquelle ausreichen. Die Meta-Keywords weisen jedoch im Schnitt die höhere Relevanz und Qualität auf. Außerdem stehen sie von Anfang an zur Verfügung, während eine Datenbank mit eingegebenen Suchbegriffen erst einmal aufgebaut werden muss.

Meine Motivation, zukünftig veröffentlichte Inhalte händisch mit Meta-Keywords zu versehen, hält sich in Grenzen. Automatisierte Lösungen zur Extrahierung von Schlüsselwörtern liefern erfahrungsgemäß eine niedrige Datenqualität (am repräsentativsten für eine Webseite wären dann „und“, „ist“ etc., so dass mit Ausschlusswörtern hantiert werden müsste). Die Lösung ist daher, die Speicherung von Suchbegriffen, die zu Treffern führten als Datenquelle für die Autosuggest-Funktion. In den alten Seiten vorhandene Meta-Keywords sind als Datenbasis zu migrieren. Für die Autosuggest-Funktion selbst wird ja hoffentlich ein Plugin verfügbar sein.

Registrierung, Login, Zugangsdatenanforderung

Diese 3 Funktionen beziehen sich rein auf die kostenlosen Werbe-Markt.de-Accounts und sind zunächst unabhängig von Kundenkonten, der Verwaltung von Newsletter-Abonnements etc.

Bei der Registrierung über das Formular auf der Website sind anzugeben:

• E-Mail-Adresse
• Passwort

Beide sind zur Kontrolle auf Tippfehler jeweils zu wiederholen. Des Weiteren müssen durch Aktivierung von Checkboxen akzeptiert werden:

• AGB
• Hinweise zum Datenschutz
• Widerrufsbelehrung

Die Aktivierung des Accounts erfolgt mittels des obligatorischen, via E-Mail zugestellten Bestätigungslinks (Double Opt-in).

Aus den erhobenen Daten bereits ersichtlich: Die Authentifizierung beim Login erfolgt ausschließlich über die Kombination E-Mail-Adresse und Passwort. Es gibt keinen gesonderten Loginnamen oder ähnliches.

Über die Verknüpfung zu anderen Funktionen (z.B. das Rechnungsarchiv) hinaus bietet der Login-Bereich nachfolgende Kernfunktionen von Werbe-Markt.de-Accounts:

• E-Mail-Adressen-Verwaltung mit den Unterfunktionen
  • E-Mail-Adresse hinzufügen (wiederum mit Double Opt-in-Verfahren)
  • Primäre E-Mail-Adresse festlegen (nur, wenn dem Account mehrere E-Mail-Adressen zugeordnet sind)
  • E-Mail-Adresse löschen (bis auf die primäre E-Mail-Adresse können mit dieser Option dem Account zugeordnete E-Mail-Adressen entfernt werden)
• Passwort-Änderung (ohne Erfordernis eines erneuten Logins)
• Account-Löschung (entfernt alle essentiellen Daten des Accounts, aber keine mit dem Account verbundenen Daten anderer Funktionen wie z.B. Newsletter-Abonnements)
• Profil anlegen (wie schon beim Admin-Modul Accounts beschrieben )

Wie schon unter Kommentare und Rezensionen und in Zusammenhang mit dem Admin-Menü erwähnt: Ohne Account kein Profil und ohne Profil keine Kommentare oder Rezensionen.

Das Ausfüllen des Registrierungsformulars auf der Website ist jedoch nicht die einzige Variante, ein kostenloses Werbe-Markt.de-Account zu eröffnen. In vom System versandten E-Mails (z.B. Zahlungseingangsbestätigungen) sind Links enthalten, die zu einer verkürzten Form des Registrierungsformulars führen. In diesem Fall ist die E-Mail-Adresse durch Klick auf den Link bereits bestätigt und es muss nur noch das für den Login erforderliche Passwort angegeben werden.

In Ermangelung tiefgehender Kenntnisse der WordPress-Benutzerverwaltung beschränke ich mich zunächst auf die Anwendersicht: Das Prozedere muss nach der Migration auf der Oberfläche genauso ablaufen wie bisher. Dies gilt insbesondere für die Rollentrennung: Kunden können ein Werbe-Markt.de-Account haben, müssen es aber nicht. Inhaber eines Accounts können Kunden sein, müssen es aber nicht u.s.w.

Die Lösung ist also ein selbstprogrammiertes Plugin, das eine neue Benutzerrolle User mit den entsprechenden Capabilities und der Möglichkeit zur Verknüpfung mit anderen Modulen in 1:1- und 1-n-Beziehungen schafft.

Zu prüfen ist in diesem Zusammenhang ferner die Möglichkeit der Anmeldung mit Facebook etc. auf Basis von OAuth 2.

Bei der Passwort-vergessen-Funktion bin ich relativ offen. Denkbar wäre die automatische Generierung eines neuen Passwortes und Versand via E-Mail, besser aber der Versand eines einmalig gültigen Login-Links, der einen Hashwert enthält oder eines ganz ähnlichen Links, der nicht direkt in den Login-Bereich führt, sondern die Angabe eines neuen Passworts ermöglicht. Letztgenannte Möglichkeit ist die sicherste der drei, zweitgenannte die anwenderfreundlichste.

Verwaltung von Werbekampagnen

An dieser Stelle müsste ich entweder etwas ausholen und die geplanten Änderungen an den Werbeprodukten vorwegnehmen, die Schnittstellen zum Rechnungswesen und zur Seite, auf der die Werbeanzeigen geschaltet werden sollen, erläutern oder ich mache es mir einfach: Das Anzeigenmanagement-Modul ist derart komplex und in Relation dazu von zu geringer Bedeutung, als dass es in der ersten auf WordPress basierenden Version von Werbe-Markt.de von Beginn an enthalten sein würde.

In seiner alten Version umfasst das Werbeanzeigenmanagement-Modul folgende Funktion:

• Angabe der Link-URL
• Angabe des Anzeigencodes, i.d.R. ein <img>-Tag zur Darstellung eines Werbebanners einer entsprechend gebuchten Größe
• Pausieren und reaktivieren von Werbeanzeigen
• Einsicht in Statistiken zur Werbekampagne

Diese grundlegenden Funktionen wird es zu einem späteren Zeitpunkt natürlich auch wieder geben. Der Fokus soll jedoch mehr auf Text- denn auf Imageanzeigen liegen. die Zielgruppe soll genauer definierbar sein (als aktuell gar nicht) und ich tendiere stark dazu, keine festen Werbepakete mehr zu offerieren, sondern freie Werbeplätze gemäß Geboten zu belegen mit Guthabenaufladung und Tageslimit, sowie ggf. zeitgesteuerter Planung der Anzeigen.

Genau: Das Modul ist von kaum geringerer Komplexität als eines, mit dem andere Firmen Milliardenumsätze generieren. Bei mir dient es allerdings der Restplatzvermarktung mit Geboten ab 0,01 EUR TKP oder CPC mit einem erwarteten Umsatz von unter 1,00 EUR pro Monat. Als Plugin verkaufen lassen wird es sich auch schwierig, weil es lediglich Schnittstellen zum AdServer haben soll, aber selbst keine Anzeigen ausliefern. Aus diesen Gründen steht die Entwicklung des Werbeanzeigen-Moduls ganz weit hintenan.

Newsletter-Abos

Wie schon in der Beschreibung des korrespondierenden Admin-Moduls vorweggenommen, sind zwei grundlegende Funktionalitäten von Relevanz:

• Schnittstellen zum Versand anderer E-Mails als Newsletter
• Eine Art „Login Light“ zur Auswahl abonnierter Newsletter bzw. Abmeldung

Darf ich nochmal schieben? Ein „sauberes“ Newsletter-Plugin mit Unterstützung für SMTP, E-Mail-Anhänge, Text-, HTML und Multipart-Format, zeitgesteuertem Versand, in mind. 2 Ebenen kategorisierbaren Abonnements, grafisch aufbereiteten Statistiken der Lese- und Klickrate, verfügbar in einer kostenlosen und einer Pro-Version würde bestimmt 3-4 Arbeitstage für die Entwicklung in Anspruch nehmen. Fügen wir noch eine Analyse der Rückläufer hinzu (Stichwort: Gold Plating), käme nochmal ein Tag hinzu. Ein Plugin für den Eigenbedarf hätte ich in weniger als einem Tag programmiert.

Ein weiteres Pro-Kontra-Pärchen: Bereits verfügbare, professionelle Lösungen wie die angedachte sind an einer Hand abzuzählen und der Bedarf ist groß. Andererseits scheint der Trend hin zu externen Dienstleistern zu gehen, die die selben Features wie das Plugin gegen monatliche Gebühren anbieten und den großen Vorteil haben, ein Outsourcing des Blacklisting-Risikos zu ermöglichen.

Ich werde dann zu gegebener Zeit eine Konkurrenzanalyse vornehmen (klar…), Chancen und Risiken durchleuchten (natürlich…) und auf Basis einer Balanced Scorecard (ja, das war jetzt übertrieben) entscheiden, welches Plugin es werden wird.

Rechnungen

Der Versand von Rechnungen via E-Mail-Anhang ist an das Bestellwesen gekoppelt. Es ist allerdings nicht viel mehr als ein 3-Zeiler, der eine Rechnung auch im Browser anzeigen lässt. SSL hin oder her ist es nicht gerade sicher, eine Rechnung direkt über einen Link, der neben der Rechnungsnummer eine 10stellige Zahlen-Buchstaben-Kombination enthält, zum Abruf bereitzustellen. Dafür ist es die nutzerfreundlichste Variante, Kunden auch ohne Account Rechnungen zugänglich zu machen und unsicherer als die Zustellung mittels unverschlüsselter E-Mail ist es auch nicht.

Ich tendiere zu einer Hybrid-Lösung: Solange anzunehmen ist, dass der Kunde über das Web und ohne Account-Login auf die Rechnung zugreifen möchte, ist der Zugriff möglich. Konkret: Solange eine (Teil-)Zahlung aussteht, ist die Rechnung online ohne Login abrufbar. Bei Stornierung oder vollständiger Begleichung wird der Zugriff auf die Rechnung automatisch deaktiviert. Sie ist dann nur noch mit Account und Login für den Kunden abrufbar und natürlich kann er sie manuell bei mir per E-Mail anfordern.

Downloads

Dazu hatte ich bei der Erläuterung des Admin-Moduls schon alles notwendige beschrieben. Der relevanteste Part sind die für Kunden verfügbaren und eine Lizenz bzw. Update-Code gekoppelten Downloads. Komplexer als die Downloads selbst ist deren Peripherie:

• In der Produkt-Verwaltung ist anzugeben, ob ein Lizenzschlüssel bzw. Update-Code generiert werden soll bei
  • Bestellung oder
  • Zahlungseingang

  optional versehen mit einer Gültigkeitsdauer. Dieser Code ist aber nicht der Rechnung bzw. Bestellung zuzuordnen, weil es zumindest theoretisch möglich sein muss, einem „Kunden“ durch Lizenzschlüsselzuweisung Downloads freizugeben, ohne dass er ein entsprechendes Produkt bestellt hätte. Einem Kundenkonto oder Nutzerkonto ist er auch nicht zuzuordnen, weil bei beidem keine Verpflichtung zur Erstellung bestehen darf bzw. es bei Werbe-Markt.de überhaupt keine Kundenkonten mit Möglichkeit zum Login gibt. Deshalb ist die Koppelung des Lizenzschlüssels an eine E-Mail-Adresse durchaus sinnvoll – nichtzuletzt zur Ermöglichung einer „Lizenzschlüssel vergessen“-Funktion.

• Im Rechnungs-Modul werden die Einstellungen aus der Produkt-Verwaltung abgefragt, der Code generiert und gespeichert.
• Der Datenbank-Eintrag zum Code enthält neben dem Code selbst also die E-Mail-Adresse und referenziert das Produkt.

Was wir jetzt immer noch nicht haben, sind Downloads. Das bisherige Prinzip bleibt bestehen: Mittels E-Mail-Adresse und Update-Code erfolgt der Zugriff auf Dateien, die über das Web nicht direkt erreichbar sein dürfen. Die Dateien selbst können zunächst einmal einfach nur via FTP hochgeladen sein oder ich komme doch schon in der ersten Version dazu, ein Admin-Modul Downloads zu kreieren.

Denkbar wäre auch, eine Upload-Möglichkeit in der Produkt-Verwaltung zu schaffen. Eine weitestgehende Trennung der Module ist aber die zukunftssicherere Variante, da der Code übersichtlicher bleibt und die Module unabhängig voneinander weiterentwickelt werden können.

Test-Versionen und sonstige öffentlich zugängliche, also nicht an Lizenzen gebundene Downloads sind erst einmal zweitrangig und mit der einfachsten Lösung zur Verfügung zu stellen.

Lizenzen und Update-Codes verwalten

Das hatte ich ja ganz übersehen. Tatsächlich handelt es sich um eine Funktion, die aktuell auch nur mit Werbe-Markt.de-Account zur Verfügung steht und die es bei der Download-Verwaltung zu berücksichtigen gilt. Die Beschreibung auf der entsprechenden Seite im Login-Bereich sagt eigentlich alles aus:

Update-Codes sind standardmäßig an die E-Mail-Adresse gekoppelt, an welche Ihnen Ihre Rechnungen gesandt wurden. Verwenden Sie für Ihr Projekt jedoch eine abweichende E-Mail-Adresse, sollten bzw. können Sie Ihren Update-Code auf diese E-Mail-Adresse übertragen unter der Voraussetzung, die E-Mail-Adresse wurde zuvor unter Ihre E-Mail-Adresse(n) hinzugefügt und verifiziert.

Die Zuordnung kann nur einmal pro 3 Monate geändert werden!

Natürlich kommt es im Lauf der Jahre vor, dass eine E-Mail-Adresse nicht mehr aktuell ist (bei manchen auch schon nach 2 Wochen). Außerdem darf eine erworbene Lizenz auf einen neuen Lizenznehmer übertragen werden, dessen E-Mail-Adresse in diesem User-Menüpunkt eingetragen werden kann.

Aus Gründen der Nachvollziehbarkeit („Ich habe vor ca. 5-10 Jahren eine Software bei Ihnen gekauft. Damals hatte ich noch einen anderen Name, habe keine Ahnung mehr, unter welcher E-Mail-Adresse ich bestellt habe oder welche Software es war. Jetzt haben wir es Sonntag, 23.15 Uhr. Ich gebe Ihnen Zeit bis 23.18 Uhr, mir die Software zu übermitteln. Andernfalls werde ich rechtliche Schritte gegen Sie einleiten.“ Folge-Mail, Sonntag, 23.21 Uhr: „Eben komme ich von einem Termin bei meinem Anwalt. Sie können sich auf etwas gefasst machen.“) wird eine History der E-Mail-Adressen angelegt, an die der Update-Code in welchem Zeitraum gekoppelt war.

Bei der Gelegenheit fällt mir auch auf, dass eine zusätzliche Koppelung des Update-Codes an das Kundenkonto, das ja zumindest intern generiert wird, zwar vorhanden ist, aber wohl fehlerhaft. Einen Kunden habe ich in der Regel schnell gefunden und kann nachvollziehen, dass er das Produkt auch erworben hat. Die Verknüpfung des Kunden zum Update-Code ist aber nur gewährleistet über den komplexen Umweg der E-Mail-Adresse, an die ihm die Rechnung für das Produkt gesandt wurde in Verbindung mit der Update-Code-History. Die bestehenden Daten müssen entsprechend ergänzt werden.

So oder so ist die Funktion nicht schwer zu programmieren. Natürlich benötige ich sie auch im Admin-Menü, weil es für den Kunden in vielen Fällen einfacher ist, mich per E-Mail oder telefonisch um die Übertragung seines Update-Codes auf seine aktuelle E-Mail-Adresse zu bitten. Ich tendiere dazu, die Funktion weiterhin nur im Login-Bereich zugänglich zu machen, um die Beschränkung der Übertragung auf verifizierte E-Mail-Adressen beibehalten zu können.

Funktionserweiterungen

In Zusammenspiel mit der Produkt- und Kunden-Verwaltung ist hinterlegt, welcher Kunde welche Funktionsweiterung bestellt hat und ein entsprechendes Anrecht auf Freischaltung durch Übermittlung einer Datei hat, mit der die AddOns domaingebunden auf seiner Website aktiv werden. Dabei fällt gleich eine Inkonsistenz auf: Lizenzen sind primär an eine E-Mail-Adresse und nur sekundär an einen Kunden gekoppelt. Funktionsweiterungen, die einer Lizenz bedürfen, sind jedoch an den Kunden gebunden. Richtig wäre, die Erweiterungen an die Lizenz zu binden, da ein Kunde ja bspw. 2 Lizenzen haben kann, aber nur für eine davon auch AddOns. Damit könnte der Eintrag für die Domain auch von den einzelnen Funktionsweiterungen losgelöst und auf den Update-Code übertragen werden.

Was dennoch schon funktioniert, ist die Kontrolle, dass ein Kunde keine bereits bestellte Funktionserweiterung pro Lizenz doppelt bestellen kann.

Ungeachtet dessen: Wie schon oben erwähnt steht das Prinzip der kostenpflichtigen, modularen Erweiterung auf dem Prüfstand und solange es nach der Migration keine AddOns zu bestellen gibt, müssen auch keine verwaltet werden. Welche AddOns welchem Kunden zur Verfügung stehen, geht aus Backups und den migrierten Rechnungen hervor. Das war es dann auch schon in puncto Funktionserweiterungen auf absehbare Zeit.

Reseller-Bereich

Es ist bestimmt schon 10 Jahre her, dass ich zuletzt Reseller-Lizenzen vergeben habe. Die Funktion war so einfach wie effektiv: Ein Reseller hat bspw. 50 Lizenzen erworben. Für jede von ihm weitergegebene Lizenz trägt er die E-Mail-Adresse des neuen Lizenznehmers ein und diesem wird ein Update-Code zugeordnet – genau so, als hätte er die Software direkt bei Werbe-Markt.de gekauft.

Daraus wird auch ersichtlich, warum Update-Codes an E-Mail-Adressen und nicht (nur) an Kundenkonten gekoppelt sein mussten. Außer der E-Mail-Adresse lagen keine Daten des Lizenznehmers vor und er ist schlichtweg nicht mein Kunde.

Dieser Punkt fällt weg. Es ist zwar schade um tausende Original-CDs, die noch im Lager sind, aber niemandem wäre geholfen, die aus der Mode gekommene Ware zu verramschen.

Referenz-Listen-Eintrag

Zu jeder angebotenen Software gibt es eine Seite, auf der Referenzen vorgestellt werden. Diese besteht zum einen Teil aus redaktionell mit Screenshot und kurzer Beschreibung vorgestellten Websites, zum anderen Teil aus einer schlichten Auflistung von Kunden der Software eingetragener Referenzen.

Die Referenzen waren eine der ersten Anlaufstellen für Interessenten. Sie ermöglichten einen unkomplizierten Eindruck, was mit der Software möglich ist. Allerdings sind fast ausnahmslos veraltet und werfen kein gutes Licht auf die Software-Produkte. Außerdem stammt die Referenz-Liste noch aus einer Zeit, in der es noch keine Möglichkeit gab, die erworbene Software zu rezensieren. Aus vorgenannten Gründen sind Referenz-Listen-Einträge obsolet und müssen weder migriert werden, noch muss die Funktion weiterhin bestehen.

Bestellen

Der Bestellvorgang unterscheidet sich im Wesentlichen nicht von dem anderer Shops. Man fügt seinem Warenkorb Produkte hinzu und klickt den „Zur Kasse“ betitelten Button, der zu einer zusammenfassenden Übersicht aktuell im Warenkorb befindlicher Artikel führt.

Was ganz einfach wirkt, ist tatsächlich schon kompliziert. Für manche Produkte fallen Versandkosten an, für reine Dienstleistungen wiederum nicht. Dies ist über die Produkt-Verwaltung geregelt. Tatsächlich wird bei den 4,20 EUR dargestellten Versandkosten von einem Kunden mit Lieferanschrift in Deutschland ausgegangen.

Machen wir es erst noch komplizierter, bevor wir über Lösungsansätze nachdenken: Die Original-CDs sind veraltet, die Software wird in jedem Fall zum Download angeboten und während einige Kunden den Versand auf Original-CD durchaus zu schätzen wussten, beschwerten sich andere nicht ganz zu Unrecht über den in ihren Augen überflüssigen postalischen Versand.

Die Lösung für letztgenanntes Problem habe ich schon seit mehreren Jahren im Kopf und ist ganz einfach: Der Kunde soll selbst entscheiden, ob er die Software ausschließlich via Download oder zusätzlich auch auf Original-CD haben möchte.

Meinem Wissensstand nach verlangt aber nun der Gesetzgeber, Versandkosten überall mit anzugeben, wo Preise genannt werden, auch wenn die Höhe der Versandkosten in Unkenntnis des Lieferlandes noch überhaupt nicht feststehen können, solange man keine Versandkostenpauschale „weltweit“ veranschlagt.

Dann nehme ich jetzt entweder 1.000,- EUR in die Hand, laufe damit zum Anwalt und erhalte eine schwammige und rechtlich nicht bindende Auskunft über die empfohlene Vorgehensweise. Oder aber ich bin so tollkühn und lasse sämtliche Versandkostenangaben weg, solange der postalische Versand nicht obligatorisch ist (und das ist er bei keinem meiner Produkte). Möchte ein Kunde die Original-CD haben, kann er nach Angabe der Lieferanschrift inklusive Empfängerland ein Häkchen setzen und die Versandkosten werden hinzuaddiert.

Das nächste Problem, für das es aber keine praktikable Lösung gibt, ist die deutsche Umsatzsteuer. Die werde ich einfach weiterhin angeben, obwohl sich meine Angebote ausschließlich an Gewerbetreibende richten und Kunden aus der Karibik ebenso keine deutsche Umsatzsteuer zahlen müssen wie Österreicher mit gültiger UstId-Nr. etc. – die Schweiz lasse ich schon ganz bewusst außen vor kann mir aber nicht verkneifen: Wo ist der Ort der Leistungserbringung, wenn ein Schweizer im Panama-Urlaub bei einer deutschen Firma Software bestellt und von einem US-Server herunterlädt? Ist der Schweizer Privatmann oder bestellt er für seine Firma? Der Serverstandort ist übrigens Deutschland – ich wollte nur noch etwas draufsatteln.

Fahren wir mit unserer Bestellung fort, bevor ich mit sich widersprechenden Gesetzestexten, 5 OLG-Urteilen vs. 3 OLG-Urteilen und der wiederum ganz anderen Auffassung des BGH anfange. Im 2. Schritt werden die Rechnungs-, Liefer- und Kontaktdaten erfasst.

Pflichtfelder sind tatsächlich nur die für die Rechnung und deren Übermittlung per E-Mail benötigten Angaben. Was aber nun, wenn der Kunde gar keine Rechnung benötigt? Soll er dann trotzdem alle Felder ausfüllen müssen? Von mir aus ja, weil während geschäftliche Kunden (wie gesagt: Das sollten prinzipiell alle sein) entweder selbst die ausgewiesene Ust. geltend machen können oder ich bei z.B. Nicht-EU-Kunden selbst die Rechnung benötige. Ich denke, ich werde auch das Plugin erst einmal so programmieren.

Aber noch ein spannendes Thema spielt sich in diesem Schritt des Bestellvorganges ab. Auf dem Screenshot ist „Deutschland“ als Land der Rechnungsanschrift ausgewählt. Wähle ich nun Österreich oder ein anderes EU-Land aus, erscheint rechts ein Eingabefeld für die UstId-Nr. Deren Angabe ist auf dieser Seite noch ohne Funktion, aber mit weitreichenden Folgen für die weitere Bestellabwicklung: Es ist aktuell keine API zur Validierung der UstId-Nr. angebunden und ich bin mir auch nicht sicher, ob es eine verlässliche Lösung dafür gibt. Tatsächlich ist es aktuell so, dass bei angegebener UstId-Nr. die Bestellung nicht automatisch den Versand einer Rechnung nach sich zieht, sondern mir die Daten zur Prüfung vorgelegt werden. Erst wenn ich die UstId-Nr. händisch geprüft habe, wird die (Netto-)Rechnung generiert.

Und noch eine Ausnahme: Es stehen alle EU-Länder und die Schweiz zur Auswahl sowie eine Option „Anderes Land“. Deren Aktivierung lässt ein Textfeld für die Eingabe des entsprechenden Landes erscheinen. Sofern der Kunde hier nicht wieder „Deutschland“ oder ein anderes EU-Land einträgt, führt dies ebenfalls zu einer Netto-Rechnung. Dies gilt bspw. auch für die Angabe von „DE“ und der Ärger mit falsch ausgewiesener Ust. ist vorprogrammiert.

Die freie Text-Eingabe muss also verschwinden und einer soweit möglich vollständigen Liste aller Länder weichen. Für diese kann dann im Admin-Menü (und zwar in einem Menüpunkt, der noch zu schaffen sein wird, fällt mir so auf) der jeweils auszuweisende Steuersatz bzw. der Sonderfall mit der VAT-ID angegeben und im Checkout-Prozess berücksichtigt werden. Außerdem muss ich mich nach einer API für die UstId-Nr-Validierung umsehen.

Die Checkbox, ob ein postalischer Versand erwünscht ist, muss ebenfalls auf dieser Seite angebracht werden. Nur in diesem Fall ist die Angabe einer von der Rechnungsanschrift abweichenden Lieferanschrift von Bedeutung. Trotzdem stehen die Versandkosten aber erst nach Auswahl des Landes bei der Lieferanschrift endgültig fest. Szenario: Der Kunde hat eine Rechnungsanschrift in Deutschland und aktiviert das Kontrollkästchen (so sagt man wohl für „Checkbox“) für

Ich möchte die Original-CD für 4,20 EUR (5,00 EUR inkl. Mwst.) Versandkosten erhalten.

Damit erhält er die Möglichkeit zur Angabe einer Lieferanschrift und möchte sich die CD an seine Schweizer Adresse schicken lassen. Via XHR wird der Text oben aktualisiert, d.h. die Versandkosten erhöht. Das ist nicht gut. Unter den Bedingungen hätte er vielleicht doch lieber auf die CD verzichtet. Die Lösung kann eigentlich nur die Angabe eines für jedes Land gültigen Texts über das Admin-Menü sein. Die tatsächlichen Versandkosten werden auf der nächsten Seite noch einmal dargestellt.

Die AGB, Hinweise zum Widerrufsrecht bei Fernabsatzverträgen und Hinweise zum Datenschutz sind bei allen Bestellungen zu akzeptieren. Dann gibt es gesonderte Bedingungen zu Produkten je nach Kategorie (z.B. Bedingungen zu Werbeschaltungen) oder tatsächlich dem einzelnen Produkt (z.B. Lizenzbedingungen zur Software). Das lässt sich alles über das Admin-Menü regeln.

Auch die Hinweistexte zur weiteren Abwicklung sind zumindest von der Kategorie der Produkte (Software, Werbeanzeigen) abhängig, von der gegebenenfalls notwendigen Prüfung der UstId-Nr. und neuerdings dann auch von der Auswahl, ob ein postalischer Versand erfolgen soll.

Die zwecks Prüfung nochmal angezeigten Bestelldaten sind nicht weiter aufregend.

Nach Absenden der Bestellung geht es weiter mit den Abhängigkeiten. Je nach angegebenem Land steht die Zahlung via Sofortüberweisung zur Verfügung oder nicht. Das Modul für die Zahlung via Sofortüberweisung muss migriert werden. Neu geschaffen werden muss zudem mindestens PayPal.

Alles weitere, wie die automatische Bereitstellung von Downloads nach Zahlungseingang etc. hatte ich ja schon an anderer Stelle beschrieben.

Kontaktformular(e)

Natürlich gibt es nur eine Kontaktformular-Funktion, die aber an mehreren Stellen in der Website eingebunden ist. Tatsächlich gibt es kein allgemeines Kontaktformular, wie es üblicherweise neben oder im Impressum verlinkt ist. Dies sollte im Rahmen der Migration geändert werden.

Stattdessen kommen Kontaktformulare mit sich aus dem Kontext ergebendem Betreff überall dort zur Anwendung, wo offene Fragen möglicherweise nicht in Hilfetexten etc. beantwortet wurden, also so ähnlich, aber nicht ganz so nervtötend, wie sie im Hilfe-Center größerer Firmen auf „Kontakt“ klicken, um dann einen Katalog von gefühlt 50 Fragen zu beantworten, um endlich tatsächlich auf ein Kontaktformular zu gelangen.

Wir halten fest: Es ist ein allgemeines im Footer verlinktes Kontaktformular einzurichten und überall dort, wo sich in der alten Version ein Kontaktformular befindet, soll in der von WordPress generierten Website ebenfalls eines sein.

LiveZilla

Da ich die meisten Zeit über nur am Nörgeln bin, freut es mich sehr, LiveZilla als das Ideal einer All-In-One-Lösung für Support-Chats, Ticket System und Help Desk anzupreisen. Schade nur, dass es in der von mir eingesetzten Version 6 keinen Client für Linux gibt. Deshalb ist der Support-Chat auf Werbe-Markt.de nur alle paar Wochen verfügbar, wenn ich Windows in einer virtuellen Maschine laufen habe.

Deshalb hat die Anbindung von LiveZilla an die neue Version ganz niedrige Priorität und wenn ich es nicht im Rahmen der Zielsetzung festhalten würde, würden möglicherweise Jahre vergehen, bis ich feststelle, dass es ja früher mal diesen Support-Chat gab.

Weitere Frontend-Funktionen

Wenn ich nichts übersehen habe, gibt es außer den bereits genannten Funktionalitäten im Frontend nur noch Working Demos zu kleinen PHP-Scripts oder JavaScript-Funktionen. Deren Mehrwert für den Anwender ist überschaubar und die Migration im Rahmen der Übertragung der Inhalte anstrebenswert, aber von niedriger Priorität.

Was ich noch fertig in der Schublade, aber nie online gestellt habe, ist eine Reihe von Tools zur OnPage-Optimierung. Die werden jetzt in der ersten auf WordPress basierenden Version von Werbe-Markt.de auch nicht enthalten sein. Tatsächlich war ich gedanklich schon so weit, die Tools in limitierter Variante kostenlos zur Verfügung zu stellen und aufgrund der teilweise intensiven Belastung von den Server in einer Premium-Variante uneingeschränkt, bspw. gegen monatliche Gebühr in Verbindung mit einem Werbe-Markt.de-Account. Das alles ist zunächst kein Thema, aber ein neuer Bereich wie Webmaster-Tools in naher Zukunft nach der Migration durchaus vorstellbar.

Hintergrundaufgaben

Zwar sind bereits einige Themen redundant in diesem Beitrag. Auf eine kurze Auflistung via CronJob zu erledigender Aufgaben kommt es dann auch nicht mehr an:

• Versand von Zahlungserinnerungen und Mahnungen
  Dieser muss in Verbindung mit dem Rechnungs-Modul weiterhin via CronJob ausgeführt werden.
• Prüfung von Linkpartnern
  (obsolet)
• Aktualisierung der News-Einträge auf der Startseite
  (obsolet)
• Aktualisierung des RSS-Feeds
  (obsolet)
• Aktualisierung eines Produkte Feeds für einen Google-Dienst, der alle paar Monate einen neuen Namen bekommt und gleichzeitig immer bedeutungsloser wird. Dafür gibt es keinen Bedarf mehr.
• Generierung von Großhandels-Preislisten zur Einbindung in Übersichtsseiten
  (obsolet, siehe Reseller-Bereich)
• Aktualisierung von News-Einträgen, -Archiven etc.
  (übernimmt WordPress)
• Generierung von kategorisierten Werbeangeboten zur Einbindung in Übersichtsseiten
  (entfällt, siehe Verwaltung von Werbekampagnen)
• Generierung kategorisierter Software-Angebote zur Einbindung in Übersichtsseiten
  Die Funktion entfällt zwar in ihrer bisherigen Form. Ich habe aber trotzdem keine Lust, die Übersichtsseiten manuell zu generieren. Ich werde wohl ein Plugin basteln, das mir einen Template-Tag zur Verfügung stellt, an dessen Stelle dann eine automatisch generierte Übersicht erscheint.
• Das gleiche gilt für zum Festpreis angebotene Services, die aber im Rahmen der Neugestaltung der Angebotspalette evtl. nicht mehr relevant sein werden.
• Referenzen-Update
  (entfällt, siehe Referenz-Listen-Eintrag)
• Generierung von PDF-Preislisten für Funktionserweiterungen
  (entfällt, siehe Funktionsweiterungen)
• Generierung von PDF-Preislisten mit Werbeangeboten
  (entfällt, siehe Verwaltung von Werbekampagnen)
• Generierung von Großhandels-Preislisten im PDF-Format
  (obsolet, siehe Reseller-Bereich)
• Bezug von allgemeinen Statistiken (Zugriffszahlen) für Werbeangebote
  Mediadaten wären natürlich schon interessant für potenzielle Werbekunden. Die einst mit Webalizer erfassten Zugriffszahlen stehen allerdings schon lange nicht mehr zur Verfügung und das an sich spannende Tracking aller Werbeeinblendungen habe ich abgeschaltet, weil die zig Giga-Byte nicht mehr zu händeln waren. Deshalb wäre aktuell nur einige demographische Daten zur Zielgruppe abrufbereit. Vermutlich werde ich aber auf die Schnittstelle zunächst verzichten.
• Generierung der Übersichtsseiten für das Support-Center
  (siehe Ausführungen über das Plugin und Template-Tag)
• Generierung der Übersichtsseiten für Downloads
  (entfällt zunächst, siehe Downloads im Fontend-Bereich)
• Aktualisierung von Listen empfohlener Webhosting-Anbieter
  Vermutlich werde ich diesen Inhalt weiter bestehen lassen und besagte Liste als zentral verwaltetes Template-Tag verfügbar machen.
• Dann gibt es noch 2 weitere gesondert ausgeführte Funktionen zur Generierung von Übersichtsseiten für die Bereiche Services, Software und Funktionsweiterungen, für die nichts anderes gilt als oben bereits geschrieben.
• Generierung einer Sitemap im XML-Format
  Nicht, dass ich das wirklich bräuchte oder einen großen Sinn darin erkennen würde, aber diese Aufgabe sollte ein frei verfügbares Plugin übernehmen.
• Caching statischer Dateien
  War es bisher vor allem meinem Performance-Fetisch geschuldet, das gecached wurde, was irgendwie geht, ist umfangreiches Caching bei einem ressourcen-fressenden Monster wie WordPress unabdingbar. Dazu werde ich WP Super Cache oder andere Plugins unter die Lupe nehmen.
• Generierung von Handbüchern zur Software im PDF-Format
  Es kommt mir so vor, als hätte ich darüber schon geschrieben. Dafür gibt es entweder ein fix und fertiges Plugin oder keine Handbücher.

Inhalte

An dieser Stelle rufen wir uns am besten noch einmal kurz ins Gedächtnis zurück: Ziele müssen erreichbar bzw. realistisch sein (je nach Übersetzung der Binsenweisheit). So günstig die Gelegenheit der Migration für eine vollständigen Überarbeitung der Seiten und Neugestaltung der Linkstrukturen auch sein mag – es ist vollkommen unrealistisch, es in einem auch nur annähernd vertretbaren Zeitraum umzusetzen.

Besagte Überarbeitung steht zwar an – aber nicht im Rahmen der eigentlichen Migration. Deshalb übernehme ich im ersten Schritt sämtliche (etwas mehr als 1.000) Seiten 1:1 von der alten Version. Dazu werde ich die Seiten als statische HTML-Dokumente exportieren und auf kostenfreie Plugins zurückgreifen, die mir die Seiten als solche bzw. als Beiträge in WordPress anlegen.

Nicht mehr benötigte Code-Passagen, CSS-Klassen und IDs werden mittels Scripts oder direkt über die Datenbank entfernt oder ersetzt. Dies gilt auch für die massenweise Einstufung als Seite oder Post sowie Zuordnung der Elternelemente und vermutlich noch sehr vieles, was mir erst bei Ansicht der migrierten Inhalte in WordPress auffallen wird.

Auch die Link-Struktur bleibt erhalten. Diese ist zwar noch einem uralten, eigenen CMS geschuldet und könnte mit den von WordPress generierten Permalinks deutlich angenehmer zu lesen und zu navigieren sein. Ich habe jedoch keine Lust auf über 1.000 301er Weiterleitungen und noch weniger auf die Anpassung von Deep-Links in Script-Archiven, sofern diese überhaupt möglich ist. Ich werde bei der manuellen Überarbeitung der Seiten dann entscheiden, ob eine Neugenerierung des Permalinks sinnvoll ist oder nicht. Neu angelegte Seiten oder Posts werden aber auf jeden Fall eine andere Struktur haben, d.h. nicht alle im Hauptverzeichnis liegen und die Endung .php haben.

Was aktuell so ist und auch zukünftig mittels eines Widgets für die Sidebar so sein soll: Sobald sich der Besucher auf einer Seite befindet, die einem Produkt zuordenbar ist, erscheint in der rechten Seitenleiste ein Bild des Produkts. Ein Klick darauf öffnet ein Modal mit den wesentlichen Merkmalen, Preis und Bestellmöglichkeit. Unterhalb des Bildes erscheint eine zusätzliche Navigationsleiste zu allen Übersichtsseiten, die mit dem Produkt in Zusammenhang stehen. Bei Software sind dies Beschreibung, Funktionserweiterungen, Referenzen, Downloads, Support, Services und Bestellung, bei Werbeangeboten lediglich Beschreibung und Bestellung.

Ein spezieller Punkt fällt mir gerade noch auf, dessen Mehrwert für den Nutzer ganz besonders bei diesem Beitrag deutlich wird: Ein Inhaltsverzeichnis, aus dem hervorgeht, was den Besucher auf der aktuellen Seite erwartet. Das Inhaltsverzeichnis ist ganz ähnlich dem von Wikipedia-Artikeln und enthält ganz einfach die Überschriften des aktuellen Dokuments mit entsprechendem Link dorthin. Sollte es tatsächlich kein „Table of Content“-Plugin geben, müsste ich selbst eines erstellen. Die vom Plugin eingefügten Sprungziele waren in der Vergangenheit auch besonders hilfreich, um Kunden direkt zur Antwort auf ihre Frage zu verweisen.

Layout

Wer in der Vergangenheit schon einmal das große Vergnügen hatte, meine Dienstleistungen in Anspruch zu nehmen, hat mit Sicherheit Wind davon bekommen, dass Webdesign nicht gerade mein Steckenpferd ist. Das soll keineswegs heißen, dass ich nicht sehr fit in puncto modernem Website-Layout mit CSS wäre. Ich bevorzuge aber klar messbare Funktionalitäten bzw. auf Erfüllung prüfbare Anforderungen gegenüber subjektiv als „schön“ oder „unschön“ empfundenen Schriftarten, Farbkombinationen etc.

Deshalb bevorzuge ich ein schlichtes Layout mit schwarzer Schrift auf weißem Hintergrund, wenig Bildern und Farben. Außerdem vertraue ich auf die Meinung von Experten. Diese beiden Argumente sprechen für das zum Zeitpunkt des Schreibens aktuelle WordPress Standard-Theme Twentyseventeen.

Da ich aber natürlich schon die ein oder andere individuelle Gestaltungsmöglichkeit benötige, werde ich ein Child-Theme erstellen und damit eine Mixtur aus Twentyseventeen und dem alten Layout kreieren.

Je nach Bereich (Support, Downloads, …) erscheint rechts oben auf der Webseite ein mehr oder weniger dazu passendes Bild. Da dieses Bild auch praktisch schon die einzige Gemeinsamkeit aller Seiten in einem Bereich ist, bin ich mir unschlüssig, ob es dafür wirklich eines Seiten-Templates bedarf. Ganz sicher werde ich aber nicht händisch in 1.000 Seiten Bilder einfügen – und sei es nur mittels Template-Tag. Stattdessen werde ich mir mal das spannende Plugin Add Categories to Pages von a.ankit ansehen und testen, ob damit kategorie-spezifische Templates für Seiten möglich sind. Für Posts wären sie es auch ohne Plugin…

Besonders gespannt bin ich auf die WordPress eigene Funktionalität zum Anlegen der Top-Navigation. Bestimmt werde ich auf ein Plugin ausweichen müssen bzw. selbst eines schreiben oder ganz einfach das Header-Template des Child-Themes entsprechend anpassen. Da es nur ein Child-Theme wird, es meinen ganz individuellen (layout-technischen) Bedürfnissen entsprechend zugeschnitten wird, brauche ich hier nicht berücksichtigen, dass es mal auf einer anderen Website zum Einsatz kommen könnte. Das heißt im Umkehrschluss, dass im Theme keine CSS-Anweisungen vorkommen dürfen, die das Aussehen von Plugins beeinflussen, die ich eben doch anderen zur Verfügung zu stellen gedenke. Da sich der Hauptteil meiner Plugins im Admin-Menü befinden wird (100%ig sicher bin ich mir diesbezüglich noch nicht) und in diesem das Stylesheet aus dem Theme ohnehin nicht geladen wird, kann es kaum zu Kollisionen kommen.

Technische Rahmenbedingungen

Über die Beibehaltung der Linkstruktur hatte ich mich bereits geäußert. Was gibt es sonst noch für nicht-funktionale Anfoderungen?

Unterstützte Versionen

Ich verwende für die Entwicklung die derzeit aktuelle WordPress-Version 4.7. Abwärtskompatibilität ist mir egal und auch für zukünftige Versionen werde ich mich eher mit den WordPress Betas und RCs herumschlagen, als um jeden Preis bis zu Version xy abwärtskompatibel zu bleiben.

In meiner Entwicklungsumgebung läuft PHP 5.6.17, auf dem Produktivserver alles von PHP 5.3 bis 7.0. Da in PHP 5.6 gegenüber 5.5 nichts Gravierendes geändert wurde, was ich einzusetzen gedenke, mit PHP 5.5 aber durchaus einige Features eingefügt wurden, die ich gerne nutze, werden meine Plugins mindestens PHP in der Version 5.5 benötigen und selbstverständlich auch unter PHP 7 lauffähig sein.

Bezüglich MySQL kann wohl 5.5 heute vorausgesetzt werden. Es ist aber ohnehin so, dass es zu einfach wäre, seine eigenen Datenbank-Tabellen anzulegen und Statements abzusetzen. Der geziemende Weg für Plugin-Entwickler ist es, die Finger von der Datenbank zu lassen und die WordPress-Funktionen zu nutzen. Der latente Frust, der sich aus diesen Zeilen ablesen lässt, führt möglicherweise noch zu einem weiteren Post namens „Warum WordPress 2“. Jedenfalls werde ich nun zur WordPress-Bitch und damit sind die Plugins unabhängig von der MySQL-Version.

Übrigens empfiehlt WordPress selbst zum Zeitpunkt des Schreibens:

• PHP 7 or greater
• MySQL 5.6 or greater
• The mod_rewrite Apache module
• HTTPS support

mod_rewrite wird zwar bei meinen Plugins kaum eine Rolle spielen. Dennoch möchte ich bei der Gelegenheit erwähnen, keine Zeit mit irgendwelchen IIS-Kompatibilitätsproblemen zu verschwenden, auch wenn ich gerade nicht wüsste, an welcher Stelle die auftreten sollten.

HTTPS

Greifen wir doch gleich die letzte Anforderung von WordPress auf. Meine Plugins werden kein HTTPS voraussetzen, wohl aber ich selbst. Derzeit laufen das komplette Admin-Menü, der Checkout-Prozess, der Zugriff auf lizenzbezogene Downloads, der Abruf von Rechnungsdaten oder Bestellstatus ausschließlich über eine sichere Verbindung. Das soll prinzipiell auch so bleiben. Ich hatte kurz erwogen, die komplette Website nur noch über https auszuliefern – aber wozu?

Was auf jeden Fall noch in die Liste der nur über https erreichbaren Seiten aufgenommen werden muss, ist der komplette Login-Bereich, also auch eigentlich ohne Login einsehbare Seiten, wenn diese von einem eingeloggten Nutzer aufgerufen werden.

So weit, so einfach. Aber was machen wir mit dem Login-Formular? Fehlender Geschmack in puncto Layout sieht das WordPress-Login-Formular aus wie in einer Zeit, als es noch kein Internet gab. Auch rein technisch ist die momentane Lösung, die einfach ein via XHR angefordertes Formular mit 2 Eingabefeldern und einem Submit-Button aufklappen lässt, deutlich nutzerfreundlicher. Dieses Formular ist allerdings auf jeder Seite abrufbar und die allermeisten werden unverschlüsselt über http ausgeliefert.

Passwort-Felder sind in einem Formular mit einer unsicheren (http://) Formular-Aktion vorhanden. Dies ist ein Sicherheitsrisiko, durch das Zugangsdaten gestohlen werden können.

Das ist noch kein Problem bzw. beschreibt eben das, was ich mit Ausweitung von https auf den gesamten Login-Bereich meinte (nicht ganz, aber so ähnlich).

Passwort-Felder sind auf einer unsicheren (http://) Seite vorhanden. Dies ist ein Sicherheitsrisiko, durch das Zugangsdaten gestohlen werden können.

Scherzkekse… Es ist doch völlig egal, wie die Seite übertragen wurde, die das Formular enthält. Das Formular ist kein Geheimnis, sondern die Daten, die darin eingetragen werden. Was passiert, wenn ich den XHR-Request aus einer unverschlüsselt übertragenen Seite heraus an eine https-Seite schicke?

Quellübergreifende (Cross-Origin) Anfrage blockiert: Die Gleiche-Quelle-Regel verbietet das Lesen der externen Ressource auf … (Grund: CORS-Kopfzeile ‚Access-Control-Allow-Origin‘ fehlt).

Ja, ist klar. Es ist zwar dieselbe Domain, aber ein anderes Protokoll. Also, Antwort-Header hinzufügen: Access-Control-Allow-Origin: *

Passwort-Felder sind auf einer unsicheren […]

Ich sehe mich also zu gegebener Zeit mal zu der Problematik recherchieren und dann wohl doch auf eine eigene Seite wie https://www.werbe-markt.de/login.php verweisen. Was funktionieren könnte, wäre eine ziemlich hässliche Lösung, wonach nicht das Formular via XHR angefordert wird, sondern ein iframe ins Dokument eingefügt, der das Formular via https anfordert. Naja, die 3 Minuten habe ich jetzt auch noch:

Ja, mit dem iframe und einer https-Quelle, die das Login-Formular ausliefert, gibt es keine Probleme. Die Entscheidung werde ich dennoch erst später treffen.

Browser-Support

Anders als bei anderen Projekten habe ich aktuell nicht vor, JavaScript-APIs etc. einzusetzen, von denen ich weiß, dass sie Webbrowser aus dem Hause Microsoft ohnehin nicht unterstützen und Apples Safari vielleicht in 2-3 Jahren. Etwaige Probleme dürften wenn dann nur optischer Natur sein. Ich selbst werde die Plugins im Firefox (Iceweasel 38.6.1) und Chrome (Chromium 53) durch Produktiveinsatz „testen“ und natürlich auf Feedback von Nutzern schnell zu reagieren versuchen.

Multilingualität

Die „Hauptsprache“ wird natürlich englisch sein mit einer vollständigen und aktuell zu haltenden Übersetzung ins deutsche. Wenn sich tatsächlich das ein oder andere Plugin verkaufen sollte, wäre spanisch noch eine interessante Sprache.

Nonces

Wo es irgendwie sinnvoll und mit vertretbarem Aufwand möglich ist, sollen WordPress-Nonces zum Einsatz kommen. Wenn es schon etwas einfaches gibt, das mehr Sicherheit bewirkt, sollte man es auch nutzen. Allerdings denke ich gerade an das Task-Modul im Admin-Menü, bei dem ich viel mit Ajax umzusetzen gedenke. XHR ist in WordPress ohnehin schon so eine Sache… und inwieweit dabei Nonces eingesetzt werden können, ist mir aktuell noch gar nicht bekannt.

WordPress Coding Standards

„Wes Brot ich ess, des Lied ich sing“ oder: Ich bin eine WordPress-Bitch. Mit den gewünschten Einrückungen in JavaScript-, CSS- und PHP-Dateien habe ich kein Problem, weil das Tools für mich erledigen. Die Zeitreise ins XHTML-Zeitalter mache ich nicht mit. Ein <br /> wird es von mir nicht mehr geben. Achso, ich bin übrigens hier: https://codex.wordpress.org/WordPress_Coding_Standards

Die JavaScript Coding Standards habe ich nur überflogen. Das dürfte kein Problem sein. Mein Problem sind die PHP Coding Standards. Ich muss mir bei Verwendung globaler, benutzerdefinierter Funktionen schon jedes Mal innerlich die Hände waschen. Bei der Underscore-Schreibweise (ich gebe zu, das bringt PHP eben so mit sich und ist durchaus konsequent) bin ich gedanklich ständig mit einem Finger auf der Backspace-Taste. Mit einigem gehe ich konform.

Was es von mir ganz sicher nicht geben wird sind Yoda Conditions. Für mich sieht das falsch aus und (ja, das ist eine philosophische Frage bezogen auf eine untypisierte Skriptsprache) die Verwendung von === für einen Vergleich ist meiner Meinung nach die sauberere Variante und birgt keinerlei Risiko, statt eines Vergleich versehentlich eine Zuweisung zu schreiben (Hoppla, ich habe statt 3 Gleichheitszeichen nur 1 geschrieben).

Leider sind die Möglichkeiten objektorientierter Programmierung von Plugins m.E. sehr überschaubar. Für Konzepte wie Vererbung ist der Umfang eines Plugins zu begrenzt und Kapselung würde ich sehr gerne einsetzen, sehe aber mit Hooks und Zugriff auf globale Funktionen kaum Spielraum.

Um nicht diesen schon vor Beginn irgendwelcher Arbeiten recht frustriert klingenden Worten schließen zu müssen, komme ich zum Abschluss noch auf ein höchst erfreuliches Thema zu sprechen.

Zeitplan

Noch vor Weihnachten wollte ich mit den Programmierarbeiten begonnen haben. Dazu ist es selbstverständlich nicht gekommen, weil ich mit dem Verfassen dieses Beitrages beschäftigt war. Tatsächlich wäre jetzt ein A/B-Test spannend: Wäre ich die Sache einfach angegangen, ohne irgend etwas zu planen – wäre die neue Version dann unter dem Strich schneller bereit zur Veröffentlichung? Die Theorien besagen natürlich „Nein, an der Planungsphase darf nicht gespart werden.“

Seis drum. Ich kann keinen realistischen Zeitplan erstellen, ohne die für Kundenaufträge verfügbare Zeit einzuschränken. Das steht nicht zur Debatte, denn Kundenaufträge haben Vorrang. Die eigene Website kann ich in meiner Freizeit entwickeln und auf ein paar Wochen kommt es jetzt auch nicht mehr an. Mit dieser Einstellung wird das bestimmt ganz schnell klappen.

Spaß beiseite: Ich werde mir diesen Beitrag ausdrucken, Notizen dazu machen, 1-2 Nächte bzw. Vormittage drüber schlafen und den Zeitplan dann in einem neuen Post veröffentlichen.

Stichwort „veröffentlichen“: Nicht, dass ich davon ausgehe, es würde wirklich jemanden interessieren. Aber Sinn der Sache ist es ja schon irgendwie, die Posts auch zeitnah ins Netz zu stellen. Ich werde das beim Zeitplan entsprechend berücksichtigen. Entweder muss ich neue und alte Version parallel laufen lassen (technisch möglich, aber ziemlich risikobehaftet, eine in der Entwicklung befindliche Website online zu stellen) oder WordPress-Beiträge als statische Seiten exportieren und innerhalb der bestehenden Website verlinken (das sähe grauenhaft aus, solange ich das Layout nicht angepasst habe und ich müsste jede Menge Deadlinks entfernen) oder ich binde nur den Inhalt der Beiträge in die bestehende Website ein (dafür müsste ich mit einem Base-Element arbeiten, was mir ziemlich widerstrebt). Ist das kompliziert…