Membership-Website mit WordPress umsetzen

Pünktlich zur erneuten Schließung der Fitnesscenter habe ich für einen Kunden eine Membership-Website umgesetzt. Dort kann nun der Zugang zu Videos mit Online-Fitnesskursen gekauft werden. Bei der Umsetzung habe ich mir diverse Lösungen angeschaut und bin ziemlich verzweifelt. Damit ihr meine negativen Erfahrungen nicht wiederholen müsst, hier mein Erfahrungsbericht wie ich das Ganze am Ende umgesetzt habe und welche Probleme ich dabei lösen musste.

Das Ganze startet wie so häufig mit einem schlechten Briefing und einer ganz anderen Aufgabe. In diesem Fall sollte den bereits bestehenden Mitgliedern der Zugang zu den Kursen ermöglicht werden. Eine Bezahlmöglichkeit wird nicht benötigt, es geht nur um bestehende Mitglieder. Nach kurzer Recherche nutze ich dafür das Tool Restrict Content Pro in Verbindung mit WP Approve User. Die Mitglieder registrieren sich auf der Website und werden dann, nach Verifizierung der Mitgliedschaft, freigeschaltet. Bei Kündigung wird der Zugang manuell deaktiviert.

So weit, so gut. Nun kommt, was kommen musste. Der Kunde will nun die Zugänge auch Nicht-Mitgliedern verkaufen. Tja nun, Restrict Content Pro bietet leider keine anständige Lösung für die Berechnung oder Anzeige der Umsatzsteuer an. Nur eine Dritt-Parteien-Lösung ist verlinkt und auf der Website finden sich keine Preise, keine anständige Produktbeschreibung und überhaupt sieht das Ganze eher nach einem Service mit Monatsgebühr aus und scheint auf die USA beschränkt zu sein. Auch im offiziellen Verzeichnis sieht es nicht besser aus. Es gibt eine 6 Jahre alte Taxamo-Integration, eine 2 Jahre alte VAT-Lösung, die aber nur für Stripe funktioniert.

Aber es gab auch noch mehr Probleme. Bei der Registrierung konnte zwar die Datenschutzerklärung und die AGB bestätigt werden, ich benötigte aber auch noch eine Bestätigung der Widerrufsbelehrung und zu dem Hinweis auf Erlöschen des Widerrufs bei Inanspruchnahme der Dienstleistung vor Ablauf der 14 Tage. Zudem musste der Button am Ende einen bestimmten Text haben. Der war aber fest auf „Registrieren“ gestellt. Fast alles davon ließ sich programmatisch lösen und war gut dokumentiert, aber es war ganz schön viel Programmierung notwendig. Für einen Laien definitiv zu viel.

Restrict Content Pro war damit als Lösung gestorben. Ich schaute mich also nach Alternativen um. Für die rechtlichen Anforderungen des deutschen Marktes empfahl sich natürlich eine deutsche Lösung, aber die Preise und der Support (bei einer Pre-Sale-Frage) von Digimember gefielen dem Kunden gar nicht, so dass wir weiter auf eine andere Lösung setzen sollten bei der das Ganze auf unserer Seite auch voll kontrollierbar ist.

Mein nächster Kandidat war Paid Memberships Pro. Großer Vorteil: Es existierte eine Lösung für die Steuerberechnung und die war wegen COVID-19 auch noch gerade frei erhältlich. Nach der ersten Freude war die Ernüchterung jedoch groß. Die Steuer wird erst im Kaufprozess addiert und ist somit erst im Bezahlprozess (hier bei PayPal) sichtbar und zudem war die Anzeige auf der Website exklusive Steuer. Die Preisangabe war also überall „falsch“ (weil für Endkunden ja der Endpreis inklusive Steuer angezeigt werden müsste), nämlich zu niedrig, denn die Steuer wurde ja erst am Ende aufgeschlagen. Eine Konfigurationsmöglichkeit die Preise inklusive Steuer anzuzeigen beziehungsweise die Preise nach Eingabe des Ortes konkret schon auf der Website richtig anzuzeigen waren allesamt nicht gegeben. Das Ganze System war einfach viel zu unflexibel. Es wird schnell klar, dass hier Amerikaner eine Lösung gebaut haben, ohne die konkreten Anforderungen des europäischen Marktes zu kennen oder zu verstehen. Als dann am Ende auch noch der Sandbox-Mode von PayPal jeden Test mit einem Fehler abbrach, musste definitiv eine andere Lösung her.

