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.

Important

Det finns otroligt många förändringar i WordPress 5.8. För att förhindra risken för oväntade konflikter med ditt tema och dina plugins rekommenderar vi starkt att du kör en säkerhetskopia av din webbplats och testar den nya versionen i en  iscensättningsmiljö innan du uppdaterar din livewebbplats.

WordPress 5.8 'Tatum' är här! 🥳 Kolla in de nya funktionerna och njut av den första implementeringen av Full Site Editing 🎁Click to Tweet

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.

Info

Mallredigering kan användas i klassiska teman, inklusive en theme.json-fil eller support av ’block-templates’. Det kan inte inaktiveras för blockteman.

Mallredigeraren.

Mallredigeraren.

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).

Mallpanelen i blockredigerarens sidofält.

Mallpanelen i blockredigerarens sidofält.

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

Ange ett mallnamn.

Ange ett mallnamn.

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.

Mallredigeringsläge i WordPress 5.8.

Mallredigeringsläge i WordPress 5.8.

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:

Alternativen för Spara mall.

Alternativen för Spara mall.

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).

Exportera mallar och malldelar.

Exportera mallar och malldelar.

Info

Observera att om du anger en blockmall för en sida eller ett blogginlägg används inte den vanliga PHP-mallen längre för att generera sidan. Då används blockmallen i stället.

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.

Fullbreddsjusterings-problem i Twenty Twenty-One klassiskt tema.

Fullbreddsjusterings-problem i Twenty Twenty-One klassiskt tema.

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.

Problemet med fullbreddsjusteringen har åtgärdats.

Problemet med fullbreddsjusteringen har åtgärdats.

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).

Fullständiga webbplatsredigerarblock som är tillgängliga i icke FSE-sammanhang sedan WordPress 5.8.

Fullständiga webbplatsredigerarblock som är tillgängliga i icke FSE-sammanhang sedan WordPress 5.8.

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:

 Föreslagna temablock.

Föreslagna temablock.

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).

Blockinställningarna för inloggning/utloggning i blockredigeraren.

Blockinställningarna för inloggning/utloggning i blockredigeraren.

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.

Listvy över ett Query Loop-block.

Listvy över ett Query Loop-block.

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.

Query Loop-blockmönster i rutnätsvyn.

Query Loop-blockmönster i rutnätsvyn.

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

Variationer i Query Loop-blocket.

Variationer i Query Loop-blocket.

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.

Query Loop-blocket med sidofältsinställningar.

Query Loop-blocket med sidofältsinställningar.

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.

Visa blockinställningar för Query Loop-blocket.

Visa blockinställningar för Query Loop-blocket.

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.

Info

Blocken Query Loop och Inläggsmall har bytt namn flera gånger under de senaste veckorna. Den slutliga namngivningen har nåtts med Gutenberg 10,9.

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.

Listvy-sidofältet i WordPress 5.8.

Listvy-sidofältet i WordPress 5.8.

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.

Hovra över objekten i listvyn.

Hovra över objekten i listvyn.

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

Lägga till ett ankare i block i WordPress 5.8.

Lägga till ett ankare i block i WordPress 5.8.

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.

Blockwidgets modal.

Blockwidgets modal.

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

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.

Blockwidgetar i anpassaren.

Blockwidgetar i 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.

Anpassa widgetar-infogaren.

Anpassa widgetar-infogaren.

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

Snabbinfogaren för att anpassa widgetar.

Snabbinfogaren för att anpassa widgetar.

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.

Visa fler inställningar.

Visa fler inställningar.

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.

Media & textblock omformningar och stilar.

Media & textblock omformningar och stilar.

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.

Omvandling till två kolumner för media och text.

Omvandling till två kolumner för media och text.

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.

Ett modal för flödet för att skapa återanvändbara block.

Ett modal för flödet för att skapa återanvändbara block.

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

Ett återanvändbart block i WordPress 5.8.

Ett återanvändbart block i WordPress 5.8.

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:

Markeringar av återanvändbara block.

Markeringar av återanvändbara block.

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”.

Rubrikblockets verktygsfält.

Rubrikblockets verktygsfält.

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.

Normaliserat bildblocks verktygsfält

Normaliserat bildblocks verktygsfält

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

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

Bildblockets verktygsfält i WordPress 5.7 vs WordPress 5.8.

Bildblockets verktygsfält i WordPress 5.7 vs WordPress 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:

Det övre verktygsfältet på breda skärmar i WordPress 5.7.

