JHewess said:

Ok, so with the two lines left commented out and the new code added, everything continues to work. With the new code and the two lines uncommented, the 500 error returns.

Click to expand...

    public function handleScriptLoaderTag($tag, $handle, $src)
    {
        try {
            if (is_string($src) && strlen($src) > 3)
            {
                $this->preload['<' . sanitize_url($src) . '>;as=script;rel=preload'] = true;
            }
        }
        catch(\Exception $e){
            wp_die($e->getMessage());
        }
        return $tag;
    }

    public function handleStyleLoaderTag($tag, $handle, $href)
    {
        try {
            if (is_string($href) && strlen($href) > 3 && strpos($href, '/ie.css') === false)
            {
                $this->preload['<' . sanitize_url($href) . '>;as=style;rel=preload'] = true;
            }
        }
        catch(\Exception $e){
            wp_die($e->getMessage());
        }
        return $tag;
    }

grafwebcuso said:

Will there be an update that does not throw the error? I am running PHP 8.3

Click to expand...

digitalpoint said:

Anything if the guts of the methods are wrapped in try/catch?

PHP:

    public function handleScriptLoaderTag($tag, $handle, $src)
    {
        try {
            if (is_string($src) && strlen($src) > 3)
            {
                $this->preload['<' . sanitize_url($src) . '>;as=script;rel=preload'] = true;
            }
        }
        catch(\Exception $e){
            wp_die($e->getMessage());
        }
        return $tag;
    }

    public function handleStyleLoaderTag($tag, $handle, $href)
    {
        try {
            if (is_string($href) && strlen($href) > 3 && strpos($href, '/ie.css') === false)
            {
                $this->preload['<' . sanitize_url($href) . '>;as=style;rel=preload'] = true;
            }
        }
        catch(\Exception $e){
            wp_die($e->getMessage());
        }
        return $tag;
    }

Click to expand...

JHewess said:

Unfortunately not no. I can only get it working if I leave those two original lines commented out.

Click to expand...

digitalpoint said:

What happens if you comment just this line (none of the other ones)?

PHP:

// add_action('wp_print_footer_scripts', [$this, 'handlePrintFooterScripts'], 9999999);

Click to expand...

digitalpoint said:

Do you have an example URL of your site (even if the plugin is disabled currently)? One possibility might be that your web server has a limitation on the size of the HTTP response headers (normally there's a limitation on the request headers, but not response headers). If that's the case, then the issue would be upstream of WordPress/PHP stack, so PHP isn't going to throw an error (would be coming from web server itself). Seeing combination of plugins causing the issue, but not individual ones may be something along the lines of different plugins are adding HTTP response headers, but it's only when the total size of all the response headers gets larger than a certain amount, the web server decides it's not doing it.

...although that wouldn't explain it happening even with the preload resources option disabled (headers are only added when it's enabled). So maybe that whole thought is irrelevant.

Still would be interested in the URL if possible... curious if there's an insane amount of individual JavaScript and CSS files that might be too many to realistically preload.

Click to expand...

JHewess said:

staging.thecuriouscreative.co.uk

everything except for Flyingpress is loaded currently, so no doubt you'll have a field-day!

Click to expand...

header('Link: ' . implode(',', array_keys($this->preload)), false);

header('Link: ' . implode(',', array_slice(array_keys($this->preload), 0, 10)), false);

JHewess said:

ok, I've amended that line of code.

Click to expand...

JHewess said:

Thank you so much for your help and prompt responses with this, much appreciated. The new update has been installed and all appears to be working. 😎

Click to expand...