Vad är nytt i WordPress 5.8 (Full Site Editing, WebP-bilder, globala stilar och inställningar och mycket mer)

WordPress 5.8 kommer att bli en viktig utgåva som inkluderar ett otroligt stort antal funktioner, förbättringar och buggfixar. Utöver detta introducerar WP 5.8 ett nytt sätt att bygga webbplatser genom att leverera de första funktionerna som faller under det bredare projektet som kallas Full Site Editing.

Bortsett från Full Site Editing, innefattar WordPress 5.8 massor av ändringar och förbättringar till flera områden i CMS.

WordPress-användare som inte använder Gutenberg-pluginet kommer att hitta funktioner och förbättringar som kommer från nio Gutenberg-utgåvor (för en djupdykning i varje utgåva, se Gutenberg 9.9,  10.0,  10.1,  10.2,  10.3,  10.4,  10.5,  10.6,  10.7).

En viktig ny funktion för användare som verkligen bryr sig om sina webbplatsers prestanda är webp-formatstödet.

Utvecklare kommer garanterat att älska borttagningen av IE11 från listan över webbläsare som stöds, den nya blockkonfigurations- och styling-mekanismen baserad på theme.json, det förbättrade blockregistreringssystemet baserat på  block.json, och de många API-förbättringarna som kommer med den andra  WordPress-utgåvan 2021.

Så ta ett djupt andetag, för det kommer att bli en lång sammanfattning av funktioner och förbättringar som banar väg för nya kraftfulla verktyg för webbplatsbyggnad. Allt detta förväntas släppas under de kommande månaderna.

Full Site Editing-funktioner i WordPress 5.8

Visionen bakom Full Site Editing är att tillhandahålla en samling verktyg och funktioner som gör det möjligt för WordPress-användare att bygga en hel webbplats med block. Med Full Site Editing, kommer vi att få många tillgängliga block för att skapa element på sidan, från navigeringsmenyer till webbplatsvarumärken, sidofälts-widgetar, mallar och mycket mer.

Även om WordPress 5.8 introducerar flera funktioner som omfattas av Full Site Editing (FSE), bör vi inte förvänta oss att se en fullständig visuell webbplatsbyggnadsmiljö. FSE är fortfarande ett pågående arbete, och lanseringen av WordPress 5.8 öppnar en slags offentlig beta-fas. Enligt Josepha Haden Chomphosy:

Full Site Editing är en samling projekt som tillsammans representerar en stor förändring, förmodligen för mycket för en enda utgåva. Det viktigaste att förmedla är att det inte levereras som en fullständig standardupplevelse för användare. En av de tydligaste feedbackbitarna från fas 1-sammanslagningsprocessen var att det inte fanns tillräckligt med tid för våra extenders (agenturer, temaskapare, pluginutvecklare, webbplatsbyggare osv.) att förbereda sig för de kommande ändringarna.

Med detta i åtanke kommer denna sammanslagningsprocess inte att vara en på / av-knapp. Fokus nu ligger inte på en fullständig och nyanserad användarupplevelse, utan mer på en öppen offentlig beta inom WordPress 5.8.

Så vi bör inte förvänta oss att se en perfekt och komplett FSE-upplevelse i nuläget. Vi kommer istället att få se nya funktioner läggas till och förbättras med tiden, från och med version 5.8. Av samma anledning kan vi anta att WordPress 5.8 inte kommer att ha en dramatisk inverkan på hur vi är vana vid att bygga webbplatser.

I skrivande stund måste webbplatsägare och administratörer fortfarande medvetet välja FSE genom att installera ett blocktema, exempelvis Twenty-Twenty One Blocks (den blockbaserade versionen av Twenty-Twenty One), och aktivera Gutenberg-pluginet.

Full Site Editing  omfattar en rad separata delprojekt, inklusive webbplatsredigerare, Global Styles, sökfrågeblock, navigeringsblock, mallar, blockteman och mycket mer. Men det närmaste webbplatsredigering som vi får i WordPress 5.8 är  mallredigeringsläget och motsvarande temablock som finns tillgängliga för användande i det läget, som vi kommer att se senare i den här artikeln.

Låt oss nu djupdyka i några FSE-funktioner som slås samman i kärnan med WordPress 5.8.

Mallredigeringsläge

Mallredigeringsläget är ett sätt att skapa inläggs-/sidmallar med hjälp av block. Det är ett bra sätt att minska komplexiteten i webbplatsbyggnaden, så att användare kan dra nytta av flera webbplatsredigeringsfunktioner utanför webbplatsredigerarens gränssnitt medan de vänjer sig vid att arbeta med block. Detta är även bra för användare som inte använder blockbaserade teman men ändå letar efter ett enkelt sätt att skapa och redigera mallar från blockredigerarens användargränssnitt.

Att anpassa teman har aldrig tidigare varit så enkelt i WordPress. Nu behöver du inte längre skapa ett barntema för att skapa dina anpassade mallar. Med WordPress 5.8 är mallredigering inte begränsat till blockteman utan är även  tillgängligt att använda med klassiska teman, även om du måste välja att aktivera det för klassiska teman.

