Pods: Yoast SEO plugin

Created on 30 Dec 2013  ·  18Comments  ·  Source: pods-framework/pods

SEO title & desc don't get saved
https://github.com/Yoast/wordpress-seo/issues/508

Integration Inactive Puntable Help Wanted Researched Bug

All 18 comments

in Yoast SEO issue you can read:

I guess that confirms that it's an issue with the Pods plugin, not with WP SEO.

Maybe inappropriate time of register_taxonomy()?

debug: WPSEO_Taxonomy class' update_term() function is registered in WP's do_action()'s $wp_filter
but does not get called

when saving to a custom taxonomy defined by Pods
PodsMeta's save_taxonomy() get called TWICE

debug: WPSEO_Taxonomy class' update_term() function is registered in WP's do_action()'s $wp_filter
but does not get called

Have you determine at what point (timing-wise) they hook the action?

At 'init' time.
Both are registered in WP's do_action()
but somehow in wp-includes/plugin.php:429 PodsMeta's save_taxonomy() gets called TWICE
and WPSEO_Taxonomy class' update_term() is left out.

Maybe pods_no_conflict_on() causes it?

but somehow in wp-includes/plugin.php:429 PodsMeta's save_taxonomy() gets called TWICE

I'll see if I can find out what's causing this particular behavior and if it's related.

Thank you very much! I see you know both plugins.

What we have here is a tricky WordPress bug: http://core.trac.wordpress.org/ticket/17817 Your leg-work saved me a lot of time I might have spent poking in unrelated areas. This was weird enough to troubleshoot as it is so that was incredibly helpful.

As you may have found, you can comment out the call to pods_no_conflict_on and the issue no longer manifests. We've wrapped Pods::save with the no conflict calls to avoid recursive action calls that might otherwise happen through save(). Due to the WordPress bug, however, when we remove our action hooks it also takes any other lower priority action hooks with it. You can re-create this situation on your own in a child theme or plugin with the following code:

add_action( 'edit_term', 'test_17817', 15, 3 );
function test_17817( $term_id, $tt_id, $taxonomy ) {
    remove_action( 'edit_term', 'test_17817', 15 );
}

I've chosen 15 as the priority for this test since it falls between Pods' priority of 10 and Yoast's 99. With that code in a child-theme functions.php and the Pods no conflict calls commented out the issue still manifests.

On the Yoast side, you can also clear up the issue by changing the 99 priority of the add_action call to 10 or less.

Also in my simplified testing you can add an action of your own (the callback function itself can just be an empty function) with a priority between Pods and Yoast and the issue will clear up.

We're still putting our heads together on this one because it has a wider impact for WordPress content types in general, and we're deeply involved in that arena.

BTW, none of that information is a suggested fix at this point. This is just details of the bug and how it manifests.

this is suitable fix for me:

add_action( 'edit_term', 'test_17817', 15, 3 );
function test_17817( $term_id, $tt_id, $taxonomy ) {
    // http://core.trac.wordpress.org/ticket/17817
    remove_action( 'edit_term', 'test_17817', 15 );
}

Thank you very much.
I do not understand WP and coding enough, I am a debugger.

I would take the remove_action out of the function body and just leave the function empty. The remove_action call there was to illustrate how you can make the bug manifest without Pods causing it. Having that in there may potentially complicate matters for you in the future.

I think it's also good to document here that the process we were using here is actually what's recommended by WordPress core (though, on a different action):

http://codex.wordpress.org/Plugin_API/Action_Reference/save_post#Avoiding_infinite_loops

Excuse me.
Why to hook edit_term when there are no extra fields for the custom taxonomy?

I'm not sure if there is a functional explanation behind that, or if it's simply "that's how it was initially written". A good question that's probably worth a new issue for 3.0 optimization considerations: not hooking things we can determine we don't need to hook at the time.

Is this issue still active?

Will Pods v3 (repeater field) be ever released?

@szepeviktor That seems unrelated to this topic.
In any case, first release will be 2.8 (group fields + full refactor of Pods admin).
For 2.9 repeatable fields, see: #1095
For 3.0 loop fields, see: #1095

Back on topic, I tried to reproduce this and this doesn't seem to be an active issue anymore (would've noticed that as I use Yoast SEO on several projects as well).

Was this page helpful?
0 / 5 - 0 ratings

Related issues

pdewouters picture pdewouters  ·  7Comments

AlexDeat picture AlexDeat  ·  3Comments

HmCody picture HmCody  ·  4Comments

sundco picture sundco  ·  5Comments

jcampbell05 picture jcampbell05  ·  5Comments