Hvad er nyt i WordPress 5.8 (redigering af fuld side, WebP-billeder, globale stilarter og indstillinger og meget mere)

WordPress 5.8 vil være en vigtig frigivelse. Bortset fra det utrolige antal funktioner, forbedringer og fejlrettelser introducerer WP 5.8 en ny måde at opbygge websteder på, ved at bringe de første funktioner, der falder ind under det bredere projekt kendt som Full Site Editing.

Bortset fra Full Site Editing bringer WordPress 5.8 mange ændringer og forbedringer til flere områder af CMS’et.

WordPress-brugere, der ikke bruger Gutenberg-pluginnet, finder funktioner og forbedringer, der kommer fra ni Gutenberg-udgivelser (for et dyk dybt ind i hver udgivelse, se Gutenberg 9.9, 10.0, 10.1, 10.2, 10.3, 10.4, 10.5, 10.6, 10.7).

En vigtig ny funktion for brugere, der er seriøse omkring deres websteds ydeevne, er understøttelsen af ​​WebP-format.

Udviklere vil helt sikkert elske fjernelse af IE11’s fra listen over understøttede browsere, den nye blokkonfigurations- og stylingmekanisme baseret på theme.json, det forbedrede block registration system based på block.json og de mange API-forbedringer, der kommer med den anden WordPress-udgivelse fra 2021 .

Så hold fast, fordi det bliver en lang opsamling af funktioner og forbedringer, der baner vejen for nye kraftfulde værktøjer til byggepladser, der forventes frigivet i de kommende måneder.

Fuldt websteds-redigeringsfunktioner i WordPress 5.8

Visionen bag Full Site Editing er at levere en samling værktøjer og funktioner, der giver WordPress-brugere mulighed for at opbygge et helt websted ved hjælp af blokke. Med Full Site Editing ser vi mange blokke til rådighed for at oprette ethvert element på siden, fra navigationsmenuer til site branding, sidebar widgets, skabeloner og meget mere.

Selvom WordPress 5.8 introducerer flere funktioner, der falder inden for FSE (Full Site Editing), bør vi ikke forvente at se et fuldt udstyret visuelt byggemiljø. FSE er stadig i gang, og frigivelsen af ​​WordPress 5.8 åbner en slags offentlig beta-fase. Ifølge Josepha Haden Chomphosy:

Fuld redigering af websteder er en samling projekter, og sammen repræsenterer de en stor ændring, uden tvivl for meget til en enkelt udgivelse. Den vigtigste kontekst at dele er, at den ikke sendes som den fulde standardoplevelse for brugerne. En af de tydeligste feedback fra fase 1-fusioneringsprocessen var, at der ikke var tid nok til vores udvidere (bureauer, temaforfattere, plugin-udviklere, site builders osv.) Til at forberede sig på de kommende ændringer.

Med dette i tankerne vil denne fletteproces ikke være en tænd/sluk-knap. Fokus er nu ikke på en fuld og nuanceret brugeroplevelse, men mere af en åben offentlig beta inden for WordPress 5.8.

Så vi bør ikke forvente at se en perfekt og komplet FSE-oplevelse lige nu. I stedet ser vi nye funktioner tilføjes og forbedres over tid, startende lige fra version 5.8. Af samme grund kan vi antage, at WordPress 5.8 ikke har en dramatisk indflydelse på den måde, vi er vant til at opbygge websteder.

På tidspunktet for denne skrivning skal ejere af websider og administratorer stadig bevidst vælge FSE ved at installere et bloktema, såsom Twenty-Twenty One Blocks (den blokbaserede version af Twenty-Twenty One) og aktivere Gutenberg-pluginet.

Full Site Editing omfatter en række separate underprojekter, inklusive Site Editor, Global Styles, Query block, Navigation block, Templates, block temaer og meget mere. Men det tætteste ved Site Editing, vi ser i WordPress 5.8, er Template Editing Mode og de tilsvarende Theme Blocks, der er tilgængelige til brug i denne mode, som vi vil se senere i denne artikel.

Lad os derefter dykke ned i nogle FSE-funktioner flettet ind i Core med WordPress 5.8.

Template Editing Mode

Template Editing Mode giver en måde at oprette indlæg/sideskabeloner ved hjælp af blokke. Det er en fantastisk måde at reducere kompleksiteten af bygning af et website, så brugerne kan drage fordel af flere site-redigeringsfunktioner uden for site editor-grænsefladen, mens de vænner sig til at arbejde med blokke. Dette er også godt for brugere, der ikke bruger blokbaserede temaer, men stadig ser efter en nem måde at oprette og redigere skabeloner fra blokeditorens brugergrænseflade på.

Tilpasning af temaer har aldrig været så let i WordPress før. Nu behøver du ikke længere oprette et child theme for at oprette dine tilpassede skabeloner. Med WordPress 5.8 er redigering af skabelon ikke begrænset til at blokere temaer, men er også tilgængelig for dig til brug med klassiske temaer, selvom du i klassiske temaer skal vælge at aktivere det.

For at oprette en ny skabelon skal du bare aktivere redigeringstilstand til skabelon i sidebar Indstillinger. Et nyt skabelon panel er nu tilgængeligt for brugere at skifte redigeringstilstand (se udgivelsesnoten til Gutenberg 10.5).

Fra panelet Skabelon kan du oprette en ny skabelon eller redigere en eksisterende.

For at oprette en ny skabelon skal du klikke på Ny. Indtast derefter et skabelonnavn i modalet, og klik på Opret, så er du klar til at køre.

