Kategorien
Content Management Systeme Shared Hosting Webdesign Webserver Wunschthema

Ein Blog Netzwerk mit WordPress

Bevor ich zum eigentlichen Thema dieses Artikels komme, muss ich etwas ausholen. Lesen und Schreiben sind gut und sehr wichtig.
Wer bloggt, macht beides!

BLOGGEN …

  • hilft dir, neue Dinge zu lernen
  • hilft klarer zu denken
  • hilft dir, strukturierter zu schreiben
  • baut dein Selbstvertrauen auf
  • hilft dir, kohärenter zu sprechen
  • kann dir helfen Geld zu verdienen
  • erfordert keine Vorkenntnisse
  • fordert dich heraus
  • ist kostenlos (oder erschwinglich)

Aus diesen Gründen führen auch wir das NOVATREND Blog und probieren immer vieles aus. Seit Mai 2015 bin ich privat beispielsweise Iron Blogger. Dieses Jahr im März war ich beim CMSSummit in Kampala, Uganda und berichtete unter anderem von meinen Iron Blogger Erfahrungen. Ein paar Zuhörer wollten sofort anfangen zu bloggen. Also starteten wir unter ironblogger.cocoate.com eine eigene, kleine Iron Blogger Gruppe, die mittlerweile aus 11 Bloggern besteht, die aus der Schweiz, Frankreich, Deutschland, Kenia, Nigeria und Uganda kommen.

Die Grundidee beim Iron Blogging ist, einmal pro Woche etwas auf seinem eigenen Blog zu schreiben. Die Beiträge werden zentral über die entsprechenden Feeds auf unserer Site (ironblogger.cocoate.com) aggregiert. Wer nicht bloggt, muss 5 Euro in einen virtuellen Topf werfen. Weil in diesem Fall viele Mitglieder aus ärmeren Ländern dabei sind, haut das mit den 5 Euro natürlich nicht hin und wir beschlossen anstelle der 5 Euro könne man auch eine „Gute Tat“ vollbringen und darüber schreiben. Das klappt nun seit 9 Monaten gut und die meisten bloggen regelmäßig. Bisher haben wir 262 Blogbeiträge.
Einmal pro Woche wird automatisiert eine Übersicht erstellt (Beispiel).

Nun stellte sich mehrfach das Problem, dass neue Mitglieder noch kein Blog haben und eine werbefreie Plattform suchen. Osbert war der erste, der ein Blog brauchte. Er kommt eigentlich aus der Joomla Welt, hat keinen eigenen Webspace und hatte sich auf joomla.com eine kostenlose Site eingerichtet. Diese Site hatte allerdings kein RSS Feed um seine Blogposts auf der zentralen Seite einzubinden.

Und damit sind wir endlich beim Thema des Artikels 🙂

Ein Blognetzwerk mit WordPress

Jede WordPress Installation bietet die Möglichkeit, beliebig viele WordPress Sites auf einer Code Basis zu erstellen.

Ziel: Die Site ironblogger.cocoate.com läuft unter WordPress und soll die Möglichkeit bieten, beliebig viele Blogs, die dann unter [blogname].ironblogger.cocoate.com laufen, anzubieten.

Hinweis: Wir diskutieren gerade über einen neuen Domain Namen für unsere Hauptseite und anstelle von ironblogger.cocoate.com wird die Site, wenn du diesen Blogeintrag liest, ibcoco.net heißen. Du bist herzlich eingeladen Iron Blogger zu werden!

Konfigurationsdatei anpassen

Die WordPress Funktion, die wir für das Blog Netzwerk benötigen, heißt Multisite. Um eine Multisite einrichten zu können, muss in der Konfigurationsdatei wp-config.php folgende Zeile hinzugefügt werden:

/* Blognetzwerk aktivieren */
define( 'WP_ALLOW_MULTISITE', true );

Danach lässt sich im Dashboard unter Tools (Einstellungen) ein Netzwerk von WordPress Seiten erzeugen. Weil unserer Site schon länger existiert müssen wir für jede neue WordPress Site eine Subdomain anlegen, aber genau das ist ja unser Ziel. Bei einer Neuinstallation wäre es möglich Unterverzeichnisse pro WordPress Site zu vergeben.

Netzwerk einrichten
Netzwerk einrichten

