Nyheder i WordPress 5.6 (tilgængelighed, ydeevne, sikkerhed)

WordPress 5.6 “Simone” er ude, og vi er spændte på at dykke dybt ind i det sammen med dig i de mest interessante funktioner og tilføjelser, der er fusioneret ind i Core med den seneste WordPress-udgivelse fra 2020.

Ligesom tidligere udgivelser inkluderer WordPress 5.6 flere versioner af Block Editor, der forbedrer redigeringsoplevelsen for WordPress-brugere, der endnu ikke har Gutenberg-pluginnet installeret og opdateret på deres hjemmesider.

Ikke alt handler dog om Block Editor. Flere funktioner er blevet tilføjet til WordPress Core, som et nyt standard Twenty Twenty-One-tema, auto-opdateringer til større udgivelser, bedre support til PHP 8.0, Application Passwords til REST API-godkendelse.

Og der er meget mere i WordPress 5.6. Vi ser tilgængelighedsforbedringer, UI-forbedringer, masser af fejlrettelser og en enorm liste over ændringer for udviklere.

Hvis du vil læse mere om WordPress 5.6 udviklingscyklus, skal du kontrollere nedenstående links:

oktober 2020: Beta 1
oktober 2020: Beta 2
november 2020: Beta 3
november 2020: Beta 4
november 2020: RC 1
december 2020: Tørløb til frigivelse af WordPress 5.6
8. december 2020: Udgivelse af WordPress 5.6 “Simone”

Klar til at dykke ned?

Hvad er nyt med Block Editor

Med WordPress 5.6 er flere versioner af Gutenberg-pluginet blevet flettet ind i kernen, så WordPress-brugere og forfattere bør bemærke flere forbedringer i editoren. Vi ser forbedrede blokmønstre, ordoptællinger i infopanelet, forbedret tastaturnavigation, forbedret drag n drop UI og meget mere.

For en mere omfattende liste over alle forbedringer og ændringer, der er tilføjet til blokeditoren, skal du tjekke udgivelsesmeddelelsens indlæg: 8.6, 8.7, 8.8, 8.9, 9.0, 9.1, og 9.2. Fejlrettelser og forbedringer af ydeevnen implementeret i Gutenberg 9.3 og 9.4 er også inkluderet i WordPress 5.6.

Lad os dykke ned i de mere interessante ændringer, vi ser i blokeditoren.

Blocks, mønstre og UI-forbedringer
Block API V2
Yderligere funktioner og forbedringer for block-udviklere

Blokeringer, patterns og UI-forbedringer

Nye block-funktioner, forbedringer og fejlrettelser forbedrer den samlede redigeringsoplevelse. Der er også gjort et stort arbejde med tilgængelighed. Nedenfor finder du vores håndplukkede udvalg af de mest interessante funktioner, du kan se i blokeditoren, når du opdaterer dit websted til WordPress 5.6.

Position controls for videoer i Cover Block

Tilføjet til Cover Blocks siden Gutenberg 8.6 giver positionskontrol til videoer brugerne mulighed for at flytte fokuspunktet og indstille en brugerdefineret position til videoer. Denne funktionalitet var tidligere kun tilgængelig for billedbaggrund.

