Andrei Baicus

Hello,

First of all, I advise you change the secret key for the purge as you now shared it publicly here and anyone can purge the cache on your website. Secondly, you seem to have a malformed command, as bash tries to run various things mentioned in the URL.

This should do it:

curl "https://allstars.com.sg?swcfpc-purge-all=1&swcfpc-sec-key=FZztIvH6gwn0qqVJjFxk&swcfpc=1"

I hope this helps!

Hey @hobos,

We’ve released a new patch for this issue. Can you please update and confirm that it fixes the problem?

Thank you!

Hey @tmora,

We recommend switching off the worker as we’re looking to phase that feature out (it’s not fully free and we wouldn’t recommend it unless you have some very specific needs), and using what the plugin provides as base functionality. It now uses Cloudflare cache rules which provide a lot more control than what the plugin was previously using.

I hope this helps!

Hey @qantumthemes,

Those options appear now only when the respective plugins or providers are detected. The third party options tab doesn’t appear at all if none of the plugins are active, or the providers are not detected.

This was done to simplify the UI as a lot of the options there might never be needed for a lot of people and they were overwhelming the dashboard.

Hey @tmora,

It seems that your website is both behind Cloudflare and behind Super Page Cache’s static cache (as both are returning a HIT response header). For some reason the test page doesn’t have the proper headers, but everything seems to be working fine.

Hey @thomastolkien,

Does this still happen on the latest version? Could you provide more details regarding where this happens (on what page / are you on the frontend and clicking the top bar purge button / does it happen in the dashboard, etc).

Thank you!

Have a great rest of the week!

Hey @stoianalex,

That particular header means the Disk Page cache is disabled. Otherwise, from your screenshot, it seems that the Cloudflare cache is hit.

If you do have the Disk Page cache enabled, it would help if you could provide the website URL so we can further look into it.

All the best!

@prestonwordsworth thanks for reporting this. We’ll include the fix in our next release!

Have a great rest of the week!

@brandohui, I’m glad you managed to fix the issue!

I’m sorry for the inconvenience! Have a great rest of the week!

I would also appreciate if you could let me know what happens if you enable a WordPress default theme, like TwentyTwentyFour on the website, together with the Super Page Cache plugin. Is the 500 error still happening? If so, could you provide any errors that are logged to the wp-content/debug.log file, please?

Thank you!

@brandohui,

If you previously added the mentioned cosntants in the wp-config.php file, the error should be displayed in the wp-content/debug.log file. However, from the screenshot you provided, it seems that the wp-config.php file only has those definitions. Depending on the hosting service, the file might not be located at the usual place (in the WordPress installation folder).

If that’s the case, another solution to this, would be adding a debug.php file in the wp-content/mu-plugins directory. This would create a must-use plugin, active by default on the website. The error not being displayed on the frontend means that you have the fatal error handler enabled on the instance.

You can use the following code to make sure that the errors are shown on the frontend:

define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', true );
define( 'WP_DISABLE_FATAL_ERROR_HANDLER', true );
ini_set('display_errors', 1);

This will display the errors directly on the website and make it easier to trace them.

All the best!

Hey @peopleinside,

It seems that one of the cookies your website sets is on the front end is wp-dark-mode-device. As such, removing wp- from the Bypass Page cache when these cookies are present in the request packet setting in the Cache tab of the plugin should probably fix this.

Hey, @gaiusjaugustus

Could you please try purging all cache first? If that doesn’t work, you can try disabling and enabling the Enable Cloudflare CDN & Caching setting to see if that works?

Thank you!

Have an awesome day ahead!

Hey @gigglesslut420,

Thank you for taking the time & providing the use-case! We’re going to fix this in an upcoming release.

Meanwhile, you can fix it on your end in the src/Services/Cloudflare_Client.php file, on line 386, by passing the true argument to the get_api_auth_args() method like below:

$args = $this->get_api_auth_args( true );

Please let me know if this fixes your issue!

All the best!

@brandohui, thanks for providing more details your reply!

Yes! The code you mentioned should log any errors happening into /wp-content/debug.log. It would help a lot if you could do that first and let me know what gets logged in the file.

The below should be enough to debug this:

// Enable WP_DEBUG mode
define( ‘WP_DEBUG’, true );
// Enable Debug logging to the /wp-content/debug.log file
define( ‘WP_DEBUG_LOG’, true );
// Disable display of errors and warnings
define( ‘WP_DEBUG_DISPLAY’, false );
@ini_set( ‘display_errors’, 0 );

Now on to fixing the error, I suspect this is happening due to the advanced-cache.php file that Super Page Cache adds in the /wp-content folder. This is needed to manage the static cache. I suggest also trying to rename this to something like advanced-cache-bak.php, or deleting it. The error should be gone.

Please let me know about the errors!

Have an awesome day ahead!

Hello @brandohui,

For now, I would advise trying to deactivate the plugin via FTP.

Do you have an error log for the website? Are there any PHP errors present on the website?

Thank you!