typeless

Thank you @jawadwp . That in combination with wp_cache_flush() did the trick.

@owaisalam It utilizes the WPDB Update function like so:

$wpdb->update($wpdb->prefix."users", ['user_pass'=>$wp_hasher->HashPassword($new_pass)], ['ID'=>$user->id]);

If Breeze does not cache user credentials, why after changing a password this way does the old password continues to work (and the new one does not work) until the Breeze cache has been cleared? Could it be getting stuck in CDN (Cloudflare)?

Or another way to approach it – is there possibly a way to trigger a Breeze cache clearing with code at the same time we make the Update?

Thank you for your reply. I found a workaround on my own, so the below is provided for your developers in case they wish to investigate further.

When Breeze is enabled, the CRLF gets inserted into the output buffer. When Breeze is disabled, the character disappears, so it seems reasonable to assume it is something Breeze is doing, though I’m not sure what that would be. In my experience this type of thing is usually caused by a blank line left outside of the PHP brackets in a place where it shouldn’t be, but I scanned the plugin code and didn’t find anything like that – nothing obvious anyway. I also tried other cache plugins to see if it is just cache in general, but they did not produce the same behavior.

There are no related PHP errors as it isn’t really an error at all – just a malformed output buffer. I’ll provide my Breeze settings below, but again, it seems to inject the character no matter what settings we use – even with all features disabled. I tried many combinations of settings, and even tried adding the page in question to the Excluded URLs list at one point.

Here’s my workaround which forcefully removes the stray character from the output buffer.

// save output buffer to a variable so we can manipulate it
ob_end_clean();
ob_start();
$objWriter->save('php://output');
$content = ob_get_contents();
ob_end_clean();

// get rid of stray CRLF
$content = ltrim($content, "\r\n");

echo $content;

Breeze settings (api-token removed):

{"breeze_basic_settings":{"breeze-active":"1","breeze-mobile-separate":"0","breeze-cross-origin":"0","breeze-disable-admin":{"administrator":0,"author":0,"contributor":0,"editor":0,"subscriber":0,"wpseo_manager":0,"wpseo_editor":0},"breeze-gzip-compression":"1","breeze-browser-cache":"1","breeze-lazy-load":"0","breeze-lazy-load-native":"0","breeze-lazy-load-iframes":"0","breeze-lazy-load-videos":"0","breeze-desktop-cache":"1","breeze-mobile-cache":"1","breeze-display-clean":"1","breeze-b-ttl":1440},"breeze_advanced_settings":{"breeze-exclude-urls":[],"cached-query-strings":[],"breeze-wp-emoji":"0","breeze-store-googlefonts-locally":"0","breeze-store-googleanalytics-locally":"0","breeze-store-facebookpixel-locally":"0","breeze-store-gravatars-locally":"0","breeze-enable-api":"0","breeze-secure-api":"0","breeze-api-token":"******"},"breeze_heartbeat_settings":{"breeze-control-heartbeat":"0","breeze-heartbeat-front":"","breeze-heartbeat-postedit":"","breeze-heartbeat-backend":""},"breeze_cdn_integration":{"cdn-active":"0","cdn-url":"","cdn-content":["wp-includes","wp-content"],"cdn-exclude-content":[".php"],"cdn-relative-path":"1"},"breeze_varnish_cache":{"auto-purge-varnish":"1","breeze-varnish-server-ip":"127.0.0.1"},"breeze_first_install":"no","breeze_preload_settings":{"breeze-preload-fonts":[],"breeze-preload-links":"1","breeze-prefetch-urls":[]},"breeze_file_settings":{"breeze-exclude-urls":[],"cached-query-strings":[],"breeze-wp-emoji":"0","breeze-store-googlefonts-locally":"0","breeze-store-googleanalytics-locally":"0","breeze-store-facebookpixel-locally":"0","breeze-store-gravatars-locally":"0","breeze-enable-api":"0","breeze-secure-api":"0","breeze-api-token":"******"},"breeze_ecommerce_detect":false,"breeze_advanced_settings_120":"yes"}

I figured out the two characters it is injecting are ASCII 013 and 010 – which of course is CR LF (Carriage Return & Line Feed).

