Hmmm, could be the API endpoint isn’t registered for the site, when it’s not network activated.
I’d have to test this and get back to you. I can’t promise it’ll be soon, though, because there’s a bunch of other things that have higher priorities.
It may be good to merge this thread with this one.
@cmgeoogz are you using LiteSpeed?
Hi guys,
The API will be dropped as v5.0.0, which is to be released later this week. So, this issue will be resolved in that release. 🙂
5.0.0 was released on Friday. Please test if your issue is resolved in that version, @galbaras 🙂
Well, my fonts are listed twice. Once for a stylesheet handle “google-fonts” and once for “google-fonts-css”, although the latter is the only one on the page.
Also, when I save the settings, the URL changes from
/wp-admin/options-general.php?page=optimize-webfonts to
/wp-admin/options.php?tab=omgf-optimize-settings and I get a 403 error.
So it’s not working for me yet.
-
This reply was modified 9 months, 1 week ago by
Gal Baras.
Well, at least you’re not getting the rest_no_route error anymore.
But, it’s the 403 again. 🙁
/wp-admin/options.php is the form’s action, which should eventually trigger a redirect back to options-general.php?etc. The fact that it’s not getting there means it fails earlier on in the script.
When I look through the options.php file I see a few moments it’ll stop code execution and return a 403 forbidden error:
if ( ! current_user_can( $capability ) ) {
wp_die(
'<h1>' . __( 'You need a higher level of permission.' ) . '</h1>' .
'<p>' . __( 'Sorry, you are not allowed to manage options for this site.' ) . '</p>',
403
);
}
This is on line 48. I’m fairly certain this isn’t the case, but it might be worth it to add a die('with a clear, unique message here so you know where exection died') within the if statement, but before the wp_die(), to see if the ends up there.
You could do the same on lines 82, 245 and 256. That should give us an idea of where execution is halted.
Looking forward to your findings!
@cmgeoogz are you using LiteSpeed?
Yes
-Apologize, we ended up re-building the site to a non-multisite.
@cmgeoogz The latest version should have no problems with REST API routes anymore. Can you confirm this?
@daanvandenbergh With 5.0.0, I got a permission message, but with 5.0.1, I’m not getting ANY message. Just the browser’s standard 403 page.
I’m not sure how this works, but shouldn’t the page POST to itself, rather than to options.php? To be sure, I changed the form action and got the same result: standard 403 page.
This also happens when my security plugin is disabled 🙁
I’m not sure how this works, but shouldn’t the page POST to itself, rather than to options.php?
No, options.php takes care of saving/updating the settings within WP’s Admin screen.
With 5.0.0, I got a permission message, but with 5.0.1, I’m not getting ANY message.
That must be a coincidence. 5.0.1 fixes a few tiny bugs. Nothing related to this.
Could you try the steps in my previous response? It might give us a hint where the 403 is triggered.
I’ve updated to 5.0.4 and added error_log() calls before every call to wp_die(). I then added one at the start of options.php, but nothing appears in the log.
Again, I’m not getting a WordPress message, just the standard 403 page, which tells me I’m being blocked before options.php is loaded.
This continued to happen after completely removing the plugin and its files (with the advanced option to delete everything), and then reinstalling it again. It discovers the fonts, but I can’t save the settings.
So I tried on another site in the same hosting account. I could save the settings without change, and when I disabled “preload” on one font, but after that, anything I turned on resulted in a 403.
-
This reply was modified 9 months ago by Gal Baras.
A while ago I added some steps in this thread, for other users experiencing 403’s to debug. Maybe you could go through these steps, Gal, to see if it resolves the issue for you: https://wordpress.org/support/topic/issues-with-latest-update-403-error/page/2/#post-15379126
Before you start debugging, it might be worth checking out if you’re not getting 403 errors in version 4.5.5.
OK, so what worked for me was the OPPOSITE of one of those suggestions, i.e. replacing the single quotes on line 346 of includes/admin/settings/class-optimize.php with double quotes.
I’ve tested this successfully on 2 sites (both in subdirectories, which doesn’t seem to matter here).
Progress!
I’ve introduced the single quotes back then, to prevent breaking of the serialized string and corrupting the detected fonts.
Why this works on some and doesn’t on other servers baffles me, but alright.
I’ll see what I can do about this. Thanks for testing, Gal!
Hi Gal,
What happens when you do the following:
Replace line 346 with the following code:
<input type="hidden" name="<?= OMGF_Admin_Settings::OMGF_OPTIMIZE_SETTING_OPTIMIZED_FONTS; ?>" value="<?= esc_attr(serialize($this->optimized_fonts)); ?>" />
Does it still work?
Since you’ve rewritten the API bit in v5.0.0, maybe the quotes no longer affect anything. Either way, that line had two pair of quotes, and they were different, which was very strange.
Anyway, regression-test for the other ticket, and if it works, you’ll get 2 birds with one stone 🙂
