Kas olete kunagi leidnud end olukorrast, kus soovite lisada oma kohandatud sätted WordPressi Gutenbergi plokkidesse? Selles postituses käsitleme üksikasjalikult, kuidas seda teha. Leiate kaks näidet WordPressi plokkidele kohandatud sätete lisamise tegelikest kasutusjuhtudest.
Pidage meeles, et kuna Gutenbergi plokid on Javascript, peate nende muutmiseks koodi kirjutama Javascriptis. Nii nagu WordPressi PHP-koodil on konksud ja filtrid, mis võimaldavad teemade või pistikprogrammide arendajatel selle koodi muuta, on ka WordPressi Javascripti koodis filtreid. Sarnaselt PHP [add_filter](https://developer.wordpress.org/reference/functions/add_filter/)()funktsioonile on meil Javascripti funktsioon [addFilter](https://developer.wordpress.org/block-editor/packages/packages-hooks/#api-usage)().
Kirjutan koodi Javascript ES6 süntaksis, mille teisendamiseks on vaja kompilaatorit. Saate kirjutada ES5 süntaksis, kuid soovitan kasutada ES6/ESNext. Mul on postitus, mis selgitab ES6/ESNexti trafo seadistamist. Samuti eeldan, et tunnete Reacti/JSX-i, võib-olla on teil kogemusi, kuidas luua oma kohandatud Gutenbergi plokke.
Mida saate Gutenbergi plokkidel filtreerida
Saadaolevate Gutenbergi konksude ja filtrite hulgas pole palju dokumentatsiooni. Aga selleks, et lisada kohandatud sätteid ja neid kuidagi olemasolevatele plokkidele rakendada; selle olen siiani leidnud. Olen keskendunud lihtsate sätete lisamisele – mitte toimingutele, mis nõuavad komponentide drastilisi muudatusi või keerukat käitumist.
Olemasolevatele plokkidele kohandatud sätete lisamiseks on kolm sammu:
- Lisame olemasoleva ploki
[registerBlockType](https://developer.wordpress.org/block-editor/developers/block-api/block-registration/#registerblocktype)seadete massiivi filtri. See võimaldab meil massiivile uusi atribuute lisadaattributes, võimaldades seega plokki lisateavet salvestada. Peame oma kohandatud seaded kuhugi salvestama. - Haakige ploki
editkomponendi külge (komponent, mis vastutab redaktoris ploki renderdamise eest). Selle konksuga saame haakuda inspektori (küljeriba) külge ja lisada oma komponente. Saame kas lisada uue jaotise/paneeli või haakuda jaotisega "Täpsemalt", mis on alati kõikides plokkides olemas. Siis on meie teha seadistussisendeid, nagu tekstisisestus, märkeruudud või muu. - Filtreerige ploki
saverekvisiidid. Saame reguleerida salvestamise rekvisiite, mis vastutavad nii ploki salvestamise kui ka renderdamise eest (väljaspool redaktorit). Meie puhul tahame lisada klassi või tekstisisese stiili.
Saame sihtida konkreetseid plokke või kõiki. Meil on alati juurdepääs sellele, millist tüüpi plokis me viibime.
Teisisõnu öeldes: lisame Inspectoris mõned kohandatud sätted ja salvestame need kohandatud atribuutidesse, mille oleme plokki lisanud. Seejärel saame mõjutada ploki klassi nime või tekstisisest stiili (mõnel juhul), olenevalt salvestatud atribuutidest. Kohandatud klassinimede abil saame hõlpsasti lisada kohandatud CSS-i, mis annab meie seadetele visuaalselt efekti.
Mida me ei saa (praegu?)
Kahjuks on mõned asjad, millele me olemasolevate plokkide filtritega juurde ei pääse. Mis puudutab lihtsate kohandatud sätete lisamist plokkidele, siis need on tavalised asjad, mida me mõjutada ei saa.
Redaktoris pole juurdepääsu ploki tekstisisesele stiilile
Ploki kujundust mõjutavate sätete puhul peame lisama ploki mähkimissõlmele tekstisisese stiili. Lihtsalt klassi nimi ei sobi. Näiteks kui lisate kohandatud värviseade ja kasutaja valib kohandatud värvi (värvivalija abil), ei saa te seda klassi lisamisega lahendada – vajate tekstisisese stiili.
Kahjuks näib, et WordPressi vaikeplokid käsitlevad redaktoris tekstisisest stiili täiesti iseseisvalt, ilma filtreerimise või „haakimise" võimaluseta. Näitan allpool viimases näites viisi, kuidas sellest mööda minna, kuid see pole kõigil juhtudel ideaalne.
Võite küsida, miks hoolite sellest, et plokk näeb redaktoris välja erinevalt esiküljest? Kogu Gutenbergi mõte on rakendada visuaalset viisi sisu redigeerimiseks, kus see, mida näeme, on tegelikult see, mida me saame. Soovime saavutada sama visuaalse välimuse nii redaktoris kui ka kasutajaliideses.
Mõned plokid ei sisalda redaktoris klassi nime
Nagu eespool mainitud, saame filtreerida ploki ümbrisklassi nime, kuna see on rekvisiit, mis edastatakse kõigile Gutenbergi plokkidele. Kuid kahjuks on mõned plokid, mis ei rakenda ploki klassi edit. Üks näide on katteplokk. Olen palju mänginud, kasutades kaaneplokke esilehtede "sektsioonidena", ja pidevalt tekib probleeme, kuna kaaneplokk loob oma klassi edit. See jätab täielikult vahele, kaasa arvatud ploki “globaalne” klass (millele on meil juurdepääs filtrite kaudu).
Kuid vähemalt saame olla kindlad, et filtreeritud klassinimesid rakendatakse alati save(frontendis). See juhtub automaatselt väljaspool iga ploki spetsiifilist koodi.
Kui ma eksin mõne ülaltoodu suhtes, siis palun andke mulle allolevates kommentaarides teada! Õpin pidevalt Gutenbergi ja samal ajal areneb ka Gutenberg. Loodan, et ühel hetkel on ülaltoodu ühel hetkel võimalik või et see on võimalik, kuid mul on lihtsalt puudu oluline teave!
Kui see on kõrvale jäänud, hakkame mõnda koodi uurima.
Näide 1: lisage lülitusväli, et peita mobiilis kaaneplokk
Oletame, et töötame välja teema, mille puhul kaaneplokke kasutatakse esilehel olevate jaotiste jaoks. Ja me tahame anda kasutajale võimaluse teatud osa mobiili eest peita. Selle lahendamiseks saame kaaneploki inspektori jaotisesse "Täpsemalt" lisada lülitusvälja. Kui väli on sisse lülitatud, saab kaaneplokk täiendava kohandatud klassi, mida saame sihtida CSS-i ja meediapäringute abil.
Muide: see on juhtum, kus kaaneploki probleem, mis ei rakenda meie kohandatud klassinimesid redaktoris, on tegelikult kasuks! Kujutage ette, kui oleks; siis poleks kasutajal võimalik plokki redigeerijas redigeerida, kui tal on väike ekraan!
Nagu varem mainitud, peame kodeerima kolme sammu. Peame lisama ka PHP, et oma Javascripti fail redaktorisse järjekorda panna. Teeme seda kõigepealt.
Meie skripti lisamine redaktorisse
Me ühendame funktsiooni toimingu külge [enqueue_block_editor_assets](https://developer.wordpress.org/reference/hooks/enqueue_block_editor_assets/). Oma funktsiooni sees paneme skripti järjekorda, nagu tavaliselt wp_enqueue_scriptskonksu puhul.
add_action('enqueue_block_editor_assets', function() {
wp_enqueue_script('awp-gutenberg-filters', get_template_directory_uri(). '/assets/js/gutenberg-filters.js', ['wp-edit-post']);
});Ärge unustage kohandada teed sinna, kus teie skript asub! Märkus. Kui kirjutate ES6-s ja Javascripti kompileerib veebipakett, ärge unustage määrata skripti järgu tee, mitte allika.
Mulle meeldib lisada wp-edit-postskriptile sõltuvusena, et tagada selle laadimine piisavalt hilja.
See on kõik PHP, mida me tegema peame. Ülejäänu on kirjutatud meie Javascripti faili.
Lisage kohandatud atribuut
Esimene filter, mida kasutame, on see, blocks.registerBlockTypemillise filtri registerBlockTypeseadete objekt.
Aga kõigepealt natuke Javascripti filtrite lisamisest. Kuna ma pole selle kohta ühtegi head dokumentatsiooni leidnud, siis selgitan seda siin veidi. Funktsioon addFilterasub wp.hooksnimeruumis ja aktsepteerib nelja argumenti.
addFilter('hookName', 'namespace', 'functionName', 'priority');
Esimene parameeter ‘hookName’ on filtri nimi, mille külge tahame ühendada. See on samaväärne esimese parameetriga PHP-de kasutamisel add_filter(). Teine parameeter "nimeruum" on teie koodi kohandatud nimeruumi nimi. See on lihtsalt selleks, et vältida nimede kokkupõrkeid. Siin saate määrata peaaegu kõike, mida soovite, lihtsalt ärge kasutage WordPressi nimeruumi (‘wp’). Kasutage oma nime või projekti nime lühivormi. Kolmas parameeter "functionName" on konksuga funktsioon – mis on sama mis PHP add_filter()teine argument. Ja lõpuks neljas parameeter "prioriteet" on valikuline. Jällegi, see on sama, mis PHP add_filter()kolmas argument.
Javascripti filtrite protsess on sama, mis PHP-s. Määratleme funktsiooni, mis peab tagastama filtreeritud muutuja. Mõnikord on muutujaks string, objekt või komponent. Funktsiooni sees muudame muutujat oma äranägemise järgi.
Meie puhul tahame ploki attributeobjektile lisada uue atribuudi. Kutsume välja uue atribuudi hideOnMobileja määrame selle tüübiks boolean. Seda tehakse järgmiselt:
function addCoverAttribute(settings, name) {
if (typeof settings.attributes !== 'undefined') {
if (name == 'core/cover') {
settings.attributes = Object.assign(settings.attributes, {
hideOnMobile: {
type: 'boolean',
}
});
}
}
return settings;
}
wp.hooks.addFilter(
'blocks.registerBlockType',
'awp/cover-custom-attribute',
addCoverAttribute
);Reas sihime #3kindlasti ainult plokke, mille tüüp on „ core/cover“. Teiseks blocks.registerBlockTypefiltreerimisargumendiks piisab mugavalt ploki nimest. Seejärel lisame objektile uue settings.attributesobjektielemendi. Lõpuks tagame kindlasti filtreeritud muutuja settings.
Praegu ei ole Gutenbergis visuaalselt midagi muutunud. Kuid kõigil kaaneplokkidel on nüüd täiendav atribuut, mida saame kasutada oma seadete salvestamiseks.
Seade lisamine inspektorisse (täpsem paneel)
Teist filtrit kutsutakse editor.BlockEditja see filtreerib ploki editkomponendi. See filter võtab vastu algse ploki BlockEditkomponendi ja tagastab uue pakitud komponendi. wp.compose.createHigherOrderComponentPakitud komponendi tagastamiseks peame kasutama .
BlockEditMeie komponendi sees renderdame sellest hoolimata kindlasti pakitud komponendi. Kui aga plokk on tüüpi Cover, ühendame me ka komponendi külge InspectorAdvancedControls(mis on Inspectori paneel Advanced) ja lisame ToggleControl. Kirjutame, ToggleControlet näidata varem lisatud kohandatud atribuudi väärtust ja värskendada seda hideOnMobile.
Ärge unustage alati originaali tagastada BlockEdit, mida teeme real #9. Real #10 kontrollime, kas ploki tüüp on Cover, ja renderdame InspectorAdvancedControlskomponendi. Siia sisse lisame ToggleControl, mis on sisendi juhtelement, mis kuvatakse tõese või vale vahel. Määrame sildi ja ühendame selle väärtuse hideOnMobileatribuudiga. Kui olete varem Inspectori seadeid lisanud, peaks see olema teile üsna lihtne.
Ülaltoodud koodiga peaksime selle nüüd saama kaaneplokkide inspektori paneelil "Täpsemalt":
Sisend värskendab nüüd meie kohandatud atribuuti hideOnMobile. Viimane samm on teha midagi sõltuvalt selle atribuudi väärtusest. Praeguse seisuga on atribuut salvestatud, kuid see ei mõjuta tegelikult midagi.
Lisage kohandatud klass
Viimane samm on kohandatud klassi lisamine ploki klassi. Teeme seda filtriga blocks.getSaveContent.extraProps. See filter mõjutab ploki savekomponendi tugipunkte. Üks neist on prop className, mida rakendatakse alati esiservas. Kui atribuut oli, lisame selle järele oma kohandatud klassi trueja tagastame selle. Otsustasin lisada klassi „ hide-on-mobile“, kuid võite seda nimetada kuidas iganes soovite.
See kood on üsna iseenesestmõistetav. Real #4kontrollime, kas atribuut hideOnMobileon olemas ja on true. classNameKui jah, siis lisame stringile kohandatud klassi .
Kõigi ülaltoodud kolme filtriga peaksime nüüd saama kohandatud klassi „peida mobiilis”, kui seade on sisse lülitatud, meie kaaneplokile rakendatud.
Jääb üle vaid lisada oma teema kasutajaliidese stiililehele CSS-i. Midagi sellist;
.wp-block-cover.hide-on-mobile { display: none; }
@media (min-width: 480px) {
.wp-block-cover.hide-on-mobile { display: block; }
}Näide 2: Lisage vaheploki jaoks kohandatud taustavärvi sättega Inspektori paneel
Teisel kasutusjuhul tahame lisada väliplokile kohandatud värvisätteid. Vaikimisi pole spaceri plokil muid seadistusi peale selle kõrguse. Oletame, et tahame lisada taustavärvi, mis värvib spaceri ploki täiskõrguse. See võimaldab kasutajal lisada sisu sisse tühje värvilisi triipe. Sel juhul tahame lisada värvisätted Inspectori eraldi paneelile, nagu tavaliselt värvisätete puhul oodatakse.
Märkus. Värvide käsitlemine on veidi keerulisem, kuna peame kasutama (muud) kõrgemat järku komponenti withColors. Kuna me peame juba rakendama kõrgemat järku komponenti, editor.BlockEditpeame kasutama composemitut komponenti. Lisaks peame iga värviseade jaoks lisama kaks atribuuti. Üks sisaldab värvipaleti näppu ja teine hex-värvikoodi – ainult siis, kui kasutaja on valinud kohandatud värvi (kasutas värvivalijat). See kõik on tavaline käitumine rakendusega töötamisel withColors. Mul on <a href="https://wordpress.mediadoma.com/et/kuidas-lisada-kohandatud-gutenbergi-plokki-vaervisaetteid/" title="postitus, mis selgitab värviseadete lisamist ja withColorsüksikasjalikult,” >postitus, mis selgitab värviseadete lisamist ja withColorsüksikasjalikult, kui jääte segadusse.
Teiseks puutume sel juhul kokku ülaltoodud probleemiga; kus me ei saa redaktorisse sobivat tekstisisest stiili lisada. Lahendus, mille olen sel juhul valinud, on mähkida divredaktoris spacer plokk a sisse ja rakendada mähistamisele õiged klassid ja tekstisisese stiili div. See muudab valitud värvi redaktoris nähtavaks, kui plokk on tühistatud. Ploki valimisel lisab WordPress aga plokile oma kohandatud helehalli tausta, mis katab meie kohandatud taustavärvi. Üks CSS redaktorile parandab selle. Lõpus selgitan täpsemalt.
Toimingud on samad, mis ülaltoodud näites. Esmalt paneme oma skripti PHP-redaktorisse järjekorda. Seejärel filtreerime Javascriptis attributesobjekti, spaceri editkomponendi ja lõpuks spaceri savekomponendi.
Meie skripti lisamine redaktorisse
Me ühendame funktsiooni toimingu külge [enqueue_block_editor_assets](https://developer.wordpress.org/reference/hooks/enqueue_block_editor_assets/). Oma funktsiooni sees paneme skripti järjekorda, nagu tavaliselt wp_enqueue_scriptskonksu puhul.
add_action('enqueue_block_editor_assets', function() {
wp_enqueue_script('awp-gutenberg-filters', get_template_directory_uri(). '/assets/js/gutenberg-filters.js', ['wp-edit-post']);
});Ärge unustage kohandada oma skripti teed. Mulle meeldib lisada wp-edit-postskriptile sõltuvusena, et tagada selle laadimine piisavalt hilja.
See on kõik PHP, mida me tegema peame. Ülejäänu on kirjutatud meie Javascripti faili.
Lisage kohandatud atribuudid
Nagu ülaltoodud näites, lisame sisse filtri blocks.registerBlockType, et lisada ploki attributesobjektile täiendavaid objekte.
Sellega töötades withColorspeame iga värvi jaoks lisama kaks atribuuti. Meie taustavärvi atribuudi nimi on backgroundColor, mis tähendab, et teisele atribuudile tuleb anda nimi customBackgroundColor. Seda kõike selgitatakse minu postituses värviseadete käsitlemise kohta Gutenbergis. Mõlemad peaksid olema stringi tüüpi ja neid tuleks rakendada ainult spacer tüüpi plokkidele.
function addSpacerAttributes(settings, name) {
if (typeof settings.attributes !== 'undefined') {
if (name == 'core/spacer') {
settings.attributes = Object.assign(settings.attributes, {
backgroundColor: {
type: 'string',
},
customBackgroundColor: {
type: 'string'
}
});
}
}
return settings;
}
wp.hooks.addFilter(
'blocks.registerBlockType',
'awp/spacer-background-attribute',
addSpacerAttributes
);Lisage inspektorisse ColorSettings paneel
Teine samm on värviseadete paneeli lisamine ploki Inspector for the Spacer jaoks filtreerimise teel editor.BlockEdit.
Peame kasutama compose, et kombineerida sellest filtrist tagastatud kõrgemat järku komponenti ja withColors. Teisisõnu mähkime tagastatud komponendi lihtsalt withColors. Parameetrina withColorsanname oma atribuudi backgroundColor.
Pakitud komponendi sees tagame alati tagasituleku BlockEdit(joon #9ja #39vaheplokkide puhul). Spaceri tüüpi plokkide puhul ühendame ka selle külge InspectorControls, et lisada PanelColorSettingsoma värvivaliku jaoks a. See on värviseadete lisamise standardprotseduur.
Real #17 - 34genereerime käsitsi vajaliku klassi ja/või tekstisisese stiili. Seejärel #38lisame reale BlockEditnende klasside ja tekstisiseste stiilidega ümbrislause.
Tulemuseks on Inspector for Spacer blocks uus värviseadete paneel, mis on täiesti töökorras.
Paleti värvi või kohandatud värvi valimist mõjutab redaktoris tõepoolest ümbris. Kuid näete seda ainult siis, kui tühistate spaceri ploki valiku!
See juhtub seetõttu, et WordPress rakendab vaheploki valimisel oma stiili. Me parandame selle lõpus, kõigepealt peame lihtsalt kasutama sama klassi ja/või sisemist stiili ka frontendis.
Salvestamiseks lisage kohandatud klass ja tekstisisene stiil
Lõpuks peame filtreerima blocks.getSaveContent.extraPropsja rakendama kasutajaliidese jaoks vajaliku klassi ja/või tekstisisese stiili. See on jällegi väga sarnane sellega, mida tegime ülaltoodud näites 1. Kui valiti paleti värv, peame lisama klassi nime, mis järgib WordPressi värviseadete standardeid (” has-<PALETTESLUG>-background-color“). Kui valiti kohandatud värv, peame lisama sisemise stiili kuuskantvärviga.
Märkus. Kui teil on vaja palju klassinimesid käsitleda, soovitan classnamesteeki importida. Seda kasutatakse Gutenbergis palju, kuna see lihtsustab õigete klassinimede määramist palju. Allolev kood eeldab, et te pole seda teinud, ja koostab klassi nime käsitsi.
function applySpacerBackground(props, blockType, attributes) {
if (blockType.name == 'core/spacer') {
const { backgroundColor, customBackgroundColor } = attributes;
// For improved class name handling, use classnames library. Or do it manually like..
let className = (props.className != undefined)? props.className: '';
if (backgroundColor != undefined) {
className += ' has-' + backgroundColor + '-background-color';
}
props.className = className;
if (customBackgroundColor != undefined) {
Object.assign(props, { style: { ...props.style, backgroundColor: customBackgroundColor }});
}
}
return props;
}
wp.hooks.addFilter(
'blocks.getSaveContent.extraProps',
'awp/spacer-apply-class',
applySpacerBackground
);Ülaltoodud koodiga renderdab kasutajaliides nüüd suurepäraselt meie kohandatud värvivalikuga Spaceri plokke!
Viimane (valikuline) parandus on CSS-i lisamine redaktorisse. Peate lisama tekstisisese CSS-i või redaktori laaditabeli. Näiteks saate laaditabeli järjekorda panna samasse PHP-konksu, mida kasutasime oma Javascripti faili järjekorda seadmiseks. Ma ei hakka üksikasjalikult kirjeldama, kuidas seda teha; kuid vajalik CSS on midagi sellist nagu allpool. Kui plokk on valitud, seab see ainult vahetüki background-colorpärilikule värvile (see pärib meie ümbrisdivist):
.block-library-spacer__resize-container.is-selected {
background-color: inherit;
}PS: Pidage meeles, et see võib tulevikus muutuda. Gutenberg areneb endiselt tugevalt.
Järeldus
Selles postituses õppisime kahte meetodit kohandatud sätete rakendamiseks olemasolevatele WordPressi Gutenbergi plokkidele. See on täiesti võimalik lihtsate seadistuste puhul, mis nõuavad võib-olla ainult klassi või tekstisisest stiili. Vaatasime hoiatusi, mis loodetavasti parandatakse hilisemates Gutenbergi versioonides!