WordPress.org

Make WordPress Core

Opened 19 months ago

Last modified 19 months ago

#44849 reopened defect (bug)

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

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

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 19 months ago.
Test case

Download all attachments as: .zip

Change History (6)

#1 @SergeyBiryukov
19 months ago

  • Component changed from Administration to Taxonomy
  • Focuses administration added

#2 @sugavinc
19 months ago

  • Resolution set to duplicate
  • Status changed from new to closed

Duplicate of #44847.

#3 @wallfur
19 months ago

  • Resolution duplicate deleted
  • Status changed from closed to 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
19 months 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 19 months ago by wallfur (previous) (diff)

@wallfur
19 months ago

Test case

#5 @wallfur
19 months ago

  • Severity changed from minor to 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.