Share
WordPress gir temautviklere et kraftig system for å lage enkle å bruke temaalternativsystemer via Theme Customizer. Mens tilpasseren gir et utmerket forhåndsvisningssystem i sanntid og en god samlet brukeropplevelse, kan definering av utgangen av alternativer som er angitt i tilpasseren, bli rotete.
I denne veiledningen vil jeg vise deg hvordan du forenkler å få fargevalg som er angitt i tilpasseren til CSS i fronten. Dette enkle systemet kan tilpasses for bruk med andre CSS egenskaper, så vel som. Dette betyr at du kan bruke disse teknikkene til å arbeide med alternativer angitt via andre metoder enn Theme Customizer.
Altfor ofte, å få farger og andre alternativer satt i Theme Customizer innebærer rotete koden blander PHP og CSS.
For eksempel:
Accentsconagua
add_action ('wp_head', 'slug_theme_customizer_css'); funksjon slug_theme_customizer_css () ?> Problemet med denne koden er ikke rent estetisk, eller at det er vanskelig å lese. Det er for enkelt å gjøre en feil. For eksempel vil lukking av PHP-koder, etterfulgt av lukking av CSS-deklarasjonen, føre til dette:?>;, som ser feil ut, men er teknisk riktig.
Mens du kan starte denne funksjonen ved å få alle fargeverdiene du trenger i variabler, trenger du fortsatt å åpne PHP-koder for å ekko deres verdier i CSS. Likevel, det er en god start. Evnen til å sette CSS fargeværdier i variabler er selvsagt en av de mange gode tingene ved å bruke en CSS preprosessor.
Mens du legger til en fullblåst Sass eller LESS prosessor til temaet ditt, er det mulig, og det er plugins for å gjøre det, det går overbord for en enkel oppgave å konvertere noen variabler til heksadesimale verdier. I stedet skal jeg vise deg hvordan du lager en enkel preprosessor i temaet ditt med bare noen få linjer med kode.
Bedre CSS Markup
Det første du må gjøre er å lage en fil i temaet ditt customizer.css. Denne filen kan virkelig ha noen utvidelse, men gir den en css utvidelse betyr at kodeditoren din eller IDE vil behandle den som en CSS-fil som gjør det enklere å jobbe med.
I customizer.css du kan reformatere den stygge koden fra det forrige eksempelet til dette:
h1.site-title a color: [site_title_color]; h3.site-beskrivelse color: [site_description_color];
Som du kan se, er du nå i stand til å skrive CSS som om det var CSS. Du erstatter bare verdiene som skal settes fra tilpasseren med navnet på theme_mod i parentes. Disse strengene vil bli erstattet av vår preprocessor med verdi fra databasen. Det viktigste her er at du bruker navnet på tema mods som din substitusjonsverdi i ubehandlet CSS.
Bygg din preprosessor
Forprosessoren selv er faktisk utrolig enkel som det tar innholdet i din customizer.css og bruker PHP str_replace () Fungerer for å erstatte verdiene i parentes med verdier fra tilpasseren.
Hele systemet innebærer en enkel klasse med tre metoder og en funksjon utenfor klassen, hekta på wp_head å skrive ut behandlet og optimalisert CSS. Husk at denne koden forutsetter at alle dataene vi trenger, er lagret i tema mods, som er standard for temaet tilpasser. Du må kanskje erstatte get_theme_mod () med get_option () i koden din, avhengig av dine eksakte behov.
Denne klassen bruker en for hver loop i hver metode. Hvis du ikke er kjent med hvordan for hver løkker, anbefaler jeg å ta en titt på min artikkel om å jobbe med løkker og arrays. Også, hvis du ikke er kjent med PHP-klasser eller objektorientert PHP (OOP) generelt, bør du sjekke ut Tom McFarlins introduksjonsserie på OOP.
For å begynne, i en din functions.php eller i en fil som er inkludert i den, opprett en tom klasse som heter slug_theme_customizer_output erstatte "slug" med temaets unike slug. Det skal se slik ut:
klasse Slug_Theme_Customizer_Output
Den første metoden i klassen vil være der du angir tema modsene du vil bruke, samt standardverdier for hvert tema mod. Du setter hver i en matrise i form av theme_mod => standard. Stikker med de samme to innstillingene som tidligere, det vil gjerne dette:
funksjon theme_mods () return array ('site_title_color' => '# ff0000', 'site_description_color' => '# 000'); Det neste trinnet vil være å få dagens verdi av hver theme_mod og sett det i en matrise som vi kan bruke i vår faktiske preprosessor. Denne metoden får bare hver verdi fra theme_mods () metode og passerer nøkkelen som det første argumentet, som er navnet_mods navn til get_theme_mods () mens du overfører standardverdien som det andre argumentet, som vil bli returnert dersom det ikke er noe satt i det aktuelle temaet. Det vil se slik ut:
funksjonen prepare_values () $ colors = array (); // Få våre tema mods og standardverdier. $ theme_mods = $ this-> theme_mods (); // For hvert tema mod, skriv ut verdien av tema mod eller standardverdien. foreach ($ theme_mods som $ theme_mod => $ default) $ farger [$ theme_mod] = get_theme_mod ($ theme_mod, $ default); returner $ farger;
Nå har vi en matrise i form av 'theme_mod_name' => 'verdi for å erstatte' og vi er klare til å behandle CSS i den tredje og siste metoden i denne klassen.
I for hver loop i denne metoden, benytter vi muligheten som PHP gir oss til å behandle arrayets nøkkel og verdi som separate variabler. Dette er en veldig kraftig funksjon av PHP for hver looper som krever litt planlegging i hvordan hver gruppe er strukturert og gjør livet mye lettere.
Det første trinnet vil være å bruke file_get_contents () å konvertere customizer.css filen inn i en streng og lagre den i en variabel. Siden denne funksjonen vil forårsake en dødelig feil hvis den ikke finner filen, må vi pakke all kode i denne metoden i en test hvis filen eksisterer i det hele tatt.
Merk at denne koden antar det customizer.css er i samme katalog som klassen, må du kanskje justere for temaets filstruktur. Slik begynner du denne metoden:
funksjonsprosess () $ css = "; // Endre dette filnavnet og / eller stedet for å dekke dine behov. $ theme_customizer_file = trailingslashit (dirname (__FILE__)). 'theme_customizer.css'; // Kontroller at filen eksisterer. (file_exists ($ theme_customizer_file)) // Hent innholdet i filen. $ css = file_get_contents ($ theme_customizer_file);
Som jeg sa før, er hele denne metoden pakket inn i en sjekk om filen eksisterer. Det betyr at det kommer tilbake falsk hvis filen ikke lastes inn. Vær oppmerksom på dette, siden vi må regne med den muligheten senere.
Nå som vi har CSS som en streng, må vi få våre utvalg av substitusjonsverdier fra prepare_values () metode. Igjen vil vi bruke array-nøkkelen og variabelen som separate variabler i for hver sløyfe. For hver theme_mod vi må legge til parentes rundt det, så vi kan bruke den til å erstatte erstatningsstrengen i CSS med str_replace (), som dette:
// Få våre farger. $ colors = $ this-> prepare_values (); // Erstatt hver farge. foreach ($ farger som $ theme_mod => $ farge) $ search = '['. $ theme_mod. ']'; $ css = str_replace ($ søk, $ farge, $ css);
Denne sløyfen gir oss fullstendig gyldig CSS med alle våre brakede tema modnavn erstattet med de riktige heksekodene for fargene. Alt som er igjen, er å pakke inn den behandlede CSS i de aktuelle stiletikettene før du returnerer den:
// Legg til stiletiketter. $ css = ''; returner $ css;
Det er hele preprosessoren. Det eneste trinnet igjen er å sende ut CSS selv. For å gjøre dette kan vi bruke en funksjon, utenfor klassen som initialiserer klassen og utdataer den i temaets topptekst.
Denne funksjonen ser slik ut:
add_action ('wp_head', 'slug_theme_customizer_output'); funksjon slug_theme_customizer_output () // Pass på at vår klasse eksisterer. hvis (class_exists ('Slug_Theme_Customizer_Output')) // Initialiser klassen og få behandlet css. $ class = new Slug_Theme_Customizer_Output (); $ css = $ class-> prosess (); // For å være trygg, kontroller at "prosess" -metoden ikke returnerte falsk eller noe annet enn en streng. hvis ($ css && is_string ($ css)) echo $ css; Hvis du kanskje husker fra før, metoden prosess() kan returnere falsk hvis CSS-filen ikke kunne lastes inn. For å ta hensyn til denne muligheten, før ekko verdien av prosess() metode, er det viktig å sørge for at det ikke returnerer false, og returnerer ikke noe som ikke er en streng.
Ekstra bonusoptimalisering
Mens vi kunne stoppe der, ville jeg gjerne gjøre ting litt mer effektive. Dette systemet fungerer perfekt, men det gjør også mye repeterende prosessering, komplett med det som kan være flere databasespørsmål på hver sidebelastning. Personlig vil jeg heller hoppe over kjører hele klassen og i stedet bare få en streng fra databasen.
For å oppnå dette kan vi omarbeide utskriftsfunksjonen for å cache CSS i en forbigående. På den måten når vi kan hoppe over hele preprosessorklassen hvis transienten har en verdi, hvis ikke, kan vi kjøre hele prosessen og re-cache den. Her er den endrede utgangsfunksjonen:
add_action ('wp_head', 'slug_theme_customizer_output'); funksjon slug_theme_customizer_output () // Enten sett css til forbigående eller gjenoppbygge. hvis (false === ($ css = get_transient ('slug_theme_customizer_css'))) // Pass på at vår klasse eksisterer. hvis (class_exists ('Slug_Theme_Customizer_Output')) // Initialiser klassen og få behandlet css. $ class = new Slug_Theme_Customizer_Output (); $ css = $ class-> prosess (); // Cache css for neste gang. set_transient ('slug_theme_customizer_css', $ css); // For å være sikker, kontroller at "prosess" -metoden ikke returnerte falsk eller noe annet enn en streng. hvis ($ css && is_string ($ css)) echo $ css; Nå, hvis det er en verdi satt i forbigående slug_theme_customizer_css det kan ekko direkte, etter å ha bestått de samme testene for å sikre at det ikke er det falsk eller ikke en streng. Preprosessorklassen er ikke lastet, og bare ett søk blir gjort til databasen. Hvis transienten returnerer falsk, prosessen kjøres og verdien blir cached for neste gang.
Selvfølgelig vil vi sørge for at når temmodusene oppdateres, fjerner vi transienten, slik at den ikke gir utdaterte innstillinger. WordPress vil behandle det når et bestemt alternativ er oppdatert.
Vi kan bruke denne handlingen siden tema mods er lagret alternativ oppkalt etter temaet det er knyttet til. For eksempel lagres TwentyFourteens tema mods i alternativet theme_mods_twentyfourteen. Slik bruker vi denne handlingen, for å fjerne transienten vår:
/ ** * Tilbakestill slug_theme_customizer_css forbigående når tema mods er oppdatert. * / // Få dagens tema navn. $ theme = get_stylesheet (); add_action ("update_option_theme_mods _ $ theme", "slug_reset_theme_customizer_css_transient '); funksjon slug_reset_theme_customizer_css_transient () delete_transient ('slug_theme_customizer_css'); Setter den i bruk og tar den videre
Nå som du kan skrive CSS som blir oppdatert, danner temaet tilpasser med variabler, kan en ting du kanskje vurdere å bruke ett tema mod mange steder.
For eksempel, hva skjer i stedet for å sette et theme_mod for hver farge i temaet, og forårsaker alternativ overbelastning, hva med alternativer for primærfarge, sekundær farge og aksentfarge?
Systemet som jeg har vist deg hvordan du lager her, fungerer bare med fargevalg, noe som gjør det bare veldig nyttig for CSS-egenskaper som farge, bakgrunnsfarge, grensefarge, etc. Du kan utvide den til å være nyttig for andre typer eiendommer.
Bare husk å ikke gjenoppfinne Sass eller mindre, poenget med dette hele var å unngå å oppblåse temaet ditt med en full PHP-implementering Sass eller LESS, som allerede er tilgjengelige som plugins.