Die anderen Anforderungen waren hier einfacher lösbar. Mit dem Register Helper können mit vergleichsweise einfachem Code neue Felder hinzugefügt werden. Mit etwa halb sovielen Code-Zeilen und deutlich verständlicherem Code war das deutlich angenehmer als bei Restrict Content Pro.

Aber es gab auch noch mehr Probleme. Die Anzeige der Währungen wurde in EWR (also für alle Staaten mit Euro als Währung) nicht weiter spezifiziert. Die Preisanzeige musste also korrigiert werden, damit das Tausendertrennzeichen von Komma auf Punkt gestellt wird und entsprechend andersherum der Dezimaltrenner kein Punkt mehr, sondern ein Komma. Der Kaufen-Button am Ende war hartgecodet auf eine PayPal-Grafik und der letzte Sargnagel für diese Lösung.

Ich benötigte eine rechtlich sichere Variante, die ausreichend flexibel ist und obwohl ich es eigentlich nicht machen wollte, schien es die einzige Lösung zu sein. Ich installierte WooCommerce, denn Paid Memberships Pro hat eine freie WooCommerce-Integration.

Ich baute also zum dritten Mal meine Lösung. Aber hier nun ganz deutlich am schnellsten: Germanized bot eine Bestätigung für Datenschutzerklärung, AGB und Widerruf sowie eine Rechnungsanzeige (bei Pro auch als PDF). Für Dienstleistungen gibt es einen vordefinierten Text für den Hinweis auf das Erlöschen der Widerrufsmöglichkeit. Mit wenigen Klicks war das Ganze eingerichtet. Und auch der Kaufen-Button am Ende kann mit Germanized textlich angepasst werden.

Aber es wäre ja keine Odyssee, wenn es das jetzt gewesen wäre …

Es wird ja eine Dienstleistung/Online-Zugang verkauft und somit muss nichts versendet werden. Wenn die Bezahlung erfolgreich abgeschlossen ist, sollte also die Bestellung nicht „In Bearbeitung“ sein, sondern „Abgeschlossen“. Der Link beim Addon für eine Problemlösung ist nicht hilfreich, da das Plugin Autocompleter geschlossen wurde. Wenn ich genauer gelesen hätte, dann hätte ich gesehen, dass es dafür im Plugin auch ein Häkchen gibt. Tja, ich habe es mit einem Code-Snippet gelöst – egal, ich hatte ja sowieso schon viel zu Zeit in dieses Projekt versenkt.

Ich wähnte mich nun kurz vorm Ziel, also habe ich ein wenig aufgeräumt. Brotkrumen-Navigation entfernt, Verwandte Artikel entfernt, Vorschaubilder aus Warenkorb und Kasse entfernt und Zoom auf Produktbild deaktiviert.

Okay, jetzt mal testen. Da ich eine spezielle Verkaufsseite mit WooCommerce-Shortcode gebaut hatte und nicht die Shop-Seite nutze, musste noch der Shop-Link angepasst werden. Kein Problem:

/**
 * Redirect WooCommerce Shop URL
 */
function st_woocommerce_shop_url() {
	return site_url() . '/jetzt-mitglied-werden/';
}
add_filter( 'woocommerce_return_to_shop_redirect', 'st_woocommerce_shop_url' );

Testlauf, die Zweite. Alles soweit fein. Doch etwas fehlte noch. Was war das noch gleich? Ach ja, die Mitgliedschaften sollten natürlich auf Dauer angelegt sein. Das geht bei WooCommerce jedoch nur mit dem Zusatzplugin Subscriptions. Was gar nicht so günstig ist. Daher hatten wir erst einmal geschaut, ob wir alle anderen Probleme lösen können. Wird ja einfach sein, es einzurichten. Ihr ahnt es, war es natürlich nicht wirklich …

