Der folgende Beitrag ist ein Gastbeitrag von Scott Fennell, einem WordPress Theme & Plugin-Entwickler in Anchorage, AK, und einem regelmäßigen Mitwirkenden hier.
Nehmen wir an, Sie haben einen Kunden, dessen Geschäft groß genug ist, um mehrere Abteilungen zu haben. Nehmen wir nun an, dieser Kunde möchte, dass jede seiner Abteilungen eine eigene Website auf einer dedizierten Domain hat. Jede Website soll das gleiche Layout, aber ein anderes Farbschema haben. Dies ist ein phänomenaler Anwendungsfall für den WordPress Customizer (auch bekannt als die Theme Customization API), und ich möchte Ihnen ein grundlegendes Beispiel geben, wie Sie dies in ein Theme integrieren können.
Am Ende dieses Artikels werden wir ein WordPress-Theme haben, das einige Theme-Modifikationen aufweist und ein offensichtliches Muster in unserem Code für zukünftige Erweiterungen aufweist.
Holen Sie sich das Beispiel
Das Beispiel-Theme, auf das wir verweisen werden, befindet sich auf GitHub und heißt CSS-Tricks Theme Mod Demo. Sie können es auch klonen und auf Ihrer WordPress-Installation ausführen – es funktioniert sofort.
Eine kurze Anmerkung zur Terminologie
Die Begriffe Customizer, Theme Modification API und Theme Customization API werden in der WordPress-Community seit einiger Zeit etwas austauschbar verwendet. Ich denke, es haben sich subtile Unterschiede zwischen diesen Begriffen herausgebildet, die ich zu respektieren versuchen werde.
- Customizer bezieht sich auf die tatsächliche Benutzeroberfläche Ihrer WordPress-Installation unter
/wp-admin/customize.php. - Theme Modification API bezieht sich auf die Familie von Funktionen, die die von Customizer verwalteten Daten erstellen, replizieren, aktualisieren und löschen (CRUD).
- Theme Customization API bezieht sich auf die Familie von Funktionen, die Entwickler verwenden können, um Einstellungen zum Customizer hinzuzufügen oder daraus zu entfernen.
Alle drei dieser Konzepte werden in diesem Artikel behandelt, obwohl ich den Begriff Theme Mods für Benennungen bevorzugen werde, wie z.B. für meinen Theme-Ordner. Persönliche Vorliebe, keine große Sache.
Erstellen Sie eine Testseite
Stellen Sie sicher, dass Ihre Testinstallation von WordPress gesichert ist und die neueste Version ausführt, die zum Zeitpunkt der Erstellung dieses Artikels 4.3.2 ist. Tatsächlich reicht eine frische Installation aus: keine Plugins, nichts. Nur das Beispiel-Theme von oben, installiert und alleine aktiviert.
Mit installiertem Beispiel-Theme, schauen Sie sich wp-admin an: Sie werden feststellen, dass unter dem Menüpunkt "Themes" auf der linken Seite ein Link mit der Bezeichnung "Customize" vorhanden ist. Dieser Menüpunkt existiert standardmäßig; ich musste ihn nicht registrieren oder die Unterstützung dafür deklarieren. Selbst wenn unser Theme keine Theme-Mods registriert hätte, wäre dieser Link trotzdem nützlich, da der WordPress-Core automatisch einige Einstellungen dafür hinzufügt, wie z.B. den Seitentitel, den Slogan usw. Customizing ist das, wofür wir hier sind, also klicken Sie auf diesen Link!
Das Customizer-Panel
Hier sind wir im Customizer. Er ist in einer Hierarchie mit drei Ebenen organisiert: Panels enthalten Sektionen, Sektionen enthalten Einstellungen und Einstellungen sind die Daten, die von den Controls in der Customizer-Oberfläche verwaltet werden.
Wir könnten es uns so vorstellen
Panel
|__ Section
| |__ Setting and its Control
| |__ Setting and its Control
|__ Section
| |__ Setting and its Control
| |__ Setting and its Control
|
Panel
|__ Section
| |__ Setting and its Control
| |__ Setting and its Control
|__ Section
|__ Setting and its Control
|__ Setting and its ControlDiese hierarchische Struktur ist ein wirklich guter Baustein zum Verständnis des Customizers. Wenn Sie sich darüber noch nicht im Klaren sind, nehmen Sie sich einen Moment Zeit, um die Dokumentation zu Panels im Vergleich zu Sektionen, im Vergleich zu Einstellungen und deren Controls zu durchstöbern. Meine Lernkurve wäre viel schneller gewesen, wenn ich das frühzeitig gelernt hätte.
Eine weitere Stolperfalle: Wenn Sie versuchen, den Customizer zu verstehen, versuchen Sie vielleicht zuerst, ein Panel zu registrieren und dann Ihre /wp-admin/customizer.php zu überprüfen, ob es funktioniert hat, bevor Sie Sektionen und Einstellungen dafür registrieren. Tun Sie das nicht: Ein Panel wird erst angezeigt, wenn bereits Einstellungen und ihre entsprechenden Controls dafür registriert sind.
Gehen wir die Hierarchie im Detail durch.
Panels
Sofort sehen wir auf der linken Seite, dass wir zwei Panels haben, die Site Identity und Body heißen.
Das Panel "Site Identity" wird mit WordPress geliefert, während unser Theme das Panel "Body" hinzugefügt hat.
Sektionen
Wenn wir auf "Body" klicken, sehen wir, dass es einige Sektionen enthält: Farben und Layout-Optionen. Nochmals zur Wiederholung: Ich habe Code in diesem Theme, der das "Body"-Panel hinzugefügt hat, und im Gegenzug habe ich auch Code, der die Sektionen "Colors" und "Layout Options" zum "Body"-Panel hinzugefügt hat.
Einstellungen
Wenn wir auf "Colors" klicken, sehen wir, dass ich ein paar Einstellungen zusammen mit ihren Controls registriert habe, um die Farbe unseres Themes zu bearbeiten. Dabei habe ich Standardwerte von Orange und Schwarz angegeben, die hier in den Controls auf der linken Seite vorab ausgefüllt sind.
Ein Wort zu Daten: WordPress speichert und ruft Einstellungen über die Familie der Funktionen für die Theme-Modifikation ab. Wir können diese Funktionen auch in unserem Theme-Code verwenden, obwohl get_theme_mod() die einzige ist, die ich in diesem Theme verwenden werde.
Controls
Ich sage Ihnen, dass Panels, Sektionen und Einstellungen eine hierarchische Beziehung haben. Controls sind ebenfalls Teil dieser Familie: Betrachten Sie ein Control als Geschwister jeder Einstellung.
Ein Control ist das, was die Benutzeroberfläche im Customizer für eine bestimmte Einstellung zeichnet. Wir müssen sowohl ein Control als auch eine Einstellung für einen Theme-Mod registrieren, um mit diesem Theme-Mod etwas Nützliches tun zu können.
Hinweis: Sie können wirklich verrückt werden und alle Arten von benutzerdefinierten Control-Typen registrieren. Dinge wie Checkbox-Gruppen, Bereiche, Mehrfachauswahlen. Justin Tadlock hat viele inspirierende Beispiele dafür geliefert, manchmal unter Verwendung von JavaScript-Templating. Obwohl wir für jede Einstellung ein Control registrieren müssen, müssen wir für dieses Tutorial keine benutzerdefinierten Control-Typen registrieren, und ich werde mich damit nicht beschäftigen. Eine Reihe von großartigen Control-Typen wird mit WordPress geliefert, einschließlich des Farbwählers im obigen Beispiel. Sie können mehr über die mit WordPress gelieferten Control-Typen im Codex lesen.
WordPress-Standardeinstellungen und wie man sie entfernt
Lassen Sie uns zurück zu den Top-Level-Panels des Customizers gehen und dann auf das Panel "Site Identity" klicken. WordPress fügt dieses Panel standardmäßig hinzu, überspringt die Sektionsebene und geht direkt zu einigen Einstellungen für den Seitentitel und das Website-Symbol. Das Website-Symbol ist neu, aber glauben Sie mir, es ist Teil des Kerns.
Sie würden vielleicht erwarten, hier auch eine Einstellung für den Slogan zu sehen, und normalerweise würden Sie das auch, aber ich habe sie entfernt. Tatsächlich habe ich eine Reihe von Panels, Sektionen und Einstellungen entfernt, die WordPress standardmäßig hinzufügt, nur um ein Beispiel dafür zu geben, wie man sie deregistriert. Unser Beispiel-Theme enthält eine Klasse namens CSST_TMD_Customizer, wo ich mit dem Customizer interagiere, um diese Theme-Mods anzupassen. Um die Standardknoten zu entfernen, hänge ich mich an die customize_register Aktion an und greife auf das $wp_customize-Objekt zu.
<?php
class CSST_TMD_Customizer {
public function __construct() {
...
// Strip away unused customizer nodes.
add_action( 'customize_register', array( $this, 'deregister' ), 999 );
}
...
/**
* Remove stuff that WordPress adds to the customizer.
*
* param object $wp_customize An instance of WP_Customize_Manager.
*/
public function deregister( $wp_customize ) {
// Remove the setting for blog description, AKA Site Tagline.
$wp_customize -> remove_control( 'blogdescription' );
// Remove the section for designating a static front page.
$wp_customize -> remove_section( 'static_front_page' );
// Remove the panel for handling nav menus.
$wp_customize -> remove_panel( 'nav_menus' );
}
?>Ich habe mich entschieden, diese Elemente zu entfernen, da sie ein gutes Beispiel für die besprochene Hierarchie liefern. Ich konnte ermitteln, welchen Schlüssel ich an jede remove_-Funktion übergeben muss, indem ich mir das Markup für diesen Bereich im Customizer angesehen habe. Es findet sich normalerweise im Datenattribut data-customize-setting-link für das jeweilige Control (Sie können dies im obigen Screenshot sehen).
Entschuldigen Sie bitte: Das Entfernen von nav_menus scheint im Debug-Modus eine PHP-Warnung auszulösen. Ich konnte keinen Weg finden, dies zu vermeiden. Wenn das stört, können Sie es gerne drin lassen und Ihre neu gewonnene Fähigkeit genießen, Navigationsmenüs im Customizer zu verwalten.
Definieren unserer eigenen Panels, Sektionen und Einstellungen
Ich wiederhole mich nicht gerne, wenn ich Code schreibe, daher definiere ich unsere Panels, Sektionen und Einstellungen nur einmal in einem großen Array, durch das der Rest unseres Themes iterieren kann. Dies wird uns in die Lage versetzen, Dinge zu tun, wie z.B. diese Einstellungen zum Customizer hinzuzufügen und sie als CSS auf dem Frontend auszugeben.
Das Beispiel-Theme enthält eine Klasse namens CSST_TMD_Theme_Mods, in der ich ein Array von Panels, Sektionen und Einstellungen erstelle, die zum Customizer hinzugefügt werden sollen. Diese Klasse ist wirklich der Kern dieses Artikels, und ich hoffe, Sie nehmen sich einen Moment Zeit, um den Quellcode zu lesen. Lassen Sie uns ein Beispiel durchgehen, bei dem das Ziel ist, das "Body"-Panel hinzuzufügen, die "Colors"-Sektion zu diesem Panel hinzuzufügen und dann die Einstellung für die background_color zu dieser Sektion hinzuzufügen. Mit anderen Worten
Panel: Body
|__ Section: Color
|__ Setting: Background Color, controlled with a Color PickerZuerst wird ein Panel namens body definiert
<?php
class CSST_TMD_Theme_Mods {
/**
* Define our panels, sections, and settings.
*
* @return array An array of panels, containing sections, containing settings.
*/
function get_panels() {
...
// Start an annoyingly huge array to define our panels, sections, and settings.
$out = array();
// Define the body panel.
$body = array(
// The title for this panel in the customizer UI.
'title' => esc_html__( 'Body', 'csst_tmd' ),
// The description for this panel in the customizer UI.
'description' => esc_html__( 'Theme Mods for the Page Body', 'csst_tmd' ),
// The order within the customizer to output this panel.
'priority' => 20,
// The body panel has a bunch of sections.
'sections' => array(),
);
$out['body'] = $body;
Als Nächstes wird eine Sektion namens colors zum Body-Panel hinzugefügt
// Define the colors section, which resides in the body panel.
$out['body']['sections']['colors'] = array(
// The title for this section in the customizer UI.
'title' => esc_html__( 'Colors', 'csst_tmd' ),
// The description for this section in the customizer UI.
'description' => esc_html__( 'Colors for the Page Body', 'csst_tmd' ),
// The order within this panel to output this section.
'priority' => 10,
// The colors section has a bunch of settings.
'settings' => array(),
);
?>Dann wird eine Einstellung für background_color zur Colors-Sektion hinzugefügt
<?php
// The setting for body background color.
$out['body']['sections']['colors']['settings']['background_color'] = array(
// The type of control for this setting in the customizer.
'type' => 'color',
// The header text for the control.
'label' => esc_html__( 'Body Background Color', 'csst_tmd' ),
// The descriptive text for the control.
'description' => esc_html( 'The background color for the body element, on landscape screens smaller than 800px.', 'csst_tmd' ),
// The order within this section for outputting this control.
'priority' => 10,
// The default value for this setting.
'default' => '#000000',
// A callback function for sanitizing the input.
'sanitize_callback' => 'sanitize_hex_color',
'sanitize_js_callback' => 'sanitize_hex_color',
// Do we want to use css from this setting in TinyMCE?
'tinymce_css' => FALSE,
// Is this setting responsible for creating some css?
'css' => array(
// This array amounts to one css rule. We could do several more right here.
array(
// Here's the selector string.
'selector' => 'body',
// Here's the css property.
'property' => 'background-color',
// Here are some media queries for this css.
'queries' => array(
'max-width' => '800px',
'orientation' => 'landscape',
),
// End this css rule. We could start another one right here, perhaps to use this setting for a border-color on the body element, or whatever.
),
// End the list of css rules (yeah, there's just one right now).
),
// End this setting.
);
?>Das führt zu viel Verschachtelung und einer sehr langen Array-Definition, die, wie ich zugeben muss, schwer zu durchschauen sein kann. Ich arbeite sowieso gerne mit tiefen Arrays, und diese Technik hat sich für mich gut bewährt. Bei Implementierungen mit vielen Einstellungen verwende ich oft Transients, um Leistungsprobleme durch all die Schleifen zu vermeiden. Ich teile das Array auch in mehrere Funktionen für jedes Panel auf, um es leichter lesbar und debuggbar zu machen.
Die gute Nachricht ist, dass Sie es nicht so machen müssen! Es gibt nichts in dieser Klasse, das sich in einem bestimmten Format an WordPress hängt. Das bin nur ich, der seine Einstellungen so definiert, wie es für mich gut funktioniert. Sie könnten noch nuancierter mit Media Queries arbeiten. Sie könnten eine Regel vielleicht nur dann anwenden lassen, wenn bestimmte Body-Klassen vorhanden sind. Sie könnten mein riesiges mehrdimensionales Array meiden und Ihre Einstellungen einzeln deklarieren. Seien Sie so kreativ und mächtig oder so einfach und lesbar, wie Sie möchten. Es liegt ganz bei Ihnen.
Wenn Ihnen all meine Schleifen schwindelig machen, schauen Sie sich das exzellente Theme Twenty Sixteen an, das seine Customizer-Einstellungen ohne Schleifen registriert. Ich neige dazu, ihre Technik zu meiden, weil ich sie als weniger DRY empfinde. Zum Beispiel erscheint die Zeichenfolge color_scheme 83 Mal in dieser Datei.
Ich kann mir einen anderen Ansatz vorstellen, inspiriert von der Arbeit und den Schriften von Tom McFarline. Er hat eine lange Reihe von Beiträgen über die Verwendung von objektorientierter Programmierung (OOP) zur Verwaltung von WordPress-Einstellungen. Wenn Ihnen eine solche Architektur intuitiver erscheint, machen Sie es ruhig. Ich denke, Sie werden feststellen, dass seine OOP-Arbeit an der Settings API einige offensichtliche Parallelen aufweist, die sich auch gut für die Customizer API eignen würden.
Unabhängig von der gewählten Technik müssen diese Informationen immer noch in den Customizer übergeben werden, um eine Benutzeroberfläche für diese Einstellungen zu erhalten. Das haben wir noch nicht getan, also machen wir es!
Übergabe von Theme-Mods an den Customizer
Das Hinzufügen unserer Einstellungen zum Customizer ist dem Entfernen von Core-Einstellungen aus dem Customizer sehr ähnlich. Wieder einmal müssen wir uns an customizer_register hängen, nur dass wir dieses Mal Dinge hinzufügen und nicht entfernen. Hier ist ein Ausschnitt aus der Funktion, die das tut
<?php
class CSST_TMD_Customizer {
public function __construct() {
// Register our custom settings and controls.
add_action( 'customize_register' , array( $this, 'register' ), 970 );
...
}
/**
* Add our panels, sections, and settings to the customizer.
*
* @param object $wp_customize An instance of the WP_Customize_Manager class.
*/
public function register( $wp_customize ) {
// Fire up our theme mods class.
$theme_mods_class = new CSST_TMD_Theme_Mods;
// Grab our panels, sections, and settings.
$panels = $theme_mods_class -> get_panels();
// For each panel...
foreach ( $panels as $panel_id => $panel ) {
// Add this panel to the UI.
$wp_customize -> add_panel(
$panel_id,
array(
'title' => $panel['title'],
'description' => $panel['description'],
'priority' => $panel['priority'],
)
);
// For each section in this panel, add it to the UI and add settings to it.
foreach( $panel['sections'] as $section_id => $section ) {
// Add this section to the UI.
$wp_customize -> add_section(
$panel_id . '-' . $section_id,
array(
'title' => $section['title'],
'description' => $section['description'],
'priority' => $section['priority'],
'panel' => $panel_id,
)
);
// For each setting in this section, add it to the UI.
foreach( $section['settings'] as $setting_id => $setting ) {
// Start building an array of args for adding the setting.
$setting_args = array(
'default' => $setting['default'],
'sanitize_callback' => $setting['sanitize_callback'],
'sanitize_js_callback' => $setting['sanitize_js_callback'],
);
// Register the setting.
$wp_customize -> add_setting(
$panel_id . '-' . $section_id . '-' . $setting_id,
$setting_args
);
// Start building an array of args for adding the control.
$control_args = array(
'label' => $setting['label'],
'section' => $panel_id . '-' . $section_id,
'type' => $setting['type'],
'description' => $setting['description'],
);
// Settings of the type 'color' get a special type of control.
if( $setting['type'] == 'color' ) {
$wp_customize -> add_control(
// This ships with WordPress. It's a color picker.
new WP_Customize_Color_Control(
$wp_customize,
$panel_id . '-' . $section_id . '-' . $setting_id,
$control_args
)
);
// Else, WordPress will use a default control.
} else {
$wp_customize -> add_control(
$panel_id . '-' . $section_id . '-' . $setting_id,
$control_args
);
}
// End this setting.
}
// End this section.
}
// End this panel.
}
}
?>Wir durchlaufen die benutzerdefinierten Panels und fügen jedes Panel hinzu. Während wir uns in einem Panel befinden, durchlaufen wir es und fügen alle Sektionen für dieses Panel hinzu. Wenn wir uns in einer Sektion befinden, durchlaufen wir die Einstellungen in dieser Sektion. Wann immer wir eine Einstellung hinzufügen, müssen wir auch ein Control für diese Einstellung hinzufügen. Schleifen-Kram!
Sie können die Details dieser Methode leichter sehen, indem Sie die Quellendatei durchsuchen.
Diese Methode des Durchlaufens eines Arrays ist rein meine persönliche Technik. Ich mag das, weil ich einfach eine neue Einstellung hinzufügen kann, indem ich sie einfach zu meinem Definitions-Array hinzufüge. Ich muss keine andere Datei anfassen oder erstellen. Sehen Sie im Codex nach Dokumentation zu den Funktionen, die ich zur Interaktion mit $wp_customize verwende, wie z.B. add_setting().
Lassen Sie uns über Live-Vorschau sprechen
Die Vorschau-Leiste macht es extrem schnell, Theme-Modifikationen auf dem Laufenden auszuwählen und anzuzeigen.
Der Grund, warum sie so schnell aktualisiert wird, ist, dass die "Live-Vorschau" aktiviert wurde. Sie ist jedoch nicht Teil unseres Beispiel-Themes, und ich persönlich verwende sie auch nicht in der Produktion. Es gibt zwei gängige Möglichkeiten für die Live-Vorschau, und ich bin mit keiner von beiden zufrieden.
#1: Inline-Stile für ein Element
Der am häufigsten dokumentierte Weg zur Live-Vorschau hat die Tendenz, das C in CSS zu zerquetschen. Mit anderen Worten, JS wird verwendet, um Inline-Stile für die ausgewählten HTML-Elemente zu erstellen, einzufügen und zu aktualisieren. So etwas wie das hier, das ich größtenteils aus dem Codex übernehme.
<script>
// Update default link color.
wp.customize( 'mytheme_options[link_color]', function( value ) {
value.bind( function( newval ) {
$( 'a' ).css( 'color', newval );
} );
} );
// Update sidebar link color.
wp.customize( 'mytheme_options[sidebar_link_color]', function( value ) {
value.bind( function( newval ) {
$( '.sidebar a' ).css( 'color', newval );
} );
} );
</script>Sehen Sie das Problem hier? Indem ich die Linkfarbe für Body-Links aktualisiere, würde ich versehentlich die spezifischeren Stile für Sidebar-Links während der Vorschauperiode demolieren. Das ist ein Problem, und ich habe keine Lösung dafür.
Ein weiteres Problem mit dieser Technik sind Media Queries. Denken Sie daran, dass wir unsere Theme-Mods auf bestimmte Media Queries beschränkt haben. Es wäre viel Arbeit, diese Logik über JS zu übergeben.
#2: Inline-Stilblöcke
Wenn Sie sich Twenty Fifteen ansehen, werden Sie sehen, dass sie anstatt die Stile direkt auf einem Element zu aktualisieren, den Block der Inline-Stile aktualisieren, den der Customizer generiert. Ich finde das viel, viel besser. Sie können sich in diese Technik hier einarbeiten. Ich habe versucht, das zurückzuverfolgen und in etwas umzuwandeln, das ich wirklich verstehen und selbst warten konnte, und hatte Schwierigkeiten. Ich habe einige Aktionen hier gefunden, aber dieses Ticket gibt mir nicht das Gefühl, dass es schlimm ist, mit der Live-Vorschau eine Weile auszusetzen. Ich behalte die Customizer API im Auge, aber ich verwende sie derzeit nicht in der Produktion und werde mich hier nicht damit befassen.
Das ist das Ding mit dem Customizer: Wenn Hunderte von Kunden-Websites das gleiche Theme verwenden, müssen wir beim Aktualisieren des Themes sehr vorsichtig sein. Ich bräuchte wahrscheinlich visuelles Regressionstesting, um verantwortlich zu sein. Deshalb neige ich dazu, mit dem Customizer weiter von der Spitze der WordPress-Funktionalität entfernt zu bleiben, als ich es bei einem Einzelkunden-Theme tun würde. Wenn der Core eine Breaking Change veröffentlicht, möchte ich mir keine Sorgen um Hunderte von Websites machen.
Die Quintessenz ist, dass die Live-Vorschau ein "Nice-to-have"-Feature ist, aber kein Dealbreaker. Ich lehne sie persönlich ab, bis die JS-API eine bessere Dokumentation hat.
Styling des Frontends
Wir haben all diese Arbeit geleistet, um eine Benutzeroberfläche für unsere Einstellungen zu erhalten, und sie funktioniert! Wir können diese Werte überall verwenden, wo wir möchten: CSS bei wp_head(), Body-Klassen, der TinyMCE-Editor – alles, was Ihnen einfällt. Wir können die Werte sogar an unseren JS übergeben.
Nutzen wir sie, um CSS auszugeben. Wir haben bereits einige Einstellungen zur Steuerung von color und background-color für das body-Element, also können wir dort anfangen.
Das Theme hat eine Klasse namens CSST_TMD_Inline_Styles, die durch alle unsere Einstellungen läuft und das entsprechende CSS ausgibt. Dies geschieht über die exzellente Funktion add_inline_style(), was bedeutet, dass benutzerdefinierte Stile als Abhängigkeit des Theme-Stylesheets geladen werden. So sieht das in Aktion aus:
<?php
class CSST_TMD_Inline_Styles {
public function __construct( $output_for = 'front_end' ) {
// Add our styles to the front end of the blog.
add_action( 'wp_enqueue_scripts', array( $this, 'front_end_styles' ) );
...
}
/**
* Append our customizer styles to the <head> whenever our main stylesheet is called.
*/
public function front_end_styles() {
// Grab the styles that pertain to the front end, but don't wrap them in a style tag.
$styles = $this -> get_inline_styles( 'unwrapped', 'front_end' );
// Attach our customizer styles to our stylesheet. When it gets called, so do our customizer styles.
wp_add_inline_style( CSST_TMD, $styles );
}
...
?>Wir rufen eine Methode auf, $this -> get_inline_styles(). Diese Methode ist dafür verantwortlich, jede Customizer-Einstellung durchzugehen und einen riesigen CSS-Block auszugeben.
<?php
class CSST_TMD_Inline_Styles {
...
/**
* Loop through our theme mods and build a string of CSS rules.
*
* @param string $wrapped Whether or not to wrap the styles in a style tag. Expects 'wrapped' or 'unwrapped'.
* @param string $output_for The context for these styles. Expects 'front_end' or 'tinymce'.
* @return string CSS, either wrapped in a style tag, or not.
*/
public function get_inline_styles( $wrapped = 'wrapped', $output_for = 'front_end' ) {
// This will hold all of our customizer styles.
$out = '';
...
// For each setting...
foreach( $settings as $setting_id => $setting ) {
// Grab the css for this setting.
$css_rules = $setting['css'];
// Grab the current value for this setting.
$value = $setting['value'];
// For each css rule...
foreach( $css_rules as $css_rule ) {
// The css selector.
$selector = $css_rule['selector'];
// The css property.
$property = $css_rule['property'];
// Build this into a CSS rule.
$rule_string = "$selector { $property : $value ; }";
// Does this css rule have media queries?
if( isset( $css_rule['queries'] ) ) {
...
foreach( $queries as $query_key => $query_value ) {
...
// Add the media query key and value.
$query .= "( $query_key : $query_value )";
// If this isn't the last query, add the "and" operator.
if( $i < $query_count ) {
$query .= ' and ';
}
...
}
// Wrap the rule string in the media query.
$rule_string = " @media $query { $rule_string } ";
}
// Add the rule, which might be wrapped in a media query, to the output.
$out .= $rule_string;
}
}
...
return $out;
}
}
?>Ein Inline-Stilblock wird Zeile für Zeile aufgebaut, wobei jeder CSS-Selektor und jede CSS-Eigenschaft in dem Einstellungs-Array definiert sind und der CSS-Wert das ist, was über die Customizer-Benutzeroberfläche gespeichert wird.
Andere Verwendungszwecke für Customizer-Einstellungen
Das obige Beispiel ist wahrscheinlich der wichtigste und offensichtlichste Verwendungszweck für den Customizer, aber bei weitem nicht der einzige. Wir haben auch eine Klasse, CSST_TMD_Body_Classes, in der wir jede Einstellung als Body-Klasse hinzufügen, sowohl in wp-admin als auch im Frontend. Das ist für Einstellungen wie color nicht sehr wichtig, könnte aber hilfreich sein, wenn wir eine Einstellung hätten, um beispielsweise eine Sidebar nach links oder rechts zu verschieben. Ähnlich haben wir eine weitere Klasse, CSST_TMD_Tiny_MCE, um den Beitragseditor in wp-admin zu stylen, sodass die Editor-Ansicht das gleiche Farbschema aufweist, das der Benutzer im Customizer gewählt hat. Ich überlasse es dem neugierigen Leser, diese zu erkunden; sie behandeln nicht unbedingt neues Terrain in Bezug auf den Customizer.
Ressourcen und nächste Schritte
Wenn Sie diesen Artikel hilfreich fanden, ermutige ich Sie sehr, die Diskussionen zum Customizer im Make-Blog zu verfolgen. Ein kürzlicher Artikel dort nannte die Frontend-Performance als einen Bereich, der im Customizer Anlass zur Sorge gibt. Dem würde ich zustimmen, obwohl ich feststelle, dass die Leistung in Chrome deutlich besser ist als in Firefox. Sie erwähnten auch die Möglichkeit von Revisionen für den Customizer, ähnlich wie bei Post-Revisionen, was in einer Agenturumgebung wie meiner eine willkommene Funktion wäre.
Ich habe im Laufe der Jahre einige Sammlungen von benutzerdefinierten Controls auf GitHub gesehen. Dieses hier scheint einige nützliche und komplexe Controls zu enthalten. Hier ist ein weiteres. Lassen Sie mich in den Kommentaren wissen, wenn Sie welche haben, denen ich folgen sollte.
Wenn Sie das Gefühl hatten, dass Sie dem Inhalt dieses Artikels folgen konnten, sind einige logische nächste Schritte:
- Fügen Sie weitere Einstellungen zum Einstellungs-Array hinzu.
- Machen Sie die Media-Query-Syntax robuster, damit Sie Media-Queries mit spezifischen logischen Operatoren registrieren können.
- Werden Sie schlau bei JavaScript-Templating für benutzerdefinierte Control-Typen, über Justin Tadlock.
Wenn Sie diesen Artikel schwierig zu befolgen fanden, antworte ich gerne über die Kommentare. Sie könnten auch in der Zeit zurückgehen, sagen wir, zu Twenty Fourteen und den Customizer-Code aus einer einfacheren Ära zerlegen, und sich dann durch jedes jährliche Theme nach vorne arbeiten. Im Zweifelsfall: var_dump()!