I skabelon redigeringstilstand kan du opbygge dine skabeloner ved hjælp af alle de tilgængelige blokke, herunder FSE-blokke som Site Title, Site Tagline, Login/out og mange flere.

Når du er tilfreds med dine redigeringer, kan du skifte tilbage til post editing mode og gemme skabelonen separat fra indlæggets/sideindholdet, som vist på billedet nedenfor:

Skabeloner gemmes i din WordPress-database som brugerdefinerede posttyper med navnet wp_template. Dette giver dig ikke kun mulighed for at redigere en skabelon fra editorgrænsefladen, men det gør det også nemt at importere eller eksportere dem efter ønske. Du kan også bruge en skabelon på tværs af forskellige websteder (på dette tidspunkt er denne funktion kun tilgængelig, hvis du aktiverer Gutenberg-pluginet).

Template Editing Mode er stadig en smule drilsk på dette tidspunkt, som rapporteret i dette opkald til test og dette eksperiment fra Justin Tadlock.

Men alt hvad der kræves, er lidt tålmodighed og at man venter på, at de store problemer løses for fuldt ud at forstå, hvordan skabelonredigeringstilstand vil ændre den måde, du tilpasser udseendet og følelsen af dine hjemmesider.

Brugere har ikke længere brug for udviklerfærdigheder for at få fuld kontrol over layoutet og websteds samlede udseende.

