🚀 Git-Branch in der WordPress Admin-Bar anzeigen 🧠

Der ursprüngliche Gedanke war eigentlich simpel:

Ich wollte in meiner lokalen WordPress-Installation direkt in der Admin-Bar sehen:

• auf welchem Environment ich arbeite (local, staging, production)
• und auf welchem Git-Branch ich mich befinde

Gerade bei mehreren parallelen Features oder Lernprojekten ist das extrem praktisch.

Also habe ich ein kleines Developer-Plugin gebaut, das ungefähr so arbeitet:

$cmd = sprintf(
    'git -C %s rev-parse --abbrev-ref HEAD 2>/dev/null',
    escapeshellarg( WP_CONTENT_DIR )
);

$result = shell_exec( $cmd );

Im Terminal funktionierte der Befehl sofort:

git -C . rev-parse --abbrev-ref HEAD

Ausgabe:

master

In WordPress hingegen:
… nichts.

Der Branch wurde einfach nicht angezeigt.

🧪 Erste Vermutung: shell_exec() deaktiviert? ⚠️

Da viele Hosting-Umgebungen shell_exec() deaktivieren, war das mein erster Verdacht.

Also geprüft:

function_exists( 'shell_exec' )

und zusätzlich:

ini_get( 'disable_functions' )

Aber:
shell_exec() funktionierte problemlos.

Das Plugin lief ebenfalls, denn das aktuelle Environment (LOCAL) wurde korrekt angezeigt.

Der Fehler musste also irgendwo zwischen:

• Apache
• PHP
• Linux-Rechten
• und Git liegen.

🔐 Zweite Vermutung: ACLs und Berechtigungen 🧱

Da ich zuvor bereits ACLs für www-data eingerichtet hatte, war ich überzeugt, dass Apache eigentlich Zugriff auf das Repository haben müsste.

Ein kurzer Test zeigte aber sofort:

sudo -u www-data ls -la /mnt/myhome/www/fullstackdevelopment/wp-content/.git

Ergebnis:

Keine Berechtigung

Das Repository lag innerhalb von:

wp-content/.git

Wichtig dabei:
Das war absichtlich so gewählt.

Normalerweise liegt .git im Projekt-Root.
WordPress deaktiviert dann jedoch automatische Core-Updates, weil die Installation als „versioniert“ erkannt wird.

Da ich automatische Updates weiterhin nutzen wollte, liegt mein Git-Repository bewusst nur innerhalb von wp-content.

🧩 ACLs waren nicht das eigentliche Problem 🔍

Nachdem die ACLs korrigiert waren, funktionierte der Zugriff auf .git plötzlich.

Trotzdem zeigte WordPress weiterhin keinen Branch an.

Der entscheidende Test war dann:

sudo -u www-data git -C /mnt/myhome/www/fullstackdevelopment/wp-content rev-parse --abbrev-ref HEAD

Und plötzlich erschien die eigentliche Ursache:

fatal: detected dubious ownership in repository

🛡️ Git blockierte das Repository selbst 🚫

Das Problem war nicht Linux.
Nicht Apache.
Nicht PHP.

Sondern Git.

Seit neueren Git-Versionen gibt es einen Sicherheitsmechanismus gegen potenziell manipulierte Repositories.

Wenn:

• Repository-Owner
• und ausführender User

nicht zusammenpassen, stuft Git das Repository als „dubious ownership“ ein.

In meinem Fall:

• Repository-Owner: mein Linux-User
• ausführender Prozess: www-data

Für Git sah das potenziell unsicher aus.

⚙️ Die Lösung: safe.directory 🧷

Die Lösung bestand darin, Git dieses Repository explizit als vertrauenswürdig zu markieren:

sudo git config --system --add safe.directory /mnt/myhome/www/fullstackdevelopment/wp-content

Danach funktionierte auch:

sudo -u www-data git -C /mnt/myhome/www/fullstackdevelopment/wp-content rev-parse --abbrev-ref HEAD

Und der Branch erschien endlich korrekt in der WordPress Admin-Bar.

🧠 Warum ich nicht einfach /mnt/myhome/www global freigegeben habe 🗂️

Kurz hatte ich überlegt, direkt den gesamten Entwicklungsordner freizugeben:

/mnt/myhome/www

Das wäre aber deutlich unsauberer gewesen.

safe.directory sollte möglichst präzise gesetzt werden, damit Git nicht pauschal komplette Verzeichnisbäume als vertrauenswürdig behandelt.

Gerade wenn mehrere Projekte oder unterschiedliche Benutzer beteiligt sind, wird das schnell problematisch.

🧾 Fazit 🎯

Der eigentliche PHP-Code war am Ende der einfachste Teil.

Die wirkliche Ursache lag in:

• Linux-Dateirechten 🐧
• Apache-Prozessen ⚙️
• ACLs 🧱
• und einem modernen Sicherheitsfeature von Git 🛡️

Genau solche Probleme zeigen aber, warum lokale Linux-Entwicklung trotz aller Komplexität langfristig oft transparenter ist als versteckte Docker- oder WSL-Setups.

Und ganz nebenbei habe ich jetzt:

• einen funktionierenden Git-Branch-Indikator 🚀
• bessere Kenntnisse über Git-Sicherheit 🧠
• und ein deutlich besser dokumentiertes lokales WordPress-Setup 🧩