Die Einrichtung ist am Anfang noch klar und einfach. Einfach aus dem Produkt eine Subscription machen. Die gibt es in „Simple“ und in „Variable“. Nun bietet „Simple“ nur Täglich, Wöchentlich, Monatlich und Jährlich, aber der Kunde wollte natürlich Halbjährlich verkaufen. Also doch ein variables Produkt und eine Auswahl des Abrechnungszeitraum per Dropdown. Nun gut.

Variable Produkte zeigen aber auch Preisbereiche an. Von x EUR bis y EUR. Leider benutzt WooCommerce aber nur den ersten Abrechnungszeitraum, was also falsch ist, denn der zweite Wert gilt ja für einen ganz anderen Zeitraum. Da hilft nur das in der Doku erwähnte Mini-Plugin zu benutzen, um den Preistext anzupassen.

Nächster Test. Jetzt ist der Double-Opt-In von Germanized kaputt. Angeblich ist der Aktivierungslink nicht korrekt. Was ist denn jetzt los? Dankenswerterweise hatten andere vor mir das Problem auch schon und es existiert eine einfache Lösung. Die Benutzerrolle änder sich bei Subscriptions, daher muss diese dem DOI-Prozess von Germanized auch mitgeteilt werden. Jetzt klappt es. Puh!

/**
 *  Add new roles to customer double opt in.
 */
function my_child_add_double_opt_in_role( $roles ) {
	$roles[] = 'subscriber';
	return $roles;
}
add_filter( 'woocommerce_gzd_customer_double_opt_in_supported_user_roles', 'my_child_add_double_opt_in_role', 10, 1 );

Jetzt klappt es! Aber beim bezahlen hapert es. Fehlermeldung. Angeblich sind keine wiederkehrenden Zahlungen möglich. Was? Ach so, dass muss explizit noch bei jedem Payment-Anbieter mit einem Häkchen aktiviert werden.

Und jetzt wird es (wieder) ein wenig kompliziert. Wenn du einen Online-Zugang verkaufen möchtest, dann muss natürlich der Gast-Zugang deaktiviert werden. Aber wann genau wird eigentlich der Zugang dann erstellt? Die Mail mit dem Konto-Aktivierungslink wird direkt vor der Kasse versendet und der Benutzer wird direkt angemeldet(!). Nun habe ich in Germanized die Möglichkeit zu definieren, dass nicht-aktivierte Benutzer nicht angemeldet sein dürfen. Dann ist aber beim Klick zur Kasse Schluss. Erst müsste der Aktivierungslink geklickt werden. Wenig intuitiv.

Obwohl der Benutzer nicht aktiviert ist, ist er also direkt nach der Bezahlung angemeldet und könnte die Inhalte ansehen, die mit der Mitgliedschaft verknüpft sind. Beim nächsten Login klappt die Anmeldung allerdings nicht, solange der Aktivierungslink nicht geklickt wurde. So weit, so schlecht, also trickse ich ein wenig:

Mit dem „Menu Item Visibility Control“-Plugin können Menüpunkte durch eine Boolesche-Funktion (Conditional Tag) begrenzt werden. Den Plugin-Tipp hatte ich schon bei Restrict Content Pro gefunden. Nach einer kurzen Recherche im Code von Germanized und Paid Memberships Pro hatte ich es gefunden:

wc_gzd_is_customer_activated() && pmpro_hasMembershipLevel()

Ins Menü sollte nur eine Portalseite mit den Videos eingebaut werden. Der Link zu dieser Seite erscheint im Menü aber nicht nach der Bezahlung, obwohl die zweite Bedingung (hat eine Mitgliedschaft) erfüllt wäre, sondern erst, wenn das Konto auch aktiviert wurde (erste Bedingung). Direkt nach dem Login wird übrigens dank Addon auf eben diese Portalseite weitergeleitet.

Damit sich mehrere Nutzer nicht einen Login teilen, noch schnell WP Bouncer installiert. Das Plugin verhindert mehrere Anmeldungen mit demselben Login. Da das Fitnesstudio insbesondere auch Livestream-Zugänge verkauft sicher eine sinnvolle Erweiterung.

