Ich bin ja auch Nutzer von InfiniteWP. Das ist eigentlich ein sehr gutes Tool zum Verwalten von mehreren WordPress-Instanzen.
Nun hatte ich in einem Kundenprojekt eine API entwickelt, die zur Authentifizierung ein WordPress mit einer Nutzerdatenbank verwendet. Dazu habe ich von einem externen Projekt die wp-load.php inkludiert. Das funktionierte auch eine zeitlang auch sehr gut, bis die Agentur, die die Seite betreut, ein paar Änderungen vornahm. Sie installierten unter anderem InfiniteWP. In der datei “api.php” von InfiniteWP ist folgender Code:
if(basename($_SERVER['SCRIPT_FILENAME']) == "api.php"):
exit;
endif;
Das Ziel dieses Codes ist relativ offensichtlich: Die Datei sollte nicht direkt geladen werden können. Blöd ist: Es wird nur auf den Dateinamen geprüft. Da meine externe Datei, auch api.php heisst, wird aber, sobald ich die wp-load.php include, das exit; ausgeführt.
Ich regte also an, vielleicht nicht nur den Filename zu überprüfen, sondern vielleicht auch den Pfad des aufgerufenen Scripts oder – wie unter WP auch nicht unüblich – auf eine gesetzte Konstante. Auf meine Anfrage beim Support bekam ich folgende Antwort:
Thanks for taking the time to reach out to us on your query. Your patience is greatly appreciated.
We are using api.php in our client plugin to use call back functions for our addons.
To fix this issue you can simply rename your file to api2.php
Are you experiencing any conflict issues with IWP client plugin and other plugins?
Please give us more information so that I can assist you accordingly.
Ich habe dann etwas möglicherweise etwas unhöflich reagiert und gefragt, wie sich das verhält, wenn der nächste dann das gleiche mit proxy.php und jemand anderes dann die index.php seines Plugins so schützt. Und dass ein HTTP Status 200 und eine weiße Seite in dem Fall auch nicht sinnvoll debugbar sind und dass mich das einige Tage Projektverzögerung gekostet hat und ziemlich beschissen ist. Zumal es in WordPress ja auch Beispiele gibt, wie es besser geht.
Erst darauf hin habe ich die Antwort bekommen, dass ein “scope of improvement on our end” vorhanden sei. Da geben sich dann Codequalität und Servicequalität dann echt nichts.
Ich habe mal ein Beispiel geschickt, wie man das sinnvoller lösen kann. Mal sehen, wann ein Update dafür kommt.
