Autoloader causes white pages when interfaces are not imported or not all methods are implemented

1st Official Post
    Affected App
    WoltLab Suite Core

    This topic made me aware of it and I started looking for the cause:

    The autoloader of the Suite Core suppresses any error caused by missing classes or interfaces that are not correctly imported or implemented.

    Traceability:

    • Use an interface in a class without importing it via use
    • Use an interface in a class with importing it via use but do not add all methods required by the interface

    With the currently used @include_once(…) you'll receive a white page. With include_once(…) (notice the missing @-supressment) you'll get the correct error message displayed. But simply removing the @-supressment seems to be not the solution as some other errors occurs1.

    Quote

    Fatal error: Class kpps\page\ShopPage contains 2 abstract methods and must therefore be declared abstract or implement the remaining methods (kpps\page\ITest::setFoo, kpps\page\ITest::getBar) in D:\xampp\htdocs\products52\shop\lib\page\ShopPage.class.php on line 20

    1:

    • Official Post

    Hello,

    Removing the @ is not an option, we're relying on the side effect of include*() that implicitly checks for the existence of the requested file. Running an explicit check via file_exists() or is_readable() is quite expensive at this point, because PHP tends to skip the statcache under certain circumstances. This has a significant performance penalty for sites running on cheaper webhosting offers that still make use of "spinning rust" (HDD).

    The original issue can be easily avoided by using a proper IDE with static code analysis (for example, Visual Studio Code would do) that will report these kind of issues ahead of time.

    We're not going to make any changes at this time, because the drawbacks of such a change are too severe with little to no benefit on average. Furthermore, this is not a bug, because the code does exactly what is was purposely instructed to do.

    Ich wechsle hier nun mal auf Deutsch um ein paar weitere Informationen zu bekommen.

    Wie kann ich als Nutzer eines Shared Hostings nun sicherstellen dass die Fehler geprintet oder zumindest irgendwo geloggt werden? Oder was kann der Webhoster evtl. veranlassen? Ich hab nun weitere Use-Cases innerhalb meiner Suite gefunden bei welchen einfach nur eine leere Seite erscheint, aufgrund der nicht bekannten Fehlermeldung kann mir weder der Hoster noch ein Plug-In Entwickler weiterhelfen!

    Wenn es mal dazu kommen sollte, das ich bei einem Kunden eine weiße, unerklärliche Seite habe und ich die Vermutung habe, das die Unterdrückung des Autoloaders mir etwas verschweigt, kann ich die Unterdrückung der Fehlerausgabe temporär aufheben.

    Als Plugin-Entwickler entwickelt man, wie Alexander schrieb, im Normalfall (lokal und) mit einer IDE, die einem diese Fehler bereits während der Entwicklung visuell anzeigt. Daher kann ich mit „Wird nicht behoben” und der Erklärung von Alexander voll und ganz leben. Die Kommentare im Quellcode haben mich das zwar schon erahnen lassen, aber ich wollte sicher sein, da diese Änderung erst in der neusten Suite 5.2 Einzug erhalten hat und die Unterdrückung davor nicht stattgefunden hat.

    Quote from Alexander Ebert

    Hello,

    Removing the @ is not an option, we're relying on the side effect of include*() that implicitly checks for the existence of the requested file. Running an explicit check via file_exists() or is_readable() is quite expensive at this point, because PHP tends to skip the statcache under certain circumstances. This has a significant performance penalty for sites running on cheaper webhosting offers that still make use of "spinning rust" (HDD).

    What about disabling the suppression in developer mode, e.g.

    Code
    if (defined('ENABLE_DEBUG_MODE') && ENABLE_DEBUG_MODE) {
    include_once($classPath);
}
else {
    @include_once($classPath);
}

    However, i don't understand the problem at all. Where's the drawback, if you just remove the @ sign and stop suppressing any errors? There's no need to check if a particular file exists and if it can be included or not (and this hasn't been asked). On a cheaper webhosting offer, it doesn't make any difference in performance, if you suppress every error nor don't suppress any. If an error occurs, it should be displayed or even logged somewhere.

    Or am i missing something?

    Quote

    The original issue can be easily avoided by using a proper IDE with static code analysis (for example, Visual Studio Code would do) that will report these kind of issues ahead of time.

    Well, you can't ask a regular website admin to install an IDE and perform a static code analysis.

    • Official Post
    Quote from SoftCreatR

    However, i don't understand the problem at all. Where's the drawback, if you just remove the @ sign and stop suppressing any errors?

    Try requesting a controller that is a form or try to use {$foo|trim}. We (and quite a few plugins) do use negative lookups to dynamically determine code paths.

    I will look into a potential code branch when running in the developer mode for 5.3.

Participate now!

Don’t have an account yet? Register yourself now and be a part of our community!

Register Yourself Login