WordPress Admin Bar nicht sichtbar [WordPress 4.3] [Benutzerrollen] [WooCommerce]


Neulich hatte ich folgendes Phänomen: Für Benutzer mit der Rolle „Redaktuer (engl. Editor)“ wurde die Admin-Bar nicht angezeigt. Natürlich war in dem betreffenden Profil der Haken gesetzt, sodass die Admin Bar hätte sichtbar sein sollen. Die Suche ist theoretisch einfach: Deaktiviere alle Plugin und wechsle auf das Standard-Theme, dann schau ob es klappt. Wenn es klappt, einfach nach und nach alle Plugins wieder aktivieren und schauen, welches Plugin dafür sorgt, dass die WordPress Admin Bar verschwindet. Darauf hatte ich keine Lust!

Das Projekt ist ein gerade entstehender Online-Shop. Es ist ein gekauftes Theme im Einsatz, welches optimal für WooCommerce vorbereitet ist. Folgende Plugins sind aktiv:

  • Admin Menu Editor Pro
  • Antispam Bee
  • Benutzerwechsel (engl. User Switching)
  • Contact Form 7
  • Disable All WordPress Updates
  • Envato WordPress Toolkit
  • Imsanity
  • Manual Image Crop
  • Passwortgeschützt (engl. Password Protected)
  • Responsive Lightbox
  • Revolution Slider
  • Simple Custom CSS
  • User Role Editor
  • WooCommerce
  • WooCommerce Header Category Image
  • Wordfence Security
  • WP Sanitize file name Plus
  • WPBakery Visual Composer
  • YITH WooCommerce Wishlist

Dabei kann ich mir vorstellen, dass in dieses Problem nur wenige dieser Plugins reinspielen könnten. Da ich aber nicht viel Zeit hatte und erstmal mehr ein Workaround her sollte, als eine super Zukunftssichere Lösung, habe ich folgendes Unternommen: Ich habe ans Ende der functions.php folgende Zeile Quellcode angefügt:

Die Änderung ist absolut unkritisch. Und schon klappt es. Natürlich nur bis zum nächsten Update des Theme. Aber das ist erstmal eine schnelle Lösung. Und zeigt mir, dass hier definitiv noch ein anderes Plugin zu Gange ist, welches über eben den selben Filter irgendwann versucht, die Admin-Bar abzuschalten (Vermutung).

GitLab – Von 7.14.3 „from source“ und MySQL nach 8.0.5 als Docker-Container mit PostgreSQL

bitconnect

Heute gehen wir zusammen mal durch, was ich alles unternommen habe um mein GitLab 7.14.3 auf ein GitLab 8.0.5 zu aktualisieren. Nebenbei habe ich MySQL verlassen und auf PostgreSQL migriert (empfohlen durch GitLab selbst). Zusätzlich läuft mein neuer GitLab dann in einer Docker-Umgebung. Aber erstmal von Anfang an.

GitLab – Ich liebe Quellcodes

Als Entwickler arbeite ich mit Quellcodes. Und das mache ich sehr sorgfältig. Ich kenne derzeit keinen Web-Entwickler der so vorgeht wie ich #selbstlobstinkt 😉

Und ein wichtiger Teil meiner Strategie ist GitLab und GitLab CI. Was genau diese beiden Tools sind, werde ich in einem anderen Artikel behandeln.

Backups – Nichts ist sicher

Wichtig ist den gesamten Prozess über immer ein Backup parat zu haben. Denn nichts ist sicher!

Aktuelle GitLab-Instanz aktualisieren

Da Backups nur in „passende“ GitLab-Systeme integriert werden können, hat man zwei Möglichkeiten:

  1. Erst auf GitLab 7.14.3 in einem Docker-Container umsteigen und dann diesen aktualisieren
  2. Erst auf GitLab 8.0.5 aktualisieren und dann auf den Docker-Container umsteigen

Da ich keinen funktionierenden Docker-Container für GitLab 7.14.3 gefunden habe, habe ich Variante 2 genommen. Dazu gibt es eine Update-Anleitung, diese hat bei mir funktioniert. Was danach nicht mehr ging waren Push oder Pull-Anfragen. Das habe ich aber ignoriert. Ich war schließlich eh dabei, diese GitLab-Instanz zu löschen.

Ich habe also nochmal ein Backup durchgeführt, jetzt nämlich für GitLab 8.0.5.

Auf PostgreSQL migrieren

In den GitLab-Backups ist ein Dump-File der Datenbank hinterlegt. Also in unserem Fall aktuell ein MySQL-Export. Dieser muss migriert werden.

Es gibt dafür ein Tool, welches MySQL-Dumps nach PostgreSQL migriert, das wusste ich bereits. Allerdings hat es nicht geklappt als ich es händisch gemacht habe. Praktischerweise hat GitLab selbst dieses Tool weiter modifiziert sodass es derzeit gut möglich ist, die Migration durchzuführen. Hier lest ihr wie ein GitLab Backup mit MySQL zu einem GitLab Backup mit PostgreSQL migriert wird.

GitLab Docker-Instanzen starten

Ich habe nicht das offizielle GitLab-Docker-Image genommen, sondern die Images von sameersbn. In dem Repository gibt es viele Images, hier kommt ihr zu den Docker GitLab Images.

Der Quick-Start dort ist sehr gut dokumentiert. Ich habe nur Step 3 Launch the GitLab Container angepasst:

Daten wiederherstellen

