Tim Eckel

Got it. The added cononical tags would kind of defeat the purpose of MininifyHTML. Turning off the setting which removes the protocol and domain from links would be preferred. That’s why there’s an option to turn it off. If you feel you don’t want links changed to relative.

Also, Google does say “relative paths are supported by Google” in regards to cononical links. The suggestion not to use them is if in case you exposed a testing domain to the search engine. This should be made physically impossible anyway, so using relative paths with cononical links isn’t a problem anyway. Sounds like an overzealous warning, I’d leave relative links on.

• This reply was modified 3 months ago by Tim Eckel.

I don’t follow. It should just be removing the protocol and the domain from links. If the link is canonical or not shouldn’t be touched as that’s the query portion of the URL. Maybe an example would be helpful? I don’t have any such issue as you’re describing, and that option is a switch in the plugin, so you can turn it off as it sounds like you have a unique situation as I’ve never heard of it.

I have no idea what these changes you refer to even are.

Just because somehting hasn’t been updated in a while doesn’t mean it’s abandoned. ?? It just means there’s been no reason to update it or there’s no suggested updates that actually work.

Its too bad you can’t create a pull request with this platform like on Github or BitBucket. Would allow for better community involvement.

Inline JSON is not minified by Minify HTML at this time.

It appears woocommerce went with their own review system starting with v6.7. Therefore, you’ll need to request this feature from woocommerce as plugings will no longer work.

The version question was about the version of Woocommerce, as I’m reading they made drastic changes in v6.7 dealing with the reviews. They’re no longer using WordPress reviews, but using their own, so my guess is that Woocommerce v6.7 is a breaking change.

Could you be running Woocommerce 6.7?

• This reply was modified 8 months, 2 weeks ago by Tim Eckel.

I’d look in the backend at the reviews to see what state they’re in. They should be in the “hold” state. If they’re in a hold state (which would be correct using my plugin), it means the issue is how you’re displaying the reviews. Specifically, it could be the rendering code is showing ALL reviews regardless of state, instead of filtering reviews on hold (which is the default).

• This reply was modified 8 months, 2 weeks ago by Tim Eckel.

First, did you activate the plugin? Secondly, you need to add a new review after the plugin is activated. Previously added reviews will not be hidden. Finally, the user who added the review will be able to see their review (but will show as being reviewed).

All this plugin does is change the default state of newly added reviews to “hold”. It doesn’t change any previously added reviews. After the plugin is activated and a new review is added, you’ll be able to see thr newly added review is in a hold state.

Make sure you sign out. If you’re signed in, as an admin you’ll see the pending review.

The issue is that WordPress no longer knows if it’s an admin in the dashboard or visitor viewing the website as it’s using an API that doesn’t know the user’s access. Therefore, it can’t disable plug-ins (like Minify HTML) when it did before. This is a current “limitation” (or bug) with WordPress. As many are having issues with this, the hope is that WordPress will adopt a more appropriate API route which validates the user’s access level (which kind of seems important).

I’ve tried work-arounds, but none have been successful at this point.

That’s very possible as both are trying to minimize in slightly different ways.

To test the fix, if you could go into the Tools>Plugin File Editor and select the Minify HTML plugin. Around line 38 the line should be:

if ( !is_admin() )

If you could change it to the following

if ( !is_admin() && !( defined( 'REST_REQUEST' ) && REST_REQUEST && 'edit' === $_GET['context'] ) )

And Update File. Then test to see if the bug no longer exists.

Thanks

Seems the source of this problem is a WordPress “bug” that’s been reported many times but there doesn’t seem to be a way to fix it.

Basically, the block editor uses the REST API which doesn’t know if the user is an admin or not. Not sure why the REST API doesn’t know that key state (would be easy to have that as part of the request payload or to be checked at validation). But in any case, admin state is not known. Further, even though there’s been numerous bug reports, it’s been determined that it’s unfixable in the WordPress core.

This bug report best discusses the issue:

https://github.com/WordPress/gutenberg/issues/51090

There’s some code in the above bug report that looks promising to resolve the problem with the plugin. I’ll see if it works. But, it’s very concerning that WordPress has parts of the admin console that no longer know if it’s in the admin state or not. is_admin() has been a core function to detect this state, and it’s no longer a valid check.