Neu dem Erzeugen des Netzwerks müssen weitere Konfigurationseinträge in der wp-config.php und der .htaccess vorgenommen werden. Die notwendigen Änderungen werden im Dashboard angezeigt, in meinem Fall sehen sie so aus:

define('MULTISITE', true);
 define('SUBDOMAIN_INSTALL', true);
 define('DOMAIN_CURRENT_SITE', 'ironblogger.cocoate.com');
 define('PATH_CURRENT_SITE', '/');
 define('SITE_ID_CURRENT_SITE', 1);
 define('BLOG_ID_CURRENT_SITE', 1);

Datei: wp-config.php

RewriteEngine On
 RewriteBase /
 RewriteRule ^index\.php$ - [L]

# add a trailing slash to /wp-admin
 RewriteRule ^wp-admin$ wp-admin/ [R=301,L]

RewriteCond %{REQUEST_FILENAME} -f [OR]
 RewriteCond %{REQUEST_FILENAME} -d
 RewriteRule ^ - [L]
 RewriteRule ^(wp-(content|admin|includes).*) $1 [L]
 RewriteRule ^(.*\.php)$ $1 [L]
 RewriteRule . index.php [L]

Datei: .htaccess

Neuanmeldung als Netzwerk Administrator

Nach der Erzeugung des Netzwerks und den Dateiänderungen musst du dich neu anmelden und siehst in deinem Dashboard nun zusätzliche Menulinks zur Netzwerkverwaltung, in der du Sites und User anlegen, Plugins und Themes installieren und Einstellungen vornehmen kannst.

Netzwerk Konfiguration
Netzwerk Konfiguration

Neue WordPress Site anlegen

Die erste Site, die ich anlege, ist die für Osbert. Hier kann der Subdomain Name festgelegt und die gewünschte Sprache installiert werden.

Site einrichten
Site einrichten

In den Netzwerk Einstellungen können weitere Parameter gesetzt werden, die für alle Blogs gelten, beispielsweise, ob die Erstellung weiterer Benutzerkonten in den einzelnen WordPress Sites erlaubt ist.

Netzwerk Einstellungen
Netzwerk Einstellungen

Damit ist für WordPress der Fall erledigt und du kannst nun beliebig viele WordPress Sites hinzufügen.

Domain Name zuordnen

Je nach deiner individuellen Infrastruktur, muss nun noch die Subdomain erzeugt werden und auf den richtigen Server zeigen. In meinem Fall nutze ich eine Wildcard Domain (*.ironblogger.cocoate.com) als Alias. Alle Namen werden dann automatisch weitergeleitet.

Achtung: Wildcard Domains können „gefährlich“ sein, weil es beispielsweise möglich ist [bekannterMarkenname].ironblogger.cocoate.com aufzurufen und je nach Rechtslage im entsprechenden Land dann eine Abmahnung wegen unzulässiger Verwendung dieses Markennamens möglich sein kann. In unserem Fall spielt das keine Rolle, weil die Sites manuell angelegt werden.

So sieht der ServerAlias Eintrag in meiner Apache Konfigurationsdatei aus:

<VirtualHost *:80>
 ServerAdmin hagen@cocoate.com
 ServerName ironblogger.cocoate.com
 ServerAlias *.ironblogger.cocoate.com
...

Nach einem Neustart des Webservers sind die Änderungen aktiv und Osbert hat sein Blog. Es ist ein ganz normales WordPress!

Osbert's Blog
Osbert’s Blog

In der Netzwerkverwaltung gibt es eine Update- und eine Upgradefunktion. Die Updates beziehen sich auf WordPress Updates und die Upgrade Funktion auf die Netzwerk Eigenschaften. WordPress weist normalerweise darauf hin, wenn ein Netzwerk Upgrade notwendig ist.

Upgrade Network
Upgrade Network

Jede Site im Netzwerk kann zentral verwaltet werden

Einstellungen einer Site
Einstellungen einer Site

Fazit

WordPress bietet auf erstaunlich einfache Weise die Möglichkeit viele WordPress Sites auf einer Code Basis zu hosten. Das ist nicht nur für Blog Netzwerke, sondern natürlich auch für Unternehmenswebsites interessant, die mehrere WordPress Installationen zusammenfassen wollen. Jede einzelne Site kann auch einen unterschiedlichen Domain Namen haben (aber das ist Stoff für einen neuen Blog Post).

