Platon Data Intelligence.
Vertikal søgning & Ai.

Brug af det nye begrænsede layout i WordPress-bloktemaer

Dato:

Et af hovedmålene for WordPress Site Editor (og ja, det er nu "officielt" navn) er at flytte grundlæggende blokstyling fra CSS til struktureret JSON. JSON-filer er maskinlæsbare, hvilket gør det forbrugsdygtigt af den JavaScript-baserede Site Editor til at konfigurere et temas globale stilarter direkte i WordPress.

Det er ikke helt der endnu! Hvis vi ser på Twenty Twenty-Two (TT2) standardtemaet, var der to hoved uløste problemer: styling interaktioner (synes godt om :hover, :active, :focus), Og marginalerne , polstring af layoutcontainere. Du kan se, hvordan de midlertidigt blev rettet i TT2 style.css fil i stedet for at gøre den til theme.json fil.

WordPress 6.1 løst disse problemer, og det, jeg vil gøre, er at se specifikt på sidstnævnte. Nu hvor vi har JSON-ificerede stilarter til marginer og polstring af layoutcontainere, åbner det os op til mere fleksible og robuste måder at definere mellemrum i vores temalayouts.

Hvilken slags afstand taler vi om?

For det første har vi allerede polstring på rodniveau hvilket er en fancy måde at beskrive polstring på <body> element. Det er rart, fordi det sikrer ensartet mellemrum på et element, der deles på alle sider og indlæg.

Men der er mere til det, for nu har vi en måde, hvorpå blokke kan omgå den polstring og justere sig i fuld bredde. Det er takket være polstringsbevidste justeringer som er en ny opt-in-funktion theme.json. Så selvom du har polstring på rodniveau, kan du stadig tillade f.eks. et billede (eller en anden blok) at bryde ud og gå i fuld bredde.

Det får os til en anden ting, vi får: begrænsede layouts. Ideen her er, at alle blokke, der er indlejret i layoutet, respekterer layoutets indholdsbredde - som er en global indstilling - og ikke flyder uden for den. Vi kan tilsidesætte den adfærd på en blok-for-blok basis med justeringer, men vi kommer til det.

Lad os starte med…

polstring på rodniveau

Igen, dette er ikke nyt. Vi har haft mulighed for at sætte polstring på <body> element i theme.json siden den eksperimentelle Gutenberg plugin introducerede det i version 11.7. Vi sætter den på styles.spacing objekt, hvor vi har margin , padding objekter til at definere den øverste, højre, nederste og venstre afstand på kroppen:

{ "version": 2, "styles": { "spacing": { "margin": { "top": "60px", "right": "30px", "bottom": "60px", "left": "30px" }, "padding": { "top": "30px", "right": "30px", "bottom": "30px", "left": "30px" } } }
}

Dette er en global indstilling. Så hvis vi skulle åbne DevTools og inspicere <body> element, ville vi se disse CSS-stile:

body { margin-top: 60px; margin-right: 30px; margin-bottom: 60px; margin-left: 30px; padding-top: 30px; padding-right: 30px; padding-bottom: 30px; padding-left: 30px;
}

Fedt nok. Men heri ligger spørgsmålet om, hvordan i alverden vi kan tillade nogle blokke at bryde ud af det mellemrum for at fylde hele skærmen fra kant til kant. Det er derfor afstanden er der, ikke? Det hjælper med at forhindre, at det sker!

Men der er faktisk masser af tilfælde, hvor du måske ønsker at bryde ud af denne afstand på en engangsforekomst, når du arbejder i Block Editor. Lad os sige, at vi pletter en billedblok på en side, og vi vil have, at den skal gå i fuld bredde, mens resten af ​​indholdet respekterer polstringen på rodniveau?

Gå ind…

Polstringsbevidste justeringer

Mens du forsøger at oprette det første standard WordPress-tema, der definerer alle stilarter i theme.json fil, leder designer Kjell Reigstad illustrerer de udfordrende aspekter ved at bryde ud af polstring på rodniveau i denne GitHub problem.

Polstring på rodniveau forhindrer blokke i at optage hele visningsportens bredde (venstre). Men med polstringsbevidste justeringer kan nogle blokke "fravælge" denne afstand og optage hele visningsportens bredde (højre). (Billedkredit: Kjell Reigstad)

Nye funktioner i WordPress 6.1 blev oprettet for at løse dette problem. Lad os grave i dem næste.

useRootPaddingAwareAlignments

En ny useRootPaddingAwareAlignments ejendom blev oprettet for at løse problemet. Det blev faktisk først introduceret i Gutenberg plugin v13.8. Det original pull anmodning er en fin primer på hvordan det virker.

