Vad är nytt i WordPress 5.6 (Hjälpmedel, prestanda, säkerhet)

WordPress 5.6 ”Simone” är ute och vi är glada över att kunna ge dig en djupgående guidning om de mest intressanta funktionerna och tilläggen som lagts till i kärnan med den senaste WordPress-versionen från 2020.

Liksom tidigare utgåvor, InnehållerWordPress 5.6 flera versioner av Block-redigeraren som förbättrar redigerings-upplevelsen för WordPress-användare som ännu inte har Gutenberg´s plugin installerat och uppdaterat på sina webbplatser.

Allt handlar dock inte om Block-redigeraren. Det har lagts till flera funktioner i WordPress kärna. Exempel på dessa är ett nytt standard Twenty Twenty-One tema, auto-uppdateringar för större utgåvor, bättre stöd för PHP 8.0 samt applikations-lösenord för REST API Autentisering.

Och WordPress 5.6 kan erbjuda mycket mer än så. Det innefattas förbättringar av tillgängligheten, UI-förbättringar, massor av buggfixar och en enorm lista med ändringar för utvecklare.

Om du vill läsa mer om WordPress 5.6 utvecklingscykel, kolla länkarna nedan:

• 20 oktober 2020: Beta 1
• 27 oktober 2020: Beta 2
• 2 november 2020: Beta 3
• 12 november 2020: Beta 4
• 17 november 2020: RC 1
• 7 December 2020: Torr körning för utgivning av WordPress 5.6
• 8 december 2020: Utgivning av WordPress 5.6 ”Simone”

Redo att köra igång? Låt oss börja:

Vad är nytt i Block-redigeraren

I WordPress 5.6 har flera versioner av Gutenberg´s plugin slagits samman i kärnan, så WordPress-användare och skribenter bör märka av flera förbättringar. Det innefattas bland annat förbättrade blockmönster, ordräkning i infopanelen, förbättrad tangentbordsnavigering, förbättrad dra & släpp UI, och mycket mer.

För en mer omfattande lista över alla förbättringar och ändringar som har lagts till i block-redigeraren, kan du kolla in inläggen om releasens tillkännagivande: 8.6, 8.7, 8.8, 8.9, 9.0, 9.1, och 9.2. Buggfixar och prestandaförbättringar som genomförs i Gutenberg 9.3 och 9.4 ingår även i WordPress 5.6.

Låt oss djupdyka i de mer intressanta förändringarna som vi får se i blockredigeraren.

1. Förbättringar av block, mönster och gränssnitt
2. Block API V2
3. Ytterligare funktioner och förbättringar för Block-utvecklare

Förbättringar av block, mönster och gränssnitt

Nya blockfunktioner, förbättringar och buggfixar kommer att förbättra den övergripande redigeringsupplevelsen. Det har dessutom jobbats mycket med tillgängligheten. Nedan hittar du vårt handplockade urval av de mest intressanta funktionerna som du kommer se i blockredigeraren när du uppdaterar din webbplats till WordPress 5.6.

Positionskontroller för videor i Omslagsblock

Sedan Gutenberg 8.6, tillåter positionskontroller för videor i omslagsblock användare att flytta runt fokuspunkt och ställa in en anpassad position för videor. Den här funktionaliteten var tidigare endast tillgänglig för bildbakgrunder.

