Make WordPress Core

Opened 8 years ago

Last modified 8 years ago

#44849 reopened defect (bug)

Post type parameter not preserved when editing/deleting custom taxonomy term

Reported by: wallfur Owned by:
Priority: normal Milestone: Awaiting Review
Component: Taxonomy Version: 4.9.8
Severity: normal Keywords:
Cc: Focuses: administration

Description

I get linked or redirected back to the Posts area in the admin menu after editing or deleting a custom taxonomy rather to the custom post type for which I registered the taxonomy.

Steps:

  1. Plugin registers custom post type then custom taxonomy
  2. Visit custom taxonomy page via automatically generated link in admin menu: ​https://foo.example/wp-admin/edit-tags.php?taxonomy=CUSTOMTAX&post_type=CUSTOMPOST (custom post type section of admin menu is highlighted and open)
  3. Add a term (term is added to the table at right)
  4. Click term's name to open full edit page; delete link and form have no reference to the post_type that is in the URL of the current edit page.
  5. Editing/deleting the term works, but afterwards I'm back at the terms list page in the context of Posts, not my custom post type.

I can maintain the context, when editing, with this code:

add_action(
    CUSTOMTAX . '_term_edit_form_top'
    , function() {
        ?><input type=hidden name=post_type value=<?= CUSTOMPOST ?>><?php
    }
);

I tried correcting the delete URL, and it got the parameter but the final redirect was missing it, thus the Posts submenu was open again:

add_filter(
    'admin_url'
    , function($url) {
        return preg_replace(
            '#/edit-tags\\.php\\?action=delete&(?:amp;)?taxonomy='. CUSTOMTAX . '(?=&)#'
            , '$0&post_type=' . CUSTOMPOST
            , $url
        );
    }
);

Attachments (1)

test.php​ (908 bytes ) - added by wallfur 8 years ago.
Test case

Download all attachments as: .zip

Change History (6)

#1 @SergeyBiryukov
8 years ago

  • Component Administration → Taxonomy
  • Focuses administration added

#2 @anonymized_16373709
8 years ago

  • Resolution → duplicate
  • Status new → closed

Duplicate of #44847.

#3 @wallfur
8 years ago

  • Resolution duplicate
  • Status closed → reopened

@sugavinc I think you've made a mistake, this has nothing to do with front-end, nor permalinks.

Simplest example: when I delete a term via a link like ​https://foo.example/wp-admin/edit-tags.php?action=delete&taxonomy=CUSTOMTAX&post_type=CUSTOMPOST&tag_ID=N&_wpnonce=HEXDIGITS I am redirected to ​https://foo.example/wp-admin/edit-tags.php?taxonomy=CUSTOMTAX, no post_type parameter and wrong admin submenu visible.

#4 @wallfur
8 years ago

Even with the admin_url filter in place, after deleting a term, I get redirected to ​https://foo.example/wp-admin/term.php?taxonomy=CUSTOMTAX&post_type=CUSTOMPOST&wp_http_referer=%2Fwp-admin%2Fedit-tags.php%3Ftaxonomy%3DCUSTOMTAX%26post_type%3DCUSTOMPOST&message=2 (not sure why to term.php) but it redirects again to the URL missing the post type ​https://foo.example/wp-admin/edit-tags.php?taxonomy=CUSTOMTAX.

I feel I'm missing something obvious, but the custom post type & taxonomy are so simple.

Last edited 8 years ago by wallfur (previous) (diff)

@wallfur
8 years ago

Test case

#5 @wallfur
8 years ago

  • Severity minor → normal

I left the hidden input in the form, which ensures the link shown after saving a change goes back to the correct terms page.

I have worked around the context loss from the delete link on that page by passing the referrer along to the link. This also reinstated the "Item deleted" message, so I'm fairly sure it's a genuine bug.

add_filter(
        'admin_url'
        , function($url) {
                if (empty($_REQUEST['wp_http_referer'])) {
                        return $url;
                }
                return preg_replace(
                        '#^[^?]+/edit-tags\\.php\\?action=delete&(amp;)?taxonomy=CUSTOMTAX(?:&.*)?$#'
                        , '$0&${1}_wp_http_referer=' . rawurlencode(stripslashes($_REQUEST['wp_http_referer']))
                        , $url
                );
        }
);
Note: See TracTickets for help on using tickets.