Link


tl;dr: Aus einem WordPress lässt sich einfach ein Netzwerk vieler WordPress Sites konfigurieren

 

 

#ffffff; background: #bd081c no-repeat scroll 3px 50% / 14px 14px; position: absolute; opacity: 1; z-index: 8675309; display: none; cursor: pointer; top: 4466px; left: 50px;">Save

Kategorien
Infrastruktur seafolly.ch Shared Hosting Tools Wunschthema

Datenbankverwaltung in einer Datei – Adminer

Heute mal wieder ein Wunschthema!
Ist dir das auch schon passiert? Du willst etwas an der Website eines Kunden oder Bekannten ändern und benötigst kurz Zugriff auf die Datenbank. Für die Verwaltungsoberfläche des Hosters hast du kein Passwort, der Mensch der das Passwort kennt ist gerade nicht erreichbar. Du könntest phpMyAdmin installieren, brauchst aber natürlich gar nicht die ganze Funktionalität. Du könntest auch auf dem Rechner, an dem du sitzt, ein Tool wie Sequel Pro installieren aber du weißt natürlich nicht ob der Datenbankserver des Hosters so konfiguriert ist, dass er von „außerhalb“ des entsprechenden Rechenzentrums überhaupt zugänglich ist. Es soll auch alles nicht so lange dauern …

Vermutlich hat jeder von uns schon mal so eine Situation gehabt und ist dann vom Hundertsten ins Tausendste gekommen bis endlich ein Datenbankzugang hergestellt werden konnte.

Das muss nicht sein, denn für solche Fälle gibt es das Projekt Adminer. Es bietet eine Datenbankverwaltung in einer Datei an, die man mal schnell per FTP auf den entsprechenden Server laden kann. Adminer gibt es für MySQL, PostgreSQL, SQLite, MsSQL, Oracle, Firebird, SimpleDB, Elasticsearch and MongoDB.

Außer der einen Datei gibt es auch ein WordPress Plugin, ein Drupal Modul und viele weitere Integrationen.

Adminer Installation

Nach soviel Vorschusslorbeeren will ich die Installation und Benutzung auf einem NOVATREND Shared Hosting Paket zeigen.

Zunächst musst du die Adminer Datei von der Projekseite herunterladen. Es gibt unterschiedliche Versionen.

Ich nutzte die MySQL Deutsch Variante die tatsächlich nur 190 kB groß ist und lade sie auf den Server.

hochladen per FTP
hochladen per FTP

Damit es einfacher ist, benenne ich die Datei von adminer-4.2.5-myqsl-de.php auf adminer.php um und rufe sie über https://seafolly.ch/adminer.php auf.

Adminer Anmeldung
Adminer Anmeldung

Ohne die Zugangsdaten zur Datenbank ist das Tool für Außenstehende wertlos, trotzdem solltest du es nach deiner Arbeit wieder vom Server entfernen (man weiß ja nie 🙂 ).

Beim Datenbankzugang ist es nicht schlimm wenn keiner das Passwort weiß. Es steht auf jeden Fall in der entsprechenden Konfigurationsdatei des installierten CMS.

Nach Eingabe von Datenbankname, Benutzername und Passwort landet man in der Adminer Oberfläche. In meinem Fall in den Tabellen einer Drupal 8 Installation.

Adminer Oberfläche
Adminer Oberfläche

Die Oberfläche bietet Funktionen wie:

  • Selektieren einer existierenden Datenbank oder Erzeugen einer Neuen
  • Auflisten vom Feldern, Indizes, Fremdschlüsseln und Triggern einer Tabelle
  • Ändern von Name, Speicher-Engine, Collation, Auto_Increment und Kommentaren von Tabellen
  • Ändern von Name,Typ, Collation, Kommentaren und Standardwerten der Spalten
  • Hinzufügen und Löschen von Tabellen und Spalten
  • Erzeugen, Ändern und Suchen über Indizes mit Volltextsuche
  • Erzeugen, Ändern, Löschen und Link Listen von Fremdschlüsseln
  • Erzeugen, Ändern und Selektieren von Views
  • Erzeugen, Ändern und Aufrufen von Stored Procedures und Functions
  • Erzeugen, Ändern und Löschen von Triggern
  • Anzeige der Daten in Tabellen mit Suchfunktion, Zusammenfassung und Sortierung
  • Fügt neue Datensätze ein und ändert oder löscht bestehende Datensätze
  • Unterstützt alle Daten Typen, Blobs über File Transfer
  • Führt SQL Befehle über ein Eingabefeld oder eine Datei aus
  • Exportiert Tabellenstruktur, Daten, Views, Routinen und Datenbanken als SQL oder CSV
  • Druckt das Datenbank Schema verbunden über Fremdschlüssel
  • Zeigt Prozesse und bricht sie ab
  • Zeigt Benutzer und Rechte und ändert sie
  • Zeigt Variablen mit Verlinkung zur Documentation
  • Eventmanager und Tabellen Partionierung (MySQL 5.1)

