Bruk av den nye begrensede layouten i WordPress-blokktemaer

Et av hovedmålene til WordPress Site Editor (og, ja, det er nå "offisielt navn) er å flytte grunnleggende blokkstyling fra CSS til strukturert JSON. JSON-filer er maskinlesbare, noe som gjør dem forbrukbare av den JavaScript-baserte Site Editor for å konfigurere et temas globale stiler direkte i WordPress.

Det er ikke helt der ennå! Hvis vi ser på standardtemaet Twenty Twenty-Two (TT2), var det to hovedproblemer som ikke ble løst: styling interaksjoner (som :hover, :active, :focus), Og marginene og polstring av layoutcontainere. Du kan se hvordan disse ble midlertidig fikset i TT2 style.css fil i stedet for å gjøre den til theme.json filen.

WordPress 6.1 fikset disse problemene, og det jeg vil gjøre er å se spesifikt på sistnevnte. Nå som vi har JSON-ifiserte stiler for marginer og utfylling av layoutbeholdere, åpner det oss for mer fleksible og robuste måter å definere mellomrom i temaoppsettene våre.

Hva slags mellomrom snakker vi om?

For det første har vi allerede polstring på rotnivå som er en fancy måte å beskrive polstring på element. Det er fint fordi det sikrer konsistent avstand på et element som deles på alle sider og innlegg.

Men det er mer til det fordi nå har vi en måte for blokker å omgå den polstringen og justere seg i full bredde. Det er takket være polstring-bevisste justeringer som er en ny opt-in-funksjon theme.json. Så selv om du har polstring på rotnivå, kan du fortsatt la for eksempel et bilde (eller en annen blokk) bryte ut og gå i full bredde.

Det får oss til en annen ting vi får: begrensede oppsett. Tanken her er at alle blokker som er nestet i layouten respekterer layoutens innholdsbredde – som er en global innstilling – og ikke flyter utenfor den. Vi kan overstyre den oppførselen på en blokk-for-blokk-basis med justeringer, men vi kommer til det.

La oss starte med...

Polstring på rotnivå

Igjen, dette er ikke nytt. Vi har hatt muligheten til å sette polstring på element i theme.json siden den eksperimentelle Gutenberg-plugin introduserte det i versjon 11.7. Vi satte den på styles.spacing objekt, der vi har margin og padding objekter for å definere topp-, høyre-, bunn- og venstreavstanden 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 setting. Så hvis vi skulle åpne DevTools og inspisere element, vil vi se disse CSS-stilene:

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;
}

Kul. Men her ligger spørsmålet om hvordan i all verden vi kan la noen blokker bryte ut av den avstanden for å fylle hele skjermen, kant-til-kant. Det er derfor avstanden er der, ikke sant? Det er med på å forhindre at det skjer!

Men det er faktisk mange tilfeller der du kanskje ønsker å bryte ut av den avstanden på en engangsforekomst når du arbeider i Block Editor. Si at vi pletter en bildeblokk på en side og vi vil at den skal gå i full bredde mens resten av innholdet respekterer utfylling på rotnivå?

Tast inn…

Polstring-bevisste justeringer

Mens du prøver å lage det første standard WordPress-temaet som definerer alle stiler i theme.json fil, leder designer Kjell Reigstad illustrerer de utfordrende aspektene ved å bryte ut av polstring på rotnivå i denne GitHub-problem.

Nye funksjoner i WordPress 6.1 ble opprettet for å løse dette problemet. La oss grave i de neste.

useRootPaddingAwareAlignments

En ny useRootPaddingAwareAlignments eiendom ble opprettet for å løse problemet. Det ble faktisk først introdusert i Gutenberg-plugin v13.8. De original pull-forespørsel er en fin primer på hvordan det fungerer.

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

Legg merke til at dette er en funksjon vi må velge. Eiendommen er satt til false som standard, og vi må eksplisitt sette den til true for å aktivere det. Legg også merke til at vi har appearanceTools satt til true også. Det velger oss til UI-kontroller i Site Editor for styling av kantlinjer, lenkefarger, typografi og, ja, mellomrom som inkluderer marg og utfylling.

