Kategorien
Content Management Systeme E-Commerce Site Builder

Stock-Photos verkaufen mit Drupal Commerce

Nachdem ich neulich beschrieben habe wie „einfach“ es ist einen Online-Shop in Drupal 9 mit Drupal Commerce zu realisieren (16.8.2021 Drupal Commerce) erhielt ich einiges Feedback mit vielen Fragen, wie man denn einen Produktkatalog erstellt, eine PayPal Anbindung konfiguriert, virtuelle Güter (Dateien) verkauft, variable Preise anbietet („pay what you like“), Gutschein-Codes erstellt und akzeptiert, wiederkehrende Zahlungen ermöglicht, was überhaupt die Unterschiede zwischen Produkten und Produktvarianten sind und vielen anderen mehr.

Das Inhaltsverzeichnis für ein Drupal Commerce Buch ist danach gewissermassen fertig und ich werde in Zukunft ein paar dieser Themen hier im Blog näher erläutern.

Im heutigen Beitrag geht es um das Verkaufen virtueller Güter am Beispiel von Stock-Photos. Wenn du ein Bild auf deiner Website verwenden möchtest, benötigst du die entsprechenden Rechte an diesem Bild. Du könntest natürlich auch selbst fotografieren oder in grossen Foto-Datenbanken die Bildrechte erwerben. Bildrechte an Fotos kannst du beispielsweise bei iStock/Getty (istockphoto.com) kaufen. Ein Mittelweg zwischen dem Kauf und der Selbstproduktion sind freie Bildarchive wie unsplash.com.

So prinzipiell wird bei diesem Geschäft der Download einer Datei und das Recht an der Verwendung verkauft. Manchmal auf Monatsbasis (z.B. 10 Photos pro Monat kosten x CHF/€/USD), manchmal einzeln (pro Photo), manchmal eine gewisse Menge (x Fotos) und manchmal zeitbeschränkt (z.B. Recht am Bild für 6 Monate).

Mit Drupal Commerce lassen sich all diese Optionen konfigurieren und in diesem Beitrag beschreibe ich die technischen Grundlagen für den Verkauf virtueller Güter.

Kategorien
Content Management Systeme E-Commerce Shared Hosting Site Builder

Drupal Commerce

Monetarisierung ist in aller Munde und jedes Content-Management-System benötigt einen optionalen Shop. In WordPress heisst „das“ Shopsystem WooCommerce, in Drupal heisst es einfach Commerce (ohne Woo).

Der Marktanteil von Drupal Commerce ist, verglichen mit WordPress WooCommerce relativ klein. Wer allerdings eine Drupal Site betreibt, findet mit dem Commerce Modul eine zuverlässige und flexible Shop-Lösung die darüberhinaus auch noch freie Open Source Software ist und sich hervorragend in das Drupal Ökosystem mit Inhaltstypen und deren Feldern und Verbindungen einpasst.

Kategorien
Automatisierung Content Management Systeme Site Builder

Drupal mit Composer oder mit Ludwig?

Das Major Update von Drupal 7 auf Drupal 8 (heute 9), vor mittlerweile sechs Jahren führte zu einer Segmentierung, um nicht zu sagen Spaltung der Drupal Community.

Bis zu dieser Zeit war Drupal ein sehr beliebtes Projekt bei Site-Buildern, die Drupal als No-Code Plattform nutzten und in kürzester Zeit beeindruckende und kostengünstige Websites nur durch Konfigurationen auf der Benutzeroberfläche realisieren konnten. Viele grosse Firmen wurden auf die Drupal Rockstars und die „One man armies“ im Theming-Bereich aufmerksam und stellten auch sehr grosse, mehrsprachige Websites auf Drupal um. Damals waren die Versionen Drupal 6 und 7 aktuell und die Art und Weise, wie diese Sites konfiguriert wurden, führte bei vielen Projekten durch ganz unterschiedliche Gründe längerfristig zu Performance- und Wartungsproblemen.

Drupal 8 war, verglichen mit Drupal 7, technisch besser durchdacht und bot „klassischen“ Software-Entwicklern Möglichkeiten, einen Grossteil der UI-Konfiguriererei zu vermeiden. Konfigurationsänderungen konnten als YAML-Dateien geschrieben und als Code ausserhalb der Datenbank in Versionskontrollsystemen verwaltet werden. Diese Vorgehensweise (Composer, Drush, Git) wurde in den letzten sechs Jahren verfeinert und ist auch heute die empfohlenen Vorgehensweise bei einem Drupal Projekt.

Kategorien
Content Management Systeme Shared Hosting

Konfigurations-Management am Beispiel Drupal

Wer eine Website über längere Zeit betreibt, muss an dieser Website oft Änderungen und Erweiterungen vornehmen. Das gilt insbesondere für Content Management Systeme wie WordPress, Drupal und Joomla.

Die Zielgruppen dieser Systeme sind durchaus unterschiedlich. Einerseits werden sie gern von Anwendern genutzt, die die individuelle Konfiguration der Website über die Benutzeroberfläche im Browser vornehmen und nur im Notfall selbst programmieren wollen.

Andererseits werden diese Systeme auch von Web-Agenturen als Basis für Kunden-Projekte genutzt. In diesem Fall werden, neben den Konfigurationsänderungen, oft individuell programmierte Features für die Kunden der Agentur erstellt die nach dem Launch der Website supported werden müssen.

In den meisten Fällen einigt man sich zwischen Agentur und Kunde auf eine Umgebung mit einer produktiven Live-Site und mindestens einer oder auch mehreren Test-, Staging- und Entwicklungs-Websites. Auch für die kleinste Website bietet es Vorteile wenn nicht „live“ konfiguriert wird. Die Änderungen können „in Ruhe“ in einer Test-Umgebung gemacht werden und bei Gefallen in die Live-Site übertragen werden. Die „Übertragung“ ist allerdings gar nicht so einfach zu realisieren, weil die Änderungen oft viele „Kleinigkeiten“ umfassen und im schlimmsten Fall auf der Live-Site manuell nachvollzogen werden müssen. Je mehr Personen an der Entwicklung der Website arbeiten, umso wichtiger sind klare Vereinbarungen, wer an welcher Stelle und zu welcher Zeit etwas ändern darf.

Programmcode für zusätzliche Plugins, Erweiterungen, Module, Themes und Templates lässt sich gut in Versionskontrollsystemen wie Git verwalten, wie aber geht man mit Konfigurationseinstellungen um? Ich denke da an die Positionierung von Blöcken, Menüpunkte, Einstellungen in Themes, der Name der Website, die Datumsformate und vieles andere mehr.

Konfigurationen werden in LAMP-basierten Systemen gern in der Datenbank verwaltet und sind daher nicht mit gängigen Mitteln wie Git versionierbar.

In diesem Blog-Post zeige ich den Ansatz, den Drupal bei der Verwaltung von Konfigurationen verfolgt.

Kategorien
Allgemein Content Management Systeme Marketing

Download gegen E-Mail Adresse. So geht es in WordPress, Joomla und Drupal

E-Mail Marketing gilt als effektiv, wenn man es „ordentlich“ betreibt. Ordentlich ist in diesem Zusammenhang ganz einfach zu verstehen. Nerve die Menschen nicht mit deinen E-Mails und frage gefälligst vorher (!), ob du ihnen etwas zusenden darfst.

Wie aber kommt man den nun an diese interessierten Personen, denen man E-Mails mit seinen wunderbare Ideen schicken darf und die vielleicht zufriedene Kundinnen und Kunden werden?

Eine sehr gebräuchliche und für beide Seiten durchaus faire Methode ist das Anbieten einer Datei zum Download. Das kann beispielsweise ein eBook, eine PDF Datei, ein Bild, ein Musikstück, oder ein Video sein. Wer die Datei laden will, muss seine E-Mail und sein Einverständnis für die gewünschte Nutzung der E-Mail hinterlassen. Die Datei muss natürlich einen gewissen Wert für die Person, die sie herunterladen soll, haben und dieser Wert wird mit den eigenen Daten bezahlt.

Das Charmante an dieser Methode ist die Ausschaltung der Mittelsmänner. E-Mail Adressen werden nicht irgendwo gekauft oder auf dunklen Wegen „besorgt“ sondern man baut sich seinen „E-Mail Stamm“ selbst auf und entwickelt daraus Kunden.

Wie aber setzt man diese Download-Idee ganz praktisch um?

Für die drei weit verbreiteten System WordPress, Joomla und Drupal werde ich jeweils eine Variante beschreiben.