Nun bleibt nur noch das migrierte Backup in das Backup-Verzeichnis vom Docker-Container zu schieben (bei mir halt /srv/docker/gitlab/gitlab/backups/) und schon kann der Restore beginnen.

Ich bin dazu in die Shell des Docker-Container gewechselt, das geht über

Und dort habe ich gitlab dann angewisen das Backup wiederherzustellen

Das ‚ts‘ bei „BACKUP=ts“ müsst ihr durch den Timestamp ersetzten, der als Prefix im Backup-Dateinamen gesetzt wurde.

GitLab 8.0.5 läuft jetzt im Docker-Container

Und schon haben wir es geschafft. Unser GitLab läuft jetzt in dem Docker-Container. Die Daten wurden vollständig migriert. Ich konnte mich einloggen.

Ein sau gutes Gefühl endlich ein vom restlichen System abgekapseltes GitLab zu haben welches sauber installiert ist. Keine großen Schwierigkeiten mehr. Echt der Hammer 🙂

WP API – Basic Auth geht nicht [PHP 5.5] [PHP FastCGI] [Odin Plesk Panel]

Genesis Mining

In einem meiner letzten Projekte, dem Relaunch der Seite mathehilfe24.de, sollte zum anbinden einer APP eine API eingebunden werden. Dazu setzten wir auf die WP API für JSON.

Nun musste der User authentifiziert werden, damit wir bestimmen konnten, ob nur die kostenfreien Abos zur Verfügung stehen oder der User ein Abo hat und somit alle Videos sehen kann.

Also für WP API noch schnell das Zusatz-Plugin WP JSON Basic Auth installiert.

WP API – Basic Auth geht nicht, trotz allem

Recht schnell stellte sich heraus: Das Plugin tat nicht ganz was es soll. Also zumindest klappte die Authentifizierung nicht.

Nach etwas Analyse fand ich heraus, dass aufgrund des eingesetzten FastCGI eine Erweiterung der .htaccess-Datei (welche über WP generiert wird) nötig war:

Nun klappte die Authentifizierung immer noch nicht. Ein kleines PHP Test-Script wiederung lief mit dieser Anpassung. Ich war verwirrt.

Debuggen zeigt: Plugin muss erweitert werden

Nach einem kurzen Debugging des WP JSON Basic Auth-Plugin wurde mir klar: Das Plugin muss erweitert werden, damit es mit PHP FastCGI funktioniert. Es müssen zwei Zeilen Quellcode hinzugefügt werden.

Lösung steht per Merge Request bereit

Ich habe natürlich das Plugin angepasst und die Erweiterung per Merge Request eingereicht, sodass das Plugin hoffentlich bald aktualisiert wird und die Anpassung für jedermann zu haben ist.

Hier seht ihr wie es geht: https://github.com/WP-API/Basic-Auth/pull/26/files

 

Windows – Große Textdatei auftrennen

bitconnect

Heute musste ich eine 1.8GB große „access-log“ Datei auf einem Windows-Gerät öffnen und einen gewissen Zeitraum daraus suchen um Webseiten-Zugriffe zu prüfen.

Notepad++ ist zumeißt das Tool meiner Wahl, wenn es um Text-Dateien geht. Doch bei 1.8 GB hat Notepad++ nur noch mitgeteilt, dass die Text-Datei schlicht zu groß ist.

Ich habe kurz gesucht und bin auf folgende Zeile gestoßen, die in der Powershell dazu führt, dass Text-Dateien beliebiger Größe in verschiedene Text-Dateien aufgeteilt wird. Dazu wird Zeilenweise vorgegangen.

Gefunden hab ich die Zeile hier: http://stackoverflow.com/questions/1001776/how-can-i-split-a-text-file-using-powershell

Angular JS vs. jQuery #1: Live-Anzeige

Genesis Mining

Der letzte Blog-Beitrag ist gechillte zwei Jahre her, wird also mal wieder Zeit für einen neuen Eintrag.

Heute geht es um einen ganz kleinen, aber praktischen Vergleich zwischen AngularJS und jQuery. Und zwar anhand einer ganz einfachen Eingabe-Maske. Die Daten die man eingibt, sollen direkt angezeigt werden.

jQuery: Eingabedaten live anzeigen

Folgenden Code habe ich benötigt, um die Live-Anzeige der Eingabedaten zu realisieren:

Natürlich kann man hier wesentlich bessere Optiken verwenden usw. Mir ging es allerdings nur um den technischen Vergleich.

AngularJS: Eingabedaten live anzeigen

Und nun zur AngularJS-Umsetzung. Hier habe ich folgenden Code umgesetzt:

Fazit: AngularJS vs. jQuery bei Live-Anzeige von Eingabedaten

Wie wir sehen, reduziert sich das benötigte JavaScript von 13- auf 5 Zeilen Quellcode. Im AngularJS-Code könnte ich sogar noch zwei Zeilen einsparen, ohne groß unleserlich zu werden. Auch die „Komplexität“ des Codes sinkt gewaltig.

Natürlich steigt bei AngularJS zugleich das Markup im HTML etwas an, das seht ihr selbst, das will ich auch nicht verheimlichen.

Ich hoffe mir fallen demnächst noch ein paar coole Vergleiche ein. Ich selbst setze aktuell sehr viel AngularJS ein, aber empfinde beide Frameworks als für Ihren Aufgabenbereich geeignet. Es ist die „Idee“, die beide unterscheidet. Aber darauf gehe ich demnächst (hoffentlich) näher ein.