Stille appearanceTools satt til true velger automatisk blokker i marg og polstring uten å måtte stille heller settings.spacing.padding or setting.spacing.margin til true.

Når vi aktiverer useRootPaddingAwareAlignments, får vi tilpassede egenskaper med rotutfyllingsverdier som er satt på element på forsiden. Interessant nok gjelder det også polstringen på .editor-styles-wrapper klasse slik at avstanden vises når du arbeider i back-end Block Editor. Ganske kult!

Jeg var i stand til å bekrefte de egendefinerte CSS-egenskapene i DevTools mens jeg gravde rundt.

Aktivering useRootPaddingAwareAlignments bruker også venstre og høyre polstring på alle blokker som støtter "innholds"-bredde- og "bred"-breddeverdiene i Global Styles-bildet ovenfor. Vi kan også definere disse verdiene i theme.json:

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

Hvis Global Styles-innstillingene er annerledes enn det som er definert i theme.json, da har Global Styles forrang. Du kan lære alt om administrasjon av blokktemastiler i min siste artikkel.

• contentSize er standardbredden for blokker.
• wideSize gir et "bredt" layoutalternativ og etablerer en bredere kolonne for blokker å strekke seg ut.

Så det siste kodeeksemplet vil gi oss 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] indikerer et unikt nummer automatisk generert av WordPress.

Men gjett hva mer vi får? Full justering også!

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

Se det? Ved å aktivere useRootPaddingAwareAlignments og definerer contentSize og wideSize, får vi også en full justering CSS-klasse for totalt tre containerkonfigurasjoner for å kontrollere bredden på blokker som legges til sider og innlegg.

Dette gjelder for følgende layoutspesifikke blokker: Kolonner, Gruppe, Innleggsinnhold og Spørringsløkke.

Blokker layoutkontroller

La oss si at vi legger til noen av de nevnte layoutspesifikke blokkene på en side. Når vi velger blokken, gir blokkinnstillingene oss nye layoutinnstillinger basert på settings.layout verdier vi definerte i theme.json (eller Global Styles UI).

Vi har å gjøre med veldig spesifikke blokker her - de som kan ha andre blokker nestet inni. Så disse layoutinnstillingene handler egentlig om å kontrollere bredden og justeringen av de nestede blokkene. Innstillingen "Indre blokker bruker innholdsbredde" er aktivert som standard. Hvis vi slår det av, så har vi nei max-width på beholderen og blokkene inni den går kant til kant.

Hvis vi lar bryteren være på, vil nestede blokker holde seg til enten contentWidth or wideWidth verdier (mer om det om litt). Eller vi kan bruke de numeriske inngangene til å definere egendefinert contentWidth og wideWidth verdier i dette engangsforekomsten. Det er stor fleksibilitet!

Brede blokker

Innstillingene vi nettopp så er satt på overordnet blokk. Når vi har nestet en blokk inne og valgt den, har vi flere alternativer i den blokken for å bruke contentWidth, wideWidth, eller gå i full bredde.

Legg merke til hvordan WordPress multipliserer de tilpassede CSS-egenskapene for polstring på rotnivå med -1 for å lage negative marginer når du velger alternativet "Full bredde".

Bruke en begrenset layout

Vi har nettopp dekket den nye avstanden og justeringene vi får med WordPress 6.1. Disse er spesifikke for blokker og eventuelle nestede blokker i blokker. Men WordPress 6.1 introduserer også nye layoutfunksjoner for enda mer fleksibilitet og konsistens i et temas maler.

Eksempel: WordPress har fullstendig omstrukturert sine Flex- og Flow-layouttyper og ga oss en begrenset layout type som gjør det enklere å justere blokkoppsett i temaer ved å bruke innstillingene for innholdsbredde i Site Editor's Global Styles UI.

Flex-, Flow- og Constrained-oppsett