Außerdem lässt sich Adminer umfangreich anpassen!

Fazit

Adminer ist die mit Abstand einfachste Art um „mal schnell“ an einer Datenbank etwas zu ändern oder zu exportieren und importieren. Ich wünsche viel Spaß bei Ausprobieren.

Links


tl;dr: Adminer ist ein Tool zur Verwaltung von Datenbanken und besteht aus einer einzigen Datei!

#ffffff; background: #bd081c no-repeat scroll 3px 50% / 14px 14px; position: absolute; opacity: 1; z-index: 8675309; display: none; cursor: pointer; top: 2293px; left: 50px;">Save

Kategorien
Content Management Systeme Shared Hosting

WordPress 4.7 – Was ist eigentlich diese REST-API?

Seit Monaten, wenn nicht Jahren, wird bei jeder neuen Version von WordPress auch über die REST-API gesprochen. Letzte Woche war es mal wieder soweit als WordPress 4.7. veröffentlicht wurde. Außer einem neuem Theme und vielen kleinen Detailverbesserungen war wieder die REST-API ein Thema.

Sie hat neue Endpunkte erhalten!

Aha, denkt sich der gemeine WordPress User!

Dieser Beitrag wendet sich an alle nicht REST-API Spezialisten und soll für Aufklärung sorgen, worum es eigentlich geht.

Das sagt Wikipedia zu Thema REST:

REST ist eine Abkürzung für „Representational State Transfer“. Die Bezeichnung „Representational State Transfer“ soll den Übergang vom aktuellen Zustand zum nächsten Zustand (state) einer Applikation verbildlichen. Dieser Zustandsübergang erfolgt durch den Transfer der Daten, die den nächsten Zustand repräsentieren. Der Zweck von REST liegt schwerpunktmäßig auf der Maschine-zu-Maschine-Kommunikation …

Das sagt Wikipedia zu Thema API:

Eine Programmierschnittstelle, genauer Schnittstelle zur Anwendungsprogrammierung, häufig nur kurz API genannt (englisch application programming interface, wörtlich ‚Anwendungs­programmier­schnittstelle‘), ist ein Programmteil, der von einem Softwaresystem anderen Programmen zur Anbindung an das System zur Verfügung gestellt wird.

Wenn dir immer noch nicht ganz klar ist worum es geht, keine Sorge, du bist nicht allein.

Wozu benötigt der Mensch eine REST-API in WordPress?

Hier ein paar Beispiele um sich dem Thema zu nähern. Außer der freien WordPress.org Software gibt es noch die Firma Automattic, die das kommerzielle WordPress.com betreibt und bereits seit längerem eine eigene REST-API in Ihren Services nutzt. Selbst gehostete WordPress.org Sites können dort integriert werden, wenn sie auf WordPress.com registriert und über ein spezielles Plugin (JetPack) „verbunden“ sind.

Calypso (WordPress.com Desktop Apps)

Calypso ist eine Desktop App für MacOS, Windows und Linux. Es stellt eine einheitliche Oberfläche dar um viele WordPress Sites zu verwalten. Die Kommunikation zwischen den WordPress Sites und Calypso findet über die WordPress.com REST-API statt. Calypso ist in JavaScript geschrieben, ist Open Source Software und stellt einen Client für WordPress Sites dar.

Calypso
Calypso

WordPress.com

Etwas später als Calypso wurde die neue Verwaltung auf WordPress.com vorgestellt, die auf der gleichen Technik wie Calypso basiert aber komplett im Browser läuft. Es muss also nichts extra installiert werden. WordPress.com ersetzt das komplette WordPress.org Website Dashboard.

