[wp-trac] [WordPress Trac] #29251: Redirect URL of "Edit <term>" from frontend is wrong.

WordPress Trac noreply at wordpress.org
Tue Apr 21 13:52:25 UTC 2015


#29251: Redirect URL of "Edit <term>" from frontend is wrong.
--------------------------+-----------------------------
 Reporter:  DzeryCZ       |       Owner:  boonebgorges
     Type:  defect (bug)  |      Status:  closed
 Priority:  normal        |   Milestone:  4.2
Component:  Taxonomy      |     Version:  3.9.2
 Severity:  normal        |  Resolution:  fixed
 Keywords:  has-patch     |     Focuses:  administration
--------------------------+-----------------------------

Comment (by boonebgorges):

 Replying to [comment:8 nacin]:
 > We don't support a taxonomy to have multiple object types unless they
 are all post types (all or none), so there isn't a concern of ambiguity,
 just perhaps something with a user taxonomy...

 By "we don't support" I assume you mean that plugin authors need to do
 their own 'update_count_callback' logic and stuff like that. I don't see
 anywhere where we enforce all-or-none.

 > @boonebgorges: Minor point, I wonder how this previously behaved when an
 object type is not a post type. (Say, a user or a link.)

 Yeah, I'd overlooked this. A more general fix is
 [attachment:29251.2.patch] - your suggestions assume the all-or-none
 enforcement you suggest above, and will miss a post-type object_type if
 it's not the first in the list. As for whether this needs to be fixed
 right now: The clause in question is only called when `$object_type` is
 not passed to `get_edit_term_link()`. In core, this only happens when
 generating the admin bar link, and this admin bar link only appears in
 term archives, which aren't natively supported for objects other than post
 types. So it'd only be an issue in plugins.

 And even there, if 'post_type=foo' is included in the URL, it'll be
 ignored if 'foo' is not a post type, and the 'Posts' menu will be
 highlighted on edit-tags.php. This is the same as what happens when no
 'post_type' qv is provided, which means that the only change in behavior
 between 4.1 and 4.2 is the appearance of the QV in the URL.

 My suggestion is to fix this for 4.3 as part of a separate ticket, but 4.2
 is fine too if you think it important and you've reviewed the patch.

--
Ticket URL: <https://core.trac.wordpress.org/ticket/29251#comment:10>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform


More information about the wp-trac mailing list