web-dev-qa-db-fra.com

Customizer - instanciation des paramètres et des contrôles via javascript

J'essaie de charger dynamiquement une tonne de contrôles en fonction de la valeur d'un menu déroulant et je ne souhaite pas les charger via PHP, car le chargement initial de la page prend bien plus de 15 secondes. J'ai beaucoup de contrôles.

Quelles sont donc exactement les conditions requises pour instancier des paramètres et des contrôles (personnalisés) via JS?

Ma classe de contrôle personnalisée doit-elle être enregistrée et la méthode content_template doit être étoffée? Ma classe a besoin du "type", non? (J'ai fait ces deux choses)

Puis-je enregistrer les paramètres dans PHP (c'est ce que j'ai fait), puis instancier les contrôles via JS ultérieurement ou dois-je également instancier les paramètres dans JS?

Qu'en est-il du JS? Dois-je répéter mon code de balisage dans l'instanciation JS?

C’est ce que j’ai eu jusqu’à présent, mais rien n’a été fait. Il manque clairement un élément fondamental, mais je ne sais pas quoi:

  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 m'a mis sur la bonne voie, mais je suis encore un peu confus par quelques points:

1- Comment la valeur est-elle passée dans le champ/sauvegardée quand il n'y a pas de lien data-personnaliser-setting-? Est-ce que cela est géré par JS content_template

2- Je vois que lorsqu'un seul paramètre est utilisé pour un contrôle, la clé "par défaut" est utilisée dans le paramètre paramètres, mais qu'en est-il lorsque plusieurs paramètres sont définis et comment saisir les valeurs pour chaque paramètre: défaut

pour 2, je pouvais le faire fonctionner avec: settings:{ variable : controlId+'[variable]', control: controlId+'[control]', value: controlId+'[value]', percentage: controlId+'[percentage]' } Je pense quelque chose comme ceci dans la fonction to_json():

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

javascripttheme-customizer
2
rugbert

Si vous enregistrez vos paramètres sur le serveur, vous n'avez pas besoin de les enregistrer sur le client dans JS, car cela sera fait pour vous. Voici quelques exemples de création de contrôles après la création des paramètres:

Dans le premier exemple pour Customize Posts CSS, cela utilise en fait un nouveau contrôle de l'éditeur de code totalement nouveau dans WordPress 4.9. Vous pouvez vous référer à cette demande d'extraction pour voir ce qui est requis. En particulier, veillez à appeler $wp_customize->register_control_type( 'My_Custom_Control' ) pour vous assurer que le modèle de contenu est réellement généré.

Lorsque vous créez dynamiquement des paramètres sur le client, vous devez d'abord les instancier dans JS avant d'instancier leurs contrôles associés.

Voici quelques exemples de création de paramètres:

Lorsque vous créez de manière dynamique des paramètres et des contrôles, l'autre élément clé à implémenter est celui des "paramètres dynamiques" sur le serveur. Si vous ne créez pas le paramètre sur le serveur, il ne sera pas reconnu. C’est à cela que servent les filtres customize_dynamic_setting_args et customize_dynamic_setting_class. Quelques exemples:

Notez que les API d'instanciation des paramètres et des contrôles seront de mieux en mieux adaptées.

1- Comment la valeur est-elle passée dans le champ/sauvegardée quand il n'y a pas de data-customize-setting-link? Est-ce que cela est géré par JS content_template?

Ensuite, vous devez créer manuellement le lien Element entre Setting et input vous-même, comme ceci:

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

Vous pouvez voir du noyau que le data-customize-setting-link est juste un raccourci pour le faire automatiquement pour vous.

2- Je vois que lorsqu'un seul paramètre est utilisé pour un contrôle, la clé "par défaut" est utilisée dans le paramètre paramètres, mais qu'en est-il lorsque plusieurs paramètres sont définis et comment saisir les valeurs pour chaque paramètre: default

Oui, vous définissez d'autres clés non -default. WordPress 4.9 apporte des améliorations importantes à son fonctionnement, ce qui facilitera grandement l’instanciation des contrôles avec JS. Outre l'attribut data-customize-setting-link, un attribut data-customize-setting-key-link est désormais pris en charge, ce qui vous permet d'utiliser la clé réelle dans le modèle par opposition à l'ID de paramètre. De plus, la variable settings que vous transmettez peut faire référence à des ID de paramètre, à des objets Setting ou même simplement à des instances Value arbitraires.

Par exemple, considérons un modèle ajouté via:

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
} );

Vous pouvez ajouter un contrôle qui utilise ce modèle en transmettant simplement son ID en tant que templateId avec la settings souhaitée:

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 );
} );

Et cela ressemble alors à ceci:

site identity control

L'année de fondation étant une Value, c'est uniquement à des fins de démonstration. Comme il s'agit d'une Value et non d'un inscrit Setting, cela signifie qu'elle ne serait pas enregistrée dans la base de données. Mais une valeur telle que celle-ci pourrait être utile pour les méta-commandes d'un thème donné, telles que le choix parmi des palettes de couleurs prédéfinies. C’est également ainsi que l’état et la date de modification sont renseignés dans WordPress 4.9.

Veuillez regarder make.wordpress.org/core pour une note de développement qui plonge dans toutes les améliorations spécifiques apportées aux API JS dans WordPress 4.9.

4
Weston Ruter