[wp-trac] [WordPress Trac] #16502: Quick Edit contents should only be rendered if quick edit button in actions after filtering
WordPress Trac
noreply at wordpress.org
Fri Aug 18 11:02:53 UTC 2023
#16502: Quick Edit contents should only be rendered if quick edit button in actions
after filtering
-----------------------------------+------------------------
Reporter: wyrfel | Owner: chriscct7
Type: enhancement | Status: reviewing
Priority: normal | Milestone: 6.4
Component: Quick/Bulk Edit | Version: 3.0.4
Severity: normal | Resolution:
Keywords: has-patch 2nd-opinion | Focuses:
-----------------------------------+------------------------
Changes (by SergeyBiryukov):
* keywords: dev-feedback 2nd-opinion changes-requested => has-patch 2nd-
opinion
* milestone: Future Release => 6.4
Comment:
Replying to [comment:50 azaozz]:
> Having some doubts about this patch. It effectively disables one of the
WordPress features: Quick Edit. As far as I know this feature is not used
very often, but is quite helpful for Editors on sites with many
users/authors.
>
> The disabling is done indirectly, by "piggybacking" on other/existing
methods. Don't think this is a good way to disable a feature. A better way
would be to have a filter where extenders will be able to disable it
directly.
>
> In addition the current code may introduce bugs/regressions in plugins
that replace the "Quick Edit" action link with another method of showing
the UI, or reuse the quick edit data in some way.
Indeed, removing `$actions['inline hide-if-no-js']` via the
`post_row_actions` filter seems like a hacky way to disable the Quick
Edit functionality.
Looking at the current PR, moving the `get_inline_data()` call to the
`handle_row_actions()` method does not seem ideal either, because the
former displays the markup directly, while the latter is supposed to
return the result as a string and should not display anything.
[attachment:"16502.2.diff"] introduces two new filters to address both
this ticket and #57596:
* `quick_edit_enabled_for_post_type`
* `quick_edit_enabled_for_taxonomy`
That seems like a cleaner way to do this, and should also resolve the
backward compatibility concerns.
--
Ticket URL: <https://core.trac.wordpress.org/ticket/16502#comment:54>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform
More information about the wp-trac
mailing list