Make WordPress Core

Opened 2 years ago

Closed 17 months ago

Last modified 17 months ago

#57596 closed enhancement (fixed)

Categories/Tags: Quick Edit contents should only be rendered if quick edit is in actions after filtering.

Reported by: costdev's profile costdev Owned by: sergeybiryukov's profile SergeyBiryukov
Milestone: 6.4 Priority: normal
Severity: normal Version: 3.0.4
Component: Quick/Bulk Edit Keywords: has-testing-info
Focuses: Cc:

Description (last modified by costdev)

This is a follow-up to #16502.

Overview

Despite Quick Edit being removed from the available actions, a class="inline_<id>" div is still rendered on the Posts > Categories and Posts > Tags screens.

To prevent the div from rendering, this code (Ref 1) must be rendered only if the $actions array includes the inline hide-if-no-js key.


The Problem

The $actions array is currently created in the ::handle_row_actions() method of WP_Terms_List_Table. This method returns an HTML string, not an array.


Possible Solution 1

We could check the return value of ::handle_row_actions() to see if it includes a substring, such as editinline, using str_contains(). However, this isn't a particularly clean solution, and is easily prone to regressions.

Possible Solution 2

We could abstract this entire portion (Ref 2) of the ::handle_row_actions() method to a new method that returns array $actions.

This new method would be called in ::handle_row_actions() to retain existing functionality, as well as in ::column_name:

$actions = $this->get_row_actions();
if ( isset( $actions['inline hide-if-no-js'] ) ) {
    // The code from (Ref 1)
}

I'm adding 2nd-opinion to gather thoughts on these possible solutions, and to explore other solutions you may have.


Reproduction/Testing Instructions

Steps to Reproduce or Test

  1. Create a new file wp-content/plugins/test-quick-edit-removal.php with the following contents:
    <?php
    /**
     * Plugin Name: Test Quick Edit Removal
     * Description: Tests the removal of Quick Edit Contents.
     * Author:      WordPress Core Contributors
     * Author URI:  https://make.wordpress.org/core
     * License:     GPLv2 or later
     * Version:     1.0.0
     */
    
    add_action( 'admin_bar_menu', 'test_qer_adminbar', 999 );
    add_filter( 'tag_row_actions', 'test_qer_hide_quick_edit', 10, 1 );
    
    function test_qer_adminbar( $wp_admin_bar ) {
            global $pagenow;
            $action = empty( $_GET['hide_quick_edit'] ) ? '1' : '0';
            $url    = add_query_arg( array_merge( $_GET, array( 'hide_quick_edit' => $action ) ), admin_url( $pagenow ) );
            $wp_admin_bar->add_node( array( 'id' => 'test-qer', 'title' => $action ? 'Remove Quick Edit' : 'Add Quick Edit', 'href' => $url ) );
    }
    
    function test_qer_hide_quick_edit( $actions ) {
            if ( isset( $_GET['hide_quick_edit'] ) && '1' === $_GET['hide_quick_edit'] ) unset( $actions['inline hide-if-no-js'] );
            return $actions;
    }
    
  2. Navigate to Plugins > Installed Plugins and activate Test Quick Edit Removal.
  3. Navigate to Posts > Categories.
  4. Open DevTools and inspect a category's title.
  5. Below the category's title <strong> markup, there will be <div class="hidden" id="inline_XXXX"> element.
  6. In the admin bar, click "Remove Quick Edit".
  7. 🐞 Repeat steps 4-5.
  8. Click "Add Quick Edit".
  9. Apply a patch.
  10. ✅ Repeat steps 3-7.
  11. Repeat steps 3-10 for Posts > Tags.

Expected Results

When reproducing a bug:

  • ❌ The hidden "inline_XXXX" element should exist even though "Quick Edit" is removed.

When testing a patch to validate it works as expected:

  • ✅ The element should no longer exist when "Quick Edit" is removed.

Change History (6)

#1 @costdev
2 years ago

  • Description modified (diff)

#2 @webcommsat
2 years ago

This ticket needs testing and alternative solutions/ views on solution proposed. Thanks to @costdev for separating this from the original ticket, and adding a solution and testing information.

This ticket was mentioned in Slack in #core by abhanonstopnews. View the logs.


2 years ago

#4 @SergeyBiryukov
18 months ago

Note: An alternative approach with a new filter is suggested in comment:54:ticket:16502.

#5 @SergeyBiryukov
17 months ago

  • Owner set to SergeyBiryukov
  • Resolution set to fixed
  • Status changed from new to closed

In 56611:

Quick Edit: Allow Quick Edit to be disabled for custom post types or taxonomies.

Some custom post types or taxonomies may not need the Quick Edit functionality, in which case adding hidden fields and rendering the form with the data to edit would be redundant.

This commit introduces two filters for more granular control:

  • quick_edit_enabled_for_post_type
  • quick_edit_enabled_for_taxonomy

Follow-up to [8857], [9083], [9098].

Props garyc40, sabernhardt, mukesh27, costdev, oglekler, wyrfel, peterwilsoncc, faguni22, robinwpdeveloper, webcommsat, johnbillion, azaozz, hellofromTonya, GunGeekATX, Jick, mikeschinkel, jane, nacin, helen, wonderboymusic, DrewAPicture, SergeyBiryukov.
Fixes #16502, #19343, #57596.

#6 @SergeyBiryukov
17 months ago

  • Keywords needs-patch needs-testing 2nd-opinion removed
  • Milestone changed from Awaiting Review to 6.4
Note: See TracTickets for help on using tickets.