Es galt WordPress zu erkunden. Mein Logo habe ich als URL fest in dem abgeleiteten Template herein gebaut. Damit das Template wirklich ein Template ist, sollte das besser gehen können. Deswegen wollte ich erst einmal herausfinden, wie wordpress und php überhaupt funktioniert.
Bei normalen Programmiersprachen gehe ich dazu in einen Debugger. Der zeigt mir dann, wie die Sachen zusammengebaut werden. Zu meiner Enttäuschung war bei one.com kein php debugger installiert. Auf Anfrage wurde mir gesagt, ich könne ja die Fehlermeldungen einschalten.
Im Internet fand ich den Verweis auf XDebug, der Debug Erweiterung für Php. Der Plan war einfach:
- wordpress lokal installieren
- Xdebug installieren
- In WordPress einsteigen und das Template erweitern.
Das las sich einfach. War es aber nicht.
WordPress zu installieren, gelang mir ohne Problem. Ich lernte, dass die 1-click WordPress Installation von one.com kein besonderer Service war. Das scheint ein Standard zu sein. Ich lud das tar.gz herunter und kopierte den Inhalt in meinem localhost.
XDebug auf eine MacOs installieren, las sich einfach:
- homebrew installieren
- dann aber doch pecl verwenden
Homebrew wollte ich sowieso schon immer installieren. Es kamen dabei Kommondos für Xcode compiler mit. Pecl fand ich unter homebrew gar nicht. Warum war das eigentlich dabei?
Pecl kam von php und wurde mit dem pear Paket installiert. Das geht über
$ wget http://pear.php.net/go-pear.phar
$ php go-pear.phar
Das wget kam über homebrew. Das php go-pear.phar meldete „autoconf“ fehlte. Mit „brew install autoconf“ behob ich das.
„sudo pecl install xdebug“ lud herunter, startete einen makefile und übersetzte munter. Ich wunderte mich, wie schnell das alles läuft. Dann kam eine unerwartete Fehlermeldung:
failed to open stream: Operation not permittedDabei war ich doch Superuser! Ich habe alle Rechte. Mit „High Sierra“ gibt es einen neuen Schutzmechanismus. Auch Superuser können nicht mehr nach /usr/lib etwas schreiben. Was sollte ich weiter tun?
Bei Stackoverflow fand ich einen Artikel, der das Problem für oauth löste. Ich lernte den „recovery mode“ von MacOS kennen.
Nun stand dem fröhlichem Debuggen und Patchen von Templates nichts mehr entgegen, oder?
In der php.ini trug ich die zend_extension ein. Ein php -i zeigte die korrekten Werte ein. Ich browste nach „localhost/software/?XDEBUG_TRACE“ und machte mich auf die Suche nach einem Tracefile.
Unter /var/tmp gab es Dateien, aber keinen trace…..xt. Ich kopierte von verschiedenen Webseiten die perfekten php.ini Einträge. Den Apachen zu restarten vergaß ich nicht!
Der Tracefile kam nicht!
Was war passiert?
Ich die php Einstellungen meines Apachen. Hatte ich mich über php -i gefreut, so zeigte die schnell geschriebene phpinfo() Seite des Apachen einen ganz anderen Pfad für die php.ini Datei an.
/usr/local/php5/lib/php.ini
Das war es also!
Schnell dort die Einträge nachgezogen und dann sollte es losgehen können.
Die Tracefiles kamen immer noch nicht.
In der Errorlog des Apachen fand ich die Einträge:
Xdebug requires Zend Engine API version 320160303.
The Zend Engine API version 320170718 which is installed, is newer.
Contact Derick Rethans at http://xdebug.org/docs/faq#api for a later version of Xdebug.
Was war da passiert? Was hatte ich überhaupt für eine php und apache Installation? Wie sollte ich weitermachen?
Ich hatte zwei php Installationen. Unter /usr/bin/php war 7.1.16 installiert. Das pear/pecl habe ich auf diese Version nachinstalliert und dort auch Xdebug eingeschaltet.
Mein Apache verwendet /usr/local/php5/bin/php mit der Versionsnummer 7.2.0. Wer php7 in einen Phad mit php5 gelegt hat, kann ich nicht sagen. Vermutlich gab es irgendein Update.
Problem war nun gefunden. Wie bekomme ich dort Xdebug hinein? Muss ich wieder in den recovery mode und Sicherheitsmechanismen aus- und wieder einschalten?
Ich schaute mir das /usr/local/php5/bin genauer an. Dort war auch pear und pecl installiert. Was würde passieren, wenn ich in diesem Verzeichnis ein „sudo pecl install xdebug“ ausführe?
Es lief ohne Probleme durch. Die phpinfo() Seite zeigte XDebug an und die Tracedateien wurden erzeugt.
Kann ich nun WordPress Templates erweitern und patchen?
Eine Seite von meinem Blog erzeugt 40000 Zeilen Text. WordPress ist dann doch eine Welt für sich. Die Stelle mit dem the_custom_logo liest sich so:
0.7446 20716104 -> the_custom_logo() /Users/thomas/gawehns_de/software/wp-content/themes/bhari-child/header.php:36
0.7446 20716104 -> get_custom_logo() /Users/thomas/gawehns_de/software/wp-includes/general-template.php:934
0.7446 20716104 -> is_multisite() /Users/thomas/gawehns_de/software/wp-includes/general-template.php:870
0.7446 20716104 -> get_theme_mod() /Users/thomas/gawehns_de/software/wp-includes/general-template.php:875
0.7446 20716104 -> get_theme_mods() /Users/thomas/gawehns_de/software/wp-includes/theme.php:855
0.7446 20716104 -> get_option() /Users/thomas/gawehns_de/software/wp-includes/theme.php:825
0.7446 20716104 -> trim() /Users/thomas/gawehns_de/software/wp-includes/option.php:33
0.7446 20716152 -> apply_filters() /Users/thomas/gawehns_de/software/wp-includes/option.php:58
0.7446 20716104 -> wp_installing() /Users/thomas/gawehns_de/software/wp-includes/option.php:69
0.7446 20716104 -> wp_cache_get() /Users/thomas/gawehns_de/software/wp-includes/option.php:71
0.7447 20716128 -> WP_Object_Cache->get() /Users/thomas/gawehns_de/software/wp-includes/cache.php:123
0.7447 20716128 -> WP_Object_Cache->_exists() /Users/thomas/gawehns_de/software/wp-includes/cache.php:530
0.7447 20716104 -> wp_load_alloptions() /Users/thomas/gawehns_de/software/wp-includes/option.php:90
0.7447 20716104 -> wp_installing() /Users/thomas/gawehns_de/software/wp-includes/option.php:189
0.7447 20716104 -> wp_cache_get() /Users/thomas/gawehns_de/software/wp-includes/option.php:190
0.7447 20716128 -> WP_Object_Cache->get() /Users/thomas/gawehns_de/software/wp-includes/cache.php:123
0.7447 20716128 -> WP_Object_Cache->_exists() /Users/thomas/gawehns_de/software/wp-includes/cache.php:530
0.7447 20716104 -> apply_filters() /Users/thomas/gawehns_de/software/wp-includes/option.php:227
0.7447 20716152 -> maybe_unserialize() /Users/thomas/gawehns_de/software/wp-includes/option.php:148
0.7447 20716152 -> is_serialized() /Users/thomas/gawehns_de/software/wp-includes/functions.php:329
0.7448 20716152 -> trim() /Users/thomas/gawehns_de/software/wp-includes/functions.php:351
0.7448 20716152 -> apply_filters() /Users/thomas/gawehns_de/software/wp-includes/option.php:148
So fand ich den Zugang zu einem wundervollen Universum von unendlich vielen interessanten php Dateien, die studiert werden wollen, bevor geändert werden kann.
Oder sollte ich mich eher in WordPress Foren tummeln?