David Bee

By default, the COOKIEPATH constant creates the path using get_option( 'home' ). On the other hand, the SITECOOKIEPATH constant is created using get_option( 'siteurl' ). For some WordPress sites, these two paths are not the same URL (for example, if the site is installed in a sub-directory, one cookie path would be “/”, and the other cookie path could be “/sub-directory/”).

The important thing is that there’s a problem in the code in wp-content/plugins/breeze/inc/functions.php:

On line 237 and line 277, you use COOKIEPATH. But on line 247 you accidentally use SITECOOKIEPATH. This should be COOKIEPATH as well.

Hope this helps fix the code.

You are 100% right. I tested soon after posting this and realized the error in my ways. ha. But thanks for the explainer. Learn something new every day! ??

@mariuszm totally agree, this would be a fantastic feature. Great references as well. It would be a huge improvement to get such contemporary web technologies incorporated into Breeze in the near future.

For the time being, what I’ve done is excluded any dynamic content from the initial HTML page output, rendering only placeholders. I then load dynamic content via Ajax calls. This means that the entire page content can still get cached, and the dynamic elements get loaded independently for each user.

Hi @adeelkhan

Thanks for your reply. Yes, I understand that adding a URL to Never Cache URL(s) will mean that the URL will never be served from cache. So I did not add https://example.com/page/ (or any variation of it) to that list.

However, according to the Knowledge Base document, if I add country to Cache Query Strings, any url that includes “country” should be served by cache. So all of the following variations should be served by cache:

• https://example.com/page/?country=germany
• https://example.com/page/?country=germany&eyes=blue
• https://example.com/page/?country=germany&eyes=blue&test=one

Please test, and you will discover that this does not happen. Only the first URL gets served by cache. This is incorrect behavior, as all three of the above URLs should be served by cache. I explained in the original post why this is happening and how to fix it. Let me know how I can help support you.

Thanks!

Happy to help! Thanks for the shoutout @bruandet !

To clarify, in version 2.0.20, the execute-cache.php file code referenced is now on lines 130–137.

Since SMUSH 3.9.1, the plugin has done away with the WP_SMUSH_PREFIX constant. So to get the code fully working again a small modification had to be made. Here’s the new code.

/**
 * Enqueue Smush Lazy Loading styles into Give form iFrames.
 */
function enqueue_smush_styles_for_give_iframe() {
	if ( class_exists( 'WP_Smush' ) ) {
		WP_Smush::get_instance()->core()->mod->lazy->add_inline_styles();
	}
}
add_action( 'give_embed_head', 'enqueue_smush_styles_for_give_iframe' );

/**
 * Enqueue Smush Lazy Loading scripts into Give form iFrames.
 */
function enqueue_smush_scripts_for_give_iframe() {
	if ( class_exists( 'WP_Smush' ) ) {
		// Get options.
		$options = Smush\Core\Settings::get_instance()->get_setting( 'wp-smush-lazy_load' );

		$script = WP_SMUSH_URL . 'app/assets/js/smush-lazy-load.min.js';

		// Native lazy loading support.
		if ( isset( $options[ 'native' ] ) && $options[ 'native' ] ) {
			$script = WP_SMUSH_URL . 'app/assets/js/smush-lazy-load-native.min.js';
		}

		wp_enqueue_script( 'smush-lazy-load', $script, array(), WP_SMUSH_VERSION );
	}
}
add_action( 'give_embed_footer', 'enqueue_smush_scripts_for_give_iframe' );

@matheusfd & @mrdaro it would be great to get this included in the plugin.

Wah-wah. Just checked and this was totally my fault. The diagnostics.php file was accidentally being caught by a slightly too general gitignore rule on my end and thus just didn’t get included in the deployment code. Once I fixed that everything works perfectly again. So please ignore. Thanks a ton for your willingness to resolve it!

Cheers!
David

Hi Till!

Thanks for your patience with the reply, was traveling.

I actually installed it from the WP repo here. It’s the latest version 2.0.21.

That sounds like a possible .htaccess file redirect issue. I’d recommend removing any custom redirect rules you may have in your .htaccess file to figure out what’s causing it. But that’s outside the scope of this thread, so I’d recommend starting a new thread on WP general support to help you figure out what’s going on with the site.

Have you checked the debug.log file at /wp-content/debug.log? If you refresh the page any errors that are being generated should get logged there.
Depending on the host you’re on, the debug file may also be located at /errors.log, or in some private logs directory.

• This reply was modified 3 years, 5 months ago by David Bee.

Let me know when you get a moment. Thanks!

Btw. In the future, should I post bugs here or directly on https://feedback.givewp.com/ ?

Cheers!
David

You’re a rockstar! Thanks!

Marvelous! Thanks for jumping on this topic so fast. Appreciate it!

Have a great week!