WordPress.com Mobile Apps

Für Mobiltelefone gibt es die iOS und Android Apps, die es ebenfalls ermöglichen, selbst gehostete WordPress Sites zu bedienen. Hier findet ein Mix aus der, bereits seit WordPress 1.5 existierenden, XML-RPC Schnittstelle und der neuen WordPress REST-API statt.

WordPress.com iOS App
WordPress.com iOS App

Alle Projekte nutzen die WordPress.com REST-API, ersetzen den klassischen WordPress.org Administrationsbereich (Dashboard) und zeigen was prinzipiell mit dieser Technik möglich ist.

Nach und nach wurde nun neben der WordPress.com REST-API auch eine WordPress.org REST-API entwickelt. Damit kann jeder Anwendungen erstellen, die nicht mit einem speziellen Plugin mit WordPress.com verbunden werden müssen sondern unabhängig davon funktionieren. Auch die Wahl der Programmiersprache ist völlig frei.

Das ist das „Ding“ mit der REST-API.
Sie eröffnet neue Möglichkeiten im Front- und Backend Bereich. Außerdem ermöglicht sie das Verschmelzen von vielen WordPress Sites zu einer (neuen) Anwendung.

Ein einfaches Anwendungsbeispiel

Ich betreibe ein Blogging Projekt, bei dem jeder Teilnehmer einmal die Woche auf seinem eigenen Blog einen Artikel schreiben muss. Am Ende der Woche werden die Artikel gesammelt und auf einer Übersichtsseite ausgegeben (Weekly blog posts). Das Sammeln und Eintragen der Daten erfolgt automatisch mit einem Python Script. Das Script nutzt die „alte“ XML-RPC Schnittstelle von WordPress und erzeugt einen neuen Artikel pro Woche. Dazu wird kein zusätzliches Plugin benötigt.

Mit der neuen REST-API liesse sich eine Anwendung schreiben (Iron Blogger App), die on the fly die Daten zusammenstellt, schick darstellt und Interaktionsmöglichkeiten bietet. Da das ohne Zusatz Plugins funktioniert, hat jede installierte WordPress Site die Funktionalität bereits eingebaut und kann genutzt werden.

Praxis

Nachdem die Dimensionen abgesteckt sind, will ich ein kleines Beispiel anhand des NOVATRENS Blogs zeigen. Ruft einfach im Browser mal http://blog.novatrend.ch/wp-json auf. Das Ergebnis sieht interessant aus:

http://blog.novatrend.ch/wp-json
http://blog.novatrend.ch/wp-json

Die Site bietet die folgenden Namespaces (API’s) an:

  • oembed/1.0
    OEmbed ist ein Format, das eine eingebettete Darstellung einer URL auf Websites von Drittanbietern ermöglicht. Wenn du einen Link von Sites wie YouTube oder Flickr in den Editor ziehst, sorgt dieses Format dafür, das ein Vorschaubild mit Text und Link angezeigt wird.
  • jetpack/v4
    JetPack ist das WordPress Plugin, dass die WordPress.com REST-API zur Verfügung stellt. Wir nutzen es, da wir die WordPress.com Apps ebenfalls nutzen.
  • wp/v2
    Da ist sie nun!
    Die standardmässige WordPress.org REST-API
    Hier sind all die neuen Sachen zu finden!

Alle Blog Posts sehen

Wenn du nun http://blog.novatrend.ch/wp-json/wp/v2/posts im Browser aufrufst, siehst du die Startseite unseres Blog in maschinenlesbarer Form.

NOVATREND Blog Posts
NOVATREND Blog Posts

Du kannst natürlich auch einen einzelnen Post aufrufen

http://blog.novatrend.ch/wp-json/wp/v2/posts/1423

Dieser Aufruf im Browser entspricht einen GET Kommando.

GET /wp/v2/posts/<id>

Mit der entsprechenden Berechtigung könntest du ihn auch löschen

DELETE /wp/v2/posts/<id>

oder einen neuen Eintrag erstellen

POST http://demo.wp-api.org/wp-json -d '{"title":"My New Title"}'

