Auto Insert does not work

Hi @fuego23,

Can you please give a specific example of settings you used that is not working for you?

What code type, which location and which theme you tried.

I can’t think of any reason none of the locations would work unless there’s something not working when trying to activate the snippet.

@gripgrip I am having the exact same issue with Astra.
I haven’t quite figured it out but none of the following combinations work ever.

HTML/Site Wide Header/No Smart Logic
HTML/Site Wide Header/With Smart Logic
HTML/Site Wide Body/No Smart Logic
HTML/Site Wide Body/With Smart Logic
HTML/Site Wide Footer/No Smart Logic
HTML/Site Wide Footer/With Smart Logic
HTML/Insert Before Post/No Smart Logic
HTML/Insert Before Post/With Smart Logic

Universal/Site Wide Header/No Smart Logic
Universal/Site Wide Header/With Smart Logic
Universal/Site Wide Body/No Smart Logic
Universal/Site Wide Body/With Smart Logic
Universal/Site Wide Footer/No Smart Logic
Universal/Site Wide Footer/With Smart Logic
Universal/Insert Before Post/No Smart Logic
Universal/Insert Before Post/With Smart Logic

It must be that there’s something with the hooks for the plugin that WordPress is not respecting. I’ll keep digging and let you know what I find.

I am using WordPress 6.0.1. FWIW, shortcodes work just fine.

• This reply was modified 2 years, 3 months ago by mikeytag.

@gripgrip I think I found the culprit. It looks like the cache entry in my database is wrong?

Looking through the code I can see that the plugin tries to cache the snippets in a serialized array with the option_name of wpcode_snippets.

Here’s what my wp_options table looks like for the wpcode_snippets entry:

a:0:{}

That’s obviously not right. There should be something in that array but there isn’t. How do I recreate the cache?

• This reply was modified 2 years, 3 months ago by mikeytag.
• This reply was modified 2 years, 3 months ago by mikeytag.

I see that cache_all_loaded_snippets() is being called on Bulk Operations and when saving an individual snippet. However, neither operation actually fills the cache for me. It’s still an empty array in the db?

• This reply was modified 2 years, 3 months ago by mikeytag.

@gripgrip and @fuego23 I figured it out!

Through much debugging I found the issue. In the file includes/class-wpcode-auto-insert-type.php there is a line like this:
(NOTE: this is line 210 for me but I did a ton of debugging so @gripgrip I’m not sure if that’s the line in production)

$term_id = $location_term->term_id;

In some debug printing I was doing I realized that $location_term->term_id is the incorrect property to grab. Instead, that line should be:

$term_id = $location_term->term_taxonomy_id;

Hope this helps!

Argh, the code formatting here leaves a bit to be desired. @gripgrip here’s that line in the broader context of where it’s used. This is in the load_all_snippets_for_type() method.

// Get the terms that are defined and then assign found snippets to their respective taxonomies
		// so that they can be picked up by id later without having to query again.
		$location_terms = $this->get_location_terms();
		foreach ( $location_terms as $location_key => $location_term ) {
			$term_id                         = $location_term->term_taxonomy_id;
			$this->snippets[ $location_key ] = array();

			// Until we update to PHP 5.3 this is the easiest way to do this.
			foreach ( $snippets as $snippet ) {
				if ( isset( $snippet->term_taxonomy_id ) && absint( $snippet->term_taxonomy_id ) === $term_id ) {
					$this->snippets[ $location_key ][] = new WPCode_Snippet( $snippet );
				}
			}
		}

Hi @mikeytag,

Thank you for digging into this and sharing your findings. I can’t see a way to replicate this issue with a site running WP now but I suspect it can happen if you have been running WP since before terms were unique per taxonomy and the ids got mismatched.

We’ll address this in the next release after running more tests.

Thanks!

That must be it @gripgrip . When I looked at my taxonomies I had multiple entries for terms that wpcode wanted to use. My blog has been in place for over 3 years, so that must be it.

After digging through and debugging this, I can’t shake the idea that everything would be more performant and resilient if WPCode created its own tables instead of overloading wp_posts, wp_terms, wp_term_taxonomy, etc.

Granted, I’m only taking a look under the hood now so I understand if you want to keep using it how it’s currently designed.

• This reply was modified 2 years, 3 months ago by mikeytag.

Oh and if you or any other developers would like SQL dumps of my tables just let me know. I don’t think I can upload them here, but I’d be happy to share them for your dev efforts.

Hi @mikeytag,

Thank you for the update.

If it’s just 3 years the issue is definitely not the one I suspected as the structure for terms has been changed in 2015 so it’s unlikely you were running such an old version at the time.

Are you using any plugin that changes the way taxonomies are stored or extend taxonomies in any way? If you don’t mind sending us a message using the form at https://wpcode.com/suggestions/ any other details (that you don’t want in a public forum) you can share about your setup will definitely help.

Thanks

Thank you so much @mikeytag !

Changing to
$term_id = $location_term->term_taxonomy_id;

did the trick. Everything works fine now.

Thanks again!

@gripgrip I’m not sure if there’s any of my plugins that are messing with taxonomies. I haven’t exactly dug into every one of them. Here’s the list of plugins on my site. Maybe @fuego23 and I have one or more of these in common?

Ad Inserter
Ads.txt Manager
Akismet Anti-Spam
Application Passwords
Comment Whitelist
Contextual Related Posts
GTranslate
Jetpack
My Custom Functions
Post Words Count
Send Images to RSS
Site Kit by Google
Smush Pro
WP AutoTerms
WP Categories Widget
WP Native Articles Premium
WP Rocket
WP Rollback
WPCode – Insert Headers, Footers, and Code Snippets
WPMU DEV Dashboard
Yoast SEO

• This reply was modified 2 years, 3 months ago by mikeytag.

Hi @mikeytag and @fuego23,

Thank you for reporting this issue, the latest release (2.0.2) includes a fix for this issue so after updating you don’t have to make any edits to the plugin.