Om du vill skapa en ny mall behöver du bara aktivera mallredigeringsläget i Inställnings-sidofältet. En ny mall-panel är nu tillgänglig för användare som vill växla redigeringsläge (se Gutenberg 10.5 viktig anmärkning).

I mall-panelen kan du skapa en ny mall eller redigera en befintlig mall.

Om du vill skapa en ny mall klickar du på Ny. Ange sedan ett mallnamn i modalen och klicka på skapa, så är du klar.

I mallredigeringsläget kan du skapa dina mallar med alla tillgängliga block, inklusive FSE-block som webbplatsrubrik, webbplats-tagline, inloggning / utloggning och många fler.

När du är nöjd med dina redigeringar kan du växla tillbaka till inläggsredigeringsläget och spara mallen separat från inlägg/sidinnehållet, som visas i bilden nedan:

Mallar lagras i din WordPress-databas som anpassade inläggstyper med namnet wp_template. Detta gör det möjligt för dig att redigera en mall från redigeringsgränssnittet, samt importera eller exportera dem när du vill. Du kan även använda en mall på olika webbplatser (vid tidpunkten för detta skrivande är den här funktionen endast tillgänglig om du aktiverar Gutenberg-pluginet).

Mallredigeringsläget är fortfarande lite buggigt vid tidpunkten för detta skrivande, som du kan läsa i detta call for testing och detta experiment från Justin Tadlock.

Men allt som krävs är lite tålamod och lite väntan på att de stora problemen ska åtgärdas så kommer det framgå hur mallredigeringsläget kommer att förändra hur du anpassar utseendet och känslan på dina webbplatser.

Användare behöver inte längre utvecklarfärdigheter för att få fullständig kontroll över layouten och webbplatsens övergripande utseende.