Positionsværdier indstilles ved at klikke et vilkårligt sted på vælgeren til fokuspunkt og/eller bruge piletasterne på dit tastatur. Du kan springe værdier med 10 ved at holde shift nede (se også #22531).

Bloker pattern opdateringer

WordPress 5.6 inkluderer også flere block pattern forbedringer tilføjet med Gutenberg 8.6.

Layoutet, teksten og farven på den store headers og afsnittet er blevet opdateret (#23858)

Headeren i To kolonner med tekst er flyttet ud af tekstblokken og placeret over kolonnerne (#23853)

Quote pattern indeholder nu et billede øverst og en separator i bunden.

Et nyt overskrift og afsnit mønster er tilføjet med Gutenberg 8.7 (#24143).

Heading og Paragraph pattern i WordPress 5.6

En god forbedring af anvendeligheden for block pattern category dropdown med block pattern category, som giver dig mulighed for at filtrere mønstre efter kategori. Dette er ekstremt nyttigt, når du har masser af patterns at vælge imellem (#24954).

Rullemenuen med pattern category dropdown

Understøttelse af video undertekster

Video Blocks understøtter nu video undertekster.

Tilføjelse af video-undertekster i videoblokering

Redaktører og indholdsskabere skal give videoundertekster i WebVTT-format (Web Video Text Tracks Format), som er “et format til visning af timede tekstspor (såsom undertekster eller billedtekster) ved hjælp af <track> -elementet” (#25861).

Track elementer, der linker til undertekster på forskellige sprog

Når du har indlæst dine .vtt-filer, får site viewers mulighed for at aktivere undertekster på deres farvoritsprog.

Transformer flere blokke til en kolonneblok

En interessant forbedring af anvendelighed er evnen til at konvertere flere valgte blokke til en kolonneblok.

Du skal bare vælge de blokke, du vil vise i kolonner, og klik derefter på den øverste højre knap på block værktøjslinjen.

Hver valgt blok konverteres til en kolonne i en kolonneblok.

Baggrundsmønstre i cover block

Cover blocks kan nu vise baggrundsmønstre.

For at tilføje et baggrundsmønster skal du uploade et mønsterbillede og derefter skifte til indstillingen Gentagen baggrund (her er alt hvad du behøver at vide om mediebiblioteket i WordPress).

Når du er færdig, skal du justere focal point picker efter dine behov og prøve forskellige kombinationer med faste baggrunde.

Billedstørrelseskontrol tilføjet til Media & Text Block

Med Gutenberg 9.1 er der tilføjet en ny kontrol af billedstørrelses til billeder i Media & Text Block.

Brugere kan nu vælge mellem alle de tilgængelige billedstørrelser (#24795).

kontrol af billedstørrelse i Media & Text Block

Block API V2

En ny Block API-version gør det muligt for blokke at gengive deres indpakningselement. Målet med den nye API-version er at lette redaktørens DOM og få den til at matche forsiden. Ifølge Ella van Durpe:

Den største fordel ved dette er, at temaer og plugins lettere kan style blokindholdet, hvis markeringen er den samme i editoren.

Den nye version kræver at deklarere apiVersion-egenskaben ved block type-registrering:

registerBlockType( name, { apiVersion: 2 } );

Den nye API kræver også useBlockProps hook i blokken Edit funktion. Denne hook markerer en blok indpakningselement som et blokelement.

Enhver ejendom, der overføres til denne krog, flettes og returneres til indpakningselementet. Følgende eksempel fra dev-notes viser en enkel brugssag:

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

For flere eksempler, se Block API version 2.

Yderligere funktioner og forbedringer for block udviklere

Udover Block API Version 2 er her en liste over tilføjelser, som udviklere kan gennemgå.

Block Supports API

Block Support API giver block udviklere mulighed for at tilføje funktioner til deres blokke. Farver, baggrunde, fontstørrelser er blot nogle få af de mange funktioner, der kan føjes til blokke gennem Block Supports API.

WordPress 5.6 introducerer også adskillige nye block supports “for at øge konsistensen og gøre det lettere at introducere disse muligheder i blokke”.

Udviklere kan bruge den nye block support, der tilføjer de tilsvarende nøgler til support egenskaben for block.json-filen eller direkte til registerBlockType funktionen.

Følgende eksempel fra Block Supports dev-note viser, hvordan det fungerer:

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

Style værdien vedhæftes automatisk til indpakningselementet enten gennem klassen has-<value>-<preset-category> (for forudindstillede værdier) eller med et style-element (til brugerdefinerede værdier).

Af denne grund er Block Supports beregnet til at blive brugt sammen med den nye Block API V2.

Block support kan også bruges med dynamic blocks.

createBlocksFromInnerBlocksTemplate API

Udviklere kan bruge InnerBlocks component til at oprette brugerdefinerede blokke, der indeholder andre blokke. Eksempler er kolonneblokken og blokken Sociale links.

Den nye createBlocksFromInnerBlocksTemplate Block API giver dig mulighed for at oprette blokke fra skabelonen InnerBlocks.

Se dev-notes for en depper-visning og et eksempel på kode.

Toolbar Components

Et par ændringer påvirker også Toolbar components:

1. ToolbarGroup Component

Før WordPress 5.6 tillod Toolbar-komponent udviklere at gruppere relaterede muligheder i en fælles container. Nu skal en ny ToolbarGroup-komponent bruges i stedet.

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

2. Komponenter i ToolbarButton og ToolbarItem

Brug af tabulatorelementer direkte som toolbar items (dvs. <button>) er udfaset. Med det formål at forbedre tilgængeligheden kan værktøjslinjeposter tilføjes ved hjælp af ToolbarButton til knapper og ToolbarItem til andre kontroller. Eksemplet nedenfor viser en knap og en dropdown menu:

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

Deaktivering af core block patterns

Core patterns kan nu deaktiveres ved hjælp af support flag for core-block-patterns (#24042)

Deaktivering af Inline Image Editor

Gutenberg 8.4 tilføjede en indbygget Inline Image Editing, der giver brugerne mulighed for at redigere billeder direkte fra Block Editor.

Udviklere kan nu deaktivere Image Editor ved hjælp af filteret block_editor_settings (#23966):

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

Genanvendelige blokke flyttet til en separat pakke

Genanvendelige blokke, der tidligere var en del af @wordpress/editor pakken, er flyttet til @wordpress/reusable-blocks pakken for at gøre dem tilgængelige i andre redaktører.

Et nyt standardtema: Twenty Twenty-One

WordPress 5.6 inkluderer et helt nyt standardtema. Twenty Twenty-One er et meget tilgængeligt, minimalistisk WordPress-tema med et enkelt kolonnelayout og sidebar i footer.

Det nye tema bruger en systemskriftsstabel og en minimal farvepalet baseret på baggrundsfarver i pastel.

Du kan læse meget mere om Twenty Twenty One i vores dybtgående blogindlæg: Twenty Twenty-One: A Deep Dive into the New Default WordPress Theme

Auto-opdateringer til større udgivelser

Automatiske opdateringer er en kernefunktion, der er introduceret i WordPress 3.7, der sigter mod at forbedre websikkerhed og gøre det lettere for webstedsadministratorer at holde deres WordPress-websteder opdaterede.

Mens automatiske mindre kerneopdateringer er blevet implementeret i tidligere versioner, kan WordPress 5.6-webstedsadministratorer nu også manuelt aktivere automatiske opdateringer til større udgivelser (mere om det på et sekund).

Desværre kan denne vigtige vedligeholdelsesopgave stadig være lidt forvirrende for ikke-teknologiske brugere. Du kan læse mere om, hvordan automatiske opdateringer fungerer, i vores Deep Dive Into WordPress Automatic Updates-blogindlæg.

Så WordPress 5.6 introducerer en ny grænseflade, der gør det muligt for webadministratorer at aktivere automatiske opdateringer til større kerneudgivelser.

Omfanget af denne funktion blev ændret under WordPress 5.6 beta-cyklus, og den originale dev-note er blevet erstattet. Med Jb Audras ord,

Det oprindelige omfang af Core-opdateringer er flyttet til:

Giver nogle opdateringer til designet af brugergrænsefladen.

For eksisterende installationer forbliver adfærden den samme som i dag: tilvalgt mindre opdateringer som standard, men en bruger skal tilvælge større opdateringer (konstanter og filtre, der allerede er i brug af værter eller agenturer, vil stadig tage forrang).

For nye installationer ændres standardadfærden: tilvalgt mindre opdateringer som standard og tilvalgt større opdateringer som standard.

Fra og med WordPress 5.6 kan du tilmelde dig automatiske opdateringer til større kerneversioner i skærmbilledet Opdateringer, hvor et nyt brugergrænseflade indeholder et afkrydsningsfelt, så du kan aktivere automatiske opdateringer til alle nye versioner af WordPress.

Aktivér automatiske opdateringer til alle nye versioner af WordPress

Når du har aktiveret centrale autoopdateringer til større udgivelser, kan du derefter aktivere dem til kun at udløse til vedligeholdelse og sikkerhed ved at klikke på Skift til automatiske opdateringer til udelukkende vedligeholdelse og sikkerhedsudgivelser

Skift til automatiske opdateringer til kun vedligeholdelse og sikkerhedsudgivelser

Større automatiske core opdateringer for udviklere

For det første, når vigtige automatiske core opdateringer er aktiveret, gemmes indstillingen auto_update_core_major i databasen med option_value aktiveret. Så hvis get_site_option ('auto_update_core_major') returnerer true, er afkrydsningsfeltet for automatiske opdateringer markeret.

Derefter kontrollerer WordPress, om større kerne auto-opdateringer er aktiveret gennem WP_AUTO_UPDATE_CORE konstant eller allow_major_auto_core_updates filter og indstiller afkrydsningsfeltet i overensstemmelse hermed.

Udviklere kan også deaktivere større kerne-autoopdateringer ved at indstille WP_AUTO_UPDATE_CORE konstant til false eller minor som vist nedenfor (se også Controlling Background Updates Through wp-config.php):

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

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

Bemærk, at mulige værdier for WP_AUTO_UPDATE_CORE er true (all), 'beta', 'rc', minor, false.

En anden mulighed for at deaktivere større kerne-autoopdateringer som standard er at bruge det nye filter for allow_major_auto_core_updates:

add_filter( 'allow_major_auto_core_updates', '_return_false' );

Et par kommentarer til tilføjelse af automatiske opdateringer til Core

Tilbage i december 2018 delte Matt Mullenweg de ni prioriteter for 2019, hvor ”At give en måde for brugere at tilmelde sig automatiske opdateringer af større Core-udgivelser” var nummer 7. Måske lidt sent, men vi kommer derhen.

Større automatiske core opdateringer skal have stor indflydelse på WordPress-sikkerhed og generelle oplevelse. Én ting ser ud til at være klar: Fra et teknisk synspunkt er den store automatiske core opdateringsfunktion en kompleks opgave, der ikke er 100% udført med udgivelsen af WordPress 5.6.

Efter en tankevækkende diskussion om Slack opsummerede Josepha Haden de bekymringer og spørgsmål, der kom fra Core-bidragydere.

Det vigtigste langsigtede mål er at have automatiske opdateringer tilgængelige på de fleste WordPress-websteder for at forbedre sikkerheden på tværs af hele WordPress-økosystemet (mere end 30% af internettet).

I hvert fald ifølge Helen Hou-Sandí, Core Lead Developer:

I mit sind er der nogle meget vanskelige tekniske ting at udføre på, og dette kræver noget MEGET disciplineret og fokuseret teknisk produkt ejerskab

Så vi skulle se yderligere ændringer og forbedringer af de større automatiske core opdaterings-UI over tid. Dette er hvad vi kan forvente fra nu af:

WordPress 5.6:

I eksisterende installationer skal større opdateringer være aktiveret af brugeren. Enhver konstant og filter, der allerede er i brug, har forrang. Mindre opdateringer er aktiveret som standard.
I nye installationer er både mindre og større opdateringer aktiveret som standard.

WordPress 5.6.1:

Vi bør se nogle ændringer i det centrale UI til automatisk opdatering baseret på feedback.

WordPress 5.7:

Der skal tilføjes et skub til skærmbilledet Site Health for alle, der fravælger større autoopdateringer.
En opt-in til automatisk opdatering skal føjes til installationsprocessen i WordPress 5.7.

En stor bekymring med centrale autoopdateringer er brugernes tillid. Ifølge Helen:

Jeg tror, at vi stadig kan gøre en masse arbejde for proaktivt at bede om brugernes tillid, især dem, der tidligere har haft dårlige erfaringer med WordPress og/eller opdateringer

Hver WordPress-webside er dog en blanding af Core, plugins og tema. Med Helenes ord:

Core opdateringer er stort set ret sikre, og der er nogle indbyggede beskyttelse, men da websteder kan køre en hvilken som helst kode fra enhver kilde, er der ikke sådan noget som “100%” for “enhver form for WordPress-websted”.

Brugere med grundlæggende automatiske opdateringer aktiveret bør regelmæssigt sikkerhedskopiere deres websteder eller vælge en webhost, der leverer automatiske backups i deres planer.

Kerne-autoopdateringer vil også påvirke den samlede oplevelse med opdatering, herunder automatiske opdateringer af plugin og tema. Joost de Valk bemærkede i en kommentar:

Hvis vi aktiverer WordPress core automatiske opdateringer som standard, skal vi gøre det samme for plugins. Ellers kan plugins og temaer ikke opdateres til ting, de skal rette på grund af core opdateringer. Jeg tror, at brugerne også ville forvente dette: hvis WordPress auto-opdateringer, plugins og temaer også automatisk opdateres.

Ændringer af websted health i WordPress 5.6

Sammen med alle de funktioner, der er diskuteret her, bringer WordPress 5.6 også en forbedret version af Site Health-værktøjet, som nu opfører sig anderledes i baggrunden.

Validering af websteds sundhedscheck

En validator kontrollerer nu svar på problemer til Site Health-tests. Validatoren vil kassere ethvert ugyldigt svar, hvilket forhindrer Site Health-værktøjet i at forårsage fatale fejl og standse yderligere kontroller.

Fra nu af påvirker ugyldige svar ikke indikatoren for websteds sundhed (#50145).

Asynkrone kontrol via REST endpoint

Site Health-værktøjet er et kraftfuldt sikkerhedsværktøj, der giver webstedsejere mulighed for at være opmærksomme på deres websteds sundhedsstatus.

Dette værktøj udfører en række sikkerhedstest, der giver et overblik over dit websteds sundhedsstatus.

Disse tests falder i to kategorier: direkte tests, kørsel af sideindlæsning og async-tests, som det kan tage lidt tid at gennemføre, og kører senere via JavaScript-opkald.

Tidligere blev disse tests udført med et opkald til admin-ajax.php. Med WordPress 5.6 bevæger ting sig væk fra admin-ajax.php, og et nyt REST API endpoint vil blive brugt i stedet. Fra og med WordPress 5.6 kan asynkrone tests findes under /wp-json/wp-site-health/v1 navneområdet.

Takket være den nye REST API-forbedring er plugins og temaer også i stand til at gøre brug af REST-slutpunkter og er ikke begrænset til Ajax-handlinger til deres sundhedstest.

Hver asynkron test kan nu erklære has_rest argumentet, som standard er false.

Koden nedenfor fra wp-admin/includes/class-wp-site-health.php viser matrixen med asynkrone tests 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,
	),
),

Planlagte websteds sundhedstjek:

Mens der er implementeret asynkrone tests for at forhindre langsom sideindlæsning og timeout, findes der ikke sådan bekymring med planlagte tests.

Med det i tankerne kan testarrays ud over argumentet has_rest, vi nævnte ovenfor, også erklære async_direct_test argument (ved hjælp af koden ovenfor), som skal være en kaldbar forekomst af en test.

Hvis en test køres under en planlagt begivenhed, bruger testen ikke REST API-endpoint, men kører direkte.

Application passwords til REST API-godkendelse

Application Passwords er et nyt system til at fremsende godkendte anmodninger til forskellige WordPress API’er.

Adgangskoder er 24 tegn lange og består af store og små bogstaver og numeriske tegn, der kan genereres enten manuelt eller via REST API.

For at generere en ny Application Password manuelt skal du gå til din profilskærm og rulle ned på siden.

Application Password i skærmbilledet Brugerprofil

Vælg et navn til dit application Password, og bekræft. WordPress viser dit nye password.

Application passwords vises i klumper med 4 tegn, adskilt af mellemrum som vist nedenfor:

gsUc UhkU 0ScI gdRd TGoU vrW5

Adgangskoder kan dog bruges med eller uden mellemrum:

Application passwords, der sendes tilbage gennem autorisationsstrømmen, inkluderer ikke mellemrum. De er strengt taget der for at gøre det lettere for nogen, der stirrer på en lang streng, at beholde deres plads, hvis de manuelt kommer ind i den.

De kan bruges klumpet, uden mellemrum, eller – nå ja – hvis du ville, kunne du sandsynligvis tilføje et mellemrum efter hver karakter.

På skærmen Brugerprofil kan du se, oprette og tilbagekalde application passwords. Sidste anvendte og Sidste IP-kolonne gør det let for dig at finde ud af passwords, der ikke længere bruges, og som skal tilbagekaldes.

På tidspunktet for denne skrivning kan application Passwords bruges sammen med REST API-godkendte anmodninger og med den ældre XML-RPC API. Vi bør dog se application Passwords, der bruges sammen med yderligere API’er i fremtiden. George Stephanis forklarer:

Ordningen til godkendelse af application passwords kan også anvendes på fremtidige API’er til WordPress, når de bliver tilgængelige. For eksempel, hvis GraphQL eller andre systemer er aktiveret i WordPress, vil application passwords give dem en solid, etableret godkendelsesinfrastruktur, der kan bygges ud af kassen.

Et godkendt opkald til REST API i Postman

Brug af application passwords på wp-login.php er ikke mulig.

For at se nærmere på denne funktion og mere teknisk indsigt, skal du kontrollere følgende ressourcer:

Bedre support til PHP 8

PHP 8.0 bringer masser af nye funktioner og optimeringer, hvilket gør det til en sand milepæl inden for sprogets udvikling. Den nyere version af PHP introducerer mange opdateringer, der bryder bagudkompatibilitet, og mange forældede funktioner er nu blevet officielt fjernet. Så det er en stor udfordring at tilføje support til PHP 8 i WordPress.

Faktisk, selvom WordPress Core-bidragsydere gør en stor indsats for at gøre WordPress 5.6 kompatibel med PHP 8, bør vi ikke forvente, at ethvert muligt problem ville blive opdaget. Målet her er at nå et punkt, hvor hele WordPress-økosystemet er kompatibelt med PHP 8, hvilket synes virkelig en hård møtrik at knække i øjeblikket.

Desuden indeholder et WordPress-websted mindst et tema og et variabelt antal plugins. Så hvad vi kan forvente er god support til PHP 8 i WordPress Core, men det er svært at tro, at plugins og temaer hurtigt vil tilføje support til PHP 8.

Vi er enige med Jonathan Desrosiers, når han siger:

Tilstanden for PHP 8-support inden for det bredere økosystem (plugins, temaer osv.) Er umulig at vide. Af den grund bør WordPress 5.6 betragtes som “beta-kompatibel” med PHP 8.

“Beta kompatibel med PHP 8” synes et godt udtryk for at repræsentere en løbende proces, der stadig kræver en stor indsats, men samtidig anerkender det store arbejde, der er udført indtil videre.

Imidlertid,

Alle plugin- og temaudviklere såvel som hosting-samfund opfordres til at gøre deres kode kompatibel med PHP 8. Dette giver WordPress mulighed for at opnå virkelig “fuld kompatibilitet” hurtigere og uden at slutbrugere skal bære byrden.

Nogle PHP 8 ændringer at være opmærksomme på

Som vi nævnte ovenfor, er det et igangværende arbejde at gøre WordPress fuldt kompatibel med PHP 8. Jonathan Desrosiers giver en liste over PHP 8-funktioner og ændringer, som WordPress-udviklere bør være opmærksomme på.

Navngivne parametre

Med PHP named arguments er det nu muligt at overføre argumenter til en funktion baseret på parameter nam snarere end parameter position. Dette gør det muligt at skrive kode, der er selvdokumenterende, argumenter er ordens-uafhængige, og standardværdier kan springes vilkårligt over.

Desværre kan aktuelt navngivne parametre forårsage bagud kompatibilitetsproblemer i WordPress. Hovedårsagen er, at parameternavne kan ændres uden varsel, indtil den aktuelle revision er afsluttet. Så på tidspunktet for denne skrivning:

Brug af navngivne parametre, når der kaldes til WordPress-funktioner og class methods, understøttes ikke udtrykkeligt og afskrækkes stærkt, før denne revision kan gennemføres, da parameternavne under revisionen kan ændres uden varsel. Når denne revision er afsluttet, vil den blive annonceret i en fremtidig udviklernote.

Stricht type/value valideringer for interne funktioner

Når du sender en parameter af ulovlig type, opfører interne og brugerdefinerede funktioner sig forskelligt. Brugerdefinerede funktioner kaster en TypeError, men interne funktioner opfører sig på forskellige måder afhængigt af flere forhold.

For at fjerne disse uoverensstemmelser genererer de interne parameter-parsing-API’er i PHP 8 altid en ThrowError i tilfælde af en uoverensstemmelse med parametertypen.

Strik type erklæring bruges ikke i WordPress Core. Core-bidragsydere arbejder dog på at forhindre ugyldige typer, der overføres til Core-funktioner. Indtil dette arbejde er afsluttet, kan denne PHP 8-ændring føre til TypeErrors, “især hvis en værdis type forkert ændres via kode, der er knyttet til et filter”.

Stricht kontrol af typen for aritmetiske og bitvise operatører

I tidligere versioner af PHP var det tilladt at bruge aritmetiske og bitvise operatorer til en matrix, ressource eller ikke-overbelastet objekt, men adfærden var undertiden inkonsekvent og endda urimelig:

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

Med PHP 8 er opførslen altid den samme, og alle aritmetiske og bitvise operatører kaster en TypeError-undtagelse, når operand er en matrix, ressource eller ikke-overbelastet objekt (se RFC).

Dette er en anden ændring, der kræver noget ekstra arbejde fra Core-bidragsydere, som de mange fejl, advarsler og meddelelsesændringer.

Igen, på grund af de mange problemer, der stadig ikke er løst, anbefales det stærkt at køre kompatibilitetstest på et scene- eller udviklingsmiljø, inden du skifter til PHP 8 på dit live-websted. Læs mere om WordPress og PHP 8.0.

Yderligere ændringer for udviklere

WordPress 5.6 introducerer masser af ændringer for udviklere, og vi kunne ikke medtage alle på vores liste. Men her er de 3 bedste, vi synes er værd at se på:

1. wp_after_insert_post Action Hook

Før WordPress 5.6 kunne du bruge save_posts eller lignende til at køre brugerdefineret kode, efter at et indlæg blev offentliggjort. Nu introducerer WordPress 5.6 den nye wp_after_insert_post action hook, der kun affyres, når udtryk og metadata er gemt.

Derudover er flere funktioner blevet opdateret for at forhindre, at disse kroge bliver fyret. Den nye $fire_after_hooks parameter er blevet føjet til funktionerne wp_insert_posts(), wp_update_post() og wp_insert_attachment(). Hvis det er indstillet til false, forhindrer det, at insert hooks kan affyres.

Tjek dev-not for et dybere overblik.

2. Typecasting

Typecasting-funktioner intval(), strval(), floatval() og boolval() er blevet fjernet fra Core til fordel for direkte typecasting:

intval() → (int)
strval() → (string)
floatval() → (float)

Denne ændring har direkte virkninger på ydeevnen, da direkte typecasting er ~6x hurtigere end typecasting-funktioner.

3. WP_Error objects

Klassen WP_Error er blevet forbedret for at muliggøre fletning af flere WP_Error-forekomster i en. Tidligere kunne du kun gøre det manuelt. Nu introducerer WordPress 5.6 tre nye metoder til at hjælpe med at håndtere flere WP_Error-forekomster. Koden nedenfor er et eksempel fra dev-note:

<?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 );

Yderligere læsninger for udviklere

Det er umuligt at nævne alle ændringer med fokus på udvikling introduceret af WordPress 5.6, men du kan læse mere om dem ved hjælp af følgende ressourcer:

Resumé

WordPress 5.6 er en stor udgivelse med masser af funktioner og ændringer for både brugere og udviklere. Vi er altid glade for at se, hvordan udviklingen af webteknologier direkte påvirker WordPress-sikkerhed, ydeevne, brugervenlighed og tilgængelighed.

Men evolution stopper aldrig, og vi kan allerede kigge på fremtidige potentielle udgivelsesdatoer.

Op til dig nu: Hvad kan du lide mest i WordPress 5.6? Og hvilke funktioner vil du føje til WordPress 5.7?

Carlo Daniele Kinsta

Carlo er en passioneret elsker af webdesign og frontend udvikling. Han har arbejdet med WordPress i over 10 år, også i samarbejde med italienske og europæiske universiteter og uddannelsesinstitutioner. Han har skrevet snesevis af artikler og guides om WordPress, udgivet både på italienske og internationale hjemmesider samt på trykte magasiner. Du kan finde Carlo på X og LinkedIn.