Auf diese Art kannst du alle Informationen, die unser Blog bietet maschinell auslesen und, so wie du willst, wieder zusammenbauen. Ich lasse die urheberrechtlichen Zusammenhänge mal außen vor :).
Du kannst dich auch gegenüber dem Blog als berechtigte Person authentifizieren und Änderungen vornehmen.

Und was ist jetzt neu in WordPress.org REST-API?

Genau das! Es gibt jetzt mehr Endpunkte und mehr Möglichkeiten. Konkret sind Zugriffe auf Posts, Nutzer, Tags und Einstellungen möglich. Für die Aufrufe selbst verwendet man die Hypertext Application Language (HAL). Der Datenaustausch erfolgt über JSON.
Öffentliche Aufrufe als auch private Anfragen, die eine vorherige Authentifizierung erfordern sind nun ebenfalls möglich.

Hinweis: Du kannst die REST-API auch für nicht eingeloggte Besucher abschalten 🙂 https://www.kuketz-blog.de/wordpress-rest-api-unter-wordpress-4-7-deaktivieren/


Links


tl;dr: WordPress hat eine REST-API und damit kannst du tolle Dinge machen!

#ffffff; background: #bd081c no-repeat scroll 3px 50% / 14px 14px; position: absolute; opacity: 1; z-index: 8675309; display: none; cursor: pointer;">Save

Kategorien
Allgemein Infrastruktur Server Services Shared Hosting Site Builder Webdesign Webserver Wunschthema

Entwicklungsworkflow für Deine Website(s)

Heute gibt es wieder ein Wunschthema. Es geht um die Art und Weise, wie du den Entwicklungsworkflow für deine Website organisierst.

Wenn du eine Website bei einem Service Provider wie NOVATREND hostest, musst du deine Entwicklungsarbeit an dieser Website organisieren. Im einfachsten Fall gibt es zwei Möglichkeiten.

  1. Du arbeitest live auf dem Server/Webhosting:
    Du installiert ein CMS per Installation-Skript, beispielsweise durch unser Installatron und arbeitest dann live weiter auf der Site.
    ACHTUNG: Seit November 2017 benutzen wir anstelle des Installatrons das Tool Softaculous. Im Beitrag Automatisierte Installation mit Softaculous beschreibe ich die grundlegenden Vorgehensweisen.
  2. Lokal auf deinem Rechner:
    Du installierst zunächst eine lokale Entwicklungsumgebung wie XAMPP, MAMP oder Vagrant/Virtual Box auf deinem lokalen Rechner. Du erstellt die Website lokal und irgendwann lädst du das Ergebnis „auf den Server“, beispielsweise mit einem FTP-Client.

Beide Varianten haben Vor- und Nachteile.
Der Vorteil (und Nachteil) bei Variante 1 ist, dass es nur eine Version der Website gibt und alle Änderungen sofort live sind. Der grösste Nachteil dabei ist, dass die Website offline ist, wenn du einen Fehler bei deinen Änderungen machst. Ausserdem hast du keine Testversion deiner Website, die du deinen Kunden zeigen kannst.
Bei Variante 2 umgehst du das Problem der Offline Zeiten durch eventuelle Fehler durch die Tatsache, dass du lokal auf deinem Rechner arbeitest. Du kannst deine Änderungen auch testen und dem Kunden auf deinem Rechner zeigen.  Du musst aber die von dir gemachten Änderungen irgendwie mit dem Server synchronisieren. Solange du allein arbeitest, klappt das noch ganz gut, spätestens wenn mehrere Personen an einer Seite entwickeln oder der Kunden nicht persönlich auf deinen Rechner gucken kann, wird es schwierig oder gar unmöglich.

Versionsverwaltung

Eine grundsätzlich gute Idee ist, den Quellcode deiner Website in einem Versionsverwaltungssystem zu lagern. Du kannst bei Fehlern zu einer älteren Version zurückkehren und mehrere Entwickler können am Code arbeiten. Für Kunden kann eine Testumgebung, meist stage genannt auf einem Live Server mit Passwortschutz bereitgestellt werden. Das von den meisten genutzte Versionsverwaltungssystem heisst Git. Es ist eine freie Software zur verteilten Versionsverwaltung von Dateien, die durch Linus Torvalds initiiert wurde. Quellcode wird in sogenannten Repositories gelagert. In einem Repository liegen alle Dateien. Das ist vergleichbar mit einem Fotoalbum, in dem Fotos liegen. Du kannst dir selbst einen Git Server einrichten, normalerweise benutzt man aber Services wie GitHub oder BitBucket, die den Quellcode lagern, auf Git basieren und viel komfortabler sind als eine selbst gehostete Lösung. Beide Services haben natürlich ein Geschäftsmodell. Bei GitHub musst du dafür bezahlen, wenn dein Code nicht öffentlich sichtbar, also privat, sein soll. Bei BitBucket sind private Repositories erlaubt, dein Team darf aber nicht mehr als fünf Entwickler haben. Du musst im Einzelfall entscheiden, was besser für dich passt.

