1

When I hook into {$taxonomy}_edit_form and edited_{$taxonomy} I am getting unexpected results. As you will see at the end - in my "postscript" (written along with these lines a few days after the original posting), I came upon a working solution that addresses my current needs, but I still do not understand why my solution works, but the seemingly more straightforward course does not.

The following code works partly (which is to say it doesn't really work, but fails interestingly/perplexingly):

 $taxes = get_taxonomies() ;

 foreach ( $taxes as $tax ) {

     add_action( $tax . '_edit_form', 'category_edit_form_test' );

 }

 function category_edit_form_test() {

     echo 'edit_form!';

 }

It echoes out "edit_form!" on the category and tag (or 'post_tag' ) edit pages, but NOT on the (custom taxonomy) "series" page.

Note: The $taxes array in this (local development) installation happens to consist of the following:

Array
(
    [category] => category
    [post_tag] => post_tag
    [nav_menu] => nav_menu
    [link_category] => link_category
    [post_format] => post_format
    [series] => series
 )

Now, if I had encountered this situation fresh, I might have guessed that for some unknown and undocumented reason, you can't use the dynamic action hook in this way, or I might have stared at my code going over the simple syntax until I went blind, but I already knew that the following works on the series page and other custom taxonomies, in this example echoing out the "edit_form!" string on the (custom) edit series page, and also echoing out the string on the category page:

$taxes = array( 'category', 'series' ) ;

foreach ( $taxes as $tax ) {

     add_action( $tax . '_edit_form', 'category_edit_form_test' );

}

function category_edit_form_test() {

    echo 'edit_form!';

}

As you can see, the only difference is that I have manually filled in the array instead of returning it from get_taxonomies() ;

I have also tried:

  1. varying priority from 2 to 10000 (no effect)
  2. specifying the number of variables for the function (no difference)
  3. seeing whether the same thing happens with other custom taxonomies (yes)
  4. returning objects rather than names with get_taxonomies() (no effect)
  5. setting '_builtin' > false in the get_taxonomies() $args (just gets rid of the built-ins)
  6. "continuing" the foreach so as to skip each taxonomy that happen to turn up between "post_tag" and "series" (no effect)
  7. mimicking the array assignments returned from get_taxonomies instead of using the simpler format shown above (no effect) (see initial comments for further discussion re a related $key => $value alternative)
  8. directly copying as well as specifically adapting the sample code from the Codex on outputting taxonomy names. See get_taxonomies() (no difference)

As maybe you can also see, I was getting a little desperate! At this point I'm afraid it's something so crushingly simple I will forever hang my head in shame. Any ideas what I'm missing or what ought to work? For your further reference, here's where you can find the action hook: wp-admin/edit-tag-form.php (line 261)

Post-Script

I considered posting the working solution that I am about to present as an answer to my own question, but I still remain at a loss as to why the original, obvious solution does not work, yet this one does.

To review, the array returned by get_taxonomies() produces differentiated results when used as the basis for a foreach loop of actions. It works as expected with the built-in editable taxonomies - categories and tags - but not with an editable taxonomy, even though the same editable taxonomy - "series" in my example - is accepted by the action hook in question when provided either directly or as a string from a manufactured array. See above for details.

What finally solves this problem for my purposes - a plug-in I'm developing - is to add an option whose default is set to the very same array returned from get_taxonomies().

So, under a set_default_options function:

$taxes_arr = get_taxonomies() ;

add_option( 'my_plugin_tax_option', $taxes_arr ) ;

I can then apply the following within the class's __construct() function:

$taxes_arr = get_option('my_plugin_tax_option') ;

foreach ( $taxes_arr as $tax_name ) {

   add_action( $tax_name . '_edit_form', array( &$this, 'taxonomy_edit_form' ), 10, 2 ) ;
   add_action( 'edited_' .  $tax_name, array( &$this, 'edited_taxonomy' ) ) ;

}

I'll stress that the examples I previously provided of attempts to work directly with the array returned by get_taxonomies() were only a few of many. For some reason, passing it through the options table produces a workable solution. I suspect an alternative might be to pass the array via a hidden input on the plug-in's settings page, but that strikes me as even more roundabout.

I still wish I understood why this method works, but the more straightforward one doesn't.

  • At first glance, there's a difference between the two arrays where get_taxonomies is an array of key => value arguments and your testing array isn't. Have you tried modifying your foreach loop to account for that? foreach ($arr as $key => $value) – Jami Gibbs Dec 28 '16 at 22:39
  • That's kind of what I meant under #7 - though I originally went about it by creating an array that more or less exactly re-produced the array returned (or kind-of-returned) by get_taxonomies(). I've now also run tests using a $key => $value statement. Same split results (category: good vs series/custom: bad). Give the peculiar nature of the array, it works/doesn't work in the same way whether you apply the $key or the $value in the action hook. – CK MacLeod Dec 29 '16 at 0:43
  • @JamiGibbs: Note postscript with mysterious working solution. – CK MacLeod Jan 1 '17 at 20:42

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Browse other questions tagged or ask your own question.