Matt

That won’t work for detecting shortcode inside another widget though.

Sorry, the website I am working on is not front-facing yet.

latest version does seem to fix the issue. I noticed you wrote in the notes that you’re looking for a better detection. I think my function above does a good job of detecting the code in a widget.

Unfortunately the site I’m working on is still in development and therefor not front-facing. But it doesn’t matter if I put the “error_log(‘page_load’);” in one of my plugins (was putting it in the main .php file) or just in the theme’s functions.php. The result is the same.

So just now I put “error_log(‘page_load’);” in the theme’s function.php. Without SEO activated if I hit refresh I only get 1 “page_load” in the error log. After activating SEO and hitting refresh I get two every time.

alright, thanks

Ok that makes sense, and I assume that is exactly what’s happening. Is it unavoidable (or necessary) to cause all plugins to reload in the ajax request though? I assume it may be necessary in order to process shortcodes depending on how you’re doing it.

I am not able to replicate it now either by creating a new site. It must have something to do with an upgrade process when the addon is updating on an already existing site?

Just a note though, when I turn debugging on for wordpress I see these:

Notice: Undefined index: cptch_login_form in D:\path\to\wp\wp-content\plugins\captcha\captcha.php on line 205

Notice: Undefined index: cptch_comments_form in D:\path\to\wp\wp-content\plugins\captcha\captcha.php on line 210

Notice: Undefined index: cptch_register_form in D:\path\to\wp\wp-content\plugins\captcha\captcha.php on line 221

Notice: Undefined index: cptch_lost_password_form in D:\path\to\wp\wp-content\plugins\captcha\captcha.php on line 232

I will work with that, thanks. If I could offer a suggestion, in addition to this change with the filters it may be a good idea to modify your css selectors to be more specific. e.g. add a #pdpdatepicker (or whatever it is, not looking at the code atm) before every selector which would thereby override any css that is less specific.

thanks

FYI– My mod for this ends up breaking next/previous links on feed pages due to code above where I inserted this. See here: https://www.ads-software.com/support/topic/bug-with-show-paging-links-checkbox?replies=3#post-6627747

What you’re doing with reading and updating the paging option on every page load seems very sloppy to me. If a widget has 10 feeds like mine did, you could be adding 20 extra database calls on every page load.

So I’ll be going to CSS route for this instead.

This was my fault. My fix here broke this. I have to say though what you’re doing with this:

if( $widget ) {
		foreach( $ids as $f ) {
			$paging = get_post_meta( $f, 'gce_paging_widget', true );
			$old_paging[] = get_post_meta( $f, 'gce_paging', true );

			if( $paging ) {
				update_post_meta( $f, 'gce_paging', true );
			}

			$paging_interval = get_post_meta( $f, 'gce_widget_paging_interval', true );
		}
	}

and then this later:

// Reset post meta
	if( $widget ) {
		$i = 0;
		foreach( $ids as $f ) {
			update_post_meta( $f, 'gce_paging', $old_paging[$i] );

			$i++;
		}
	}

seems very sloppy to me.

Try my fix here: https://www.ads-software.com/support/topic/tooltips-in-wigets-broken-in-22?replies=3#post-6623127

Try my fix here: https://www.ads-software.com/support/topic/tooltips-in-wigets-broken-in-22?replies=3#post-6623127

You can try my fix here as it looks like you have your calendar in a widget: https://www.ads-software.com/support/topic/tooltips-in-wigets-broken-in-22?replies=4

Could it be this: https://www.ads-software.com/support/topic/bug-with-show-paging-links-checkbox?replies=1 ?