Det övre verktygsfältet på breda skärmar i WordPress 5.7.

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.

Det övre verktygsfältet på breda skärmar i WordPress 5.8.

Det övre verktygsfältet på breda skärmar i WordPress 5.8.

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).

En inbäddad PDF i WordPress 5.8.

En inbäddad PDF i WordPress 5.8.

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.

Det nya duotondesignverktyget i ett bildblock.

Det nya duotondesignverktyget i ett bildblock.

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.

Den nya duotonväljaren i WordPress 5.8.

Den nya duotonväljaren i WordPress 5.8.

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.

Inspekterar duoton SVG filtret i Chrome DevTools.

Inspekterar duoton SVG filtret i Chrome DevTools.

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:

Duotonfärgfilter som används över en bild.

Duotonfärgfilter som används över en bild.

Ett annat duotonfärgfilter som används över en bild.

Ett annat duotonfärgfilter som används över en bild.

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.

Utökade Inställningar för tabellblocksfärg.

Utökade Inställningar för tabellblocksfärg.

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.

Kantblockskontroller i WordPress 5.8 och TT1 Block.

Kantblockskontroller i WordPress 5.8 och TT1 Block.

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):

Om du trycker på pilen uppåt och nedåt flyttas radfokus.

Om du trycker på pilen uppåt och nedåt flyttas radfokus.

  1. Tvådimensionell tangentbordsnavigering på blockinfogaren. Nu kan vi navigera mellan block mer exakt och intuitivt.
  1. En ny ”Tema”-kategori för malldelar och variationer visas nu i infogaren i Full Site Editing (se PR #30020).
  2. 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).

Dra och släpp bakgrundsbilder i omslagsblocket.

Dra och släpp bakgrundsbilder i omslagsblocket.

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).

Publiceringsgränssnitt i WordPress 5.7.

Publiceringsgränssnitt i WordPress 5.7.

Publiceringsgränssnitt i WordPress 5.8.

Publiceringsgränssnitt i WordPress 5.8.

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:

Anpassad duotonförinställning i theme.json.

Anpassad duotonförinställning i theme.json.

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.

Behöver du snabb, pålitlig och säker hosting för din WordPress-webbplats? Kinsta tillhandahåller allt detta och 24/7 support i världsklass från WordPress-experter. Kolla in våra planer

En globalt definierad anpassad teckenstorlek i theme.json.

En globalt definierad anpassad teckenstorlek i theme.json.

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.

Ett styckeblock med anpassade förinställningar för teckenstorlek.

Ett styckeblock med anpassade förinställningar för teckenstorlek.

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' );
Info

Inställningarna som deklareras i theme.json har företräde framför inställningar som deklareras via add_theme_support.

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:

Ä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.”.

 Google Lighthouse föreslår att du använder nästa generations bildformat.

Google Lighthouse föreslår att du använder nästa generations bildformat.

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:

Exportera bilden som WebP i GIMP.

Exportera bilden som WebP i GIMP.

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.

Jämförelse av komprimeringsfaktor och filstorlekar.

Jämförelse av komprimeringsfaktor och filstorlekar.

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 JPEG-filstorleken är 127 KB.

Den komprimerade JPEG-filstorleken är 127 KB.

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

Samma bild i WebP-format är 74 kB.

Samma bild i WebP-format är 74 kB.

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.

Kinsta stödjer Imagickbiblioteket.

Kinsta stödjer Imagickbiblioteket.

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.

ImageMagick version fält i Site Heath.

ImageMagick version fält i Site Heath.

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:

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:

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:

En anpassad flik som lagts till på navigeringsmenyn för Site Health.

En anpassad flik som lagts till på navigeringsmenyn för 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:

WordPress 5.8 introducerar den första implementeringen av Full Site Editing 🎁 Nyfiken på Framtiden för WordPress? Missa inte vår djupgående översikt över de viktigaste funktionerna och ändringarna som kommer med WordPress 5.8 🚀Click to Tweet

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?


Spara tid, kostnad och maximera webbplatsens prestanda med:

  • Omedelbar hjälp från WordPress -hostingexperter, 24/7.
  • Cloudflare Enterprise-integration.
  • Global publik räckvidd med 28 datacenter över hela världen.
  • Optimering med vår inbyggda Application Performance Monitoring.

Allt detta och mer, i en plan utan långsiktiga kontrakt, assisterad migration och en 30-dagars pengarna-tillbaka-garanti. Kolla in våra paket, eller prata med säljteamet för att hitta den plan som fungerar för dig.