Mallredigeringsläget var till en början tillgängligt för både blockteman och klassiska teman. Efter en tankeväckande diskussion i 5.8 leads-kanalen bestämdes det att mallredigeraren skulle bli opt-in för klassiska teman och opt-out för blockteman (se även pull #32858).

Enligt Carolina Nymark:

Mallredigering aktiverades ursprungligen för alla teman. Temautvecklare uttryckte en oro över att de inte skulle kunna uppdatera alla sina befintliga klassiska teman för att stödja den här nya funktionen. Men med en sen ändring väljer releasegruppen och redigeringsteamet att mallredigeringen ska vara opt-in för klassiska teman.

För opt-in i klassiska teman bör utvecklare nu lägga till temastöd:

add_theme_support( 'block-templates' );

Klassiska teman som använder theme.json kan opt-out genom att ta bort temastöd:

remove_theme_support(  'block-templates' );

För en mer detaljerad översikt över hur mallredigeringsläget fungerar i WordPress 5.8 och några användbara exempel på användning, se till att titta på den här videon från Anne McCarty:

Temablock

Som nämnts tidigare är FSE inte en enda funktion utan en komplett uppsättning av webbplatsbyggnadsfunktioner som inte endast är relaterade till webbplatsredigeraren. Mallredigeringsläget är bara ett exempel på detta. Men utöver mallredigeringen erbjuder WordPress 5.8 även många temablock som kan visa information som dynamiskt hämtas från databasen. Vissa av dessa block kan även användas i icke FSE-sammanhang (se ärende nr 28744).

Temablock ger malltaggs-funktionalitet till klassiska teman, och du kan använda dem på samma sätt som vanliga block. Du kan exempelvis lägga till inläggstaggar eller inläggets utvalda bild var som helst i inläggsinnehållet eller mallen. För att få en uppfattning om antalet temablock som läggs till kärnan med WordPress 5.8, skriv bara /post i blockplatshållaren:

Ett användbart temablock som finns tillgängligt i och med WordPress 5.8 är inloggnings/utloggnings-blocket, som tillhandahåller inloggnings- och utloggningslänkar. Om så önskas kan det visa inloggningsformuläret istället för en länk. Webbplatsadministratörer kan även anpassa omdirigeringsmålet (se PR #29766).

En närmare vy över FSE-block finns i ”Aktivera Full Site Editor-block i klassiska teman” på Github.

Query Loop-blocket

Hur många gånger har du befunnit dig i en situation där du behöver visa en anpassad lista över blogginlägg eller anpassade inläggstyper? Tänk på produkter, evenemang, fastigheter… Det finns naturligtvis massor av plugins som du kan välja mellan för detta, men möjligheten att skapa väldigt anpassade sökfrågor kräver ofta utvecklarfärdigheter om man ska kunna jobba med WordPress Loop.

Med introduktionen av Query Loop-blocket i WordPress kärna kan webbplatsägare och administratörer skapa listor över inlägg och HLT utan att skriva komplex kod eller hyra in en utvecklare, åtminstone i de vanligaste användningsområdena.

Så vad gör Query Loop-blocket?

Det gör kort sagt samma arbete som WordPress Loop, men i blockredigerarens visuella kontext.

Query Loop-blocket utför en sökfråga baserat på användarens inställningar i WordPress-databasen, loopar genom varje hämtat inlägg och visar data på sidan.

Efter intensiv utveckling har det här blocket nått sin nuvarande struktur och består numera av två kapslade block: fråge– och postmall-blocken.

Eftersom Query Loop-blocket är en avancerad funktion kräver det vissa konfigurationer.

Du kan välja mellan olika blockmönster som listas i karusell- och rutnätsvyn. När du har valt ditt mönster klickar du bara på Välj, så genererar Query Loop-blocket din anpassade lista med inlägg.

Om du klickar på Starta tomt ser du en lista med fyra kärnblockvariationer:  Titel & Datum; Titel & Utdrag; Titel, datum & utdrag; och bild, datum & titel (se erbjudna mönster vid blockinställningar).

När du är på plats kommer valet av Query Loop-blocket att visa sidofältet för blockinställningar, där du kan bygga sökfrågan. Du kan antingen ärva frågan från URL:en  eller anpassa frågeargumenten: vilken typ av inlägg som ska inkluderas i listan, visningsordningen och om du vill ha klisterposter eller inte.

Du kan även ställa in flera filter, välja mellan kategorier, författare och nyckelord.

Dessutom ger knappen Bildskärmsinställningar i blockverktygsfältet fler inställningar för att styra antalet objekt per sida, förskjutningen och det maximala antalet sidor som ska visas.

Ja, Query Loop-blocket är ett kraftfullt verktyg som gör det möjligt för webbplatsägare att skapa väldigt anpassade listor över inlägg och anpassade inläggstyper.

Men om du går igenom WP_Query-klassparametrarna är det tydligt att den möjliga anpassningsnivån med koden är mycket mer detaljerad än vad som är möjligt med hjälp av Query Loop-blocket.

Men det är ändå ett värdefullt och flexibelt verktyg som lämpar sig för många användningsområden, och vi kommer sannolikt att se ytterligare förbättringar i framtiden.

Beständig listvy i inläggsredigeraren

En annan FSE-funktion som läggs till i inläggsredigeraren är Beständig listvy. Innan WordPress 5.8 (och Gutenberg 10.7) visades listvyn i ett flytande fönster. När du flyttade fokus utanför fönstret försvann listan.

Omvänt visade webbplatsredigeraren listvyn i ett sidofält som innehöll hela blockträdet.

Med WordPress 5.8 visas listvyn nu i ett sidofält i inläggsredigeraren, så att användarna kan navigera i blockträdet snabbare och exaktare.

Om du klickar på ett objekt i listvyn markeras listobjektet och fokus flyttas till motsvarande block på inläggsredigerarens arbetsyta. Om du håller muspekaren över objekten i listvyn markeras dessutom både objektet och motsvarande block i inläggsredigeraren.

Slutligen visas även ett tillagt ankare i ett block bredvid motsvarande objekt i listvyn.

Med alla dessa förbättringar i listvyn bör det bli mycket enklare att navigera i komplexa dokument.

Blockbaserad widgetredigerare och blockwidgetar i anpassaren

Den blockbaserade widgetredigeraren är ett brett projekt som syftar till att ta gränssnittet från blockredigeraren till widgetar med klassiskt tema.

Den nya widgetredigeraren erbjuder många fördelar för de allra flesta som fortfarande använder klassiska teman. Det tillåter dem samtidigt att bekanta sig med blockgränssnittet innan det blir standard för alla WordPress-användare.

Som Anne McCarty påpekar erbjuder blockbaserade widgets flera fördelar, inklusive följande:

• Du kan nu skapa layouter i sidofält, sidhuvuden och sidfötter med kolumner, avgränsare, mellanslag och andra designblock.
• Widgets stöder nu RTF-redigering som standard, utan att användarna behöver lägga till anpassad kod eller bädda in en HTML-redigerare från tredje part med ett plugin.
• Många kortkodsbaserade widgetar är nu tillgängliga som block, vilket effektiviserar redigeringsupplevelsen.

Andrei Draganescu betonar även fördelarna som vi kan få av att kunna redigera widgets från ett blockbaserat gränssnitt:

Den största fördelen med att uppgradera widgets-funktionen till block är möjligheten att direkt redigera widgets med hjälp av den välbekanta blockinteraktion som du använder när du redigerar en sida eller ett inlägg på din webbplats. Att kunna använda block öppnar massor av nya kreativa möjligheter, från minilayouter utan kodskrivning till att utnyttja det stora biblioteket med kärnblock och block från tredje part för att skapa innehåll.

Du behöver inte oroa dig för att dina widgets ska sluta fungera med WordPress 5.8 eftersom communityn har arbetat hårt för att säkerställa bakåtkompatibilitet så att ”befintliga widgets och widgets från tredje part fortsätter att fungera och kan användas tillsammans med block” (se Blockbaserad widgetredigerare i WordPress 5.8).

Men återigen, för att förhindra eventuella kompatibilitetsproblem på din befintliga WordPress-installation, glöm inte att testa den nya versionen i en iscensättningsmiljö innan du uppdaterar din livewebbplats.

För dig som inte vill använda den blockbaserade widgetredigeraren för tillfället är det fortfarande möjligt att återställa den klassiska widget-skärmen på tre olika sätt:

1. Du kan installera det officiella Classic Widgets-pluginet, som återställer det tidigare gränssnittet på widgetsskärmen. Pluginet ”kommer att stödjas och underhållas till åtminstone 2022, eller så länge som det är nödvändigt”.
2. Temautvecklare kan som vanligt inaktivera den blockbaserade widgetredigeraren genom att ta bort temastödet:
   remove_theme_support( 'widgets-block-editor' );
3. Det går även att använda ett use_widgets_block_editor-filter:

   add_filter( 'use_widgets_block_editor', '__return_false' );

Se även Återställa den klassiska widgetredigeraren i Blockbaserade widgetredigerarens översikt.

Blockwidgetar till anpassaren

Som en del av samma projekt tar WordPress 5.8 även blockwidgetar till anpassaren.

Att lägga till en blockbaserad widget i anpassaren är ganska enkelt. Du kan starta anpassa widgetar-infogaren genom att klicka på plusikonen i det övre högra hörnet på widgetpanelen.

Du kan även starta snabbinfogaren längst ned på widgetpanelen, som visas i följande bild.

Vid tidpunkten för denna artikel krävs det fortfarande förbättringar och buggfixar för det nya widgetredigeringsgränssnittet. Möjligheterna till anpassning är dock praktiskt taget obegränsade.

I grund och botten, från och med WordPress 5.8, har du kraften hos blockredigeraren  i anpassaren, och du kommer att kunna bygga väldigt anpassade sidofält utan krångel.

Den blockbaserade widgetredigerarens anmärkning för utvecklare ger en mer djupgående översikt över den blockbaserade widgetredigeraren, med exempel och resurser för utvecklare.

Blockredigerarens funktioner och förbättringar

Förutom den första FSE-implementeringen erbjuder WordPress 5.8 även nya funktioner och förbättringar till flera delar av blockredigeraren, vilket avsevärt förbättrar den övergripande redigeringsupplevelsen.

Dessa ändringar inkluderar:

Förbättringar av media & textblock

Det har varit möjligt att omvandla ett block till ett kolumnblock ett tag nu. Alla block omvandlas dock till kolumnblock med en enda kolumn. Detta kan leda till mindre bra resultat för media & text-block, där en enda kolumn vanligtvis inte är lämpligt.

Från och med WordPress 5.8 (och Gutenberg 10.2) medför omvandlingen av media & textblock till kolumnblock automatiskt att det läggs till två kolumner: en för bilden och en annan för texten.

Förbättringar av återanvändbara block

Återanvändbara block gör det möjligt för användaren att spara ett block eller en grupp block som ska återanvändas senare i ett inlägg eller en sida på en webbplats. Detta är främst användbart för användare som upprepade gånger inkluderar samma block eller grupp av block i olika inlägg / sidor.

I WordPress 5.8 är återanvändbara block tydligare visuellt, vilket gör dem enklare för WordPress-användare att hantera.

Här är en snabb lista över förbättringarna med återanvändbara block som användare har upptäckt efter att ha uppdaterat sina webbplatser till WordPress 5.8:

• När du skapar ett återanvändbart block tillåter en modal nu användare att tilldela blocket ett namn.
• Det återanvändbara blockets namn visas nu i blockverktygsfältet, navigeringslistan och brödsmulorna.
• När ett underordnat block är valt markeras nu återanvändbara block. Detta innebär en betydande förbättring av användbarheten eftersom det gör att du enkelt kan identifiera det överordnade blocket och dess innehåll.
• Det är nu möjligt att ändra blocknamnet i sidofältsinspektören.

Normaliserade verktygsfält för block

Flera blockverktygsfält har placerats om för att ge ett konsekvent användargränssnitt för blocken och förbättra användarupplevelsen. Verktygsfältskontroller grupperas efter semantisk ordning på ”meta, blocknivå, infogad”.

Sedan Gutenberg 10.1 och Gutenberg 10.3 har en hel uppsättning blockverktygsfält normaliserats. Dessa inkluderar en bild, knapp, knappar, lista, rubrik, stycke, citat, ljud, fil, media & text, video och mer.

Enligt Matias Ventura:

De semantiska grupperingar som vi har i verktygsfältet – meta, blocknivå, infogad – bör även ha en visuell representation med gränserna. Just nu har separata blocknivåkontroller olika representationer, inklusive Navigering där var och en har gränser.

Så sedan WordPress 5.8 är blockverktygsfälten styrda i segment och omgivna av gränser. Dessutom:

• Metasegmentet innehåller blocktypskontroller, exempelvis blockväxlaren, draghandtaget och flytt-kontrollen.
• Segmentet Blocknivå innehåller specifika blockverktyg som påverkar hela innehållet, exempelvis justering i ett paragrafblock eller länkning i ett bildblock.
• Segmentet Infogad nivå/Övrigt innehåller infogade omvandlingsverktyg, exempelvis infogad formatering i ett textblock.
• Menyn Mer innehåller ytterligare verktyg.

Bilden nedan jämför Bildblockets verktygsfält i WordPress 5.7 och 5.8:

Förbättringar av det övre verktygsfältet

När det övre verktygsfältsläget aktiverades i tidigare WordPress-versioner visades det övre verktygsfältet och blockverktygsfältet sida vid sida, som du kan se i följande bild:

Med WordPress 5.8 kommer blockverktygsfältet att fixeras högst upp i det övre verktygsfältet genom att du aktiverar den övre verktygsfältsvyn. Detta sker oberoende av webbläsarens bredd och bör förbättra användarupplevelsen avsevärt.

Den här förbättringen medför även ändringar för utvecklare eftersom den förenar API:er i verktygsfältet under komponenten <BlockTools /> (se PR #31134).

Inbäddade PDF-filer

När en PDF-fil läggs till i dokumentet via filblocket kan du med en ny sidofältsväxling aktivera/inaktivera en inbäddad PDF-version (se PR #30857).

Du kan antingen dra filen direkt till redigerarens arbetsyta eller helt enkelt markera den från biblioteket. Det är även möjligt att manuellt justera höjden på PDF-visaren eller att använda sidofältskontrollen.

Alla större webbläsare stöder PDF-visaren, förutom mobila webbläsare.

Stöd för duotonblock

En av de mest intressanta funktionerna som slås samman i kärnan med WordPress 5.8 är duotonfiltret, som först introducerades med Gutenberg 10.6.

Duotonfiltret är tillgängligt som en ”blockstödsfunktion” och är aktiverat som standard i kärn-bilden och omslagsblocken. I omslagsblocket fungerar det dock inte ihop med fasta bakgrunder.

Verktygsfälten för Bild- och Omslagsblock visar nu en Använd duoton filter-kontroll som visar en duotonväljare med många förinställningar att välja mellan.

Två underkontroller tillåter separat anpassning av skuggor och markeringar. Effekten tillämpas med ett SVG-filter som är dolt med infogade format och som tillämpas med ett specifikt klassnamn.

Det nya verktyget levereras ihop med en ny color._ experimentalDuotone-egenskap, vilket gör det möjligt för utvecklare att lägga till duotonfiltret i block eller delar av block i sin block.json-fil  (mer om detta i color object reference):

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

När ett block förklarar stöd för color.__experimentalDuotone kan ett  style  -attribut användas för att ange anpassade standardfärger:

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

Nedan kan du se samma bild med två olika tillämpade duotoneffekter:

Utvecklare kan definiera duoton-förinställningar i filen theme.json  (se nästa avsnitt), som visas i följande utdrag:

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

Du kan läsa mer om duotonfilter i Färgläggning av dina bilder med duotonfilter.

Tabellblocksfärger och kantlinjer

WordPress 5.8 ger även ett par förbättringar till tabellblocket, inklusive bättre kontroll över tabell-bakgrund och förgrundsfärger.

Ett annat tillägg till tabellblocket är stöd för kantblock, vilket ger användarna möjlighet att styra kantlinjefärg, format och bredd.

Om det aktiva temat stöder denna nya funktion, ger en ny panel för kantinställningar tre nya kontroller för användaranpassningar.

Utvecklare kan lägga till stöd för kantblock i sina teman genom att lägga till följande kod i filen theme.json:

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

Förbättringar av blockinfogaren

I WordPress 5.8 har blockinfogaren förbättrats med flera tillägg (PR #26938 och #21080):

1. Tvådimensionell tangentbordsnavigering på blockinfogaren. Nu kan vi navigera mellan block mer exakt och intuitivt.

• Genom att trycka på pilen uppåt (↑ ) och pilen nedåt ( ↓) flyttas fokus till raden ovanför eller under.
• Genom att trycka på Tab eller Skift + Tab kan du flytta fokus mellan sökrutan, tab-listan och det första objektet i varje kategori.

2. En ny ”Tema”-kategori för malldelar och variationer visas nu i infogaren i Full Site Editing (se PR #30020).
3. Flera ord i den autokompletterande frasmatchningen är nu tillåtna (se PR #29939).

Ytterligare förbättringar av blockredigeraren

WordPress 5.8 innefattar massor av ytterligare små och medelstora förändringar som är värda att skriva om här. Vi kommer att nämna följande av dessa förbättringar:

Dra och släpp-stöd i omslagsblock

Nu kan du dra och släppa bilder från skrivbordet för att ersätta ett omslagsblocks bakgrund (se Gutenberg 10.3 och PR #29813).

Förbättrat publiceringsgränssnitt

I och med WordPress 5.8 visar publiceringsgränssnittet webbplatsikonen och titeln för att göra det tydligare var du publicerar dina inlägg eller sidor (Gutenberg 10.4).

Den här förbättringen  är fördelaktig om du arbetar i helskärmsläge eller på mobila enheter.

Blockinställningar och stilar med theme.json

Med WordPress 5.8 blir filen theme.json ”en central konfigurationspunkt”, vilket ger ett nytt sätt för temautvecklare att anpassa redigeringsinställningar och stilar.

Med hjälp av en theme.json-fil  kan teman ange anpassade förinställningar och/eller lägga till stöd för nya funktioner, exempelvis duoton och tabellkantlinjer (se Globala inställningar & stilar).

Enligt André Maneiro:

Denna nya mekanism syftar till att ta över och konsolidera alla add_theme_support-anrop som tidigare krävdes för att kontrollera redigeraren.

Du kan exempelvis globalt ange en anpassad duotonförinställning med följande kod:

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

Detta skulle skriva över standardförinställningarna så att du endast ser ett duotonalternativ:

Den nya mekanismen skapar ett sätt att styra inställningarna antingen globalt eller per block. Du kan exempelvis lägga till en anpassad 12px-teckenstorlek globalt genom att lägga till följande förinställning i filen theme.json:

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

Detta resulterar i en ny teckenstorlek som är tillgänglig för användare att använda med vilken text som helst i innehållet.

Om du bara vill anpassa paragrafblocket blir koden något annorlunda:

{
	"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"
						}
					]
				}
			}
		}
	}
}

Sådär! Du har just ställt in dina anpassade förinställningar för teckenstorlek i paragrafblocket.

Kärnblocken har uppdaterats för att följa den nya mekanismen, medan block från tredje part kan anpassas till den nya mekanismen med hjälp av React useSetting  hook (läs mer om den här funktionen i dev-note och API-dokumentationen):

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

Den nya mekanismen som baseras på filen theme.json gäller inte bara för blockinställningar. Faktum är att från och med WordPress 5.8 kommer det inte längre att vara nödvändigt att skapa redigeringsstilar och placera dem sist i kön. Det kommer att räcka med att deklarera förinställningar i theme.json-filen;  motorn genererar klasserna och sätter dem automatiskt sist i kön både i redigeraren och frontend.

Motorn genererar även motsvarande CSS Anpassade Egenskaper.

I föregående exempel angav vi fem fontSizes-förinställningar för paragrafblocket. För dessa förinställningar genereras följande anpassade CSS-egenskaper:

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 angett paragrafteckensnittsstorleken i filen theme.json tar motsvarande p-element klassen has-{preset-slug}-{preset-category}.

Detta innebär att ett stycke med en extra-extra-small teckenstorlek får klassen has-extra-extra-small-font-size.

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

Och här är CSS-deklarationsblocket:

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

För en närmare titt på inställningen och stilarna med theme.json, se till att kontrollera dev-note och API-dokumentationen.

Kontrollera även Anne McCartys FSE Call for testing för mer användbar läsning och en spännande utmaning för utvecklare som vill utforska de nya  theme.json-funktionerna.

Block API-förbättringar

Block API-förbättringar som kommer med WordPress 5.8 förtjänar en särskild uppmärksamhet från plugin-utvecklare.

Att använda filen block.json uppmuntras nu som det kanoniska sättet för att registrera blocktyper och ger flera fördelar:

• När det gäller prestanda: Om temat stöder lazy loading av tillgångar, kommer registrering av blocktyper via filen block.json  automatiskt att optimera resursen som är sist i kön. Detta beror på att de resurser som anges av style –  och script-egenskaperna endast kommer att anges på frontend när blocket identifieras. Detta möjliggör utveckling av effektivare plugins, minskar sidstorleken och förhindrar flera av de problem som omfattas av den här artikeln.
• Filen block.json förenklar blockregistreringen på serversidan genom att låta API-slutpunkten för Block Types REST lista blocket.
• Filen block.json krävs även om du bestämmer dig för att skicka in ditt blockplugin till WordPress Plugins Directory.

Ändringar i register_block_type-funktionen

Sedan WordPress 5.8 har register_block_type -funktionen förbättrats för att läsa metadata från filen block.json.  Nu accepterar den första parametern sökvägen till mappen där filen block.json finns.

Funktionen kan användas enligt följande exempel:

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

Den returnerar den registrerade blocktypen eller false vid fel.

Som du kanske märker används funktionen register_block_type nu på samma sätt som register_block_type_from_metadata-funktionen, som tidigare var den enda funktionen som var tillgänglig för att registrera en blocktyp  genom att läsa metadata från filen block.json.  Här förklaras detta av Greg Ziółkowski:

Vi bestämde oss för att förena den befintliga funktionaliteten som finns i register_block_type_from_metadata-metoden med  register_block_type för att undvika den förvirring som den skapade. Det är fortfarande möjligt att använda båda funktionerna, men vi planerar att endast använda den kortare versionen i de officiella dokumenten och verktygen från och med nu.

När blocket har registrerats på servern behöver du bara registrera inställningarna på klienten med samma blocknamn i din index.js-fil.

För en mer djupgående översikt över block-API-förbättringarna som introducerats av WordPress 5.8, se till att kontrollera dev-note av Greg Ziółkowski.

WebP-stöd i WordPress 5.8

Här på Kinsta är vi besatta av webbplatsens hastighet och WordPress-prestanda. Av den anledningen är WebP-formatstöd i WordPress 5.8 väldigt spännande nyheter för oss.

WebP anses vara nästa generations format och är ett bildformat som är utvecklat av Google och som ger ”bättre komprimering än PNG eller JPEG, vilket innebär snabbare nedladdningar och mindre dataförbrukning.”.

Enligt Google:

WebP är ett modernt bildformat som ger en överlägsen förlustfri och förstörande komprimering för bilder på webben. Med WebP kan webbansvariga och webbutvecklare skapa mindre och rikare bilder som gör webben snabbare.

WebP förlustfria bilder är 26% mindre i storlek jämfört med PNGs. WebP förstörande bilder är 25-34% mindre än jämförbara JPEG-bilder med motsvarande SSIM-kvalitetsindex.

Från och med WordPress 5.8 kan du använda WebP-bildformatet på samma sätt som JPEG-, PNG- och GIF-format. Ladda bara upp dina bilder till mediebiblioteket  och inkludera dem i ditt innehåll.

I en tidigare artikel tog vi en djupgående titt på WebP-formatet och de verktyg som finns tillgängliga för att använda detta i WordPress. Nu, på grund av stödet för WebP-bilder i WordPress 5.8, kan saker och ting förändras litegrann. Eftersom WebP-formatet stöds direkt behöver du inte installera plugins från tredje part för att ladda upp WebP-bilder i WordPress, åtminstone inte för de vanligaste användningsområdena.

Observera att även om du nu kan ladda upp dina WebP-bilder till WordPress med hjälp av mediebiblioteket, stöder WordPress inte automatisk bildkonvertering till WebP-format. För att aktivera den funktionen på din webbplats behöver du ett tredje parts WebP WordPress-plugin.

Så här använder du WebP-bilder i WordPress

Du kan konvertera dina bilder till WebP på många olika sätt:

• • Du kan använda Googles förkompilerade WebP-verktyg och bibliotek för Linux, Windows eller Mac OS X.
  • Mac-användare kan installera en pakethanterare som Homebrew WebP-paketet  eller Macports WebP-paketet.
  • Du kan använda ett bildredigeringsverktyg som stöder WebP, exempelvis Squoosh av Google Chrome Labs, batchbildkonverteraren XnConvert, en populär bildredigerare som GIMP och många andra.

• Du kan installera ett WebP WordPress-plugin för en bättre övergripande kontroll över WebP-bilder i WordPress.

Om du väljer ett kommandoradsverktyg kan du koda och avkoda dina bilder med hjälp av cwebp– och dwebp.  Följande kommando kör exempelvis en grundläggande JPEG till WebP-konvertering:

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

Du kan även köra en masskonvertering av dina bilder med Bash och cwebp (exempel av Jeremy Wagner):

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

Kommandot ovan konverterar alla .png till .webp  med en komprimeringsfaktor på 75.

När du har dina WebP-bilder kan du helt enkelt ladda upp dem med WordPress Mediebibliotek. Nedan kan du se en JPEG-bild på 127 KB före konvertering i mediebiblioteket:

Den komprimerade WebP-bildstorleken är 42 % mindre än den ursprungliga JPEG-bilden!

Slutligen har WebP-bilder samma redigeringsfunktioner som JPEG-, PNG- och GIF-bilder. Du kan beskära, rotera, vända och skala dem och tillämpa ändringar på valfri bildstorlek.

Varningar om WebP i WordPress 5.8

Enligt Adam Silverstein:

WebP-bilder stöder förstörande och förlustfri komprimering, samt ett animerat format och stöd för transparenta bilder. I WordPress stöds det förlustfria WebP-formatet endast när hosting-servern använder Imagick (PHP-biblioteket) tills LibGD lägger till stöd. Animerade format och alfaformat stöds dessutom ännu inte för ändrad bild (när du laddar upp bilder i dessa format skapas förstörande bilder i stället).

Om hosting-leverantören inte stöder WebP-bilder visas ett felmeddelande när du försöker ladda upp dem. Om du inte är säker på om hosting-leverantören stöder Imagick-biblioteket innehåller Site Health Tools info-flik ett Imagick-biblioteksfält som tillhandahåller den informationen.

I och med WebP-stöd introducerar WordPress 5.8 även två ytterligare fält i avsnittet Mediehantering i Site Health: Imagick-versionen och ImageMagick-stödda filformat.

Om WebP inte finns med bland filtyper som stöds måste du kontakta hosting-leverantören för support.

Dev-note innehåller ytterligare information om WebP-stöd i WordPress 5.8, användbara vanliga frågor och ytterligare resurser.

Om du är intresserad av bildoptimering kanske du även gillar följande självstudier:

• Hur man optimerar bilder för webben och prestanda
• Varför och hur man använder förstörande komprimering på sina WordPress-bilder
• Hur man använder WebP-bilder på WordPress (och krymper bildfilstorlekar med upp till 35%)
• 15 filtyper för bästa bild
• Allt du behöver veta om WordPress bildstorlekar

Ytterligare funktioner för utvecklare

Det finns dussintals spännande funktioner för utvecklare i WordPress 5.8. I den här artikeln har vi ägnat mest uppmärksamhet åt de som borde ha störst inverkan på ditt utvecklingsarbete. Men det finns verkligen många nya funktioner som är värda uppmärksamhet, inklusive följande:

Block Supports API

WordPress 5.8 lägger till nytt block supports flags som gör det möjligt för utvecklare att anpassa registrerade block med de senaste blockfunktionerna.

Förutom det experimentella duoton blockstödet som nämndes tidigare (color._experimentalDuotone), lägger WordPress 5.8 även till stöd för länkfärg. Om du vill dra nytta av den här funktionen lägger du bara till följande flag i dina blockmetadata:

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

Du kan ange standardvärden med attribut, som visas i följande exempel, eller ställa in förinställningarna i theme.json:

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

Ytterligare Block API-ändringar inkluderar:

• fontSize och lineHeight-stöd blir stabilt.
• spacing-stödet har utökats, och du kan nu styra margin och padding, samt individuellt styra top, right, bottom och left-storlekar.

Du kan läsa mer om Block Supports API i WordPress 5.8 i Block Supports API-uppdateringar dev-note.

En närmare titt på hur du använder Block Supports API finns i Block Supports API:s  officiella dokumentation.

Anpassade flikar för Site Health

Två nya krokar gör det nu möjligt för utvecklare att lägga till sina anpassade flikar i Site Health-gränssnittet och anpassa tillgängliga skärmar.

Filtret site_health_navigation_tabs är en associativ matris med flik-ID:t och etiketter för att registrera en ny flik på skärmen Webbplatshälsa. Du kan använda filtret genom att lägga till följande exempelkod i temats funktionsfil eller anpassade 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' );

Bilden nedan visar den nya fliken Site Health:

Tack vare site_health_navigation_tabs är det även möjligt att ändra ordning på flikar eller ta bort ett eller flera objekt.

Åtgärden site_health_tab_content utlöses när en användare besöker skärmen Site Health, med undantag för standardstatusskärmen. Du kan använda den här kroken som visas i följande utdrag (exempel från 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' );

Den undersöker först om den aktuella fliken är din anpassade flik, och läser sedan in Site Health-skärminnehållet från en .php-fil. site_health_tab_content -åtgärden gör det även möjligt för utvecklare att utöka standard Info fliken och lägga till information som är specifik för deras plugins eller teman.

Block API-ändringar i redigeraren för att stödja flera administratörsskärmar

I och med WordPress 5.8 är inläggsredigeraren inte längre den enda administratörsskärmen som använder blockredigeraren (widgetsskärmen är ett exempel).

De som bidragit till kärnan hittade flera krokar som definierades på servern beroende på $post-objektet. Det här objektet finns inte i webbplatsredigerings-, widget- och navigeringsskärmarna. Ett flertal filter har blivit inaktuella och ersatta med kontextmedvetna ersättningar.

Dessutom har en ny WP_Block_Editor_Context-klass introducerats, som representerar den aktuella blockredigeringskontexten och olika metoder.

Dessa ändringar kommer att förbättra dessa skärmar med nya funktioner och göra det möjligt för utvecklare att lägga till sina egna anpassningar.

En omfattande lista över API-ändringar i blockredigeraren som är relaterade till administratörsskärmar finns i dev-note från Greg Ziółkowski.

Ytterligare funktioner och förbättringar

Det finns så många nya funktioner och ändringar för utvecklare i WordPress 5.8 att det skulle vara omöjligt för oss att nämna dem alla i den här artikeln. Men vi har samlat en lista över dev-notes som inte omfattas här för vidare läsning:

• Släpper stöd för Internet Explorer 11
• Laddningsförbättringar för block-stilar i WordPress 5.8
• Block i en iframed-redigerare (mall)
• Om layout och innehållsbredd i WordPress 5.8
• Vi presenterar plugin-sidhuvudet ”Update URI” i WordPress 5.8
• Olika API-borttagningar i blockredigeraren i WordPress 5.8
• REST API-ändringar i WordPress 5.8
• Diverse utvecklarfokuserade förändringar i WordPress 5.8

Sammanfattning

WordPress 5.8 markerar en milstolpe på vägen till Full Site Editing. Men årets andra WordPress-utgåva erbjuder mycket mer än FSE. Användare och utvecklare hittar massor av förbättringar av blockredigeraren, en ny theme.json-mekanism,  ett kraftfullare Block API, webp-bildformatstöd och mycket mer.

Vi är särskilt imponerade av förbättringarna, både små och stora, för blockredigeraren och dess användargränssnitt. Vi älskar den förbättrade navigerbarheten mellan blocken, det omarbetade blockverktygsfältet, den berikade klarheten i gränssnittet och förbättringarna av flera block.

Dessa små förändringar förbättrar redigeringsupplevelsen ett steg i taget, och nästan utan att märka det, använder vi bättre och mer robust programvara. Det är WordPress!

Nu är det dags för dig! Vad tycker du om Full Site Editing? Och vilka är dina favoritändringar i WordPress 5.8?