#35914 closed defect (bug) (fixed)
Prevent exporting a partial for selective refresh when user can't preview its settings
Reported by: | westonruter | Owned by: | westonruter |
---|---|---|---|
Milestone: | 4.5 | Priority: | normal |
Severity: | normal | Version: | 4.6 |
Component: | Customize | Keywords: | has-patch has-unit-tests commit |
Focuses: | Cc: |
Description
When partials get registered, they are associated with one or more settings, just as controls do. Controls are prevented from being exported to the client if they are associated with any settings that the user doesn't have the capability to update. At the moment, however, partials do not have parity with controls in this way: partials are being exported to the client even if the user cannot make any changes to them. This results in misleading “Shift-click to edit this element.” messages for such users.
So WP_Customize_Partial::check_capabilities()
should be created for parity with WP_Customize_Control::check_capabilities()
. Partials that don't pass the capability check can be omitted from being exported to the client. These partials can also be rejected from requests to render partials. While these are currently not rejected, they can only be previewed using settings already saved in the DB, since setting changes will be ignored if the user doesn't have the capability: these are currently treated as read-only partial renders.
@westonruter 35914.1.diff Looks good. One thing on the DocBlock for the
check_capabilities()
method, the return type should just befalse
if the return is always false.