grafwebcuso
New member
We just did the update and we had to disable the plugin because it keeps throwing a 500 server error!!!!!!!!!!
- Item seller digitalpoint
- Featured
New Update gave 500 server error
- Thread starter grafwebcuso
- Start date
What version of PHP are you using? Do you happen to have access to error log so you could see exactly what the error is?
There really isn't a whole lot that changed with the update.
There really isn't a whole lot that changed with the update.
We've also experienced this issue. We initially thought it was contained to Woocommerce pages as the 500 error originally only appears when attempting to login via the /my-account URL, however after disabling caching (Flyingpress), it occurred site-wide.
PHP version: 8.3.22
No logs as yet as we've had to revert to the previous version of the plugin.
PHP version: 8.3.22
No logs as yet as we've had to revert to the previous version of the plugin.
Still haven't been able to replicate this on our end no matter the setup/config I try. I did find some old references to stacking ob_start() being problematic when a PHP is using an internal output handler that doesn't support stacking. Not sure if this is what's going on since I haven't been able to replicate it yet, but it's a lead to try and test.
If someone is able to check if their phpinfo has an
If someone is able to check if their phpinfo has an
output_handler set, that could be useful to know what it's set to.
One thought that just came to mind (and maybe why I'm unable to replicate it). It could be that some servers have certain PHP functions/classes explicitly disabled (ones that are being used). Any chance you could check to see if your phpinfo shows anything for
disable_functions or disable_classes?
Okay, so not that... 🤔
Not sure how willing you are to test things, but unfortunately I'm not able to since I can't come up with a PHP/web server combo that causes any issues. But if you are...
If you make a new file on your server with this (can name it test.php or anything really):
PHP:
<?php
echo inet_ntop(inet_pton('103.21.244.0')) . '; '; // IPv4
echo inet_ntop(inet_pton('2a06:98c0::')) . '; '; // IPv6
echo inet_ntop(inet_pton('1.2.3.300')) . '; '; // Invalid IPRequest that file with a browser and you should see:
Code:
103.21.244.0; 2a06:98c0::; ;One (of the two) changes in the new version is it simplified the code for replacing Cloudflare's IP with the user's actual IP... so if a server is barfing when using
inet_ntop or inet_pton (standard PHP functions), it will be a problem.
Ok... so not that.
Did you enable the new option (preload resources)?
With that enabled, it does trigger an ob_start() call so any output is buffered (allows us to add the necessary preload header after WordPress generates it's content).
So maybe something going on with ob_start(), but that shouldn't be called unless the new option is enabled.
Augh... sorry for all the testing (feel free to not do anything). I really wish I was able to replicate it somehow.
In the
...does that help?
Maybe it has something to do with WordPress not being able to initialize a PHP class at that point for some reason.
In the
wp-content/plugins/app-for-cf/src/DigitalPoint/Cloudflare/Base/Pub.php file, if you just remove these lines (around line #20):
PHP:
$cloudflareRepo = new \DigitalPoint\Cloudflare\Repository\Cloudflare();
if ($cloudflareRepo->option('cloudflarePreload'))
{
ob_start();
}...does that help?
Maybe it has something to do with WordPress not being able to initialize a PHP class at that point for some reason.
May be as easy as adding this to your config.php file once it's ready:
developer.wordpress.org
Did I mention how much I hate that I can't replicate it? 😂
PHP:
define('WP_DEBUG', true);Debugging in WordPress – Advanced Administration Handbook | Developer.WordPress.org
Debugging PHP code is part of any project, but WordPress comes with specific debugging systems designed to simplify the process as well as…
Did I mention how much I hate that I can't replicate it? 😂
I've been digging and trying to think of various "what if" situations. One possibility I've come up with (and would cause an issue regardless if the new option was enabled or not) would be an invalid script or CSS URL came through WordPress's filter mechanism. It's *supposed* to be a string, but if something (like a third-party plugin) turned it into something that isn't a string (a null value or an array or something like that), I could see an error happening when it tries to use that as it's supposed to be (a string).
Even if that doesn't end up being the case here, I've added a check to make sure that what is supposed to be a string actually *is* a string (it never hurts to add sanity checks when third-party plugins have the potential to return something unexpected).
You could test that one by just commenting out these two lines (around line #95 in the same Pub.php referenced here):
Even if that doesn't end up being the case here, I've added a check to make sure that what is supposed to be a string actually *is* a string (it never hurts to add sanity checks when third-party plugins have the potential to return something unexpected).
You could test that one by just commenting out these two lines (around line #95 in the same Pub.php referenced here):
PHP:
// add_filter('script_loader_tag', [$this, 'handleScriptLoaderTag'], 9999999, 3);
// add_filter('style_loader_tag', [$this, 'handleStyleLoaderTag'], 9999999, 3);Okay... one last test (hopefully).
If you uncomment those two lines, and also replace the
handleScriptLoaderTag and handleStyleLoaderTag methods farther down that file (approx line #223) with this:
PHP:
public function handleScriptLoaderTag($tag, $handle, $src)
{
if (is_string($src) && strlen($src) > 3)
{
$this->preload['<' . sanitize_url($src) . '>;as=script;rel=preload'] = true;
}
return $tag;
}
public function handleStyleLoaderTag($tag, $handle, $href)
{
if (is_string($href) && strlen($href) > 3 && strpos($href, '/ie.css') === false)
{
$this->preload['<' . sanitize_url($href) . '>;as=style;rel=preload'] = true;
}
return $tag;
}...does that work?
That's the new code I added to handle the "what if" situation where a third-party plugin might be mucking a URL that's supposed to be a string. It doesn't answer the question about what may be transforming the URLs into something unusable, but it at least ignores them in that case.
Similar threads
