Is the PHP Warning with the correct API Token something ongoing or did it fix itself?
The settings page is unique because it’s built using many API calls in parallel. The upside is the Settings page is able to render much faster (~10x faster), but the downside is we don’t get feedback on individual API calls that failed for whatever reason (maybe it’s a network issue or just a temporary API issue on Cloudflare’s side). API calls that aren’t run in parallel are internally retried once (and this usually works if it’s something on Cloudflare’s side). By running those API calls in parallel, we have to trade the ability to automatically retry for the speed. I’ve tossed around the idea of implementing a setting where people can choose “error checking” or “speed” on the settings API page, but I’m not sure how many people would actually opt-in for slower Settings (both presenting and saving), so I haven’t done it yet.
If any of the API calls that run in parallel end up with an error, it does at least dump the latest error to an internal transient that lasts 10 seconds. Due to some internal limitations of WordPress, there isn’t a great way to instantly present the user with an error that happened while the API requests were being run in parallel. However, if you reload the page or navigate to a new page within 10 seconds, you will see the error that was logged on the backend. In the case of your example where “I love WP” is the API token, you get: Cloudflare: 6003: Invalid request headers. A bit of a strange error, but it’s directly relayed from Cloudflare and that’s the error they are kicking back (better errors would need to be something coming from Cloudflare).
As far as verifying API Tokens, I 100% agree that it should be done, however there isn’t a particularly great way to do it with the Cloudflare API. Specifically, you need to grant the API token an extra permission related to API management… at which point a compromised API token has the permissions to retrieve ALL the API tokens on your Cloudflare account. So the ability to auto-verify a token comes with a huge security risk that (imo) isn’t worth taking. I’m hoping {fingers crossed} that Cloudflare implements a verify token API call that is restricted just to the token making the call rather than needing permissions to access any/all API tokens on the account.
If you want to restrict your API token to certain Cloudflare accounts (if you have multiple) and/or specific Zones, you are free to do so, but it’s not a necessity (most users use a single API token across multiple domains). So just be wary that if you set restrictions on the API token, those restrictions will be enforced by Cloudflare. Not sure there’s much I can add beyond what Cloudflare labels each option as: “Select accounts to include or exclude.” and “Select zones to include or exclude.” Again, those options (as well as IP filtering and TTL) are optional and individual site owners can choose to use (or not use) as they wish. As long as you don’t *exclude* the account/zone you are trying to use the API token, it should work.
