Wordpress und GIT

Um sehr große GIT Directories zu vermeiden, sollte im Falle von Wordpress lediglich der Bereich wp-content von GIT überwacht werden. D.h. es werden alle Themes, PlugIns, CSS; JS Skripte etc. übertragen, jedoch NICHT:

• neue WP Kategorien
• Passwortänderungen
• neue Beiträge, etc
• alles was mit der DB zu tun hat

Diese müssen nach wie vor über das PlugIn "all in one migration" nach Hostinger deployed werden. Anschliessend muss das GIT Repo bei Hostinger neu aufgesetzt werden.

--> werden bei WP viele Änderungen gemacht, die außerhalb von wp-content statt finden (MichiPedia), ist eine GIT Überwachung nicht sinnvoll.

GIT Vorbereitung

# korrektes Directory

cd <WP PROJECT>/wp_data/wp-content

# .gitignore Datei (ggfs anpassen)

   uploads
   node_modules
   upgrade
   upgrade-temp-backup
   ai1wm-backups
   /index.php
   /themes/index.php
   /plugins/index.php

# GIT aufsetzen

   git init
   git add -A
   git commit -m 'xxx'

# Remote Repository bekannt machen

Abhängig davon, wohin deployed wird (Github / Hostinger), unterscheidet sich der Remote Pfad. Zur Verdeutlichung bleibt im Falle Github der übliche Kurzname "origin". Bei Hostinger wird "hosti" (o.ä.) verwendet.

# GitHub

git remote add origin git@github.com:MichaelBaierlein/<GITHUB PROJECT>.git

# Hostinger

git remote add hosti ssh://<USER>@<HOSTINGER_DOMAINE_IP>:<PORT>/home/<USER>/repo_pediatest
git remote add hosti ssh://u714311881@154.56.32.212:65002/home/u714311881/repo_christine

# Remote Pfad nachträglich ändern

   git remote set-url hosti ssh://<USER>@<DOMAINE>:<PORT>/home/<USER>/repo_pediatest

Variante 1: über Github nach Hostinger (Webhook)

Projekte werden LOKAL bearbeitet. GITHUB dient als "source of truth". Jedes neue nach Github "gepushte" Commit wird von Github automatisch an HOSTINGER übertragen.

Github

1. Entsprechendes Github Projekt anlegen (private, ohne README.md)

!!
Achtung: branch Name. Aktuell wird "main" als default genommen. Hostinger Standard ist "master".

Wenn man ein leeres Repo erzeugt und von lokal nach Github pusht, gibt es nur den "master" branch und man muss nichts weiter beachten. Wenn man allerdings die Readme erzeugt wird ein Branch "main" mit einem Commit angelegt.
!!

2. Hostinger key

# muss erst bei Hostinger für dieses private Repo erzeugt werden !!
# Erfahrung: ein alter bereits genutzer Hostinger key wurde von GITHUB nicht akzeptiert !!

Unter Security - Deploy keys den öffentlichen Key von Hostinger hinterlegen

  - Titel: z.B. Hostinger
  - Key
  - Allow write access wird nur benötigt wenn Hostinger schreibt


3. Webhook anlegen

# muss erst in Hostinger erstellt werden !!

Unter Webhooks - add webhook den Hostinger Webhook hinterlegen

- payload URL (Hostinger WebHook)
  z.B. https://webhooks.hostinger.com/deploy/xxxxxxxxxxxx
- Content type sollte voreingestellt sein (application/x-www-form-urlencoded
- Enabkle SSL verification (sollte standardmäßig aktiviert sein)
- Just push content

Hostinger

Unter GIT

- Neues Repo erstellen

  Repository   --> git@github.com:MichaelBaierlein/MichiPedia.git
  Zweig        --> master
  Verzeichnis  --> z.B. pediatest/wp-content
                   !! wp-content muss leer sein
                   !! Pfad wird relativ von html-public genommen

- automatische Bereitstellung

  - Webhook in Github anlegen
  - Webhook URL in GIThub eintragen

Variante 2: direkt nach Hostinger

Projekte werden LOKAL bearbeitet und sind "source of truth". Nach jedem neuen Commit kann direkt nach Hostinger gepusht werden.

Wir pushen NICHT in den öffentlich zugänglichen Bereich (public_html), sondern in ein neu anzulegendes Repo ausserhalb von publich_html.

Der GIT Work Tree kann jedoch ein leeres Directory innerhalb von public_html sein (Deployment).

Hostinger

# Repo (ausserhalb von "public_html" z.B. <HOME>/repo_pediatest)

  mkdir <HOME>/repo_pediatest

  cd repo_pediatest

# GIT "bare" repository (kein Working Directory / Working Tree)

  git init --bare

  cd hooks

# Neuen GIT Hook erzeugen

  touch post-receive

  vi post-receive (oder: vim, nano)

# Inhalt von post-receive

  #!/bin/bash
  git --work-tree=/home/u714311881/public_html/wp-content --git-dir=/home/u714311881/repo_pediatest checkout -f

# post-receive muss ausführbar sein

  chmod +x post-receive

#
# Alternativer, flexiblerer Inhalt "post-receive"
#
# Achtung: GIT benötigt mindestens 2 Commits, damit die Parameter
# oldref und newref versorgt werden können
#

#!/bin/bash
TARGET="/home/u714311881/repo_worktree"
GIT_DIR="/home/u714311881/public_html/wp-content"

BRANCH="master"

while read oldrev newrev ref
do
    # only checking out the master (or whatever branch you would like to deploy)
    if [[ $ref = refs/heads/$BRANCH ]];
    then
        echo "Ref $ref received. Deploying ${BRANCH} branch to production..."
        git --work-tree=$TARGET --git-dir=$GIT_DIR checkout -f
    else
        echo "Ref $ref received. Doing nothing: only the ${BRANCH} branch may be deployed on this server."
    fi
done