Disable phastpress on Woocommerce cart and checkout

What’s happening: In WooCommerce checkout, the HTML body tag is set to a .woocommerce-no-js class which is dynamically changed to woocommerce-js with JavaScript (without jQuery) by the template/theme. The .woocommerce-no-js class renders certain elements as display:block and the .woocommerce-js class renders these elements as display:none.

This creates a brief flash of unwanted HTML elements on the checkout page until JavaScript is able to change the body class from .woocommerce-no-js to .woocommerce-js. I’ve tried to put inline CSS and JavaScript in a WooCommerce template file next to these elements as an attempt to prevent this unwanted behavior. But even these techniques do not prevent the brief rendering of these HTML elements.

Perhaps this is just a consequence of deferring all render-blocking resources? It happens on all browsers.

• This reply was modified 4 years, 12 months ago by kw11.
• This reply was modified 4 years, 12 months ago by kw11.
• This reply was modified 4 years, 12 months ago by kw11.
• This reply was modified 4 years, 12 months ago by kw11.
• This reply was modified 4 years, 12 months ago by kw11.
• This reply was modified 4 years, 12 months ago by kw11.
• This reply was modified 4 years, 12 months ago by kw11.
• This reply was modified 4 years, 12 months ago by kw11.
• This reply was modified 4 years, 12 months ago by kw11.
• This reply was modified 4 years, 12 months ago by kw11.

I figured out how to fix this visual bug by adding some css and then edited the WooCommerce template to use styles inside of a <noscript> tag.

However, this visual bug may be a common occurrence on WooCommerve checkout pages. If this can’t be fixed via plugin code, I recommend giving the option for people to disable optimizations on cart and checkout pages for WooCommerce. Other than that this plugin is mostly flawless.

But I couldn’t enable image optimizations because when there are hundreds (more or less) of small product images, they aren’t all generated/rendered. A lot of broken images. Therefore, I am still using Smush Pro for now.

But a huge fan of your plugin!

• This reply was modified 4 years, 12 months ago by kw11.

What’s happening is that on the server-side cached version of a products page (using WP Engine as host), your image loading implementation causes a 429 Too Many Requests error.

On the non-cached requests, this 429 error doesn’t seem to happen.

The 429 Too Many Requests errors for images looks to be caused by images being served as text/html. Is this intentional?

Hi @kw11,

Thanks for trying out PhastPress and debugging the issue you faced yourself. ??

Regarding the rendering issue with WooCommerce:

PhastPress delays JavaScript from running until after the page is rendered. That causes problems when correct rendering depends on JavaScript.

In this case, that could be solved by removing the woocommerce-no-js class.

Regarding the failing image optimization:

The 429 Too Many Requests is caused by some sort of rate limiting your host/server is doing on the amount of PHP script requests. Unfortunately, that might mean you can’t use Phast image optimization, at least until your hosting provider lifts this limit. A plug-in that doesn’t optimize images on-the-fly, like Smush Pro, is a good alternative.

If you want to exclude pages from optimization by Phast:

You can use the hook described in the FAQ. Something like:

add_filter('phastpress_disable', function ($disable) {
return $disable || is_cart() || is_checkout();
});

If PhastPress is working well for you, I’d really appreciate it if you left a review here. ??

–Albert

The plugin is excellent. Definitely will leave a review.

However, the rate limiting appears to be happening because images are served as text/html instead of image/jpeg as observed in the network logs. Is this intentional?

Also, are you willing to do create a “custom” plugin for us that removes the Phast branding from the HTML for a fee? It’s something we’re interested in.

I think a feature some would enjoy is moving specific slugs, page IDs, and post/page types from optimizations. I am pretty technically-minded but I even have trouble figuring out the best place to stick that hook. Users less technically-inclined would have no idea where to even start.

I know you’re trying to make a plugin that just works and doesn’t need any exclusions. And while it’s genius and 10,000x better than the popular auto-optimize, I think you can still argue that there are use cases where such exclusions are desired.

Thank you for your reply!

-Kyle

• This reply was modified 4 years, 12 months ago by kw11.
• This reply was modified 4 years, 12 months ago by kw11.

Hi Kyle,

However, the rate limiting appears to be happening because images are served as text/html instead of image/jpeg as observed in the network logs. Is this intentional?

Definitely not intentional, and this should not be happening, but I assumed this is an effect of the rate limiting being applied. Would you be able to share the URL of your site with me, so that I can have a look at what’s actually happening?

Also, are you willing to do create a “custom” plugin for us that removes the Phast branding from the HTML for a fee? It’s something we’re interested in.

Discussing commercial affairs is not permitted on the www.remarpro.com forums. You can find my contact details via the website on my profile.

I think a feature some would enjoy is moving specific slugs, page IDs, and post/page types from optimizations.

I don’t disagree. ?? The intention with PhastPress was always to create a plugin that does not need any custom setup to work, as you pointed out. This is something I might add in a future release.

For now, a good place to stick the hook would be in your theme’s functions.php, or if you are using a stock theme, in a .php file inside wp-content/mu-plugins.

–Albert