OMGF encountered an error while downloading Google Fonts: rest_no_route – No rou

v4.5.16 does not fix this problem ??

Well, there you go. The API fails to execute, probably because the nonce is cached by LiteSpeed. Does LiteSpeed support excluding nonces?

As for your comment about using the API: it’s a much more flexible option (also keeping in mind different PHP timeout configurations on different servers) compared to just executing it on pageload, or something.

v4.5.18 also fails.

I’ve excluded /wp-json/ from caching and page optimisation, and it’s made no difference. Also, as I’ve mentioned, this fails even when no other plugins are active, including LiteSpeed Cache.

This is also not likely to be a timeout issue. The failure happens very quickly.

No luck with v4.5.19 ??

@daanvandenbergh can you provide a snippet that will test this? I can it within WordPress, just like the plugin would, but with more detailed checks and output.

Have you tried excluding the wp_rest nonce from LS cache?

I’ve spoken to people on LiteSpeed servers and I’ve been on LiteSpeed myself, we’ve never had issues. So, this is clearly an issue specific to some server configurations.

I’ll try and help, ofcourse, just don’t get your hopes up everytime I release an update ??

From what I understand, this isn’t even a server problem. The error code and message seem to indicate a problem with the REST API setup in WordPress, and I can see this on multiple sites.

As for caching, I get different results from different API queries, whether or not anything is excluded, so that’s not it either.

To exclude any hosting account specific issues, I’ve just tested on another site and gotten the same result. To be sure, this site has NO caching or page optimisation in effect.

On a previously configured site with fonts being listed, simply clicking Save & Optimize returns a “No (additional) fonts” message. Then, after emptying the cache directory, the messages changes to “No route”.

Perhaps the first message is OK and something happens when the cache directory is cleared?

Could this be about the timing of REST API calls relative to when routes are registered (I’m really fishing here)?

Again, a debugging snippet should go a long way towards resolving this, so I’d really appreciate help coming up with one. Calling OMGF functions in this snippet is OK, so this can be based on plugin code with some debugging enhancements.

Alternatively, I’m happy to hack the plugin on my test sites and insert code, if it will help figure out what’s going on.

I’ve added a debug function to OMGF in one of the last releases.

You can add OMGF::debug('string to print') anywhere in the code, and when OMGF_DEBUG_MODE is set to true, e.g. in your wp-config.php file, it’ll print the debug information to omgf-debug.log in the wp-content folder.

I’ll add debug information in the Download API in the next release, alright?

OK, I’ve found the problem.

In includes/optimization-mode/class-manual.php, line 154 is:

$request = new WP_REST_Request('GET', str_replace('/wp-json', '', $parsed_url['path']));

Because the site is in a subdirectory, this changes /behappyinlife/wp-json/omgf/v1/download/css into /behappyinlife/omgf/v1/download/css, which is incorrect.

This works:

$request = new WP_REST_Request('GET', preg_replace( '|^.*/wp-json|', '', $parsed_url['path']));

• This reply was modified 3 years, 1 month ago by Gal Baras.
• This reply was modified 3 years, 1 month ago by Gal Baras.

Hi guys,

I’m currently re-factoring the entire API approach and found a much simpler method to achieve this. So, this issue will be fixed in the next release.

Thanks for your patience!

I’m closing this one, so we can continue this discussion in this thread and the API (causing the rest_no_route error) doesn’t exist anymore.