Positionsvärden ställs in genom att du klickar någonstans på väljaren för fokuspunkten och/eller använder piltangenterna på tangentbordet. Du kan hoppa 10 värden åt gången genom att hålla ner skift (se även #22531).

Uppdateringar för blockmönster

WordPress 5.6 innehåller även flera förbättrade blockmönster som lades till i Gutenberg 8,6.

Layouten, texten och färgen på den stora rubriken och stycket har uppdaterats (#23858)

Rubriken i Två kolumner med text har flyttats ut ur textblocket och placerats ovanför kolumnerna (#23853)

Citat-mönstret innehåller nu en bild längst upp och en avgränsare längst ned.

Ett nytt Rubrik- och styckemönster har lagts till med Gutenberg 8.7 (#24143).

En bra förbättring när det gäller användbarheten för block-insättaren är rullgardinsmenyn med kategorier över blockmönster, som låter dig filtrera mönster efter kategori. Detta är oerhört användbart när du har massor av mönster att välja mellan (#24954).

Stöd för Video-undertexter

Video Block stöder nu video-undertexter.

Redigerare och innehållsskapare bör tillhandahålla videoundertexter i WebVTT-format (Web Video Text Tracks Format), vilket är ”ett format för visning av tidsanställda textspår (exempelvis undertexter eller bildtexter) med hjälp av elementet <track> ” (#25861).

När du har laddat dina .vtt-filer, kommer webbplatsens besökare att kunna aktivera undertexter på sina favoritspråk.

Omvandla flera block till ett kolumn-block

En intressant förbättring i användbarhet är möjligheten att konvertera flera utvalda block till ett kolumn-block.

Du behöver endast markera de block du vill visa i kolumner. Sedan ska du klicka på övre högra knappen i verktygsfältet.

Varje markerat block kommer att omvandlas till en kolumn i ett kolumn-block.

Bakgrundsmönster i Omslagsblock

Omslagsblock kan nu visa bakgrundsmönster.

Om du vill lägga till ett bakgrundsmönster laddar du upp en mönsterbild och växlar sedan på alternativet för Upprepad Bakgrund (här är allt du behöver veta om mediebiblioteket i WordPress).

När du är klar, kan du justera väljaren för fokuspunkten efter dina behov och prova olika kombinationer med fasta bakgrunder.

Kontroll av bildstorlek som lagts till i medie- och textblocket

Med Gutenberg 9.1 har en ny bildstorlekskontroll lagts till i bilder i Media & Text Block.

Användare kan nu välja mellan alla tillgängliga bildstorlekar (#24795).

Block API V2

En ny Block API-version gör det möjligt för block att rendera sina inslagnings-element. Målet med den nya API-versionen är att göra redigerarens DOM lättare och matcha framsidans innehåll. Enligt Ella van Durpe:

Den största fördelen med detta är att teman och plugins lättare kan stilisera block-innehållet om märkningen är densamma i redigeraren.

Den nya versionen kräver att man deklarerar egenskapen för apiVersion på registreringen av blocktypen:

registerBlockType( name, { apiVersion: 2 } );

Den nya API:n kräver även useBlockProps–hook i blockets Edit-funktion. Denna krok markerar inslagnings-elementet av ett block som ett block-element.

Alla egenskaper som skickas till den här kroken kommer att slås samman och returneras till inslagnings-elementet. I följande exempel från utvecklings-anteckningarna visas ett enkelt användningsområde:

import { useBlockProps } from '@wordpress/block-editor';
 
function Edit( { attributes } ) {
	const blockProps = useBlockProps( {
		className: someClassName,
		style: { color: 'blue' },
	} );
	return <p { ...blockProps }>{ attributes.content }</p>;
}

Fler exempel finns i Block API version 2.

Ytterligare funktioner och förbättringar för block-utvecklare

Förutom Block API Version 2, finns här en lista över tillägg som utvecklare kan gå igenom.

Block Supports API

Block Support API gör att block-utvecklare kan lägga till funktioner i sina block. Färger, bakgrunder och teckenstorlekar är endast några av de många funktioner som kan läggas till via Block Support API.

WordPress 5.6 introducerar även flera nya block-supports ”för att öka stabiliteten och göra det lättare att införa dessa alternativ i block”.

Utvecklare kan använda den nya block-supporten genom att lägga till motsvarande nycklar till support-egenskaperna för block.json-filen eller direkt i funktionen registerBlockType.

Följande exempel från Block Supports utvecklings-anteckningar visar hur det fungerar:

supports: {
	color: {
		background: true, // Enable background color UI control.
		gradient: true, // Enable gradient color UI control.
		text: true // Enable text color UI control.
	},
	fontSize: true, // Enable font size UI control.
	lineHeight: true // Enable line height UI control.
}

Stilvärdet kommer automatiskt att kopplas till inslagnings-elementet antingen genom klassen has-<value>-<preset-category> (för förinställda värden) eller med ett style-element (för egna värden).

Av den anledningen är Block Supports avsett att användas med det nya Block API V2.

Block Supports kan även användas med dynamiska block.

createBlocksFromInnerBlocksTemplate API

Utvecklare kan använda komponenten InnerBlocks för att skapa anpassade block som innehåller andra block. Exempel är Kolumn-blocket och blocket för Sociala länkar.

Det nya createBlocksFromInnerBlocksTemplate Block API tillåter dig att skapa block från InnerBlocks-mallen.

Se utvecklings-noteringar för en djupare förståelse och ett exempel på kod.

Komponenter i verktygsfältet

Det finns även ett par ändringar som påverkar Toolbar-komponenterna:

1. Komponenten ToolbarGroup

Innan WordPress 5.6 tillät komponenten Toolbar utvecklare att gruppera relaterade alternativ i en gemensam container. Nu ska en ny ToolbarGroup-komponent användas i stället.

<BlockControls>
	<ToolbarGroup>
		<ToolbarButton />
	</ToolbarGroup>
</BlockControls>

2. ToolbarButton och ToolbarItem-komponenter

Att använda element som kan navigeras med tab direkt som verktygsfältsobjekt (dvs.<button>) har inte varit uppskattat. Med syftet att förbättra tillgängligheten, kan verktygsfält-objekt läggas till genom att använda toolbarButton för knappar och ToolbarItem för andra kontroller. Exemplet nedan visar en knapp och en rullgardins-meny:

<BlockControls>
	<ToolbarItem as="button" />
	<ToolbarButton />
	<ToolbarItem>
		{ ( itemProps ) => ( <DropdownMenu toggleProps={ itemProps } /> ) }
	</ToolbarItem>
</BlockControls>

Inaktivera kärnblocksmönster

Kärnmönster kan nu inaktiveras med hjälp av support-flag core-block-patterns (#24042)

Inaktivera Infogad bildredigerare

Gutenberg 8.4 lade till en Infogad bildredigeringsfunktion som gör det möjligt för användare att redigera bilder direkt i block-redigeraren.

Utvecklare kan nu inaktivera Bildredigeraren med hjälp av block_editor_settings – filtret (#23966):

add_filter( 'block_editor_settings', function( $settings ) {
	$settings['imageEditing'] = false;
	return $settings;
} );

Återanvändbara block flyttade till ett separat paket

Återanvändbara block, som tidigare var en del av @wordpress/editor-paketet, har flyttats till paketet @wordpress/reusable-blocks för att göra dem tillgängliga i andra redigerare.

Ett nytt standardtema: Twenty Twenty-One

WordPress 5.6 innehåller ett helt nytt standardtema. Twenty Twenty-One är ett mycket tillgängligt och minimalistiskt WordPress-tema med en enda kolumnlayout och en sidfotsbar.

Det nya temat använder en systemtypsnitts-stack och en minimal färgpalett som bygger på pastellbakgrundsfärger.

Du kan läsa mycket mer om Twenty Twenty-One i vårt djupgående blogginlägg: Twenty Twenty-One: En djupdykning i det nya Standard WordPress-temat.

Auto-uppdateringar för större utgåvor

Automatiska uppdateringar är en kärnfunktion som infördes i WordPress 3.7 och syftar till att förbättra webbplatsens säkerhet och göra det lättare för webbplatsadministratörer att hålla sina WordPress-webbplatser aktuella.

Det har visserligen genomförts mindre kärnuppdateringar i tidigare versioner. Med WordPress 5.6 kan dock webbplatsadministratörer aktivera automatiska uppdateringar manuellt även för större utgåvor (mer om detta strax).

Tyvärr kan denna avgörande underhålls-uppgift fortfarande vara lite förvirrande för användare som inte är så tekniskt kunniga. Du kan läsa mer om hur automatiska uppdateringar fungerar i vårt blogginlägg djupdykning i WordPress Automatiska uppdateringar.

Nu introducerar WordPress 5.6 ett nytt gränssnitt som gör att webbplatsadministratörer kan aktivera auto-uppdateringar för större kärnutgåvor.

Omfattningen av denna funktion ändrades under WordPress 5.6 beta cykel och den ursprungliga utveckings-noteringen har ersatts. För att citera Jb Audras,

Den initiala omfattningen av autouppdateringar av kärnan har flyttats för att:

• Erbjuda några uppdateringar av användargränssnittets utformning.
• För befintliga installationer kommer beteendet att förbli detsamma som det är idag: Mindre uppdateringar sker som standard, men en användare måste göra ett aktivt val för större uppdateringar (konstanter och filter som redan används av hostar eller agenturer kommer fortfarande att ha företräde).
• För nya installationer kommer standardbeteendet att ändras: Mindre uppdateringar sker som standard och aktivt val för större uppdateringar som standard.

Från och med WordPress 5.6 kan du anmäla dig till automatiska uppdateringar för större kärnversioner i skärmen Uppdateringar, där ett nytt UI tillhandahåller en kontrollruta som gör att du kan Aktivera automatiska uppdateringar för alla nya versioner av WordPress.

När du har aktiverat auto-uppdateringar av kärnan för större utgåvor, kan du göra så att de endast gäller underhåll och säkerhet genom att klicka på Växla till automatiska uppdateringar endast för nya utgåvor av underhåll och säkerhet.

Större automatiska kärnuppdateringar för utvecklare

I början, när större automatiska uppdateringar av kärnan är aktiverade lagras auto_update_core_major-alternativet i databasen med option_value aktiverat. Så, om get_site_option( 'auto_update_core_major' ) returnerar true, markeras kryssrutan för automatiska uppdateringar.

Sedan kontrollerar wordpress om större auto-uppdateringar av kärnan aktiveras genom WP_AUTO_UPDATE_CORE-konstanten eller allow_major_auto_core_updates-filtret och ställer in kryssrutan därefter.

Utvecklare kan även inaktivera större auto-uppdateringar av kärnan genom att ställa in WP_AUTO_UPDATE_CORE konstant på false eller minor som visas nedan (se även kontrollera bakgrundsuppdateringar genom wp-config.php):

# Disables all core updates:
define( 'WP_AUTO_UPDATE_CORE', false );

# Enables minor updates:
define( 'WP_AUTO_UPDATE_CORE', 'minor' );

Observera att möjliga värden för WP_AUTO_UPDATE_CORE är true (alla), 'beta', 'rc', 'minor', false.

Ett annat alternativ för att inaktivera större auto-uppdateringar av kärnan som standard är att använda allow_major_auto_core_updates– filtret:

add_filter( 'allow_major_auto_core_updates', '_return_false' );

Några kommentarer om att lägga till auto-uppdateringar av kärnan

Redan i december 2018 delade Matt Mullenweg de nio prioriteringarna för 2019 där ”Att tillhandahålla ett sätt för användare att välja automatiska uppdateringar av större kärn-utgåvor” var nummer 7. Vi kanske är lite sent ute, men vi är på väg.

Större automatiska kärnuppdateringar bör ha stor inverkan på WordPress säkerhet och övergripande användarupplevelse. En sak verkar vara tydlig: ur en teknisk synvinkel, är den stora automatiska kärnuppdaterings-funktionen en komplex uppgift som inte utförs till 100% med utgivningen av WordPress 5.6.

Efter en genomtänkt diskussion om Slack sammanfattade Josepha Haden den oro och de frågor som väller in från kärn-bidragsgivare.

Det huvudsakliga långsiktiga målet är att ha auto-uppdateringar tillgängliga för majoriteten av WordPress webbplatser för att förbättra säkerheten i hela ekosystemet (mer än 30% av webben).

Helen Hou-Sandí, huvud utvecklare för kärnan skriver:

Enligt mig finns det några mycket svåra tekniska saker som måste lösas och detta kräver mycket disciplin och fokus från de som har ansvar.

Så vi bör kunna se ytterligare ändringar och förbättringar på UI av de stora automatiska kärnuppdateringarna med tiden. Detta är vad vi kan förvänta oss från och med nu:

WordPress 5.6:

• I befintliga installationer måste större uppdateringar aktiveras av användaren. Alla konstanter och filter som redan används kommer att ha företräde. Mindre uppdateringar är aktiverade som standard.
• I nya installationer aktiveras både mindre och större uppdateringar som standard.

WordPress 5.6.1:

• Vi bör kunna se några ändringar i UI för auto-uppdateringar av kärnan baserat på feedback.

WordPress 5.7:

• En nudge bör läggas till på skärmen för webbplatsens hälsa för alla som valt bort större auto-uppdateringar.
• En alternativ för automatisk uppdatering bör läggas till i installationsprocessen för WordPress 5.7.

Ett stort bekymmer med auto-uppdateringar av kärnan är förtroendet från användarna. Helen skriver:

Jag tror att vi fortfarande kan göra en hel del arbete för att proaktivt få förtroende från användare, särskilt de som förr har haft dåliga erfarenheter av WordPress och / eller uppdateringar

Men varje WordPress-webbplats är en blandning av Kärna, plugins, och teman. För att citera Helen:

Kärnuppdateringar är i stort sett ganska säkra och det finns vissa skydd inbyggda. Men på grund av att webbplatser kan köra vilken kod som helst från alla källor, finns det inget hundraprocentigt skydd för ”varje typ av WordPress-webbplats”.

Användare med aktiverade automatiska kärnuppdateringar bör regelbundet säkerhetskopiera sina webbplatser eller välja en hosting-leverantör som erbjuder automatiska säkerhetskopior i sina planer.

Automatiska kärnuppdateringar kommer även att påverka den övergripande uppdaterings- upplevelsen, inklusive automatiska uppdateringar av plugins och teman. Joost de Valk noterade i en kommentar:

Om vi aktiverar automatiska kärnuppdateringar i WordPress som standard, bör vi göra samma sak för plugins. Annars kan plugins och teman inte uppdateras på grund av centrala uppdateringar. Jag tror att användarna kommer att förvänta sig detta.

Förändringar i Site Health för Webbplatser i WordPress 5.6

Utöver alla funktioner som nämns i den här artikeln, erbjuder WordPress 5.6 även en förbättrad version av Site Health-verktyget, som nu beter sig annorlunda i bakgrunden.

Site Health´s dataverifiering

Numera kontrollerar en validator problemsvar för Site Health-tester. Valideraren kommer att kasta alla ogiltiga svar, och förhindra att Site Health-verktyget orsakar allvarliga fel och stoppar ytterligare kontroller.

Från och med nu kommer ogiltiga svar inte att påverka indikatorn för Site Health (#50145).

Icke-synkroniserade kontroller via REST Slutpunkt

Verktyget Site Health är ett kraftfullt säkerhetsverktyg som gör att webbplatsägare kan ha koll på hälsotillståndet för sina webbplatser.

Det här verktyget utför ett antal säkerhetstester som ger en översikt över din webbplats hälsotillstånd.

Dessa tester kan delas in i två kategorier: direkta tester, som körs vid sidladdning, och icke-synkroniserade tester, som kan ta lite tid att slutföra, och kommer att köras senare via JavaScript-anrop.

Tidigare utfördes dessa tester med en uppmaning till admin-ajax.php. I och med WordPress 5.6, flyttas fokus från admin-ajax.php och en ny REST API-slutpunkt kommer att användas i stället. Från och med WordPress 5.6, kan icke-synkroniserade tester hittas under /wp-json/wp-site-health/v1.

Tack vare den nya REST API-förbättringen, kommer även plugins och teman att kunna använda sig av REST-slutpunkter. De kommer inte längre vara begränsade till Ajax-åtgärder för sina hälsotester.

Varje icke-synkroniserat test kan nu deklarera argumentet has_rest, vars standardvärde är false.

Koden nedan från wp-admin/includes/class-wp-site-health.php visar matrisen av icke-synkroniserade tester i WordPress 5.6:

'async'  => array(
	'dotorg_communication' => array(
		'label'             => __( 'Communication with WordPress.org' ),
		'test'              => rest_url( 'wp-site-health/v1/tests/dotorg-communication' ),
		'has_rest'          => true,
		'async_direct_test' => array( WP_Site_Health::get_instance(), 'get_test_dotorg_communication' ),
	),
	'background_updates'   => array(
		'label'             => __( 'Background updates' ),
		'test'              => rest_url( 'wp-site-health/v1/tests/background-updates' ),
		'has_rest'          => true,
		'async_direct_test' => array( WP_Site_Health::get_instance(), 'get_test_background_updates' ),
	),
	'loopback_requests'    => array(
		'label'             => __( 'Loopback request' ),
		'test'              => rest_url( 'wp-site-health/v1/tests/loopback-requests' ),
		'has_rest'          => true,
		'async_direct_test' => array( WP_Site_Health::get_instance(), 'get_test_loopback_requests' ),
	),
	'authorization_header' => array(
		'label'     => __( 'Authorization header' ),
		'test'      => rest_url( 'wp-site-health/v1/tests/authorization-header' ),
		'has_rest'  => true,
		'headers'   => array( 'Authorization' => 'Basic ' . base64_encode( 'user:pwd' ) ),
		'skip_cron' => true,
	),
),

Site Health´s schemalagda kontroller:

Icke-synkroniserade tester har implementerats för att förhindra långsam sidladdning och timeout. Det finns ingen oro för sånt när det gäller schemalagda tester.

Med detta i åtanke, kan test-arrayer även deklarera async_direct_test-argument (med hjälp av koden ovan), som bör vara en anropningsbar instans av ett test. Detta är utöver has_rest– argumentet som vi nämnde ovan,

Om ett test körs under en schemalagd händelse används inte REST API-slutpunkten. Testet körs istället direkt.

Application-Passwords för REST API-autentisering

Application Passwords är ett nytt system för att göra autentiserade förfrågningar till olika WordPress API: er.

Lösenorden är 24 tecken långa och består av versaler, gemener och numeriska tecken, som antingen kan genereras manuellt eller via REST API.

Om du vill generera ett nytt lösenord manuellt bläddrar du till din Profilskärm och bläddrar nedåt på sidan.

Välj ett namn på ditt applikations-lösenord och bekräfta. WordPress kommer att visa ditt nya lösenord.

Applikations-lösenord visas i bitar på 4-tecken, åtskilda av mellanslag, som nedan:

gsUc UhkU 0ScI gdRd TGoU vrW5

Lösenord kan dock användas med eller utan mellanslag:

Applikations-lösenorden som skickas tillbaka genom auktoriseringsflödet inkluderar inte blanksteg. Blankstegen finns där för att göra det lättare för någon som behöver återge den långa strängen manuellt.

De kan användas utan mellanslag eller med — —. Om du vill kan du förmodligen lägga till ett blanksteg efter varje tecken.

På skärmen Användarprofil kan du visa, skapa och återkalla applikations-lösenord. Kolumnerna för Senast använda och Senaste IP gör att du enkelt kan hitta lösenord som inte längre används och som ska återkallas.

Vid tidpunkten för denna skrift kan Application Passwords användas med REST API´s autentiserade begäranden och med det äldre XML-RPC API. Vi bör dock kunna se Application Passwords användas med ytterligare API:er i framtiden. George Stephanis förklarar:

Autentiseringsschemat för applikations-lösenord kan även tillämpas på framtida API:er för WordPress när de blir tillgängliga. Om exempelvis GraphQL eller andra system är aktiverade i WordPress, kommer applikations-lösenord att ge dem en solid och etablerad autentiseringsinfrastruktur direkt.

Att använda Application Passwords på wp-login.php är inte möjligt.

För en närmare bild av den här funktionen och mer tekniska insikter kan du kontrollera följande resurser:

• Förslag: REST API Autentisering / Application Passwords
• Application Passwords: Integrerings-guide
• Application Password´s plugins

Bättre stöd för PHP 8

PHP 8.0 erbjuder massor av nya funktioner och optimeringar och gör det till en sann milstolpe inom utvecklingen av språket. Den nyare versionen av PHP introducerar många uppdateringar som bryter bakåtkompatibilitet och många dåliga funktioner har nu officiellt tagits bort. Så, att lägga till stöd för PHP 8 i WordPress är en stor utmaning.

Faktum är att även om bidragsgivarna till WordPress Kärna lägger stora ansträngningar på att göra WordPress 5.6 kompatibelt med PHP 8, bör vi inte förvänta oss att varje möjligt problem har upptäckts. Målet är att nå en punkt där hela WordPress ekosystem är kompatibelt med PHP 8, vilket verkar vara en tuff nöt att knäcka för tillfället.

Dessutom innehåller en WordPress-webbplats minst ett tema och ett varierande antal plugins. Så vi kan förvänta oss ett bra stöd för PHP 8 i WordPress Kärna, men det är svårt att tro att detta även kommer gälla plugins och teman.

Vi håller med Jonathan Desrosiers när han säger:

Hur stödet för PHP 8 kommer att vara inom det bredare ekosystemet (plugins, teman, osv.) är omöjligt att veta. Av den anledningen bör WordPress 5.6 betraktas som ”beta kompatibelt” med PHP 8.

”Beta kompatibelt med PHP 8” känns som ett bra uttryck för att representera en pågående process som fortfarande kräver en hel del ansträngning, men samtidigt erkänner det stora arbete som gjorts hittills.

Emellertid

Alla utvecklare av plugins och teman, samt host-communities, uppmanas att göra sin kod kompatibel med PHP 8. Detta kommer att tillåta WordPress att verkligen uppnå en ”full kompatibilitet”, utan att slutanvändare behöver bära bördan.

Vissa PHP 8-förändringar som man bör vara medveten om

Som vi nämnde ovan, är arbetet med att göra WordPress fullt kompatibelt med PHP 8 under process. Jonathan Desrosiers erbjuder en lista över PHP 8-funktioner och förändringar som WordPress-utvecklare bör vara medvetna om.

Namngivna parametrar

Med PHP namngivna argument är nu möjligt att skicka argument till en funktion som bygger på parameterns namn, snarare än parameterns position. Detta gör det möjligt att skriva kod som är självdokumenterande. Det innebär även att argument är oberoende av order och att standardvärden godtyckligt kan hoppas över.

Tyvärr kan namngivna parametrar för närvarande orsaka problem med bakåtkompatibilitet i WordPress. Den främsta orsaken är att parameternamn kan ändras utan nåt meddelande tills den aktuella granskningen har slutförts. Så, vid tidpunkten för denna skrift:

Användning av namngivna parametrar när du anropar WordPress-funktioner och klassmetoder stöds uttryckligen inte och avråds starkt tills denna revision kan slutföras. Detta beror på att parameternamn kan ändras utan nåt meddelande under granskningen,. När den här granskningen har slutförts kommer den att tillkännages i en framtida utvecklings-meddelande.

Strikta typ/värde-valideringar för interna funktioner

När de passerar en parameter av olaglig typ beter sig interna och användardefinierade funktioner annorlunda. Användardefinierade funktioner kastar en TypeError, men interna funktioner beter sig på en mängd olika sätt, beroende på ett flertal villkor.

För att ta bort dessa inkonsekvenser, genererar den interna parametern parsing API:s i PHP 8 alltid en ThrowError när en parametertyp inte matchar.

Strikt typdeklaration används inte i WordPress Kärna. Kärnbidragsgivarna arbetar dock med att förhindra att ogiltiga typer skickas till Kärn-funktioner. Tills detta arbetet är slutfört, kan denna ändring i PHP 8 leda till TypeErrors, ”särskilt om ett värdes typ ändras felaktigt genom kod som är ansluten till ett filter”.

Strängare typ kontroller för Aritmetiska och Bitwise Operatörer

I tidigare versioner av PHP, var det tillåtet att använda aritmetiska och bitvisa operatörer till en array, resurs, eller icke överbelastade objekt. Beteendet var dock inkonsekvent och till och med orimligt ibland:

var_dump([] % [42]);
// int(0)

Med PHP 8 är beteendet alltid detsamma och alla aritmetiska och bitvisa operatörer kommer att kasta ett TypeError-undantag när operanden är en array, resurs, eller icke-överbelastat objekt (se RFC).

Detta är en annan förändring som kräver lite extra arbete från kärnbidragsgivarna, som de många meddelandena om fel, varningar och ändringar.

På grund av alla dessa olösta problem, rekommenderas det starkt att man kör kompatibilitetstester på en iscensättning eller utvecklingsmiljö innan man gör övergången till PHP 8 på sin live-webbplats. Läs mer om WordPress och PHP 8.0.

Ytterligare ändringar för utvecklare

WordPress 5.6 introducerar tonvis med ändringar för utvecklare och vi kunde inte ta med alla i vår lista. Men här är topp 3 som vi tycker att man ska ta en titt på:

1. wp_after_insert_post åtgärds-Krok

Innan WordPress 5.6 kunde du använda save_posts eller liknande åtgärder för att köra anpassad kod efter ett publicerat inlägg. Nu introducerar WordPress 5.6 åtgärds-kroken wp_after_insert_post, som avfyras endast efter att termer och metadata har sparats.

Dessutom har flera funktioner uppdaterats för att förhindra att dessa krokar avfyras. Den nya $fire_after_hooks-parametern har lagts till i funktionerna wp_insert_posts(), wp_update_post() och wp_insert_attachment(). Om den är inställd på false, förhindrar det att efterinsatskrokarna avfyras.

Kolla in utvecklings-noteringen för en djupare översikt.

2. Typecasting

Typecasting-funktioner intval(), strval(), floatval() och boolval() har tagits bort från kärnan till förmån för direkt typecasting:

1. intval() → (int)
2. strval() → (string)
3. floatval() → (float)

Den här ändringen har direkta effekter på prestanda eftersom direkt typecasting är ~ 6x snabbare än typecasting funktioner.

3. WP_Error objekt

Klassen WP_Error har förbättrats för att tillåta sammanslagning av flera WP_Error-instanser till en. Tidigare kunde man endast göra detta manuellt. Nu introducerar WordPress 5.6 tre nya metoder för att hjälpa till att hantera flera WP_Error-instanser. Koden nedan är ett exempel från utvecklings-noteringarna:

<?php
$error_1 = new WP_Error(
	'code1',
	'This is my first error message.',
	'Error_Data'
);
 
$error_2 = new WP_Error(
	'code2',
	'This is my second error message.',
	'Error_Data2'
);
 
// Merge from another WP_Error.
$error_1->merge_from( $error_2 );
 
// Retrieve all error data, optionally for a specific error code.
$error_1->get_all_error_data( 'code2' );
 
// Export to another WP_Error
$error_1->export_to( $error_2 );

Ytterligare avläsningar för utvecklare

Det är omöjligt att nämna alla förändringar som är inriktade mot utveckling i WordPress 5.6, men du kan läsa mer om dem med hjälp av följande resurser:

• Uppdatering av jQuery-version levereras med WordPress
• Uppdatering av core jQuery till version 3 – del 2
• WordPress och PHP 8.0
• REST API Batch-ramverk i WordPress 5.6
• Diverse utvecklarfokuserade förändringar i WordPress 5.6

Sammanfattning

WordPress 5.6 är en stor release med massor av funktioner och ändringar för både användare och utvecklare. Vi är alltid glada över att se hur utvecklingen av webbtekniker direkt påverkar WordPress-säkerhet, prestanda, användbarhet och tillgänglighet.

Men utvecklingen slutar aldrig och vi kan redan nu ta en titt på framtida potentiella release- datum.

Nu vill vi veta: Vad tycker du mest om i WordPress 5.6? Och vilka funktioner skulle du vilja läggas till i WordPress 5.7?