Forskjellen mellom disse tre layouttypene er stilene de produserer. Isabel Brison har en utmerket tekst som pent skisserer forskjellene, men la oss omskrive dem her for referanse:

• Flytoppsett: Legger til vertikal avstand mellom nestede blokker i margin-block retning. Disse nestede blokkene kan også justeres til venstre, høyre eller senter.
• Begrenset layout: Samme nøyaktige avtale som en Flow-layout, men med breddebegrensninger på nestede blokker som er basert på contentWidth og wideWidth innstillinger (enten i theme.json eller Global Styles).
• Fleksibel layout: Dette var uendret i WordPress 6.1. Det bruker CSS Flexbox for å lage et oppsett som flyter horisontalt (på rad) som standard, men som også kan flyte vertikalt slik at blokker stables oppå hverandre. Avstand brukes ved hjelp av CSS gap eiendom.

Denne nye listen med layouttyper lager semantiske klassenavn for hver layout:

Semantisk layout klasse	Oppsettstype	Støttede blokker
.is-layout-flow	Flytoppsett	Kolonner, gruppe, innleggsinnhold og spørringsløkke.
.is-layout-constrained	Begrenset layout	Kolonner, gruppe, innleggsinnhold og spørringsløkke.
.is-layout-flex	Fleksibel oppsett	Kolonner, knapper, sosiale ikoner

Justin Tadlock har en omfattende artikkel om de ulike layouttypene og semantiske klasser, inkludert brukstilfeller og eksempler.

Oppdaterer temaet ditt for å støtte begrensede oppsett

Hvis du allerede bruker et blokktema du selv har laget, kommer du til å ønske det oppdater den for å støtte begrensede oppsett. Alt som trengs er å bytte ut et par ting theme.json:

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

Dette er nylig utgitte blokktemaer som har aktivert avstandsinnstillinger med useRootPaddingAwareAlignments og ha en oppdatert theme.json fil som definerer et begrenset oppsett:

Deaktiverer layoutstiler

Basislayoutstilene er standardfunksjoner som leveres i WordPress 6.1 Core. Med andre ord, de er aktivert rett ut av esken. Men vi kan deaktivere dem hvis vi trenger det med dette lille utdraget functions.php:

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

Stor advarsel her: deaktivering av støtte for standard layouttyper også fjerner all grunnstyling for disse layoutene. Det betyr at du må rulle dine egne stiler for mellomrom, justeringer og alt annet som trengs for å vise innhold i forskjellige mal- og blokkkontekster.

Innpakning opp

Som en stor fan av bilder i full bredde, er den nye inneholdte WordPress 6.1-layouten og polstringsbevisste justeringsfunksjoner to av mine mest favoritter ennå. Sett sammen med andre verktøy inkludert bedre margin- og polstringskontroll, flytende typografi, og oppdaterte liste- og sitatblokker, blant annet, er et solid bevis på at WordPress beveger seg mot en bedre opplevelse for innholdsskaping.

Nå må vi vente og se på hvordan fantasien og kreativiteten til vanlige designere og innholdsskapere bruker disse utrolige verktøyene og tar det til et nytt nivå.

På grunn av gjentakelser av utviklingen av nettstedredaktøren som pågår, bør vi alltid forutse en vanskelig vei fremover. Som optimist er jeg imidlertid ivrig etter å se hva som vil skje i den kommende versjonen av WordPress 6.2. Noe av det jeg holder et øye med er ting som funksjoner som vurderes for inkludering, støtte til klissete posisjonering, nye layoutklassenavn for innvendige blokkpakker, oppdaterte alternativer for bunntekstjusteringog legge til begrensede og flytende layoutalternativer til Cover-blokker.

Dette GitHub problemer #44720 lister opp layoutrelaterte diskusjoner beregnet for WordPress 6.2.

Tilleggsressurser

Jeg konsulterte og refererte til mange kilder mens jeg gravde i alt dette. Her er en stor ol 'liste over ting jeg fant nyttig og tror du også kan like.

Guider

WordPress-innlegg

GitHub pull-forespørsler og problemer