Damit der Nutzer sich auch bequem abmelden kann (die WP Toolbar habe ich natürlich ausgeblendet) wird noch schnell ein Abmelden-Link ins Menü eingebaut (mit dem einem Plugin geht das ganz leicht) und jetzt sollte ich es wirklich geschafft haben …

Was für eine Reise! Ich habe bei wenig Projekten soviel geflucht über schlechte Dokus, kaputte Links, Sackgassen und Detailprobleme, die mir bestimmt einige neue graue Haare beschert haben dürften. Aber am Ende ist es doch eine nette, sehr flexible und sichere Lösung geworden. Dank WooCommerce und Germanized sind viele, auch zukünftige, Herausforderungen hervorragend gelöst und neue Anforderungen, wie Öffnung zu Schweiz und Österreich oder sogar EU-weit sind ebenso einfach möglich wie Gutscheine und tausende andere Dinge, die WooCommerce selbst oder via Plugin anbietet.

Die Herausforderung viele Einzelteile zu einem funktionierenden Gesamtprodukt zu bauen sind aber unübersehbar deutlich geworden. Shoplösungen wie Shopware, Magento und Co. sind vielleicht nicht so flexibel, aber dafür (hoffentlich) in sich kohärenter umgesetzt und weniger mit solchen Kompatibilitätsproblemen behaftet.

Hast du auch schon eine MembershipWebsite mit WordPress umgesetzt? Was war dein Ansatz? An welche Problem bist du gestoßen? Und wie hast du sie gelöst? Ich freue mich über Erfahrungsberichte als Kommentar oder noch besser als Blog-Artikel 😉!

2 Antworten auf Membership-Website mit WordPress umsetzen

  1. Ich habe bisher eine echte Membership-Seite umgesetzt. Dabei war die einzige Anforderung, dass bestimmte Pakete gebucht werden konnten, die dann auf eine WordPress-Rolle gemappt wurden, um bestimmte Seiten sehen zu können und Funktionen zu nutzen.

    Aufgrund der recht einfacher Anforderung und dem großen Overhead, den WooCommerce (zumindest damals) mitbrachte, habe ich mich auf die Suche nach einer anderen Lösung gemacht. Dabei habe ich viele gute Artikel bei Chris Lema gefunden, der die verschiedenen Plugins verglichen hat. Meine Auswahl viel schließlich auf MemberPress. Hier konnte ich die beiden gewünschten Bezahlmethoden PayPal und Kreditkarte (mit Stripe) umsetzen und den Bezahlvorgang auch mit den üblichen Anforderungen an Bestellungen in Deutschland umsetzen.

  2. Hallo Torsten,
    lange nichts gehört. Ich habe dieses Jahr auch eine Membershipseite umgesetzt. Ich habe glücklicherweise gleich mit Kanonen auf Spatzen geschossen. Also mit Wocommerce, Germanized Pro, WooCommerce Memberships, WooCommerce Subscriptions, Woocommerce Teams, und Mailchimp for WooCommerce Memberships und noch ein paar andere Plugins gestartet. Das war ein einziges Testen, bis der Arzt kommt.
    Was wollte ich erreichen? Ich wollte eine Newletter Membershipseite bauen, bei der auch Teams (Firmen) bezahlen können (Rechnung (16%), Stripe mit Kreditkarte und Paypal) und die hinterlegten Mailadressen sich mit Mailchimp synchronisieren (also flac mit aktiv und deaktiv setzen). Das funktioniert auch. Nur gab es zu Beginn große Probleme bei den monatlichen Bezahlungen, wenn im Teambereich mehr als 50 Mailadressen hinterlegt waren (time out des Servers). Jetzt läuft es endlich und mit Woocommerce lassen sich noch andere schöne Dinge zukünftig machen. Bezüglich meiner Anforderungen gab es nicht anderes was die Teams-Problematik lösen konnte. Und Germanized 3.0 ist auch mit WooCommerce Subscriptions super cool geworden.

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.