Thanks again Jeff – I think we can mark this as resolved, it doesn’t seem to be this plugin’s fault after all.

Upon further investigation this has something to do with having 3 properties which are somehow interconnected in Google Analytics itself, though I am not sure how they are linked. At any rate, I tried manually embedding the code and it still produced the same 3 headers.

So despite looking very much like this plugin was the cause I guess it is not! Google Analytics sure does a good job making its interface as confusing as possible.

Normally I would agree with you, but all 3 codes show up when the plugin is enabled and all 3 codes disappear when the plugin is disabled. This pretty clearly indicates the source of the problem, although not the cause.

All 3 codes show up in the response header, while only one of the three is embedded in the code – prefixed by the GA Google Analytics comment. All 3 properties receive data. I found this to be very strange behavior, and thought your developer(s) might at least want to know about it.

If there’s no known explanation or curiosity I’ll move on to other solutions. Thanks anyway.

EDIT: Can confirm there is nothing saved in the 3 “Custom Code” input boxes.

• This reply was modified 6 months, 3 weeks ago by typeless.

It seems pretty clear at this point that this issue is very specific to one very particular situation. I’m marking this as Resolved for now and will continue investigating as I find the time. If I discover anything concrete that could be helpful to others I will do my best to share those findings with the appropriate channels.

Thank you for your time and consideration.

@adamdunnage Yes, we are using both a staging and a production environment. I would appreciate if you could please scrub our URLs from the above message if possible so they don’t become associated with debugging information in public searches.

Both environments have the same issue activating Site Kit regardless.

I got the same impression from the logs – code and site_code are passed back, but the plugin somehow does not receive them.

Can I ask where you pushed out this new release to? Presumably you are referring to version 4.4.4 which is referenced in the online changelog. However, the version here on www.ads-software.com is still 4.4.3. Hoping to try the latest version to see if it fixes some bugs.

@adamdunnage I have submitted the relevant HTTP requests to that form. Definitely looks to me like the site_id and site_secret are coming back in the second response payload, but maybe something else will stand out to you.

Thanks for continuing to look into this.

@adamdunnage

No success as of yet. I did go through and compare the server configuration of both a working and not-working site and everything seems exactly identical. Same firewall settings, same server configuration, same server type, same plugins, same theme and customizations, same headers… But one works and the other doesn’t. At this point I’m not sure if it would be hosting related since an identical hosting configuration both works and doesn’t at the same time.

Do you have any other ideas to try? Anything which might shed some light? Where is the site_id supposed to come from?

Thanks

This was an issue for me as well. The CSS hot fix provided by @htmgarcia wasn’t working because the quotation marks were not properly formatted – probably got changed on here because they weren’t in a code block. The below version does work so we can continue using the latest version:

.metaslider .slides [aria-hidden="true"] a {
display: block!important;
}

@adamdunnage It happens on both the Staging and Production version of the same site in the same hosting (AWS). However, I do manage other WordPress sites in similar environments which have not had this problem.

@adamdunnage There are no Critical issues reported on the Site Health Status tool.

I went ahead and deactivated all other plugins, deactivated all browser extensions (browser used was Google Chrome), uninstalled and reinstalled a fresh copy of Site Kit version 1.106.0, switched to a default theme and tried again – it still produced the same error.

• This reply was modified 1 year, 3 months ago by typeless.

@adamdunnage Thanks for the reply. Yes, I have tried the same setup process since upgrading to version 1.106.0. Also tried it while having all other plugins disabled and a default theme applied (Twenty Twenty-Three).

I went through the setup process on your demo site and it worked without any problems. On the site I’m working with it never gets to Step 1. Instead, it produces the fatal error upon returning from the “Sign in with Google” screen after selecting my account and clicking Continue.

I made a temporary modification on a copy of the plugin code to have it spit out the value of $query_params whenever that error occurs and site_id is indeed coming back empty, and the alternate parameter it is looking for (site_code) is missing altogether. Seems it needs to see at least one of the two.

Array
(
    [site_id] => 
    [step] => verification
    [code] => sitekit-ub....
)

I wonder if something CORS related could be blocking this? I’m not sure where that site_id should originate from.