it-roy-ru.com

Customizer - создание экземпляров настроек и элементов управления через JavaScript

Я пытаюсь динамически загрузить тонну элементов управления в зависимости от значения раскрывающегося списка, и я не хочу загружать их через PHP, поскольку начальная загрузка страницы занимает более 15 секунд. У меня много контроля.

Итак, каковы требования к созданию экземпляров настроек и (пользовательских) элементов управления через JS?

Нужно ли регистрировать мой пользовательский класс управления и использовать метод content_template? Моему классу нужно правильно установить "тип"? (Я сделал обе эти вещи)

Могу ли я зарегистрировать настройки в PHP (это то, что я сделал), а затем создать экземпляры элементов управления через JS или мне также нужно создать экземпляры настроек в JS?

Что насчет JS? Нужно ли повторять код разметки в экземпляре JS?

Это то, что я имею до сих пор, но на самом деле ничего не появляется .. Я явно упускаю некоторые фундаментальные вещи, но я не уверен, что:

  var api = wp.customize;

  var sectionID = 'site_variables_section'; // section.id.replace( '[', '-' ).replace( ']', '' )
  api.controlConstructor.ColorVariable = api.Control.extend({
    ready: function() {
        var control = this;
        wp.customize.Control.prototype.ready.call( control );
    }
  });

  // The control
  var controlID = 'site_variables_section[' + field.name.replace('$', '') + ']';

  var controlParams = {
      section: sectionID,
      label: 'label',
      settings: {
        'default': controlID
      },
      active: true,
      type: 'ColorVariable',
    };

  var control = new api.controlConstructor.ColorVariable( controlID, controlParams );
  control.active.validate = function() {
    return true;
  };
  api.control.add( control.id, control );

@ weston-ruter заставил меня пойти по правильному пути, но я все еще немного растерялся из-за нескольких вещей:

1- Как значение передается в поле/сохраняется, когда отсутствует ссылка на данные-настройки-настройки? Это обрабатывается JS content_template

2- Я вижу, что когда для элемента управления используется одна настройка, используется ключ "по умолчанию" в параметре настроек, но как насчет того, когда несколько настроек и как мы получаем значения для каждой настройки: по умолчанию

для 2 я смог заставить его работать с: settings:{ variable : controlId+'[variable]', control: controlId+'[control]', value: controlId+'[value]', percentage: controlId+'[percentage]' } я думаю что-то вроде этого в функции to_json():

$this->json['percentage_value'] = $this->value('my-settings-id);

2
rugbert

Если вы регистрируете свои настройки на сервере, вам не нужно регистрировать их на клиенте в JS, так как это будет сделано для вас. Вот несколько примеров создания элементов управления после создания настроек:

В первом примере для Customize Posts CSS фактически используется новый элемент управления Code Editor, совершенно новый в WordPress 4.9. Вы можете обратиться к этому запрос на извлечение , чтобы увидеть, что требуется. В частности, убедитесь, что вы вызываете $wp_customize->register_control_type( 'My_Custom_Control' ), чтобы убедиться, что шаблон содержимого действительно выводится.


Когда вы are динамически создаете настройки на клиенте, вам следует сначала создать их экземпляры в JS, прежде чем создавать их связанные элементы управления.

Вот несколько примеров создания настроек:

Когда вы динамически создаете настройки и элементы управления, другая ключевая вещь, которую нужно реализовать, это "динамические настройки" на сервере. Если вы не создаете параметр на сервере, он не будет распознан. Это то, для чего предназначены фильтры customize_dynamic_setting_args и customize_dynamic_setting_class. Некоторые примеры:

Обратите внимание, что API для создания экземпляров настроек и элементов управления в ядре будут улучшаться.

1- Как значение передается в поле/сохраняется, когда нет data-customize-setting-link? Это обрабатывается JS content_template?

Затем необходимо вручную создать ссылку Elementмежду Settingи inputname__, например:

element = new wp.customize.Element( input );
element.sync( setting );
element.set( setting() );

Вы можете видеть из ядра , что data-customize-setting-link - это просто ярлык, чтобы сделать это автоматически для вас.

2- Я вижу, что когда для элемента управления используется одна настройка, используется ключ "по умолчанию" в параметре настроек, но как насчет того, когда несколько настроек и как мы получаем значения для каждой настройки: defaultname__

Да, вы определяете другие не -defaultключи. В WordPress 4.9 появилось несколько ключевых улучшений того, как все это работает, что значительно упростит создание экземпляров элементов управления с помощью JS. В дополнение к атрибуту data-customize-setting-link теперь поддерживается атрибут data-customize-setting-key-link, который позволяет использовать фактический ключ в шаблоне, а не идентификатор параметра. Кроме того, передаваемое вами settingsможет ссылаться либо на идентификаторы настроек, либо на объекты Settingname__, либо даже на произвольные экземпляры Valuename__.

Например, рассмотрим шаблон, добавленный через:

add_action( 'customize_controls_print_footer_scripts', function() {
    ?>
    <script id="tmpl-site-identity-control-content" type="text/html">
        <# var elementIdPrefix = _.uniqueId( 'site-identity-' ); #>
        <details>
            <summary class="customize-control-title">{{ data.label }}</summary>
            <ul>
                <li>
                    <label for="{{ elementIdPrefix }}_title">Title:</label>
                    <input id="{{ elementIdPrefix }}_title" type="text" data-customize-setting-key-link="title">
                </li>
                <li>
                    <label for="{{ elementIdPrefix }}_tagline">Tagline:</label>
                    <input id="{{ elementIdPrefix }}_tagline" type="text" data-customize-setting-key-link="tagline">
                </li>
                <li>
                    <label for="{{ elementIdPrefix }}_founded">Year founded:</label>
                    <input for="{{ elementIdPrefix }}_founded" type="number" min="1" max="9999" data-customize-setting-key-link="founded">
                </li>
            </ul>
        </details>
    </script>
    <?php
} );

Вы можете добавить элемент управления, который использует этот шаблон, просто передавая его идентификатор как templateIdвместе с желаемым settingsname__:

var foundedValue = new api.Value( 2017 );
var control = new api.Control( 'site_identity', {
    templateId: 'site-identity-control-content',
    label: 'Site Identity',
    priority: 5,
    section: sectionId,
    settings: {
        title: 'blogname', // Setting ID which may not be registered yet.
        tagline: api( 'blogdescription' ), // Existing registered Setting object.
        founded: foundedValue // Non-setting Value.
    }
} );
api.control.add( control );
foundedValue.bind( function( newYear ) {
    console.info( 'The year is now', newYear );
} );

И тогда это выглядит так:

 site identity control 

Год основания Valueтолько для демонстрационных целей. Это Valuename__, а не зарегистрированное Settingозначает, что оно не будет сохранено в базе данных. Но значение, подобное этому, может быть полезно для мета-контроля в данной теме, например, для выбора из предустановленных цветовых схем. Это также, как статус набора изменений и дата заполняются в WordPress 4.9.

Пожалуйста, просмотрите make.wordpress.org/core для заметки разработчика, которая углубляется во все конкретные улучшения API JS в WordPress 4.9.

4
Weston Ruter