Artikelformat

“Obligatorische” WordPress-PlugIns

Gleich vorweg: Nein, das ist keine Liste von WordPress PlugIns die ich für zwingend notwendig halte :-)

In diesem Artikel möchte ich ein kleines WordPress-Feature vorstellen das so gut wie unbekannt ist. Nehmen wir mal folgendes (relativ übliches) Szenario: man entwickelt für einen Kunden eine Seite auf WordPress-Basis und möchte bestimmte Tweaks einbauen (z.B. um die überflüssigen Sprachen aus der Rechtschreibprüfung zu entfernen, den Admin-Bar zu verstecken, usw.). Man kann diese Funktionen natürlich alle in die functions.php des Themes packen (wo sie meiner Meinung nach nicht unbedingt hingehören) oder man erstellt sich ein entsprechendes PlugIn. Problematisch wird das in dem Augenblick, wo der Kunde Administrator-Zugang hat. Schnell ist da mal ein PlugIn deaktiviert. Da hilft auch ein beherztes "FINGER WEG!" als PlugIn-Beschreibung nicht.

Aber wie das bei WordPress oft so ist, gibt es für diesen Fall eine eingebaute Lösung. Diese nennt sich "obligatorische" PlugIns (oder im englischen: "Must-Use") und werden hier im WordPress-Codex genauer beschrieben. Legt man im wp-content-Ordner ein Verzeichnis mu-plugins an und kopiert sein PlugIn dort hinein, erscheint in der PlugIn-Übersicht ein neuer Auswahlpunkt "Obligatorisch" unter dem man zukünftig sein PlugIn wiederfindet.

PlugIns in diesem Verzeichnis verhalten sich allerdings ein wenig anders als von normalen PlugIns gewohnt und unterliegen bestimmten Beschränkungen / Regeln:

  • PlugIns in Unterordnern werden nicht geladen
  • alle PlugIns in diesem Verzeichnis sind automatisch aktiviert und können nicht deaktiviert oder gelöscht werden
  • über den eingebauten Editor können keine Veränderungen an den Dateien vorgenommen werden
  • es werden keine (automatischen) Updates eingespielt

Muss man also ein solches PlugIn aus irgendeinem Grund aktualisieren oder löschen, geht das nur über einen direkten Zugriff auf Verzeichnisebene (FTP, Shell, etc.) – meiner persönlichen Meinung nach sollte man sich dort also auf gut getesteten Code beschränken. Nützlich ist dieses Feature aber auf jeden Fall (finde ich zumindest).

Autor: Christian

Baujahr 1976, Software-Entwickler und Web-Designer aus Leidenschaft, Erfahrung in gefühlten 9342049 Programmiersprachen (PHP, Perl, C#, VB.Net, VB6, Delphi um nur einige zu nennen), in der Vergangenheit an diversen Open Source Projekten beteiligt (allen voran das gute alte YaBB und YaBB SE)

Kommentare sind geschlossen.