Fail to save API token

Hello, this probably indicates a basic problem with the browser’s attempt to communicate to your web server on that address using the PUT http verb. If so, then this plugin’s code (on the sever side) never gets a chance to try to handle the request.

Consider trying a different browser, or a different version of that browser, to see if it makes any difference. This would help to rule out whether it just happens to be a problem with the version of browser you’re using.

On the server, I’d recommend that you confirm that your web server is configured to allow PUT requests on URLs under /wp-json/font-awesome. Occasionally, I’ve seen web servers that disallow PUT requests (even though the WordPress docs recommend its use in situations like this).

Another possibility–which seems less likely, but just maybe… Another user was experiencing a problem that turned out to have been caused by the web hosting provider filtering IP traffic, which was interfering with this plugin’s backend (PHP) code, running on the web server, from being able to make requests to the Font Awesome API server. In that case, it was a different kind of error message that resulted. That’s one reason why this kind of root cause seems less likely in your case. But I mention it because it’s another example of the kind of configuration problem that blocks communications. The solution in that case was for the hosting provider to change its network configuration to allow the request to pass through.

To summarize at a higher level:

There are two communications that have to happen successfully when you add an API Token: (1) your browser talking to your web server, (2) your web server then talking to the Font Awesome API server.

The error message you’re seeing is specifically referencing step #1, so that’s the most likely place you’ll find the root cause. It’s possible, but seems less likely, that something is going on with #2, which results in the symptom of #1.

Hello,

Hosting indeed was blocking PUT but they opened it. However the script still does not work. Tested it with Chrome and Firefox (latest versions).

Could you give us a sample curl bash command that should be working to test the server side?

I could do that, but it would be a little more complicated, since it would require lifting the authentication stuff out of your WordPress admin session and using it in that curl command.

There’s an easier test or two I’d recommend first.

This /wp-json/font-awesome/v1/config route is the main route to which any configuration changes would be PUT when saving.

So, I know you’re trying to enter an API Token, probably to set up a kit. But for the moment, could you try and tweak a simple configuration on the “Use CDN” tab?

Just switch from Webfont to SVG or something, and save changes.

If that works, then it means that the browser in question is working fine sending a PUT to that route on the server, and that the server is also configured properly.

If it fails, then I’d be curious to see if the console log messages are any different. Handling that “save changes” request does not entail your WordPress server contacting the Font Awesome API server, so it’s a simpler operation on the back end.

By the way, you’ve apparently already succeeded in activating the plugin, if you’re in there trying to add an API Token, right? If so, that is probably a confirmation that your WordPress server is successfully communicating with the Font Awesome API server. Upon activation, the plugin’s backend code sends a request to the Font Awesome API server to load up metadata about the available versions of Font Awesome. If it were not able to succeed in that initial request, I expect that plugin activation would have failed.

Something else that comes to mind: are you using WordPress multi-site / network mode? This plugin is not yet compatible with multi-site mode, and as a result, there may be some strange behaviors in some scenarios.

Good morning,

Thanks a lot for the detailed answer.
You are assuming correctly, plugin is activated and I am trying to add the API Token. I am not using network or multisite.

I tried to use the CDN option, got the exact same error:

reportRequestError.js:134 Font Awesome WordPress Plugin Error Report
reportRequestError.js:108 Error
reportRequestError.js:68 message: A request to your WordPress server never received a response
code: fontawesome_request_noresponse

reportRequestError.js:75 XMLHttpRequest?{readyState: 4, timeout: 0, withCredentials: false, upload: XMLHttpRequestUpload, onreadystatechange: ?,?…}
xhr.js:155 PUT https://www.afisesapollon.gr/wp-json/font-awesome/v1/config net::ERR_HTTP2_PROTOCOL_ERROR
(anonymous) @ xhr.js:155
e.exports @ xhr.js:16
e.exports @ dispatchRequest.js:48
Promise.then (async)
l.request @ Axios.js:55
a.forEach.l.<computed> @ Axios.js:74
(anonymous) @ bind.js:11
(anonymous) @ actions.js:518
(anonymous) @ index.js:8
y @ SettingsTab.js:50
l @ react-dom.production.min.js:33
p @ react-dom.production.min.js:53
(anonymous) @ react-dom.production.min.js:57
g @ react-dom.production.min.js:77
it @ react-dom.production.min.js:942
at @ react-dom.production.min.js:931
lt @ react-dom.production.min.js:955
pt @ react-dom.production.min.js:1041
ae @ react-dom.production.min.js:7278
ce @ react-dom.production.min.js:327
Zt @ react-dom.production.min.js:1378
Xt @ react-dom.production.min.js:1341
t.unstable_runWithPriority @ scheduler.production.min.js:309
Ba @ react-dom.production.min.js:2816
ne @ react-dom.production.min.js:7263
Qt @ react-dom.production.min.js:1329

Thank you very much for your efforts to solve this.

What I’m most curious about now is the part of the console error message that says: net::ERR_HTTP2_PROTOCOL_ERROR.

I’m not accustomed to seeing HTTP2 used on a WordPress web server, and I’m not sure what difference it might make here. But it does seem like it would be helpful to further isolate the issue by trying it as a curl command.

Also, are there any other non-standard configurations on the web server? I wonder what kind of web server it is.

Are you using LiteSpeed Cache? If so, is this issue relevant in your case, or this one?

A teammate reminded me of Chrome’s handy feature to copy a network request as a curl command, and I confirmed that it does include the appropriate authentication request headers for a WordPress admin request, so give that a try. Here’s a link to some screenshots that might help.

I recommend NOT posting that curl command here in this forum, since it will include some secrets.

In my local development environment, when I run that curl command, it returns successfully with the expected JSON response.

If you get that working, I’d be interested to know, if you add the “-v” option (verbose) to the curl command, what HTTP protocol it uses by default. In my environment, I see this in the request:

PUT /wp-json/font-awesome/v1/config HTTP/1.1

and this from the response:

HTTP/1.1 200 OK

I also wonder what you see in the Server response header. In my environment (the official wordpress Docker image), I see this:

Server: Apache/2.4.38 (Debian)