{ "version": 2, "settings": { "appearanceTools": true, "useRootPaddingAwareAlignments": true, // etc. },

Læg mærke til, at dette er en funktion, vi skal tilvælge. Ejendommen er indstillet til false som standard, og vi skal udtrykkeligt indstille det til true for at aktivere det. Læg også mærke til, at vi har appearanceTools indstillet til true også. Det tilmelder os UI-kontroller i webstedseditoren til styling af rammer, linkfarver, typografi og, ja, mellemrum, som inkluderer margen og polstring.

Lokal område appearanceTools indstillet til true tilvælger automatisk blokke i margen og polstring uden at skulle indstille heller settings.spacing.padding or setting.spacing.margin til true.

Når vi aktiverer useRootPaddingAwareAlignments, er vi forsynet med brugerdefinerede egenskaber med rodudfyldningsværdier, der er indstillet på <body> element på forenden. Interessant nok anvender den også polstringen til .editor-styles-wrapper klasse, så afstanden vises, når du arbejder i back-end Block Editor. Ret sejt!

Jeg var i stand til at bekræfte disse tilpassede CSS-egenskaber i DevTools, mens jeg gravede rundt.

Aktivering useRootPaddingAwareAlignments anvender også venstre og højre polstring til enhver blok, der understøtter "indholds"-bredde- og "brede"-breddeværdierne i Global Styles-billedet ovenfor. Vi kan også definere disse værdier i theme.json:

{ "version": 2, "settings": { "layout": { "contentSize": "640px", "wideSize": "1000px" } }
}

Hvis indstillingerne for Global Styles er anderledes end det, der er defineret i theme.json, så har Global Styles forrang. Du kan lære alt om styring af bloktemastile i min sidste artikel.

  • contentSize er standardbredden for blokke.
  • wideSize giver en "bred" layoutmulighed og etablerer en bredere søjle, hvor blokke kan strækkes ud.

Så det sidste kodeeksempel vil give os følgende CSS:

/* The default content container */
.wp-container-[id] > * { max-width: 640px; margin-left: auto !important; margin-right: auto !important;
} /* The wider content container */
.wp-container-[id] > .alignwide { max-width: 1000px;
}

[id] angiver et unikt nummer, der automatisk genereres af WordPress.

Men gæt hvad vi ellers får? Fuld justering også!

.wp-container-[id] .alignfull { max-width: none;
}

Kan du se det? Ved at aktivere useRootPaddingAwareAlignments og definerende contentSize , wideSize, får vi også en fuld justering CSS-klasse for i alt tre containerkonfigurationer til styring af bredden af ​​blokke, der føjes til sider og indlæg.

Dette gælder for følgende layout-specifikke blokke: Kolonner, Gruppe, Indlægsindhold og Forespørgselsløkke.

Bloker layoutkontroller

Lad os sige, at vi tilføjer nogen af ​​de førnævnte layoutspecifikke blokke til en side. Når vi vælger blokken, giver brugergrænsefladen for blokindstillinger os nye layoutindstillinger baseret på settings.layout værdier vi definerede i theme.json (eller Global Styles UI).

Vi har at gøre med meget specifikke blokke her - dem, der kan have andre blokke indlejret indeni. Så disse layoutindstillinger handler i virkeligheden om at kontrollere bredden og justeringen af ​​de indlejrede blokke. Indstillingen "Indre blokke bruger indholdsbredde" er aktiveret som standard. Hvis vi slår det fra, så har vi nej max-width på beholderen og klodserne inde i den går kant til kant.

Hvis vi lader knappen være slået til, vil indlejrede blokke holde sig til enten contentWidth or wideWidth værdier (mere om det om lidt). Eller vi kan bruge de numeriske input til at definere brugerdefineret contentWidth , wideWidth værdier i dette engangstilfælde. Det er stor fleksibilitet!

Brede blokke

De indstillinger, vi lige har kigget på, er indstillet på forældreblokken. Når vi har indlejret en blok inde og valgt den, har vi yderligere muligheder i den blok for at bruge contentWidth, wideWidth, eller gå i fuld bredde.

Denne billedblok er indstillet til at respektere contentWidth indstilling, mærket "Ingen" i kontekstmenuen, men kan også indstilles til wideWidth (mærket "Wide width") eller "Fuld bredde".

Læg mærke til, hvordan WordPress multiplicerer de tilpassede CSS-egenskaber for polstring på rodniveau med -1 for at skabe negative margener, når du vælger "Fuld bredde".

.alignfull klasse indstiller negative margener på en indlejret blok for at sikre, at den fylder hele visningsportens bredde uden at komme i konflikt med udfyldningsindstillingerne på rodniveau.

Brug af et begrænset layout

Vi har lige dækket de nye mellemrum og justeringer, vi får med WordPress 6.1. Disse er specifikke for blokke og alle indlejrede blokke i blokke. Men WordPress 6.1 introducerer også nye layoutfunktioner for endnu mere fleksibilitet og konsistens i et temas skabeloner.

Eksempel: WordPress har fuldstændig omstruktureret sine Flex- og Flow-layouttyper og givet os en hæmmet layout type, der gør det nemmere at justere bloklayouts i temaer ved hjælp af indstillingerne for indholdsbredde i Site Editor's Global Styles UI.

Flex-, Flow- og Constrained-layouts

Forskellen mellem disse tre layouttyper er de stilarter, de udskriver. Isabel Brison har en fremragende skrivning det skitserer forskellene fint, men lad os omskrive dem her for reference:

  • Flow layout: Tilføjer lodret mellemrum mellem indlejrede blokke i margin-block retning. Disse indlejrede blokke kan også justeres til venstre, højre eller centreret.
  • Begrænset layout: Samme nøjagtige aftale som et Flow-layout, men med breddebegrænsninger på indlejrede blokke, der er baseret på contentWidth , wideWidth indstillinger (enten i theme.json eller Global Styles).
  • Flex layout: Dette var uændret i WordPress 6.1. Det bruger CSS Flexbox at skabe et layout, der flyder vandret (på række) som standard, men som også kan flyde lodret, så blokke stables oven på hinanden. Mellemrum anvendes ved hjælp af CSS gap ejendom.

Denne nye tavle af layouttyper opretter semantiske klassenavne for hvert layout:

Semantisk layout klasse Layouttype Understøttede blokke
.is-layout-flow Flow layout Kolonner, gruppe, indlægsindhold og forespørgselsløkke.
.is-layout-constrained Begrænset layout Kolonner, gruppe, indlægsindhold og forespørgselsløkke.
.is-layout-flex Flex layout Kolonner, knapper, sociale ikoner

Justin Tadlock har en omfattende skrivning om de forskellige layouttyper og semantiske klasser, herunder use cases og eksempler.

Opdatering af dit tema for at understøtte begrænsede layouts

Hvis du allerede bruger et bloktema, du selv har lavet, vil du det opdatere det for at understøtte begrænsede layouts. Det eneste, der skal til, er at skifte et par ting ud theme.json:

{ "version": 2, "settings": { "layout": { "type": "constrained", // replaces `"inherit": true` "type": "default", // replaces `"inherit": false` } }
}

Disse er for nylig udgivne bloktemaer, der har aktiveret afstandsindstillinger med useRootPaddingAwareAlignments og få en opdateret theme.json fil, der definerer et begrænset layout:

Deaktivering af layoutstile

Basislayoutstilene er standardfunktioner, der leveres i WordPress 6.1 Core. Med andre ord, de er aktiveret lige ud af boksen. Men vi kan deaktivere dem, hvis vi har brug for det med dette lille uddrag functions.php:

// Remove layout styles.
add_theme_support( 'disable-layout-styles' );

Stor advarsel her: deaktiverer også understøttelse af standardlayouttyperne fjerner al basisstyling for disse layouts. Det betyder, at du bliver nødt til at rulle dine egne stilarter til mellemrum, justeringer og alt andet nødvendigt for at vise indhold i forskellige skabelon- og blokkontekster.

Indpakning op

Som en stor fan af billeder i fuld bredde er det nye indeholdte WordPress 6.1-layout og polstringsbevidste justeringsfunktioner to af mine mest favoritter endnu. Taget sammen med andre værktøjer, herunder bedre margin- og polstringskontrol, flydende typografi, og opdaterede liste- og citatblokke, blandt andre, er et solidt bevis på, at WordPress bevæger sig mod en bedre oplevelse for oprettelse af indhold.

Nu må vi vente og se på, hvordan fantasien og kreativiteten hos almindelige designere og indholdsskabere bruger disse utrolige værktøjer og tager det til et nyt niveau.

På grund af de igangværende udviklingsgentagelser af webstedseditor, bør vi altid forudse en vanskelig vej forude. Som optimist er jeg dog spændt på at se, hvad der vil ske i den kommende version af WordPress 6.2. Noget af det, som jeg holder godt øje med, er ting som funktioner, der overvejes til inklusion, støtte til klæbrig positionering, nye layout klassenavne til indvendige blokindpakninger, opdaterede sidefodsjusteringsmulighederog tilføjelse af begrænsede og flowlayoutindstillinger til Cover-blokke.

Denne GitHub problemer #44720 lister de layoutrelaterede diskussioner beregnet til WordPress 6.2.

Yderligere ressourcer

Jeg konsulterede og refererede en masse kilder, mens jeg gravede i alt dette. Her er en stor ol 'liste over ting, jeg fandt nyttige, og jeg tror, ​​du også kunne nyde.

Vejledninger

WordPress-indlæg

GitHub pull anmodninger og problemer

spot_img

Seneste efterretninger

spot_img

Chat med os

Hej! Hvordan kan jeg hjælpe dig?