Template Editing Mode var først tilgængelig for både bloktemaer og klassiske temaer. Efter en tankevækkende diskussion i 5.8 leads-kanalen blev det besluttet at lade skabeloneditoren tilvælge klassiske temaer og fravælge bloktemaer (se også pull #32858).

Ifølge Carolina Nymark:

Oprindeligt blev skabelonredigering aktiveret for alle temaer. Temaudviklere rejste bekymring for, at de ikke kunne opdatere alle deres eksisterende klassiske temaer for at understøtte denne nye funktion. Med en sen ændring vælger frigørelsestroppen og redaktørholdet at ændre redigering af skabeloner, så de vælger klassiske temaer.

For at tilvælge klassiske temaer skal udviklere nu tilføje temasupport:

add_theme_support( 'block-templates' );

Klassiske temaer ved hjælp af theme.json kan fravælge ved at fjerne temasupport:

remove_theme_support(  'block-templates' );

For en mere detaljeret oversigt over, hvordan skabelonredigeringsfunktion fungerer i WordPress 5.8 og nogle nyttige eksempler på brug, skal du sørge for at se denne video fra Anne McCarty:

Temablokke

Som nævnt tidligere er FSE ikke en enkelt funktion, men et komplet sæt af site-building-funktioner, der ikke kun er relateret til site-editoren. Template Editing Mode er bare et eksempel på det. Men sammen med skabelonredigering bringer WordPress 5.8 også mange temablokke, der kan vise information dynamisk hentet fra databasen. Nogle af disse blokke kan også bruges i ikke-FSE-sammenhænge (se nummer 28744).

Tema-blokke bringer skabelonfunktionaliteter til klassiske temaer, og du kan bruge dem på samme måde som almindelige blokke. For eksempel kan du tilføje post-tags eller indlæggets fremhævede billede hvor som helst i indlæggets indhold eller skabelon. For at få en idé om antallet af temablokke, der er føjet til kernen med WordPress 5.8, skal du bare skrive/poste i blokholderen:

En nyttig temablok tilgængelig med WordPress 5.8 er Login/out-blokken, som giver login- og logout-links. Det kan valgfrit vise loginformularen i stedet for et link. Webstedsadministratorer kan også tilpasse omdirigeringsmålet (se PR #29766).

For en nærmere visning af FSE-blokke, se spørgsmålet “Aktivering af Full Site Editor-blokke i klassiske temaer” på Github.

The Query Loop Block

Hvor mange gange har du befundet dig i en situation, hvor du har brug for at vise en tilpasset liste over blogindlæg eller tilpassede typer af indlæg? Tænk på produkter, begivenheder, fast ejendom … Selvfølgelig har du masser af plugins at vælge imellem til det, men evnen til at oprette meget tilpassede forespørgsler kræver ofte udvikler-færdigheder for at kæmpe med WordPress Loop.

Med introduktionen af ​​Query Loop-blokken i WordPress Core kan webstedsejere og administratorer oprette lister over indlæg og CPT’er uden at skrive kompleks kode eller hyre en udvikler, i det mindste i de mest almindelige brugssager.

Så hvad gør Query Loop Block?

Kort sagt, det fungerer det samme som WordPress Loop, men i den visuelle kontekst af blokeditoren.

Query Loop-blokken udfører en forespørgsel baseret på brugerens indstillinger over WordPress-databasen, løber gennem hvert hentet indlæg og viser data på siden.

Efter intensiv udvikling, har denne blok nået sin nuværende struktur og består nu af to indlejrede blokke: Query og Post Template-blokke.

For at være en avanceret funktion kræver Query Loop-blokken nogle konfigurationer.

Først kan du vælge mellem forskellige blokmønstre, der er angivet i karrusel- og gittervisning. Når du har valgt dit mønster, skal du blot klikke på Vælg, og Query Loop-blokken genererer din brugerdefinerede liste over indlæg.

Hvis du klikker på Start tomt, vil du se en liste med fire Core-blokvarianter: Titel & dato; Titel & uddrag; Titel, dato og uddrag; og billede, dato og titel (se Tilbud af mønstre ved blokopsætning).

Når du er på plads, skal du vælge Query Loop-blokken for at vise sidebar for blokindstillinger, hvor du kan oprette din forespørgsel. Du kan enten arve forespørgslen fra URL’en eller tilpasse forespørgsels-argumenterne: typen af indlæg, der skal medtages på listen, visningsrækkefølgen og om der skal være sticky post eller ej.

Du kan også indstille flere filtre, vælge mellem kategorier, forfattere og nøgleord.

Derudover giver en knap Visningsindstillinger i blokværktøjslinjen flere indstillinger til at styre antallet af elementer pr. side, forskydningen og det maksimale antal sider, der skal vises.

Ja, Query Loop-blokken er et kraftfuldt værktøj, der giver webstedsejere mulighed for at oprette meget tilpassede lister over indlæg og tilpassede indlægstyper.

Men hvis du går gennem WP_Query klasseparametrene, er det klart, at niveauet for tilpasning, der er mulig ved hjælp af koden, er langt mere detaljeret, end hvad der er muligt ved hjælp af Query Loop-blokken.

Ikke desto mindre er det faktisk et værdifuldt og fleksibelt værktøj, der egner sig til mange brugssager, og vi vil sandsynligvis se yderligere forbedringer i fremtiden.

Vedvarende listevisning i Post Editor

En anden FSE-funktion udvidet til Post Editor er Persistent List View. Før WordPress 5.8 (og Gutenberg 10.7) blev listevisningen vist i en popover. Når du flytter fokus uden for popover, forsvinder listen.

Omvendt viste Site Editor redigering af listevisning i et sidebjælke, der indeholder hele blok-træet.

Med WordPress 5.8 vises listevisningen nu i en sidebar i Post Editor, så brugerne kan navigere i blok-træet hurtigere og mere præcist.

Ved at klikke på et element i listevisningen fremhæves listeelementet og flytter fokus til den tilsvarende blok i Post Editor-lærredet. Hvis du derudover holder markøren over elementerne i listevisningen, bliver både elementet og den tilsvarende blok i Post Editor markeret.

Til sidst vises tilføjelse af et anker til en blok også ved siden af det tilsvarende element i listevisningen.

Med alle disse forbedringer af listevisningen skal det være meget lettere at navigere i komplekse dokumenter.

Block-Based Widgets Editor og Block Widgets i Customizer

Den blokbaserede widgetseditor er et bredt projekt, der sigter mod at bringe grænsefladen til blokeditoren til klassiske tema-widgets.

Den nye widgeteditor tilbyder mange fordele for langt de fleste, der stadig bruger klassiske temaer. Samtidig giver det dem mulighed for at stifte bekendt med blokgrænsefladen, før det bliver standard for alle WordPress-brugere.

Som Anne McCarty påpeger, giver blokbaserede widgets flere fordele, herunder følgende:

• Du kan nu oprette layout i sidebars, headers, and footers ved hjælp af kolonner, separatorer, afstandsstykker og andre designblokke.
• Widgets understøtter nu som standard redigering af rich text uden behov for brugere at tilføje brugerdefineret kode eller integrere en tredjeparts HTML-editor med et plugin.
• Mange kortkodebaserede widgets er nu tilgængelige som blokke og strømliner redigeringsoplevelsen.

Andrei Draganescu understreger også de fordele, vi kan få ved at kunne redigere widgets fra en blokbaseret grænseflade:

Den største fordel ved at opgradere widgets-funktionaliteten til blokke kommer fra muligheden for direkte at redigere widgets ved hjælp af den velkendte blokinteraktion, som du bruger, når du redigerer en side eller et indlæg på dit websted. At kunne bruge blokke åbner for masser af nye kreative muligheder, fra mini-layout uden kode til at tappe i det store bibliotek med kerne- og tredjepartsblokke for at skabe indhold.

Du behøver ikke bekymre dig om, at dine widgets måske holder op med at arbejde med WordPress 5.8, fordi samfundet har arbejdet hårdt for at sikre bagudkompatibilitet, så “eksisterende widgets og tredjepartswidgets fortsætter med at arbejde og kan bruges sammen med blokke” (se Block-baseret widgets editor i WordPress 5.8).

Men igen, for at forhindre kompatibilitetsproblemer med din eksisterende WordPress-installation skal du ikke glemme at teste den nye version i et scenemiljø, før du opdaterer dit live-websted.

For de af jer, der fravælger at bruge den blokbaserede widgets-editor lige nu, er det stadig muligt at gendanne den klassiske widgets-skærm på tre forskellige måder:

1. Du kan installere det officielle Classic Widgets-plugin, som gendanner den tidligere grænseflade på widgets-skærmen. Pluginet “understøttes og vedligeholdes indtil mindst 2022 eller så længe det er nødvendigt”.
2. Temaudviklere kan deaktivere den blokbaserede widgetseditor ved at fjerne temasupport som normalt: remove_theme_support( 'widgets-block-editor' );
3. Et nyt use_widgets_block_editor-filter kan også bruges:

   add_filter( 'use_widgets_block_editor', '__return_false' );

Se også Gendannelse af den klassiske widget editor i Widget Block Editor-oversigten.

Bloker widgets til Customizer

Som en del af det samme projekt bringer WordPress 5.8 også blok widgets til customizer.

Tilføjelse af en blokbaseret widget i tilpasningen er ret ligetil. Du kan starte tilpasning af widget-indsætter ved at klikke på plusikonet i øverste højre hjørne af widgetspanelet.

Du kan også starte hurtig-indsættelsen fra bunden af widgetpanelet, som vist på det følgende billede.

På dette tidspunkt kræver den nye widget redigering grænseflade stadig forbedringer og fejlrettelser, men mulighederne for tilpasning er næsten ubegrænsede.

Grundlæggende starter du med WordPress 5.8, at du har kraften i blokeditoren i tilpasningen, og du vil være i stand til at oprette meget tilpassede sidebars uden besvær.

Den blokbaserede widgets editor-dev-note giver et mere dybtgående overblik over den blokbaserede widgets editor med eksempler og ressourcer til udviklere.

Block Editor-funktioner og forbedringer

Ud over den første FSE-implementering bringer WordPress 5.8 også nye funktioner og forbedringer til flere elementer i blokeditoren, hvilket forbedrer den samlede redigeringsoplevelse betydeligt.

Disse ændringer inkluderer:

Medie- og tekstblokforbedringer

Omdannelse af en blok til en kolonneblok har været mulig i et stykke tid nu. Imidlertid omdannede alle blokke til kolonneblokke med en enkelt kolonne. Dette kan føre til suboptimale resultater for medie- og tekst blokken, som en enkelt kolonne normalt ikke er egnet til.

Fra og med WordPress 5.8 (og Gutenberg 10.2) tilføjer automatisk medie- og tekst blok til en kolonneblok automatisk to kolonner: en til billedet og en anden til teksten.

Forbedringer af genanvendelige blokke

Genanvendelige blokke giver brugeren mulighed for at gemme en blok eller en gruppe blokke til senere genbrug i ethvert indlæg eller side på et websted. Dette er hovedsageligt nyttigt for brugere, der gentagne gange inkluderer den samme blok eller gruppe af blokke i forskellige indlæg eller på sider.

Med WordPress 5.8 er genanvendelige blokke visuelt klarere, hvilket gør dem lettere for WordPress-brugere at administrere.

Her er en hurtig liste over genanvendelige blok forbedringer, som brugere finder efter opdatering af deres websteder til WordPress 5.8:

• Når du opretter en genanvendelig blok, tillader et modal nu brugere mulighed for at tildele et navn til blokken.
• Genbrugsblokens navn vises nu i blok toolbar, navigationslisten og brødkrummer.
• Når en underordnet blok er valgt, er genanvendelige blokke nu beskrevet. Dette markerer en betydelig forbedring i brugervenlighed, da det giver dig mulighed for let at identificere parent-blokken og dens indhold.
• Det er nu muligt at ændre navnet på blok i sidebar inspector.

Normaliserede block toolbars

Flere block toolbars er blevet omarrangeret for at give en ensartet brugergrænseflade på tværs af blokke og forbedre brugeroplevelsen. Nu er toolbar kontrol grupperet efter den semantiske rækkefølge “meta, blokniveau, inline”.

Siden Gutenberg 10.1 og Gutenberg 10.3 er et helt sæt block toolbars blevet normaliseret. Disse inkluderer et billede, en knap, knapper, liste, header, afsnit, citat, lyd, fil, medier og tekst, video og meget mere.

Ifølge Matias Ventura:

De semantiske grupperinger, vi har i værktøjslinjen – meta, blokniveau, inline – skal også have en visuel repræsentation med grænserne. Lige nu har separate block level controls forskellige repræsentationer, herunder tilfælde som Navigation, hvor hver enkelt har grænser.

Så siden WordPress 5.8 grupperer blokværktøjslinjen kontroller i segmenter omgivet af grænser. Ud over:

• Meta segmentet indeholder kontrolelementer af bloktypen, såsom blokomskifteren, trækhåndtaget og bevægelsesstyringen.
• Block level segmentet indeholder specifikke blokværktøjer, der påvirker hele indholdet, f.eks. justering i en afsnit eller blokering i en billedeblock.
• Inline-niveauet/andet segment indeholder integrerede transformationsværktøjer, såsom integreret formatering i en tekstblok.
• Menuen Mere indeholder yderligere værktøjer.

Billedet nedenfor sammenligner billede-blok toolbar i WordPress 5.7 og 5.8:

Top forbedringer til toolbar

Med top toolbar modus aktiveret i tidligere WordPress-versioner blev den øverste værktøjslinje og blok toolbar vist side om side som vist i følgende billede:

Med WordPress 5.8 vil aktivering af den øverste visning af toolbar rette blok toolbar øverst på editoren lige under den øverste toolbar. Dette sker uafhængigt af browserbredden og bør forbedre brugeroplevelsen betydeligt.

Denne forbedring medfører også ændringer for udviklere, da den forener toolbars API’er under komponenten <BlockTools /> (se PR #31134).

Embedded PDF-filer

Når en PDF-fil føjes til dokumentet gennem filblokken, giver en ny sidebarskift dig mulighed for at aktivere/deaktivere en embedded PDF version (se PR #30857).

Du kan enten trække filen direkte på editorens lærred eller blot vælge den fra biblioteket. Det er også muligt manuelt at justere højden på PDF-fremviseren eller ved hjælp af sidebjælken.

Alle større webbrowsere understøtter PDF-fremviseren, undtagen mobilbrowsere.

Duotone Block Support

En af de mest interessante funktioner, der er slået sammen i Core med WordPress 5.8, er duotone filteret, der først blev introduceret med Gutenberg 10.6.

Tilgængelig som en “block understøtter” funktion, er duotonefilteret aktiveret som standard i kerne billede og cover blokke. I forsideblokken fungerer det dog ikke med faste baggrunde.

Billed- og cover block toolbars viser nu en Anvend duotone-filter kontrol, der viser en duotone-vælger med mange forudindstillinger at vælge imellem.

To subcontrols tillader tilpasning af skygger og højdepunkter separat. Effekten anvendes med et SVG-filter skjult med indbyggede stilarter og anvendes ved hjælp af et specifikt klassenavn.

Det nye værktøj kommer i par med en ny color.__experimentalDuotone, der tillader udviklere at tilføje duotonefilteret til blokke eller dele af blokke i deres block.json-fil (mere om dette i farve objekt reference):

supports: {
	color: {
		__experimentalDuotone: '> .duotone-img, > .duotone-video',
		background: false,
		text: false
	}
}

Når en blok erklærer understøttelse af color.__experimentalDuotone, kan en styleattribut bruges til at indstille brugerdefinerede standardfarver:

attributes: {
	style: {
		type: 'object',
		default: {
			color: {
				duotone: [
					'#FFF',
					'#000
				]
			}
		}
	}
}

Nedenfor kan du se det samme billede hvor to forskellige duotoneffekter er anvendt:

Udviklere kan definere duotone-presets i theme.json filen (se næste afsnit) som vist i følgende uddrag:

{
"version": 1,
"settings": {
	"color": {
		"duotone": [
			{
				"colors": [ "#000", "#7f7f7f" ],
				"slug": "black-and-white",
				"name": "dark-grayscale"
			}
		],
	...

Du kan læse mere om duotone filtre i Farvelægning af dine billeder med duotone filtre.

Tabelblokfarver og kanter

WordPress 5.8 bringer også et par forbedringer til tabelblokken, herunder bedre kontrol over tabel baggrund og forgrundsfarver.

En anden tilføjelse til tabelblokken er understøttelse af border blok, som giver brugerne mulighed for at kontrollere kantfarve, stil og bredde.

Hvis det aktive tema understøtter den nye funktion, giver et nyt panel til border indstillinger tre nye kontroller til brugertilpasninger.

Udviklere kan tilføje border block support til deres temaer ved at tilføje følgende kode til theme.json-filen:

"border": {
	"customColor": true,
	"customStyle": true,
	"customWidth": true
}

Forbedringer af Block Inserter

I WordPress 5.8 er blok inserter forbedret med flere tilføjelser (PR #26938 og #21080):

1. Todimensionelt tastaturnavigation på blokindsætteren. Nu kan vi navigere mellem blokke mere præcist og intuitivt.

• Ved at trykke på pil op (↑) og pil ned (↓) flyttes fokus til rækken over eller under.
• Ved at trykke på Tab eller Skift + Tab kan du flytte fokus mellem søgefeltet, fanelisten og det første element i hver kategori.

2. En ny “Tema” -kategori for skabelondele og variationer vises nu i indsætteren i Full Site Editing (se PR #30020).
3. Flere ord i den auto fuldførte sætnings matcher er nu tilladt (se PR #29939).

Yderligere forbedringer af Block Editor

WordPress 5.8 bringer masser af ekstra små og mellemstore ændringer til et par linjer her. Blandt disse forbedringer nævner vi følgende:

Træk og slip support i cover blokke

Nu kan du trække og slippe billeder fra skrivebordet for at erstatte en coverblocks baggrund (se Gutenberg 10.3 og PR #29813).

UI til forbedret udgivelse

Siden WordPress 5.8 viser udgivelsesgrænsefladen webstedets ikon og titel for at gøre det tydeligere, hvor du vil udgive dine indlæg eller sider (Gutenberg 10.4).

Denne forbedring er fordelagtig, hvis du arbejder i fuldskærmstilstand eller på mobile enheder.

Block indstillinger og stilarter med theme.json

Med WordPress 5.8 bliver theme.json-filen “et centralt konfigurationspunkt”, hvilket giver en ny måde for temaudviklere at tilpasse editorindstillinger og stilarter.

Ved hjælp af en theme.json-fil kan temaer indstille brugerdefinerede forudindstillinger og/eller tilføje support til nye funktioner, såsom duotone og tabelgrænser (se Globale indstillinger og stilarter).

Ifølge André Maneiro:

Denne nye mekanisme sigter mod at overtage og konsolidere alle de forskellige add_theme_support opkald, der tidligere var nødvendige for at kontrollere editoren.

For eksempel kan du globalt indstille en brugerdefineret duotone-forudindstilling med følgende kode:

{
	"version": 1,
	"settings": {
		"color": {
			"duotone": [
				{
					"colors": [ "#000", "#0FF" ],
					"slug": "black-cyan",
					"name": "Black Cyan"
				}
			],

Dette overskriver standardindstillinger, og du kan kun se en duotone-indstilling:

Den nye mekanisme giver mulighed for at kontrollere indstillinger enten globalt eller pr. blok. For eksempel kan du tilføje en brugerdefineret størrelse 12px skrifttype globalt ved at tilføje følgende forudindstilling til din theme.json-fil:

{
	"version": 1,
	"settings": {
		"typography": {
			"customLineHeight": true,
			"fontSizes": [
				{
					"slug": "extra-extra-small",
					"size": "12px",
					"name": "Extra extra small"
				},
				{...}

Dette resulterer i en ny skriftstørrelse, som brugerne kan bruge sammen med enhver tekst i deres indhold.

Hvis du kun vil tilpasse afsnitblokken, vil din kode være lidt anderledes:

{
	"version": 1,
	"settings": {
		"blocks": {
			"core/paragraph": {
				"typography": {
					"fontSizes": [
						{
							"slug": "extra-extra-small",
							"size": "12px",
							"name": "Extra extra small"
						},
						{
							"slug": "extra-small",
							"size": "16px",
							"name": "Extra small"
						},
						{
							"slug": "small",
							"size": "18px",
							"name": "Small"
						},
						{
							"slug": "normal",
							"size": "20px",
							"name": "Normal"
						},
						{
							"slug": "large",
							"size": "24px",
							"name": "Large"
						}
					]
				}
			}
		}
	}
}

Det er det! Du har lige indstillet dine forudindstillede størrelser på skrifttype til afsnitblokken.

Kerneblokke er opdateret for at følge den nye mekanisme, mens tredjepartsblokke kan tilpasse sig den nye mekanisme ved hjælp af React useSetting hook (læs mere om denne funktion i dev-note og API-dokumentation):

const isEnabled = useSetting( 'spacing.margin' );

The new mechanism based on the theme.json file does not apply only to block settings. In fact, starting with WordPress 5.8, it will no longer be necessary to create editor styles and enqueue them. It will be enough to declare presets inside the theme.json file; the engine will generate the classes and automatically enqueue them both to the editor and the frontend.

The engine will also generate the corresponding CSS Custom Properties.

Den nye mekanisme baseret på theme.json-filen gælder ikke kun for blokeringsindstillinger. Faktisk, startende med WordPress 5.8, er det ikke længere nødvendigt at oprette editor-stilarter og sætte dem fast. Det vil være tilstrækkeligt at erklære forudindstillinger i theme.json-filen; motoren genererer klasser og automatisk indkalder dem både til redaktøren og frontend.

Motoren genererer også de tilsvarende CSS Custom Properties.

I det foregående eksempel indstillede vi fem fontSizes-forudindstillinger for afsnitblokken. For disse forudindstillinger genereres følgende CSS tilpassede egenskaber:

p {
	--wp--preset--font-size--extra-extra-small: 12px;
	--wp--preset--font-size--extra-small: 16px;
	--wp--preset--font-size--small: 18px;
	--wp--preset--font-size--normal: 20px;
	--wp--preset--font-size--large: 24px;
}

Når du har indstillet afsnitstørrelsen i afsnittet i din theme.json-fil, tager det tilsvarende p-element has-{preset-slug}-{preset-category} class.

Dette betyder, at et afsnit med en ekstra-ekstra-small skriftstørrelse får klassen has-extra-extra-small-font-size:

<p class="has-extra-extra-small-font-size">Lorem ipsum dolor...</p>

Og her er CSS-deklarationsblokken:

p.has-extra-extra-small-font-size {
	font-size: var(--wp--preset--font-size--extra-extra-small) !important;
}

For at se nærmere på indstillingen og typografierne med theme.json, skal du kontrollere dev-note– og API-dokumentationen.

Tjek også Anne McCartys FSE-opfordring til test for mere nyttig læsning og en spændende udfordring for udviklere, der ønsker at udforske det nye tema.json-funktioner.

Block API enhancements

Block API enhancementsr, der kommer med WordPress 5.8, fortjener særlig opmærksomhed fra pluginudviklere.

Brug af block.json-filen tilskyndes nu som den kanoniske måde at registrere bloktyper på og giver flere fordele:

• Med hensyn til ydeevne, hvis temaet understøtter lazy loading af aktiver, vil registrering af bloktyper gennem filen block.json automatisk optimere ressourceindsamling. Det skyldes, at de ressourcer, der er specificeret af typografien og scriptegenskaberne, kun bliver indkapslet på frontend, når blokken registreres. Dette giver mulighed for at udvikle mere effektive plugins, reducere sidestørrelse og forhindre flere af de problemer, der er dækket af denne artikel.
• json-filen forenkler server-side block registration ved at lade bloktyperne REST API-endpoints liste listen.
• json-filen er også påkrævet, hvis du beslutter at sende dit blok-plugin til WordPress Plugins Directory.

Ændringer i funktionen register_block_type

Siden WordPress 5.8 er funktionen register_block_type blevet forbedret til at læse metadata fra filen block.json. Nu accepterer den første parameter stien til mappen, hvor filen block.json er placeret.

Funktionen kan bruges som vist i følgende eksempel:

function create_custom_block_init() {
	register_block_type( __DIR__ );
}
add_action( 'init', 'create_custom_block_init' );

Den returnerer den registrerede bloktype eller false ved failure.

Som du måske bemærker, bruges funktionen register_block_type nu på samme måde som register_block_type_from_metadata-funktionen, som tidligere var den eneste tilgængelige funktion til at registrere en bloktype ved at læse metadataene fra block.json-filen. Som forklaret af Greg Ziółkowski:

Vi besluttede at konsolidere den eksisterende funktionalitet, der er tilgængelig med register_block_type_from_metadata-metoden, til register_block_type for at undgå forvirring, som den skabte. Det er stadig muligt at bruge begge funktioner, men vi planlægger kun at bruge den kortere version i de officielle dokumenter og værktøjer fra nu af.

Når blokken er registreret på serveren, skal du kun registrere indstillinger på klienten ved hjælp af det samme bloknavn i din index.js-fil.

For en mere detaljeret oversigt over blok-API-forbedringer, der er introduceret af WordPress 5.8, skal du sørge for at kontrollere dev-note af Greg Ziółkowski.

WebP-support i WordPress 5.8

Her på Kinsta er vi besat af webstedshastighed og WordPress-ydeevne. Derfor er support til WebP-format i WordPress 5.8 så spændende nyheder for os.

WebP betragtes som et næste generations format og er et billedformat udviklet af Google, der giver “bedre komprimering end PNG eller JPEG, hvilket betyder hurtigere downloads og mindre dataforbrug.”

Ifølge Google:

WebP er et moderne billedformat, der giver overlegen lossless og lossy kompression for billeder på nettet. Ved hjælp af WebP kan webmastere og webudviklere oprette mindre, rigere billeder, der gør Internettet hurtigere.

WebP-lossless billeder er 26% mindre i størrelse sammenlignet med PNG’er. WebP-lossy billeder er 25-34% mindre end sammenlignelige JPEG-billeder med tilsvarende SSIM-kvalitetsindeks.

Fra og med WordPress 5.8 kan du bruge WebP-billedformatet på samme måde som JPEG-, PNG- og GIF-formater. Upload bare dine billeder til dit mediebibliotek og inkluder dem i dit indhold.

I en tidligere artikel tog vi et dybdegående kig på WebP-formatet og de tilgængelige værktøjer til at bruge det i WordPress. Nu, på grund af understøttelsen af ​​WebP-billeder i WordPress 5.8, kan tingene ændre sig lidt. Da WebP-formatet understøttes direkte, behøver du ikke installere tredjeparts-plugins for at uploade WebP-billeder i WordPress, i det mindste i de mest almindelige brugssager.

Bemærk, at selvom du nu kan uploade dine WebP-billeder til WordPress ved hjælp af mediebiblioteket, understøtter WordPress ikke automatisk billedkonvertering til WebP-format. For at aktivere denne funktion på dit websted skal du bruge et tredjeparts WebP WordPress-plugin.

Sådan bruges WebP-billeder i WordPress

Du kan konvertere dine billeder til WebP på mange forskellige måder:

• Du kan bruge Googles forudkompilerede WebP-værktøjer og bibliotek til Linux, Windows eller Mac OS X.
• Mac-brugere kan installere en pakkehåndtering som f.eks. Homebrew WebP-pakken eller Macports WebP-pakken.
• Du kan bruge et billedredigeringsværktøj, der understøtter WebP, såsom Squoosh af Google Chrome Labs, batch-billedkonvertereren XnConvert, en populær billededitor som GIMP og mange andre.
• Du kan installere et WebP WordPress-plugin for bedre samlet kontrol over WebP-billeder i WordPress.

Hvis du vælger et kommandolinjeværktøj, kan du kode og afkode dine billeder ved hjælp af cwebp og dwebp-værktøjer. For eksempel udfører følgende kommando en grundlæggende JPEG til WebP-konvertering:

cwebp [options] original_image.jpg -o compressed_image.webp

Du kan også køre en bulk-konvertering af dine billeder ved hjælp af Bash og cwebp (eksempel af Jeremy Wagner):

find ./ -type f -name '*.png' -exec sh -c 'cwebp -q 75 $1 -o "${1%.png}.webp"' _ {} \;

Kommandoen ovenfor konverterer alle .png-billeder til .webp-format med en kompressionsfaktor på 75.

Når du har dine WebP-billeder, kan du blot uploade dem ved hjælp af WordPress Media Library. Nedenfor kan du se et 127 KB JPEG-billede inden konvertering i mediebiblioteket:

Den komprimerede WebP-billedstørrelse er 42% mindre end det originale JPEG-billede!

Endelig har WebP-billeder de samme redigeringsfunktioner som JPEG-, PNG- og GIF-billeder. Du kan beskære, rotere, vende og skalere dem og anvende ændringer i de billedstørrelser, du vælger.

Advarsler om WebP i WordPress 5.8

Ifølge Adam Silverstein:

WebP-billeder understøtter tabsfri og tabsfri komprimering samt et animeret format og understøtter transparente billeder. I WordPress understøttes det lossless WebP-format kun, når hosting-serveren bruger Imagick (PHP-biblioteket), indtil LibGD tilføjer support. Derudover understøttes animerede og alfa-formater endnu ikke til størrelsesændrede billeder (når du uploader billeder i disse formater, oprettes lossy billeder i stedet).

Hvis din webhost ikke understøtter WebP-billeder, får du vist en fejlmeddelelse, når du prøver at uploade dem. Hvis du ikke er sikker på, om din webhost understøtter Imagick-biblioteket, indeholder fanen Info om webstedssundhed et Imagick-biblioteksfelt, der leverer det stykke information.

Med WebP-support introducerer WordPress 5.8 også to yderligere felter til sektionen Mediehåndtering i Site Health: Imagick-version og ImageMagick-understøttede filformater.

Hvis WebP ikke er angivet blandt understøttede filtyper, skal du kontakte din webhost for support.

Dev-note giver yderligere oplysninger om WebP-support i WordPress 5.8, nyttige ofte stillede spørgsmål og yderligere ressourcer.

Hvis du er interesseret i billedoptimering, kan du muligvis også lide følgende tutorials:

• Sådan optimeres billeder til web og ydeevne
• Hvorfor og hvordan man bruger tabt kompression på dine WordPress-billeder
• Sådan bruges WebP-billeder på WordPress (og formindsk billedfilstørrelser op til 35%)
• 15 bedste billedfiltyper
• Alt hvad du behøver at vide om WordPress-billedstørrelser

Yderligere funktioner til udviklere

Du finder snesevis af spændende funktioner til udviklere i WordPress 5.8. I denne artikel har vi været mere opmærksomme på dem, der burde have den mest betydningsfulde indflydelse på dit udviklingsarbejde. Men der er faktisk mange nye funktioner, der er værd at være opmærksom på, herunder følgende:

Blokering understøtter API

WordPress 5.8 tilføjer ny blok understøtter flag, der giver udviklere mulighed for at tilpasse registrerede blokke med de nyeste blokfunktioner.

Ud over den eksperimentelle duoton blokstøtte, der er nævnt tidligere (color._experimentalDuotone), tilføjer WordPress 5.8 også understøttelse af linkfarve. For at udnytte denne funktion skal du blot tilføje følgende flag til dine blokmetadata:

supports: {
	color: {
		link: true;
	}
}

Du kan indstille standardværdier ved hjælp af attributter, som vist i følgende eksempel, eller indstille dine forudindstillinger i theme.json:

attributes: {
	style: {
		type: 'object',
		default: {
			color: {
				link: '#FF0000',
			}
		}

Yderligere Block API-ændringer inkluderer:

• fontSize og lineHeight understøtter bliver stabile.
• Spacing støtte er blevet udvidet, og nu kan du kontrollere margen og padding samt individuelt kontrollere top-, højre-, bund– og venstrestørrelse.

Du kan læse mere om Block Supports API i WordPress 5.8 i Block understøtter API-opdateringer dev-note.

For en nærmere oversigt over, hvordan du bruger Block Supports API, se officiel dokumentation for Block Support API.

Specielle faner på webstedets sundhed

To nye hooks giver udviklere nu mulighed for at tilføje deres brugerdefinerede faner til Site Health-grænsefladen og tilpasse tilgængelige skærme.

Site_health_navigation_tabs-filteret er et associerende array af fane-id’er og etiketter, der registrerer en ny fane på skærmbilledet Site Health. Du kan bruge filteret ved at tilføje følgende eksempelkode til dit temas funktionsfil eller brugerdefinerede plugin:

function kinsta_site_health_navigation_tabs( $tabs ) {
	$tabs['kinsta-site-health-tab'] = esc_html_x( 'Kinsta', 'Site Health', 'text-domain' );

	return $tabs;
}
add_filter( 'site_health_navigation_tabs', 'kinsta_site_health_navigation_tabs' );

Billedet herunder viser den nye fane Site Health:

Takket være filteret site_health_navigation_tabs er det også muligt at omarrangere faner eller fjerne et eller flere emner.

Actionsite_health_tab_content udløses, når en bruger besøger skærmbilledet Site Health, bortset fra standardskærmen Status. Du kan bruge denne hook som vist i følgende uddrag (eksempel fra dev note):

function kinsta_site_health_tab_content( $tab ) {
	// Return if this is not your tab.
	if ( 'kinsta-site-health-tab' !== $tab ) {
		return;
	}

	// Include the interface, kept in a separate file just to differentiate code from views.
	include trailingslashit( plugin_dir_path( __FILE__ ) ) . 'views/kinsta-site-health-tab.php';
}
add_action( 'site_health_tab_content', 'kinsta_site_health_tab_content' );

For det første registrerer den, om den aktuelle fane er din brugerdefinerede fane, så indlæser den dit Site Health-skærmindhold fra en .php fil. Handlingen site_health_tab_content tillader også udviklere at udvide standardfanen Info ved at tilføje stykker information, der er specifikke for deres plugins eller temaer.

Block Editor API-ændringer til understøttelse af flere administrationsskærme

Med WordPress 5.8 er indlægseditoren ikke den eneste admin-skærm, der bruger blokeditoren længere (widgets-skærmen er et eksempel).

Kernebidragydere fandt flere kroge defineret på serveren afhængigt af $post-objektet. Dette objekt er ikke til stede i webstedets redigering, widgets og navigationsskærme. Fremadrettet er flere filtre udfaset og erstattet med kontekstbevidste erstatninger.

Derudover er der introduceret en ny klasse WP_Block_Editor_Context, der repræsenterer den aktuelle blokeditorkontekst og forskellige metoder.

Disse ændringer vil forbedre disse skærmbilleder med nye muligheder og gøre det muligt for udviklere at tilføje deres tilpasninger.

For en omfattende liste over Block Editor API-ændringer relateret til admin-skærme, se dev-note fra Greg Ziółkowski.

Yderligere funktioner og forbedringer

Der er så mange nye funktioner og ændringer for udviklere bragt af WordPress 5.8, at det ville være umuligt for os at nævne dem alle i denne artikel. Men vi har samlet en liste over dev-noter, der ikke er dækket her til din videre læsning:

• Dropping support for Internet Explorer 11
• Block-styles loading enhancements in WordPress 5.8
• Blocks in an iframed (template) editor
• On layout and content width in WordPress 5.8
• Introducing “Update URI” plugin header in WordPress 5.8
• Various Block Editor API removals in WordPress 5.8
• REST API Changes in WordPress 5.8
• Miscellaneous developer-focused changes in WordPress 5.8
• Miscellaneous block editor API additions in WordPress 5.8

Resumé

WordPress 5.8 markerer en milepæl på vejen til redigering af komplet websted. Men den anden WordPress-udgivelse af året bringer meget mere end FSE. Brugere og udviklere finder masser af forbedringer af blokeditoren, en ny theme.json-mekanisme, en mere kraftfuld Block API, WebP-billedformatstøtte og meget mere.

Vi er især imponeret over forbedringerne, både små og store, af blokeditoren og dens brugergrænseflade. Vi elsker den forbedrede navigationsevne mellem blokke, den opdaterede blokværktøjslinje, den berigede klarhed i grænsefladen og forbedringerne til flere blokke.

Disse små ændringer forbedrer redigeringsoplevelsen lidt efter lidt, og uden at vi næsten er klar over det, finder vi os selv ved hjælp af bedre og mere robust software. Det er WordPress!

Over til dig nu! Hvad er dine tanker om fuldtidsredigering? Og hvad er dine foretrukne ændringer, der kommer med WordPress 5.8?