[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