… bauen gerne mal Konstrukte der folgenden Art:
$path = ltrim( end( @explode( get_template(), str_replace( '\\', '/', dirname( __FILE__ ) ) ) ), '/' );
Sortiert sieht es dann so aus:
$path = ltrim( end( @explode( get_template(), str_replace('\\', '/', dirname(__FILE__)) ) ), '/' );
Zum Kontext: diese Zeile stammt aus einem kommerziellen WordPress-Template und es soll der letzte Teil des Pfadnamens des aktuell ausgeführten Skripts bestimmt werden. Aus /var/www/wordpress/wp-content/themes/valenti/option-tree
soll also option-tree
werden.
Von innen nach außen:
dirname(__FILE__)
liefert den Pfadanteil des aktuell ausgeführten PHP-Skriptes; aus/var/www/wordpress/wp-content/themes/valenti/option-tree/ot-loader.php
wird also/var/www/wordpress/wp-content/themes/valenti/option-tree
str_replace('\\', '/', …)
ersetzt den Backslash (vermutlich als Workaround für Windows-Systeme) mit einem Slash, der Pfad bleibt auf einem unixoiden System also erstmal unverändert (es sei denn, er enthält tatsächlich den Backslash)get_template()
liefert den Namen des aktiven WordPress-Templates, in diesem Fallvalenti
explode()
trennt den Pfadnamen in einzelne Teile, und zwar an jeder Stelle an der der Stringvalenti
vorkommt; man erhält also dieses Array:[0 => '/var/www/wordpress/wp-content/themes/', 1 => '/option-tree']
end()
liefert den Wert des letzten Elements des Arrays:/option-tree
ltrim(…, '/')
entfernt zum Schluss den Slash am Anfang des Strings, so dass wir das Ergebnis erhalten:option-tree
Diese Variante hat unter Umständen einige Probleme, Backslashes im Pfadnamen könnten eines davon sein. Unterdrückte Fehlermeldungen mit dem @
-Operator könnte zu weiteren Hässlichkeiten beim Debugging führen.
Aber das Hauptproblem ist, dass der Entwickler oder die Entwicklerin hier eine komplexe Lösung für ein einfaches Problem geschaffen hat. PHP löst die gegebene Fragestellung nämlich mit Bordmitteln viel eleganter und zudem fehlerunanfällig und OS-unabhängig:
$path = basename(DIR);
Keine Ursache.