Entwicklung und Deployment

Unter Entwicklung verstehe ich das Arbeiten am Code und unter Deployment die Übertragung der Änderungen auf ein Live System. Das ist auch für Nicht-Entwickler interessant, denn Design Anpassungen oder ganze Webseiten bei dateibasierten CMS stehen natürlich auch in Dateien.

Ein Beispiel mit BitBucket

Ich gehe im Beispiel davon aus, dass du deinen Website Quellcode nicht öffentlich verwalten möchtest. Da BitBucket es erlaubt, private Repositories kostenlos zu verwalten, werde ich es für das Beispiel nutzen. Ich möchte mit einer neuen Website in einer lokalen Entwicklungsumgebung beginnen, den Quellcode bei BitBucket versionieren und bei Bedarf mit dem Live Server synchronisieren.

Konto und Repository bei BitBucket anlegen

Als Erstes musst du dir ein BitBucket Konto anlegen. BitBucket kennt Projekte und Repositories. Du könntest beispielsweise ein Projekt anlegen und darin dann mehrere Repositories. Du kannst aber auch ein Repository ohne übergeordnetes Projekt anlegen.

BitBucket - Repository anlegen
BitBucket – Repository anlegen

Lokales Verzeichnis einrichten

Richte dir lokal ein Verzeichnis für deine Projekte ein, beispielsweise /dev, öffne eine Shell, gehe in dieses Verzeichnis und führe die folgenden Befehle aus.

git clone git@bitbucket.org:hagengraf/novatrendtest.git

Der Inhalt des novatrendtest Repositories wird „gecloned“, d.h. in das lokale Verzeichnis geladen. Git erstellt ein Verzeichnis mit dem Namen des Repositories. Wechsele in dieses Verzeichnis.

cd novatrendtest

Nun kannst du mit einem Texteditor oder dem folgenden Befehl eine Datei mit dem Namen README.md erzeugen und den Text „# My project’s README“ hineinschreiben. Du kannst sie auch test.txt oder meinewebsite.html nennen. Eine „read me“ Datei ist aber immer eine gute Idee, weil dort immer die wichtigste Informationen stehen.

echo "# My project's README" >> README.md

Die Datei muss dem Git System hinzugefügt werden, damit das die verschiedenen Versionen verwalten kann.

git add README.md

Dein lokales Git weiss nun, das es eine neue Datei gibt, weiss aber noch nicht, wann du mit deinen Änderungen soweit bis, das du sie abschliessen (commit) kannst. Der Befehl git commit signalisiert dem lokalen Git System, dass du deine Änderungen für abgeschlossen erklärst. Der Parameter -m übermittelt eine Bemerkung zu den Änderung (message), damit Dritte (und auch du selbst nach ein paar Monaten) nachvollziehen können, was du da geändert hast. Im unserem Fall ist es ein Initial commit, also eine erste Änderung

git commit -m "Initial commit"

Das lokale System ist nun up to date, das BitBucket System weiss aber noch nichts von deinen Änderungen. Der Befehl git push überträgt die letzten Änderungen (commits) an dein Bitbucket Repository (origin master).

git push -u origin master

Alles zusammen sieht in der Shell so aus:

Lokales Verzeichnis einrichten
Lokales Verzeichnis einrichten

Änderungen auf BitBucket angekommen?

Wenn du dein BitBucket Repository im Browser ansiehst, siehst du deinen ersten Commit mit der Nachricht Initial commit.

Initial commit
Initial commit

Wenn du auf die Nummer des Commits klickst, siehst du die Details. Du hast eine Zeile eingefügt!

Commit 5020980
Commit 5020980

Live Server

