Fatal error

It that something still happening? I’ve toyed with the idea of suppressing that error, but usually it’s a good idea to know there’s something wrong with the Cloudflare API. Specifically, that could happen if the API call to get your zone settings returned something unexpected. There was some major issues with the Cloudflare API and dashboard earlier in the week, but those are supposed to have been resolved.

If it’s not happening anymore, I’d say it was probably related to Cloudflare’s service outage. If it’s still happening, here’s a few things to check:

• Make sure the domain is a valid zone on the Cloudflare account that the API token is coming from.
• Make sure all the required permissions are correct for the API token.

If both of those check out okay and it’s still happening, let me know and I can give you a few lines of debugging code to add that will let you see *exactly* what the Cloudflare API request is returning which might give some insight as to what the underlying issue may be (it could be a lot of different things, for example if the SSL certificates on your server have expired it wouldn’t be able to communicate with the API server).

The site is managed by my client. Lately, I have not received any complaints regarding I posted on another topic.

the above one is an unique issue I just observed while testing plugin at OLS / OpenLiteSpeed stack via Runcloud.

i couldn’t understand why that happens. I know I selected right zone and site URL

It is best to handle error gracefully if possible.

CF downtime is frustrating. And my client and his team constantly update every few mins.

I dropped plugin and simply added 300 for s-maxage for all pages except logged in.

Now either api is up or down… Doc (HTML) cache get flushed automatically every 5 min and this is critical for the news site (excluding Static files).

Well, the only “graceful” way to handle it would be to throw an error that blocks someone from viewing the settings, which is going to give far less (as in none) info about what the underlying issue might be. You really wouldn’t want someone looking at the Cloudflare settings and displaying the options in some sort of default state (since we don’t know what they actually are due to the API failure). You would end up with problems where the user didn’t know something went wrong, sees some of their Cloudflare options set “wrong” and then proceeds to start changing settings when really they didn’t need to be changed to begin with.

That being said, it does probably make sense to do exactly that now that I think about it. Just present the user with some sort of “Unexpected API error” and maybe if WordPress debugging is on, give them some extra info (like the debug backtrace) rather than giving everyone the debug backtrace (sometimes I forget not all users would want the extra info).

I am curious though if it’s something still happening or if it sorted itself out (like a Cloudflare API issue on their end that they then fixed)? Internally the addon is already retrying anytime there’s an API error, but it does give up after the second try (doesn’t make sense to just do a retry loop for an hour if Cloudflare actually is having API issues).

no worries ??

i will double check and provide an update.

Thank you

Well regardless if the API is up or down, things should work for normal usage. I already added the thing where the purge cache will not throw an error if it fails for whatever reason (rate limiting or API just being down). The error above would have strictly been on the Cloudflare Settings page (there’s no way around that failing if the API is having issues), but normal use (like writing/editing posts), a user is never going to need to be there. There are no API calls needed to serve a page.

But ya, if you are needing to view/edit Cloudflare account settings (which is where that error came from) while there’s an API issue, that’s just not going to be possible (with the addon or without via the Cloudflare dashboard, as their dashboard uses the same API calls).

Again, just to be clear… normal usage for things like edit/creating posts is only going to make the purge cache API call, and that’s setup to not throw an error if it fails (for any reason).

FWIW, I was able to reproduce the error when visiting the settings page. In my case it was an API request timeout (WordPress defaults to a 5 second timeout). I went ahead and raised the timeout for the next version to 10 seconds. *Normally* the Cloudflare API should never take anywhere remotely close to 5 seconds to return something, but I’m guessing right now they are in a less than ideal state due to still fully recovering from last week’s issues. As I mentioned earlier, that is going to apply if you are trying to manage your Cloudflare settings from within WordPress or if you are doing it in Cloudflare dashboard since they are using the same underlying API calls. So if the Cloudflare API for managing settings is being screwy it’s also going to be screwy via normal Cloudflare dashboard, so using one method over the other isn’t really going to be able to “get around” any issues Cloudflare is having with their API.

While normally it shouldn’t be an issue, there are times where there’s an issue with the Cloudflare API itself (which would also mean their own dashboard doesn’t work as expected). For the 1.8.0 version I added some sanity checks that we are getting expected API results as well as upped the API timeout from the default of 5 seconds in WordPress to 15 seconds. I also rebuilt the backend for gathering and compiling Cloudflare Settings when viewing/editing settings to make it significantly faster (it requires 10 individual API calls, which were run sequentially before… now they run in parallel so it’s a lot faster now).

While I can’t control if Cloudflare’s API is having issues like they had last week, I did make some changes to mitigate errors in the 1.8.0 version should address those the best that can be done.

Going to mark this as resolved since 1.8.0 is out, but let me know if you are seeing anything else…