WordPress Gutenberg Block API Blokk Look and Feel

Den nye WordPress-redaktøren (kodenavnet Gutenberg) er på grunn av utgivelse i versjon 5.0. Nå er det den perfekte tiden for å få tak i det før det lander i WordPress-kjerne. I denne serien vil jeg vise deg hvordan du arbeider med Block API og lage dine egne innholdsblokker som du kan bruke til å bygge ut innlegg og sider.

I det første innlegget i denne serien hadde vi en oversikt over Block API og opprettet en enkel blokk for testing. Vi tar en nærmere titt på Block API kort, men først la oss redigere standardblokken vi opprettet i forrige innlegg for å få en følelse for hvor enkelt det er å gjøre endringer i en eksisterende blokk.

Hvis du husker, ble vår tilpassede blokk gjengitt annerledes på forsiden og baksiden for å demonstrere at du har full kontroll over hvordan blokken blir gjengitt inne i redaktøren, og hvordan besøkende ser blokken.

Hvis du har fulgt med, så åpne den / Wp-content / plugins / min-custom-blokk / src / blokk mappe hvor blokkkilden er plassert. Den mappen inneholder en JavaScript-fil og to Sass-filer, som kontrollerer blokkens oppførsel og hvordan den gjøres inne i editoren og på forsiden.

De block.js JavaScript-filen inneholder JSX, som blir transpiled under byggeprosessen til gyldig JavaScript. Tilsvarende blir de to Sass-filene konvertert til standard CSS.

Under byggeprosessen krever disse filene behandling for å lage distribusjonsfiler i pluginets dist / mappe. Dette er de faktiske filene som er godkjent av WordPress, da de inneholder gyldig JavaScript og CSS som alle nettlesere kan forstå.

Heldigvis lag-guten-blokk verktøykasse håndterer bygging og transpiling for oss ved å se etter endringer i blokkeringsfilene våre. Dette er en veldig fin funksjon som det er en mindre ting for oss å bekymre seg for. Vi kan bare fokusere på å skrive vår blokkkode (og stiler), og pluginfilene oppdateres automatisk. Hyggelig!

Bare vær sikker på at du kjører npm start kommando fra innsiden av plugin-rotmappen for å utløse filsporing.

Tid til å redigere noen kode!

Ikke bekymre deg for detaljene i JSX-koden i block.js akkurat som vi vil dekke det i detalj senere. For nå, la oss bare fokusere på å gjøre noen enkle endringer i blokkutgangen for front- og backendevisninger.

Åpne opp block.js, Finn redigere metode for objektet som er det andre argumentet passert til registerBlockType (), og erstatt den med følgende:

rediger: funksjon (rekvisitter) retur ( 
 
Redigeringsvisning
 
Dette er vår egendefinerte blokk inne i redaktøren.
 
La oss legge til en uordnet liste!
 
 
eple
 
oransje
 
Pære
 
Plomme
 
 
 ); ,

Denne metoden styrer hvordan blokken gjøres i redigeringsvinduet. Finn nå lagre metode og erstatt den med:

lagre: funksjon (rekvisitter) retur ( 
 
Frontend View
 
Dette er vår egendefinerte blokk som sett av besøkende på nettstedet.
 
La oss legge til en bestilt liste!
 
 
rød
 
Blå
 
Rosa
 
brun
 
 
 ); ,

Denne metoden brukes til å gjøre blokkutgangen på frontenden.

I style.scss, erstatt alle stiler med:

.wp-block-cgb-blokk-my-custom-blokk bakgrunn: # a7d9f1; farge: #ffffff; grense: 1px solid # 62afd4; border-radius: 15px; margin: 0 auto; maksimal bredde: 740px; polstring: 1.5rem; ol, ul margin-left: 20px! viktig;  li margin-bunn: 0;  h3 farge: #ffffff; margin-topp: 0; 

Så, i editor.scss, erstatt alle stiler med:

.wp-blokk-cgb-blokk-min-tilpasset blokk bakgrunn: # cba7f1; grense: 1px solid # a170d6; 

Du kan se på skjermbildene nedenfor hvordan disse endringene påvirker gjengivelsen av blokken vår, avhengig av om vi ser det i redigeringsvinduet eller frontenden.

Vi vil ikke dekke enqueueing block script enda, men det er nok for nå å vite det editor.scss stiler brukes bare til redigeringsvinduet og style.scsser lagt til både redigeringsvinduet og frontenden. Derfor kan stiler som brukes både i redaktør og frontend, utelates fra style.scss.

Legg merke til hvordan i Sass-filene vi refererer til en lang CSS-velger for å målrette mot blokkelementene våre.

.wp-blokk-CN-blokk-my-custom-blokk

Denne klassen legges automatisk av Gutenberg til blokkbeholderelementet på forsiden, men vi må søke det manuelt i redigeringsvinduet for å få samme klasse som du kan se i redigere metode nedenfor.

Klassenavnet generert av Gutenberg er bestemt som følger: wp-block- [block namespace] - [blokknavn.

I vårt tilfelle brukte vi lag-guten-blokk verktøykasse for å lage vår blokk, som bruker CGB for navneområdet som standard, og block-my-custom-blokk er basert på blokknavnet vi angav. Dette resulterer i CSS klassenavnet wp-blokk-CN-blokk-my-custom-blokk blir lagt til blokkbeholderen. Navneplass og blokknavn brukes av Gutenberg internt for å identifisere blokker unikt.

Når jeg gjorde endringer for å blokkere filer der, fant jeg et par smertepunkter verdt å nevne.

For det første, når du gjør endringer i redigere metode, fant jeg meg selv å måtte slette nettleserens cache før du oppdaterer redigeringsvinduet for å se de siste endringene. Dette skjedde ikke hele tiden, men det var ganske ofte tilfelle. Hvis du finner det samme som skjer med deg, må du bare fjerne nettleserens cache og prøve igjen.

For det andre, når du redigerer innholdet i lagre Metode, noe merkelig ser ut til å skje med redigeringsvinduet når det neste oppdateres.

For å demonstrere dette, la jeg til et nytt liste element (

indigo

) i lagre metode og deretter oppdatere postredigereren (etter at du må tømme hurtigbufferen igjen, selvfølgelig!). Her er resultatet:

Hvis du velger enten Konverter til blokker eller Rediger som HTML så blir du presentert med innholdet i lagre metode, som er ment å bli sett på forsiden og ikke i redaktøren.

Dette er veldig forvirrende, og den eneste åpenbare måten å bringe ting tilbake til normalitet var å slette blokken fra redigeringsvinduet og sette det inn igjen. Som nevnt i forrige innlegg, er Gutenberg fortsatt et pågående arbeid, og dette er et godt eksempel på det!

Forhåpentligvis vil dette bli gjort mer intuitivt i fremtidige versjoner, men for nå er det bare noe å passe på. Når du gjør endringer i lagre fungere, vær forberedt på å slette de relaterte blokkene i redigeringsvinduet og legg til dem igjen.

Som nevnt tidligere, har produksjonen fra lagre og redigere metoder kan være helt forskjellige. Men i de fleste tilfeller vil du sannsynligvis at frontendgangsutgangen skal matche redigeringsutgangen, slik at redigeringsopplevelsen er like konsekvent som mulig med frontend-gjengivelse.

I vårt fremtredende eksempel ovenfor har jeg bare lagt til annet innhold og stiler i redigerings- og frontend-visning for demonstrasjonsformål.

Blokker API-oversikt

Block API består av et sett med JavaScript-objekter som er lagt til globalt wp admin objekt. Og fordi wp er global, trenger vi ikke å importere det spesifikt i vår kildekode, det er tilgjengelig på forespørsel.

Objektene som er tilgjengelige i wp avhengig av admin siden du ser på. For eksempel, hvis du tilpasser nettstedet ditt da wp inneholder det viktigste tilpasset API-objektet. 

Foreløpig er Gutenberg Block API imidlertid bare tilgjengelig på postredigereren. Jeg forventer at dette vil forandres i fremtiden når integrering mellom postredigeringsprogrammet og nettstedet tilpasser seg nærmere.

Du kan se strukturen til wp ved å åpne Gutenberg-redaktøren og skrive inn wp i nettleserkonsollen.

Som du kan se, wp inneholder mange objekter, men de som vi er mest interessert i er:

• wp.elements
• wp.blocks
• wp.components
• wp.data
• wp.i18n

Disse objektene gir deg tilgang til alle verktøyene som trengs for å lage noen svært komplekse blokker. Prøv å skrive inn de fulle objektnavnene i nettleserkonsollen for å utforske disse objektene videre.

For eksempel, hvis du skriver inn wp.blocks og utvide objektet, vil du se at en av de tilgjengelige funksjonene er registerBlockType (). Dette er en svært viktig funksjon som vi dekker i dybden i neste innlegg

De wp.elements Gjenstand

Dette objektet er abstraksjonslaget på toppen av React (og ReactDom) som avslører React-funksjonalitet på en forutsigbar og konsekvent måte. Dette forblir sant selv om den underliggende implementeringen er endret eller endret helt.

Så lenge grensesnittet forblir det samme, vil plugins som interagerer med Block API ikke bli påvirket i fremtiden.

De wp.blocks Gjenstand

Kjernefunksjonen for å lage en blokk (registerBlockType ()) finnes i wp.blocks sammen med andre funksjoner som er nødvendige for generell blokkadministrasjon, for eksempel:

• getBlockType ()
• getBlockContent ()
• getBlockAttributes ()
• hasBlockSupport ()
• isValidBlock ()

Dette objektet inneholder også et sett med gjenbrukbare blokker som du kan inkludere i dine egne blokker for å gi funksjonalitet uten ekstra kostnader. Disse klare blokkene som er ute av boksen, kan øke hastigheten på blokkutviklingen dramatisk, og vi vil benytte noen av dem i neste innlegg som vi dyper videre til blokkdannelse.

Noen av de tilgjengelige er:

• justering verktøylinjen
• Autofullfør
• media opplasteren
• farge palett
• rik tekstredigerer

De wp.components Gjenstand

De wp.components objekt inneholder også gjenbrukbare komponenter, men disse er mer generiske og brukes vanligvis til å opprette flere brukergrensesnittelementer i redigeringsvinduet, for eksempel kontrollpaneler for blokkinnstillinger.

Disse inkluderer:

• knapp
• avkrysnings
• kode redaktør
• dash ikon
• dato tid
• fall ned
• menyelement
• radioknapp
• rekkevidde kontroll

De wp.data Gjenstand

Datamodulen administrerer applikasjonsstatus i Gutenberg-editoren, som inkluderer lagring av innstillinger for hver blokk. Vi tar en titt på forskjellige måter du kan legge til innstillinger i en blokk i det siste innlegget i denne serien.

wp.data implementeres på toppen av Redux, så når Gutenberg slås sammen med kjernen, har vi ikke bare tilgang til React, men også til en komplett sentralisert datalager drevet av Redux! 

Det wp.i18n objektet

Plugins og temaer har i løpet av flere år lett å oversette PHP-strenger, og en lignende metode er også tilgjengelig for å oversette strenger i JavaScript takket være wp.i18n gjenstand. Dette betyr at alle strenger som finnes i blokken din, inkludert blokknavn, nøkkelord og etiketter, kan oversettes til hvilket som helst språk.

Hvis du har brukt standard PHP oversettelse funksjoner før da vil du føle deg hjemme, da prosessen er stort sett den samme. Jeg tror dette er et smart trekk da det vil oppfordre utviklere til å aktivere strengoversettelser i blokkene deres fra begynnelsen.

Innenfor blokkekoden er oversettelse av en streng like enkelt som:

wp.i18n .__ ('Denne strengen er oversettbar', 'tekst-domene');

Konklusjon

I denne opplæringen har vi implementert en grunnleggende blokk og redigert koden. Vi har også sett at vi har total kontroll over blokkgengivelse og kan ha forskjellige blokkvisninger i redigereren sammenlignet med forenden.

Redaktøren har fortsatt noen problemer som kan overraske deg fra tid til annen. Dette tjener som en påminnelse om at Gutenberg fortsatt er i utvikling og kanskje ikke er klar til bruk på produksjonssteder.

Til slutt avsluttet vi med en oversikt over blokk-API, som introduserer flere nye objekter på global wp JavaScript-objekt for å opprette og administrere blokker.

I neste innlegg vil vi hente tempoet og opprette en mer omfattende blokk. For å gjøre det, vil vi utforske registerBlockType () fungere i dybden. Vi vil også ta en nærmere titt på riktig enqueueing blokkeringsskriptene dine.