Zuletzt musst du auf deinem Live Server ebenfalls ein Verzeichnis einrichten, das mit dem BitBucket Repository verbunden ist. Um den Live Server zu aktualisieren, kannst du vom Server aus den Befehl git pull [option] eingeben und die Änderungen „pullen“ oder du konfigurierst sogenannte Webhooks, die die Änderungen aus BitBucket heraus auf den Server „pushen“.

Abhängig vom Provider und der Art des Servers gibt es viel Konfigurationsmöglichkeiten. Grundsätzlich benötigst du ein installiertes Git auf dem Server und einen Key, der in BitBucket hinterlegt werden muss. Ohne Key musst du bei jedem git pull ein Passwort eingeben, was auf die Dauer nicht praktikabel ist. Der Befehl für die Schlüsseleinrichtung ist ssh-keygen. Normalerweise wird der Key in ~/.ssh/id_rsa gespeichert. Im Dialog musst du bei der Abfrage, wo du den Key speichern willst, das Wort deploy_key eingeben und KEIN Passwort festlegen.

### SSH Key einrichten
$ ssh-keygen 
Generating public/private rsa key pair.
Enter file in which to save the key (~/.ssh/id_rsa): deploy_key
Enter passphrase (empty for no passphrase):

Gibt man wie oben gezeigt „deploy_key“ ein, erzeugt das Tool zwei Dateien im aktuellen Verzeichnis: deploy_key und deploy_key.pub.

Auf dem Server muss das Verzeichnis initialisiert werden (git init). Dann muss das existierende Verzeichnis geklont werden (git clone). Danach wird das remote Repository festgelegt (git remote add …).

Wenn diese Schritte erledigt sind, können Änderungen aus BitBucket mit dem Befehl git pull auf den Live-Server übertragen werden.

git init
git clone bitbucket git@bitbucket.org:hagengraf/novatrendtest.git
git remote add bitbucket git@bitbucket.org:hagengraf/novatrendtest.git
git pull

Hier in meinem Beispiel ist public_html das Live-Verzeichnis auf dem Server. Die Verzeichnisstruktur sieht folgendermassen aus (Befehl ls -al).

drwxr-xr-x 6 root root 4096 Nov 14 17:09 .
drwxr-xr-x 23 root root 4096 Nov 14 14:28 ..
-rw------- 1 novatrend novatrend 1675 Nov 14 16:39 deploy_key
-rw-r--r-- 1 novatrend novatrend 412 Nov 14 16:39 deploy_key.pub
drwxrwxr-x 7 novatrend novatrend 4096 Nov 14 16:37 .git
drwxr-xr-x 2 root root 4096 Jan 19 2016 logs
drwxrwxr-x 12 www-data www-data 4096 Nov 14 17:27 public_html

Wenn du Änderungen „pullen“ möchtest, musst du ins Verzeichnis public_html wechseln und den Befehl git pull eingeben.

Ein User-Interface für Änderungen (Source Tree)

Wenn die Basiseinstellungen eingerichtet sind, ist SourceTree eine hervorragende Software, mit der man die Änderungen in einfachen Projekten per Mausklick verwalten kann.

SourceTree
SourceTree

Ergebnis

Das Beispiel ist extrem einfach, enthält aber das Wesentliche. Es ist jetzt möglich

  1. lokale Änderungen an den Dateien vorzunehmen und zu „committen“ (git commit …).
  2. die Commits in das BitBucket Repository zu „pushen“ (git push).
  3. das BitBucket Repository mit dem Live-Server zu synchronisieren (git pull).

Auch wenn es anfangs aussieht als sei das alles sehr kompliziert, so überwiegen die Vorteile eindeutig. Zugegebenermassen ist es aber auch kompliziert :). Jede berechtigte Person kann sich nun eine lokale Entwicklungsumgebung einrichten, den Code „pullen“, Änderungen vornehmen und „committen“ und schliesslich auf den Live-Server einspielen. Wenn mehrere Entwickler am Code arbeiten, so können sie sogar in der gleichen Datei ändern, ohne sich „ins Gehege“ zu kommen. Genau das ist die wichtigste Voraussetzung für Team- und Remote-Arbeit.

Links


tl;dr: Versionsverwaltung ist die Basis einer geordneten Software Entwicklung und gar nicht so schwer!