[wp-trac] [WordPress Trac] #30448: Customizer Manager/Settings classes do not provide public save method to use outside of customize.php

WordPress Trac noreply at wordpress.org
Mon Jan 12 05:18:19 UTC 2015


#30448: Customizer Manager/Settings classes do not provide public save method to
use outside of customize.php
-------------------------+------------------------------
 Reporter:  CrazyJaco    |       Owner:
     Type:  enhancement  |      Status:  new
 Priority:  normal       |   Milestone:  Awaiting Review
Component:  Customize    |     Version:  4.0
 Severity:  normal       |  Resolution:
 Keywords:  has-patch    |     Focuses:
-------------------------+------------------------------

Comment (by westonruter):

 For the work I've been doing on #30937 for Customizer Transactions, I've
 also ended up modifying the `WP_Customize_Setting::save()` method:
 https://github.com/xwp/wordpress-develop/pull/61/files#diff-
 8582bb972a2a8283eebe2050f95f3c19L170

 In my change, the settings are pre-saved in the transaction and the
 transaction does a capability check itself to ensure that the user is
 authorized to update the setting before storing the value in the
 transaction: https://github.com/xwp/wordpress-develop/pull/61/files#diff-
 4fb8a477f559bdfad2c1e6db6d1c8b06R999

 If my patch were to be applied, then the way you could programmatically
 update a setting would be:

 {{{#!php
 <?php
 $setting = new WP_Customize_Setting( 'whatever_the_setting_name_is', $args
 );
 $value = get_value_from_wherever();
 $wp_customize->transaction->set( $setting, $value );
 $setting->save();
 }}}

 But this still seems a bit round-about, and the
 `WP_Customize_Setting::save()` method would ideally take an argument which
 would override what is currently in the `post_value` (or
 `transaction_value`).

 My concern now with the changes to the `save` method to remove the
 capability check is whether existing plugins would by relying on there
 being capability checks in the method to ensure proper authorization. I
 wonder if a better approach might be to instead just make the `update`
 method public instead of private so that plugins would be able to access
 that method? That would be a patch that could go in now without waiting
 for a decision on transactions.

--
Ticket URL: <https://core.trac.wordpress.org/ticket/30448#comment:9>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform


More information about the wp-trac mailing list