Make WordPress Core

Changes between Initial Version and Version 1 of Ticket #35451


Ignore:
Timestamp:
01/14/2016 12:01:27 AM (9 years ago)
Author:
westonruter
Comment:

@mattwiebe: So are you saying that a sanitize callback is actually doing a write operation on the value for another setting, or rather here the setting root? If so, then I would say this would be a bad practice since as far as I see it, the sanitize should be a read-only operation. I'd suggest a better approach to be to hook into the customize_save_after action, like this:

<?php
$wp_customize->add_setting( 'custom_colors[colors]', array(
        'type' => 'option',
        'default' => array(),
        'sanitize_callback' => function( $colors ) { /* ... */ return $colors; },
) );

add_action( 'customize_save_after', function ( $wp_customize ) {
        $is_colors_changed = array_key_exists( 
                'custom_colors[colors]', 
                $wp_customize->unsanitized_post_values() 
        );
        if ( $is_colors_changed ) {
                // update the CSS used to output colors
                $opts = get_option( 'custom_colors', array() );
                $opts['css'] = wpcom_create_css_for_colors( $colors );
                update_option( 'custom_colors', $opts );
        }
} );

Legend:

Unmodified
Added
Removed
Modified
  • Ticket #35451

    • Property Keywords reporter-feedback added
  • Ticket #35451 – Description

    initial v1  
    114.4's aggregated multidimensional settings naïvely assumes that no other code will touch the root setting, but that's not necessarily true. Here's some pseudo code from WP.com:
    22
    3 {{{
     3{{{#!php
     4<?php
    45$wp_customize->add_setting( 'custom_colors[colors]', array(
    56  'sanitize_callback' => 'wpcom_sanitize_colors'