500 error?

[JohnRDOrazio]

When enabling the plugin on the website of a certain Italian diocese, a 500 error was triggered.

I really have no idea why this is, but it sure needs looking into. I mean, how many other people may have gotten a similar error, but without giving feedback I have no idea how or why. I can't reproduce on my end. But it may very well have to do with them using an old version of PHP on the server.

I've asked them to look at the server logs to see what the error is. Until they give me feedback from the server logs, there isn't a whole lot we can do about it... I have even removed PHP 5.4 completely from my own remote server, I figured most people would have updated a while ago. In theory the plugin should work on PHP 5.4, but since I haven't been using or testing on PHP 5.4 lately who knows, maybe there is some incompatibility?

[JohnRDOrazio]

I have been able to trigger an error when running WordPress on a Windows machine, and when trying to activate a Google Fonts key.

One problem seems to have been the way paths are interpreted on Windows. The WordPress constants were not working at all (I'm guessing because the backslashes needed to be escaped but weren't). In the end I went for using just plugin_dir_path(__FILE__), substituting all backslashes with forward slashes ( $plugin_path = str_replace('\\','/', plugin_dir_path( __FILE__ ) ); ) and followed by the path relative to the current executing / included script. This seems to have taken care of PHP scripts getting loaded properly.

I also some problems communicating with the Google Fonts API from a localhost instance, because of the way the cURL request was being put together. I had to take care of this by conditionally sending IP information based on whether the script is running on a local address or not, so I had to create a method that would check whether the current server address is local:

    private static function isLocalIp( $ip ) {
        $isLocal = false;
        if(filter_var($ip, FILTER_VALIDATE_IP, FILTER_FLAG_IPV4)) {
            $ipNum = ip2long($ip);
            if(
                ($ipNum >= 167772160    && $ipNum <= 184549375)     //10.0.0.0 – 10.255.255.255
                ||
                ($ipNum >= 2886729728   && $ipNum <= 2887778303)    //172.16.0.0 – 172.31.255.255
                ||
                ($ipNum >= 3232235520   && $ipNum <= 3232301055)    //192.168.0.0 – 192.168.255.255
            ) {
                $isLocal = true;
            }
        } else if(filter_var($ip, FILTER_VALIDATE_IP, FILTER_FLAG_IPV6)) {
            if( $ip === "::1" ) {
                $isLocal = true;
            }
        }
        return $isLocal;
    }

If it's not local, then I send it along with the request so that the Google Fonts API knows exactly who is sending the request:

if( false === self::isLocalIp( $_SERVER['SERVER_ADDR'] ) ) {
    curl_setopt($ch, CURLOPT_INTERFACE, $_SERVER['SERVER_ADDR']);
}

This is mostly useful when the API key is restricted to certain IP addresses. If you're using a localhost instance, you want a key without IP address restrictions (and probably even without domain restrictions). If localhost is used for testing, it's probably a key you'll only create temporarily anyways. Make sure you deactivate or delete or restrict the key in the Google Fonts API after you're done testing locally.

[JohnRDOrazio]

I also moved the Minify script to a composer installation, instead of manually loading the script. This way I don't even have to keep the minify script in my Github repository (I don't want my code linting to be influenced by external code anyways). Only thing to look into now is to make sure that a composer install is run by a Github action before checking the code into the SVN repository. We want to be sure that the SVN repository has all the necessary artifacts for the plugin to run correctly.

[JohnRDOrazio]

I got a little more information from the server logs of the nearby diocese.

On March 17th, after installing the plugin in a test WordPress instance that they put up, the webmaster sent me a portion of the server logs (probably cutting out quite a bit of information that might have been useful). There was just one message that gave a little bit of a hint:

Failed to release SSL session cache lock

From a quick check on online forums I was able to gather this information:

https://serverfault.com/questions/856561/how-to-solve-apache-2-4-ah02026-failed-to-acquire-ssl-session-cache-lock

https://electrictoolbox.com/failed-to-acquire-ssl-session-cache-lock/

https://stackoverflow.com/questions/70068708/ah02026-failed-to-acquire-ssl-session-cache-lock

Non of this has anything to do with the plugin, it has everything to do with the server setup...