#51872 closed defect (bug) (fixed)
Registering a custom taxonomy with `show_in_quick_edit` set to 'false' makes the whole Quick Edit UI to not show up
Reported by: | _luigi | Owned by: | azaozz |
---|---|---|---|
Milestone: | 5.6 | Priority: | high |
Severity: | normal | Version: | 5.6 |
Component: | Quick/Bulk Edit | Keywords: | has-patch needs-testing commit dev-reviewed |
Focuses: | ui, administration | Cc: |
Description
When a custom taxonomy, either public or private, is registered with show_ui = true
and show_in_quick_edit = false
as arguments, and the user, in the edit.php
screen, clicks on a 'Quick edit' link for a (Custom) Post to which the custom taxonomy has been associated, the whole row that contains the 'Quick edit' link disappears and the following error pops up in the JavaScript console:
Uncaught TypeError: Cannot set property '_renderItem' of undefined at jQuery.fn.init.$.fn.wpTagsSuggest (tags-suggest.js?ver=5.6-RC1-49690:151) at HTMLDivElement.<anonymous> (inline-edit-post.js?ver=5.6-RC1-49690:342) at Function.each (jquery.js?ver=3.5.1:381) at jQuery.fn.init.each (jquery.js?ver=3.5.1:203) at Object.edit (inline-edit-post.js?ver=5.6-RC1-49690:326) at HTMLButtonElement.<anonymous> (inline-edit-post.js?ver=5.6-RC1-49690:128) at HTMLTableSectionElement.dispatch (jquery.js?ver=3.5.1:5429) at HTMLTableSectionElement.elemData.handle (jquery.js?ver=3.5.1:5233)
As a result the Quick Edit UI doesn't show up.
The test code I have used to register the custom taxonomy is the following:
$arguments = array( 'public' => false, 'show_ui' => true, 'show_admin_column' => true, 'show_in_quick_edit' => false ); register_taxonomy( 'page_tag', 'page', $arguments );
The snippet of code has been executed from the functions.php
file of the TwentyTwentyOne Theme with no plugin active. I have used WordPress 5.6-RC1-49690 to run the test.
Attachments (2)
Change History (22)
#2
@
4 years ago
Hello @_luigi,
Thank you for submitting this ticket. I can also confirm that the issue. Also just to add a note, the issue isn't happening if 'hierarchical' => true,
.
This ticket was mentioned in Slack in #core by hellofromtonya. View the logs.
4 years ago
This ticket was mentioned in PR #771 on WordPress/wordpress-develop by donmhico.
4 years ago
#4
- Keywords has-patch added; needs-patch removed
Taxonomies registered with
{{{php
$args = [
'show_in_quick_edit' => false,
'hierarchical' => false,
];
}}}
are causing the Post row in edit.php
disappear when Quick Edit is clicked. And the console is throwing out
Uncaught TypeError: n.on(...).autocomplete(...).autocomplete(...) is undefined wpTagsSuggest http://localhost/wp56/wp-admin/js/tags-suggest.min.js?ver=5.6-RC1-49690:2 edit http://localhost/wp56/wp-admin/js/inline-edit-post.min.js?ver=5.6-RC1-49690:2 jQuery 2 each each edit http://localhost/wp56/wp-admin/js/inline-edit-post.min.js?ver=5.6-RC1-49690:2 init http://localhost/wp56/wp-admin/js/inline-edit-post.min.js?ver=5.6-RC1-49690:2 jQuery 2 dispatch handle tags-suggest.min.js:2:1507
It seems that the <textarea>
which invokes wpTagsSuggest()
is non-existent to the taxonomies created with the $args
above. This PR just make sure that the <textarea>
exists before invoking wpTagsSuggest()
.
Trac ticket: https://core.trac.wordpress.org/ticket/51872
#5
@
4 years ago
Yep, can reproduce. Seems to be a change in UI 1.12.1 (as stated above). The line:
jQuery( '#nonexisting' ).autocomplete().autocomplete( 'instance' );
returns Object { context: HTMLDocument... }
in UI 1.11.4, but returns undefined
in 1.12.1.
The fix in https://github.com/WordPress/wordpress-develop/pull/771 looks good but thinking this should also be fixed in tags-suggest.js
. Patch coming up.
#6
@
4 years ago
- Keywords needs-testing added
- Priority changed from normal to high
- Severity changed from major to normal
In 51872.diff:
- Do not initialize
wpTagsSuggest
if a textarea doesn't exist ininline-edit-post.js
(Quick Edit). - Ensure the element exists before initializing UI Autocomplete in
tags-suggest.js
.
#7
@
4 years ago
On second thought, this will be easier to test if it is in trunk. Seems to be working well here. Going to commit it for that reason, please feel free to tweak/change as needed.
#8
@
4 years ago
- Owner set to azaozz
- Resolution set to fixed
- Status changed from new to closed
In 49703:
#9
follow-up:
↓ 10
@
4 years ago
- Keywords 2nd-opinion added
- Resolution fixed deleted
- Status changed from closed to reopened
Reopen for the 5.6 branch.
#10
in reply to:
↑ 9
;
follow-up:
↓ 11
@
4 years ago
- Keywords commit dev-reviewed added; 2nd-opinion removed
Replying to azaozz:
Reopen for the 5.6 branch.
[49703] looks good to backport.
Hint: If you add the dev-feedback
keyword instead of 2nd-opinion
, the ticket will show up in "Commit Candidates which need Dev Review" section on Next Major Release, Workflow Oriented report :)
#11
in reply to:
↑ 10
@
4 years ago
Replying to SergeyBiryukov:
If you add the
dev-feedback
keyword instead of2nd-opinion
...
Uh, right, that's what I meant to add. Guess getting too tired :)
#12
@
4 years ago
Looking at the patch again, for completeness it seems better to negate the check whether the autocomplete instance exists (currently it seems it always would, but that may change in the future or there might be edge cases where initializing autocomplete may fail).
#13
@
4 years ago
In 51872.2.diff (follow up to [49703]):
- Return early if the autocomplete instance doesn't exist.
- Always return
this
(the jQuery object).
This ticket was mentioned in Slack in #core by azaozz. View the logs.
4 years ago
#16
@
4 years ago
- Keywords dev-feedback added; dev-reviewed removed
- Resolution fixed deleted
- Status changed from closed to reopened
Reopen for the 5.6 branch.
Adding dev-feedback
again as there's a little bit more to review.
#17
@
4 years ago
- Keywords dev-reviewed added; dev-feedback removed
Replying to azaozz:
Looking at the patch again, for completeness it seems better to negate the check whether the autocomplete instance exists (currently it seems it always would, but that may change in the future or there might be edge cases where initializing autocomplete may fail).
Makes sense, also good catch on always returning the jQuery object :)
This ticket was mentioned in Slack in #core by hellofromtonya. View the logs.
4 years ago
hellofromtonya commented on PR #771:
4 years ago
#20
Merged in changeset https://core.trac.wordpress.org/changeset/49703
This is a new problem in 5.6.
I tried that snippet in the Twenty Twenty functions.php and received a different JS error in Firefox: