WordPress.org

Make WordPress Core

Opened 4 months ago

Last modified 6 weeks ago

#51093 new defect (bug)

Custom CSS output runs through the wrong filter for custom user role

Reported by: kittmedia Owned by:
Milestone: Future Release Priority: normal
Severity: normal Version: 5.4.1
Component: Customize Keywords: needs-patch
Focuses: Cc:

Description

I added a custom user role, which is able to see the Custom CSS in the Customizer. As soon as a user with such a role publishes the Customizer settings, the Custom CSS gets filtered through the wrong filter. This wasn’t the case in WordPress < 5.5 and is a new issue.

My created user role:

<?php
function add_custom_role() {
        add_role(
                'custom',
                esc_html__( 'Custom' ),
                array(
                        'update_core' => false,
                        'update_plugins' => false,
                        'update_themes' => false,
                        'activate_plugins' => false,
                        'edit_plugins' => false,
                        'edit_themes' => false,
                        'delete_plugins' => false,
                        'delete_themes' => false,
                        'switch_themes' => false,
                        'create_users' => false,
                        'edit_users' => false,
                        'delete_users' => true,
                        'edit_files' => true,
                        'edit_theme_options' => true,
                        'export' => false,
                        'import' => true,
                        'list_users' => true,
                        'manage_options' => true,
                        'remove_users' => true,
                        'edit_dashboard' => true,
                        'customize' => true,
                        'unfiltered_html' => true,
                        'delete_others_pages' => true,
                        'delete_others_posts' => true,
                        'delete_pages' => true,
                        'delete_posts' => true,
                        'delete_private_pages' => true,
                        'delete_private_posts' => true,
                        'delete_published_pages' => true,
                        'delete_published_posts' => true,
                        'edit_others_pages' => true,
                        'edit_others_posts' => true,
                        'edit_pages' => true,
                        'edit_posts' => true,
                        'edit_private_pages' => true,
                        'edit_private_posts' => true,
                        'edit_published_pages' => true,
                        'edit_published_posts' => true,
                        'manage_categories' => true,
                        'moderate_comments' => true,
                        'publish_pages' => true,
                        'publish_posts' => true,
                        'read' => true,
                        'read_private_pages' => true,
                        'read_private_posts' => true,
                        'upload_files' => true,
                        'copy_posts' => true,
                )
        );
}

add_action( 'init', 'add_custom_role' );

Tested CSS:

body > a {
color: #fff;
}

Actually CSS output:

body &lt;
a {
color: #fff;
}

The data is stored correctly in the database, so it doesn’t seem to be a problem during the save function but rather during the output.

Tested with WordPress 5.5 and Twenty Seventeen theme.

Change History (10)

#1 @SergeyBiryukov
4 months ago

  • Milestone changed from Awaiting Review to 5.5.1

Hi there, welcome back to WordPress Trac! Thanks for the report.

Moving to 5.5.1 for investigation.

This ticket was mentioned in Slack in #themereview by joyously. View the logs.


4 months ago

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


4 months ago

#4 @khag7
4 months ago

I'm having trouble reproducing.

  • Clean install WordPress 5.5
  • Change to Twenty Seventeen Theme
  • Created new user "bob"
  • Used the code snippet you provided (put it in theme functions.php just to get it going)
  • Made bob's user role "custom" (I installed the "Members" plugin to achieve this)
  • Logged out of admin, logged into bob
  • Bob went to customizer, added custom css: body > a { background: blue; }
  • All links show in customizer preview with a blue background. Also shows same on front end

If I'm misunderstanding the issue please point me in the right direction.
Have you experienced this on a clean install of 5.5 with no plugins?

#5 @kittmedia
3 months ago

You did all right! I missed some details, sorry for that …

On a single site installation, it works fine as you also discovered. I can reproduce it in a clean multisite installation. To see the Custom CSS in the Customizer as “bob” you need to re-map the capability:

<?php
function map_css_cap( $caps, $cap ) {
        if ( 'edit_css' === $cap && is_multisite() ) {
                $caps = array( 'import' );
        }
        return $caps;
}

add_filter( 'map_meta_cap', 'map_css_cap', 20, 2 );

If you then re-do what you did on the single site installation, it should produce the wrong CSS.

#6 @dlh
3 months ago

  • Keywords needs-patch added
  • Version changed from 5.5 to 5.4.1

Introduced, I think, in [47633] for 5.4.1. My untested guess is that this issue occurs because KSES is no longer suspended when writing the custom_css post upon publishing the Customizer changeset.

#7 @khag7
3 months ago

I'm starting to get the impression this has something to do with two capabilities: edit_css and unfiltered_html. Testing is needed to determine what happens if a user has one but not the other. Also we need to confirm behavior should be the same in boths single site and multi site.

I think what is happening (untested) is that if a user does not have the unfiltered_html capability, then the CSS output gets run through KSES. Probably what should happen is because the user does have the edit_css capability, then KSES should not run on the custom css regardless if the user has unfiltered_html or not.

#8 @audrasjb
3 months ago

  • Milestone changed from 5.5.1 to 5.6

Moving to milestone 5.6 as we are close to release 5.5.1 RC.
Also, this issue was introduced in 5.4.1.

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


6 weeks ago

#10 @hellofromTonya
6 weeks ago

  • Milestone changed from 5.6 to Future Release

From today's 5.6 core scrub, Sergey notes:

Yeah, still needs a patch and more testing.
At this point, should probably be moved to Future Release.

Moving this ticket to Future Release. If any maintainer or committer feels this can be resolved in time, or wishes to assume ownership during a specific cycle, feel free to update the milestone accordingly.

Note: See TracTickets for help on using tickets.