Hvad er nyt i WordPress 5.5 – Et dybt dyk ind i en (episk) udgivelse

Med WordPress 5.5 “Eckstine” lige om hjørnet, er det tid for os at introducere de mest bemærkelsesværdige ændringer og funktioner, der føjes til Core med årets anden WordPress-udgivelse.

I disse dage er vi vant til at se mange tilføjelser til blokeditoren ved hver WordPress-udgivelse. WordPress 5.5 er ingen undtagelse!

Denne version bringer også masser af ændringer, der ikke er relateret til editoren, og som bør have en stor indflydelse på den måde, vi bruger CMS på.

Mens WordPress 5.5 bringer mange ændringer til WordPress Core, er flere funktioner, der afventer med 5.5, blevet forsinket og fjernet fra denne version på grund af flere uløste problemer. Så redigering på fuld side, navigationsblok, navigationsskærm og widgetskærm er ikke en del af WordPress 5.5.

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

• 7. juli 2020: Beta 1
• 14. juli 2020: Beta 2
• 21. juli 2020: Beta 3
• 27. juli 2020: Beta 4
• 28. juli 2020: RC 1
• 4. august 2020: RC 2
• 10. august 2020: RC 3
• 10. august 2020: Tørkørsel til frigivelse af WordPress 5.5
• 11. august 2020: Måldato for WordPress 5.5 “Eckstine“

Så hvad er nyt i WordPress 5.5?

Hvad er nyt med Block Editor

Med den endelige udgivelse af WordPress 5.5 tilføjes ti versioner af Gutenberg plugin til kernen, hvilket bringer et stort antal UI-forbedringer, funktioner, forbedringer og fejlrettelser, der påvirker alle forventninger til oplevelsen med redigering, fra brugervenlighed til funktionalitet og ydeevne .

Det ville være tæt på umuligt at nævne alle disse ændringer her, så i dette indlæg finder du bare et håndplukket udvalg af vores foretrukne nye funktioner og forbedringer.

For en mere omfattende liste over forbedringer og funktioner, der er føjet til blokeditoren med WordPress 5.5, se de officielle meddelelser fra plugin-frigivelserne: 7.5, 7.6, 7.7, 7.8, 7.9, 8.0, 8.1, 8.2, 8.3, 8.4, 8.5.

Når det er sagt, vil vi her dække følgende tilføjelser, der er bragt til blokeditoren med WordPress 5.5:

1. Nyt UI-design
2. Blok designværktøjer
3. Inline Billedredigering
4. Bloker kategorier og nyt blok inserter panel
5. Block Directory og Block Plugins
6. Blokmønstre

Nyt UI-design

Hver version af Gutenberg-pluginet bringer små og ikke-så-små forbedringer, der stille ændrer den samlede redigeringsoplevelse. En masse af disse ændringer vil nu blive flettet ind i WordPress-kernen. Så når du først starter blokredigeringsprogrammet i WordPress 5.5, bør en lidt anden grænseflade fange din opmærksomhed. Du finder:

• En forenklet blok værktøjslinje
• Stærkere farvekontrast
• Nye ikoner
• Blok bevægere
• Omgivende elementer
• Enhedseksempler
• Forbedret drag n drop
• Forbedrede og forenede blok fokus stilarter i hele brugergrænsefladen
• Mulighed for at formatere flere blokke på én gang
• Bedre ydeevne

De nævnte ovenfor er kun nogle få af de mange ændringer, der påvirker redigeringsoplevelsen.

Yderligere ændringer inkluderer også:

Subscript- og Superscript-indstillinger

Formateringsindstillinger for abonnement og superscript tekst er nu tilgængelige via Rich Text-kontrollerne (Gutenberg 8.0).

Parent blok valg

En helt ny værktøjslinjeknap vises nu, når du holder musen over venstre side af blok værktøjslinjen. Den nye knap giver mulighed for at vælge overordnede blokke i indlejrede sammenhænge (Gutenberg 8.3).

Blok designværktøjer

Flere designværktøjer er blevet føjet til Gutenberg-pluginet i de sidste måneder og vil nu blive inkluderet i Core med WordPress 5.5.

Højde kontrol og baggrundsgradienter

Et første sæt værktøjer giver kontrol over dimensioner og baggrundsfarve i flere blokke (Gutenberg 7.9).

Polstring og link farvekontrol

To yderligere funktioner lander til kernen (Gutenberg 8.3), men på dette tidspunkt er de stadig markeret som eksperimentelle:

• Patting kontrol for cover blok.
• Link farvekontrol til afsnit, header, gruppe, kolonner og medie- og tekstblokke.

Padding kontrol og link farvekontrol er som standard slukket, og udviklere skal eksplicit erklære støtte til dem, som forklaret i Block Editor-håndbogen.

Hvis du vil tilføje padding kontroller til Cover-blokken til dine temaer, skal du blot tilføje følgende linje til dit temas functions.php:

add_theme_support( 'experimental-custom-spacing' );

Hvis du vil aktivere link farvekontrol for afsnit, header, gruppe, kolonner og medie- og tekstblokke, skal du bare tilføje følgende linje til dit temas funktionsfil:

add_theme_support( 'experimental-link-color' );

Custom Units and Custom Line Heights

Denne nye funktion giver dig mulighed for at indstille px, em, rem, vw og vh højdeværdier for padding blokken (Gutenberg 7.9). % understøttes også, men det er udeladt på grund af den uforudsigelige gengivelse af procenthøjder.

Med den forbedrede højdekontrol kan du hoppe værdier med 10 ved at holde Shift nede, mens du trykker up eller down.

Udviklere kan tilføje support til brugerdefinerede enheder ved at definere support flaget for custom-units:

add_theme_support( 'custom-units' );

Du kan også indstille specifikke brugerdefinerede enheder:

add_theme_support( 'custom-units', 'rem', 'em' );

Udviklere kan også tilføje tilpassede liniehøjder til header og afsnit ved at definere support flaget med custom-line-height:

add_theme_support( 'custom-line-height' );

Inline Billedredigering

En ny redigeringsfunktion er føjet til blok redigeringsprogrammet med Gutenberg 8.4, der giver brugerne mulighed for at redigere billeder direkte fra Billedeblokken.

Nu er det blevet fusioneret til kerne, og fra WordPress 5.5 kan du beskære, rotere, zoome og justere billedepositioner uden behov for at starte mediebiblioteket, hvilket resulterer i en hurtigere redigeringsoplevelse.

Hvis du bruger til at offentliggøre en masse fotos, vil du uden tvivl nyde denne funktion.

Bare klik på Beskær-knappen på billede værktøjslinjen, så får du adgang til de nye redigeringsfunktioner. Når du er tilfreds med dine tilpasninger, skal du anvende dine ændringer, og du er færdig.

WordPress gemmer et nyt billede som vedhæftet fil i mediebiblioteket og kopierer detaljer fra det originale billede (titel, beskrivelse, billedtekst, alt-tekst og EXIF-data). Dette giver dig fuld kontrol over nye billedeversioner.

Bloker kategorier og nyt blok inserter spanel

Et redesignet blok inserter panel viser blokke og mønstre efter kategorier, hvilket forbedrer oplevelsen med redigerings markant og gør blokke og mønstre lettere at finde (Gutenberg 8.3).

Block Directory og Block Plugins

Med implementeringen af blokmappen kan du finde, installere og tilføje tredjepartsblokke direkte fra block inserter.

Når du søger efter en blok, hvis du ikke allerede har installeret den, bliver du bedt om en liste over tilgængelige plugins i Plugin Directory. Disse plugins kaldes “block plugins”, og du kan tilføje dem til din editor med et enkelt klik.

Takket være denne nye fantastiske funktion kan du nu opbygge dine egne blokke og offentliggøre dem i Plugin Directory og gøre dine kreationer tilgængelige for hele WordPress-samfundet.

Den gode nyhed er, at du ikke behøver at være en PHP-guru for at oprette dine tilpassede blokke. Du har bare brug for noget arbejdskendskab til JavaScript.

Ikke sikker på, hvordan du kommer i gang med at udvikle dine egne blokke? Det fantastiske WordPress-samfund hjælper dig med en nem trin for trin-tutorial.

Den første version af blokvejledningen er allerede tilgængelig i den officielle Block Editor-håndbog for at hjælpe dig med at lære det grundlæggende om blokudvikling. Du kan læse mere om blokmappen og blok plugin-udvikling på bloggen Make WordPress Plugins.

Blokmønstre

Tilbage i marts 2020 introducerede Gutenberg 7.7 og Gutenberg 7.8 blokmønstre og blokmønstre API for temaer og plugins.

Blokmønstre er foruddefinerede bloklayouts, så brugerne hurtigt kan tilføje komplekse strukturer af indlejrede blokke til deres sider. Deres hensigt er at hjælpe content forfattere og webstedsadministratorer med at overvinde “syndromet med en blank side” og med at opbygge professionelle layout og avancerede visninger med lethed.

Vi bør se blokmønstre på deres bedste ved redigering på fuld side.

En klar forklaring af, hvad blokmønstre er beregnet til kommer fra Mathias Ventura, hovedarkitekt for Gutenberg-projektet:

En afklaring – opsætningen af ​​”blokmønstre” handler mindre om skabelondele (som er strukturelt meningsfulde) og mere om generelle designelementer lavet af mindre blokke. Når de er indsat, opbevares de ikke separat. For eksempel et “Cover” -billede, der kombinerer et par blokke for at opnå et specifikt udseende, som ellers ville få brugere noget arbejde at udføre. Tænk på det mere som en samling af designs, der kan tilføjes hvor som helst uden nødvendigvis at repræsentere en genanvendelig del af en temaskabelon.

Bortset fra skabelondele er blokmønstre designelementer, der skal hjælpe webstedsadministratorer og indholdsskabere til at fremskynde og forbedre deres redigeringsoplevelse.

Lanceret med Gutenberg 7.7, dukkede først Block mønstre i et sidebar plugin. Senere, med frigivelsen af ​​Gutenberg 8.0, flyttede de ind i en fornyet block inserter der nu vises som et panel placeret på venstre side af redaktøren, som vist på billedet herunder:

I deres tidlige fase kommer blokmønstre med et meget begrænset sæt mønstre. Uanset hvad vil de bringe en enorm forbedring til redigeringsoplevelsen, og forhåbentlig vil der blive tilføjet mere i den nærmeste fremtid.

Ligesom almindelige blokke kan mønstre søges og organiseres i følgende kategorier

• Tekst
• Hero
• Kolonner
• Knapper
• Galleri
• Features
• Udtalelser
• Ikke kategoriseret

Ud over indbyggede blokmønstre kan WordPress-udviklere give deres temaer og plugins tilpassede mønstre ved at drage fordel af et helt nyt API.

Du kan registrere dine brugerdefinerede mønstre ved hjælp af funktionen register_block_pattern og register_block_pattern_category for kategorier.

register_block_pattern tager to argumenter:

1. Navnet på mønsteret.
2. En række mønsteregenskaber..

Egenskaber inkluderer følgende:

• title
• content
• description
• categories
• keywords
• viewportWidth

register_block_pattern_category tager også to argumenter::

1. Navnet på mønsterkategorien.
2. En række egenskaber.

API giver også to funktioner til at afregistrere mønstre og kategorier: unregister_block_pattern og unregister_block_pattern_category.

Den måde, du kan opbygge dine egne blokmønstre på, er ret ligetil. Kopier og indsæt f.eks. følgende kode i et brugerdefineret plugin eller en functions fil for et child theme, og skift derefter navnet på mønsteret i henhold til dine præferencer.

add_action( 'init', function(){

	register_block_pattern_category( 
		'kinsta', 
		array( 'label' => __( 'Kinsta stuff', 'kinsta-pattern' ) ) );

	register_block_pattern(
	'kinsta-pattern/my-custom-pattern',
	array(
		'title'			=> __( 'Two Kinsta buttons', 'kinsta-pattern' ),
		'description'	=> _x( 'Two nice buttons.', 'Kinsta Buttons', 'kinsta-pattern' ),
		'content'		=> "<!-- wp:buttons {\"align\":\"center\"} -->\n<div class=\"wp-block-buttons aligncenter\"><!-- wp:button {\"backgroundColor\":\"very-dark-gray\",\"borderRadius\":0} -->\n<div class=\"wp-block-button\"><a class=\"wp-block-button__link has-background has-very-dark-gray-background-color no-border-radius\">" . esc_html__( 'Button One', 'kinsta-pattern' ) . "</a></div>\n<!-- /wp:button -->\n\n<!-- wp:button {\"textColor\":\"very-dark-gray\",\"borderRadius\":0,\"className\":\"is-style-outline\"} -->\n<div class=\"wp-block-button is-style-outline\"><a class=\"wp-block-button__link has-text-color has-very-dark-gray-color no-border-radius\">" . esc_html__( 'Button Two', 'kinsta-pattern' ) . "</a></div>\n<!-- /wp:button --></div>\n<!-- /wp:buttons -->",
		'categories'	=> array( 'kinsta' ),
	)
	);
});

Koden ovenfor er enkel tilpasning af det originale uddrag fra Block API Reference. Som du kan se, kræves der ingen JavaScript.

Se også Block Patterns i WordPress 5.5..

Native billede Lazy-Loading i WordPress Core

Lazy loading er en optimeringsteknik, der modvirker belastning af ikke-kritiske ressourcer. Dette betyder, at browseren bliver bedt om at indlæse synligt indhold ved sideindlæsning og udsætte download og gengivelse af billeder placeret under folden, indtil de faktisk er nødvendige.

Før native lazy loading kunne webudviklere lazily load assets via JavaScript ved hjælp af IntersectionObserver API eller ved hjælp af scroll-, resize– og orientationchange af event handlers.

Men da lazy loading blev en standard, behøver vi ikke at skrive brugerdefineret kode eller bruge JavaScript-biblioteker længere, og lazyload-billeder kan implementeres ved hjælp af den nye loading attribut i img og iframe-tags.

Loading-attributten bestemmer, om browseren skal indlæse en ressource med det samme eller vente, indtil nogle betingelser er opfyldt. Det understøtter i øjeblikket følgende værdier:

• lazy: Vent indtil nogle betingelser er opfyldt
• eager: indlæse ressourcen med det samme

På dette tidspunkt understøttes indbygget doven indlæsning af Microsoft Edge, Firefox, Google Chrome, Opera-browser, Android-browser og Chrome til Android.

Før WordPress 5.5 var lazy loading kun muligt i WordPress med et optimization plugin som Autoptimize, BJ Lazy Load eller andre. Nu er det en del af WordPress Core og kræver ikke yderligere plugins for at blive installeret!

Native Lazy Loading i WordPress

Som Felix Arntz rapporterede i et gammelt blogindlæg på Make WordPress Core blog, blev en JavaScript-implementering af lazy loading i WordPress oprindeligt foreslået for et par år siden, men det blev aldrig en del af Core. Den nye implementering af indbygget lazy loading til billeder fjerner enhver kompatibilitetsproblem, og nu kan den nye funktion sikkert sammenføjes til Core med WordPress 5.5.

Ifølge Felix ville indbygget doven indlæsning på WordPress-billeder have en gunstig indflydelse på webstedsydelsen og brugeroplevelsen for et stort antal WordPress-websteder, der ikke gør brug af lazy loading plugins:

… uden at kræve nogen teknisk viden eller endda bevidsthed om lazy-loading som et koncept. Vedtagelse af den nye indlæsningsattribut er en stor chance for WordPress at lede vejen for en hurtigere internet generelt.

For at forhindre layoutskift tilføjes loading= "lazy" automatisk til img-tags med width– og heightattributter, og det er kun muligt, hvis billedet er tilgængeligt for WordPress som vedhæftet fil og inkluderer en wp-image-$id class.

Lazy loading er en must-have optimering for hver WordPress-installation– og websted med en betydelig mængde billeder. Felix bemærker:

Dette vil drastisk spare båndbredde på både servere såvel som brugeragenter på tværs af websteder, hvor billeder længere nede på siden plejede at indlæses med det samme, selv i tilfælde af at brugeren måske aldrig ruller mod dem.

Indfødte lazy loading i WordPress fungerer med følgende billeder:

• Billeder i post content (the_content).
• Billeder i post excerpts (the_excerpt).
• Billeder i tekst widgets (widget_text_content).
• Avatar billeder rendered via get_avatar().
• Template billeder bruger wp_get_image

Med den første implementering understøtter doven indlæsning kun billeder, men vi kan forvente en fremtidig forbedring af doven belastning på iframe-tags.

Lazy Loading for WordPress-udviklere

Udviklere kan tilsidesætte standardadfærden ved hjælp af flere nye filtre. Blandt disse filtre er wp_lazy_loading_enabled og wp_img_tag_add_loading_attr de mest nyttige for udviklere:

• wp_lazy_loading_enabled aktiverer og deaktiverer attributten for loading. Dette filter kan anvendes globalt eller per tag.
• wp_img_tag_add_loading_attr filtrerer belastningsattributværdien og giver en måde at kontrollere doven loading pr. billede.

Følgende eksempel viser, hvordan man globalt deaktiverer doven belastning:

add_filter( 'wp_lazy_loading_enabled', '__return_false' );

Vi kan også deaktivere doven indlæsning for et specifikt mærke. I eksemplet nedenfor er lazy loading slået fra på billeder i the_contentsammenhæng (læs mere på Make WordPress Core):

add_filter(
	'wp_lazy_loading_enabled',
	function( $default, $tag_name, $context ){
		if ( 'img' === $tag_name && 'the_content' === $context ){
			return false;
		}
		return $default;
	},
	10,
	3
);

• $default: Den boolske standardværdi (true).
• $tag_name: Tagnavnet på de elementer, der skal lades ladet.
• $context: : En valgfri parameter, der specificerer billedets kontekst (se listen ovenfor).

Bemærk, at $tag_name parameteren kun understøtter img-taget på dette tidspunkt. Som nævnt ovenfor bør der alligevel føjes flere tags til fremtidige implementeringer.

Hvis du vil have mere granuleret kontrol over, hvordan du laver billedet i WordPress, kan du følge to forskellige tilgange afhængigt af konteksten.

Hvis du arbejder med indholdet (dvs. the_content, the_excerpt, widget_text_content), kan du bruge wp_img_tag_add_loading_attr-filteret. Følgende eksempel viser, hvordan du deaktiverer lazy loading på et specifikt billede:

add_filter(
	'wp_img_tag_add_loading_attr',
	function( $value, $image, $context ){
		if ( 'the_content' === $context ){
			$image_url = wp_get_image_url( 67, 'medium' );
			if ( false !== strpos( $image, ' src="' . $image_url . '"' ) ) {
				return false;
			}
		}
		return $value;
	},
	10,
	3
);

Temaudviklere kan også styre billeder via wp_get_attachment_image. I dette scenarie kan du blot indstille billedet til at loading attribut for indlæsning til false:

echo wp_get_image(
	67,
	'medium',
	false,
	array( 'loading' => false ),
);

Native lazy-loading images is coming to #WordPress 5.5, for faster sites and less waste of network resources! And it's accompanied by further image improvements which reduce those annoying layout shifts that make you accidentally click on the wrong things. https://t.co/e7g2s9uSPk

— Felix Arntz (@felixarntz) July 14, 2020

Du finder yderligere oplysninger om lazy loaded af billeder i WordPress 5.5 på Make WordPress Core-bloggen.

Auto-opdateringer til plugins og temaer

En af de største bekymringer for webstedsejere er webstedets sikkerhed, og at holde din software ajour er en almindelig anbefaling, som hver websteejer skal tage hensyn til.

WordPress Automatiske opdateringer har været tilgængelige som en funktion siden WordPress 3.7. Problemet her er, at selvom automatiske opdateringer er aktiveret som standard til grundlæggende vedligeholdelses- og sikkerhedsudgivelser, før WordPress 5.5, udnyttede mange webstedsejere ikke auto-opdateringer til plugins og temaer.

Årsagen er, at denne funktion krævede grundlæggende viden om WordPress-udvikling. Faktisk kunne udviklere finjustere deres opdatering præferencer ved at definere en eller flere konstanter i wp-config.php eller bruge et filter i et plugin.

Nu med WordPress 5.5, kan administratorer til at skifte plugin og tema auto-opdateringer til og fra med et enkelt klik direkte i deres WordPress-dashboard.

Auto-opdateringer af plugin kan aktiveres og deaktiveres ved at klikke på linket, der vises i kolonnen Automatiske opdateringer, der nu findes på skærmen Plugins.

Hvis du vil aktivere automatiske opdateringer til dit tema, skal du gå til Udseende > Temaer og derefter holde markøren over dit tema og klikke på Temaoplysninger. Klik derefter på det nye link Aktiver automatisk opdateringer, og du er færdig.

Det nye auto-opdatering grænseflade til plugins og temaer leveres med flere funktioner og hooks, der er tilgængelige for udviklere til at tilpasse oplevelsen med auto-opdaterings.

Auto-opdatering af funktioner og filtre til plugin- og temaudviklere

En ny funktion og flere filtre giver WordPress-udviklere mulighed for at tilpasse mange aspekter af plugin- og tema-autoopdateringer.

Kontroller automatisk opdateringsgrænseflade

Den nye wp_is_auto_update_enabled_for_type() WordPress-funktion kontrollerer, om automatisk opdateringsgrænseflade er aktiveret for en given type. Den nye funktion bevarer et enkelt argument ($type), der bestemmer typen af ​​opdatering, der skal kontrolleres for ('theme' eller 'plugin') og returnerer true eller false i overensstemmelse hermed.

Den nye auto-opdateringsgrænseflade kan deaktiveres til plugins eller temaer takket være to nye filtre: plugins_auto_update_enabled og themes_auto_update_enabled. Se eksemplet nedenfor:

// Disable plugins auto-update UI elements.
add_filter( 'plugins_auto_update_enabled', '__return_false' );

// Disable themes auto-update UI elements.
add_filter( 'themes_auto_update_enabled', '__return_false' );

Ovenstående filtre er dokumenteret i wp-admin/include/update.php.

Tilpas links til automatisk opdatering

Plugin- og temaudviklere kan tilpasse HTML-output fra link til auto-opdatering.

plugin_auto_update_setting_html-filter giver mulighed for at tilpasse skifte links og tidsforløb mellem to opdateringsforsøg.

Genopkaldsfunktionen holder tre argumenter:

• $html: HTML-koden til plugins indhold med automatisk opdatering af kolonnen, inklusive skift af link til auto-opdatering og tid til næste opdatering.
• $plugin_file: Sti til plugin-filen i forhold til plugins-biblioteket.
• $plugin_data: En række plugin-data.

Hvis du nu ønsker at tilpasse etiketten til link-teksten til automatisk opdatering, kan du bruge filteret som vist i følgende uddrag.

add_filter( 'plugin_auto_update_setting_html', function( $html, $plugin_file, $plugin_data ){
	if ( 'kinsta-plugin/kinsta-plugin.php' === $plugin_file ) {
		$html = __( 'Custom HTML', 'kinsta-plugin' );
	}
	return $html;	
	}, 
	10, 
	3 
);

Billedet herunder viser resultatet på skærmen.

Dette filter er dokumenteret i wp-admin/include/class-wp-plugins-list-table.php.

På enkelte websteder kan du tilpasse JS-skabelonen til linket til automatisk opdatering via filteret theme_auto_update_setting_template. Blogindlægget, der introducerer auto-opdateringer af plugin og temaer, giver følgende eksempel til dette filter:

function myplugin_auto_update_setting_template( $template ) {
    $text = __( 'Auto-updates are not available for this theme.', 'my-plugin' );
 
    return "<# if ( [ 'my-theme', 'twentytwenty' ].includes( data.id ) ) { #>
        <p>$text</p>
        <# } else { #>
        $template
        <# } #>";
}
add_filter( 'theme_auto_update_setting_template', 'myplugin_auto_update_setting_template' );

Det anbefales at tjekke for måltemaet ved hjælp af parameteren data.id.

Hvis du arbejder på en WordPress-multisiteaninstallation, har du brug for themet_auto_update_setting_html filter, som giver dig mulighed for at tilpasse linkene Automatiske opdateringer på skærmen Temaer på samme måde som skærmbilledet Plugins.

Endelig kontrollerer to ekstra filtre alle automatiske opdateringer til hvert tema og plugin, inklusive temaer og plugins, der skal installeres i fremtiden.

Disse filtre, der er tilgængelige siden WordPress 3.7, tilsidesætter alle indstillinger for automatisk opdatering i dit WordPress-dashboard. Du kan læse mere om det i vores Deep Dive Into WordPress automatiske opdateringer. For en dybere oversigt over automatiske opdateringer til plugins og temaer, kan du læse mere i dette blogindlæg.

Automatisk opdatering af e-mail-meddelelser og information om webstedets sundhed

Siden WordPress 5.5 sendes en e-mail-meddelelse efter ethvert forsøg på auto-opdatering.

Filterkroken auto_plugin_theme_update_email filtrerer e-mails sendt efter en automatisk baggrundsopdatering. Se dev-notes-blogindlægget for et eksempel på brug.

Auto-opdatering af e-mail-meddelelser kan også deaktiveres ved hjælp af to nye filtre:

// Disable auto-update email notifications for plugins.
add_filter( 'auto_plugin_update_send_email', '__return_false' );

// Disable auto-update email notifications for themes.
add_filter( 'auto_theme_update_send_email', '__return_false' );

Information om automatisk opdatering af plugin og tema vises også under fanen Site Health Info.

Udviklere kan tilpasse teksten, der vises på denne skærm ved hjælp af filtre plugin_auto_update_debug_string og theme_auto_update_debug_string. Mere info og flere eksempler er tilgængelige her.

Udvidelige Core Sitemaps

Et sitemap er simpelthen en liste over webadresser, der gør det muligt for søgemaskiner hurtigt at gennemgå dit websted.

Sitemaps ligner meget robots.txt med den forskel, at en robots.txt-fil udelukker indhold fra at blive indekseret, mens et sitemap indeholder en liste over webadresser, der skal indekseres af søgemaskiner.

Før WordPress 5.5 kunne sitemaps kun føjes til WordPress-websteder ved hjælp af et plugin eller andre værktøjer.

Nu bringer WordPress 5.5 en helt ny XML-sitemaps-funktion til WordPress Core.

Den nye funktion tilføjer grundlæggende funktionalitet, men den leveres med et stort antal hooks og filtre, der giver plugin-udviklere mulighed for yderligere at udvide den indbyggede funktionalitet.

XML-sitemaps er aktiveret som standard (medmindre du afskrækker søgemaskiner fra at indeksere dit websted) og giver følgende objekttyper:

• Hjemmeside
• Indlægsside
• Core posttyper (sider og indlæg)
• Tilpassede indlægstyper
• Kerne taxonomier (tags og kategorier)
• Brugerdefinerede taksonomier
• Forfatter arkiver

Sitemap-indekset er tilgængeligt på /wp-sitemap.xml, der maksimalt indeholder 2.000 URL’er. Når den maksimale grænse er nået, tilføjes en ny sitemap-fil.

Som nævnt før kan plugin-udviklere tilpasse deres sitemaps ved hjælp af en eller flere af de mange tilgængelige handlinger og filtre. For en omfattende liste over sitemaps-relaterede kroge, se feature plugin dokumentation og det indledende blogindlæg.

Som et eksempel kan du programmatisk deaktivere kerne-sitemaps ved hjælp af filteret wp_sitemaps_enabled, der filtrerer, om XML-sitemaps er aktiveret eller ikke, eller forhindrer, at funktionen wp_sitemaps_get_server udføres:

add_filter( 'wp_sitemaps_enabled', '__return_false' );

Core sitemaps bør ikke være i konflikt med nogen sitemap-plugins, du muligvis har installeret på dit websted. I følge Pascal Birchler på Make WordPress Core:

Core-sitemaps-funktionen blev bygget på en robust og let udvidelig måde. Hvis to sitemaps af en eller anden grund er eksponeret på et websted (en ad gangen, en af ​​et plugin), resulterer dette ikke i nogen negative konsekvenser for webstedets opdagelighed.

Som en del af XML-sitemaps-funktionen slipper en ny esc_xml() -funktion undslipper strenge til XML-blokke. Funktionen og det tilsvarende filter er dokumenteret i wp-includes/formatting.php.

På dette tidspunkt understøtter den nye sitemap-funktion ikke image/video/news-sitemaps, og sandsynligvis ændres dette ikke i fremtiden. Under alle omstændigheder kunne nye filtre og hooks, der giver udviklere mulighed for at tilføje denne funktion tilføjes i fremtidige versioner.

For mere information om udvidelige sitemaps, se udviklerens introduktion til sitemaps, der dækker nye klasser, funktioner, kroge og filtre.

Videresendelse af argumenter til skabelonfiler

Før WordPress 5.5 var det kun muligt at overføre data til skabelonfiler via globale variabler, forespørgselsvarsler og et par andre ikke-optimale indstillinger. Fra WordPress 5.5 er der nu tilføjet en $args-parameter til skabelon indlæsning funktioner (de tilsvarende hooks er blevet opdateret i overensstemmelse hermed):

• get_header()
• get_footer()
• get_sidebar()
• get_template_part()
• locate_template()
• load_template()

Temaudviklere kan nu indstille en variabel i en skabelonfil og gøre den tilgængelig i enhver inkluderet skabelondel ved blot at videregive en række argumenter.

Mens denne funktion åbner nye brede muligheder for temaudviklere, stiller Justin Tadlock på WP Tavern et godt spørgsmål:

Et spørgsmål tilbage: er ankomsten af ​​denne funktion for sent? Med WordPress på sporet for at gendanne hele temasystemet til at integrere med den kommende redigeringsfunktion på hele webstedet, vil denne funktion kun være nyttig i de næste par måneder?

Et godt punkt kommer fra John Blackbourne:

Selv i fremtiden med redigering af webstedet er der stadig masser af behov for skabelondele. Dynamisk gengivne bloktyper kan og gøre en god brug af for eksempel strukturerede skabelondele. De er ikke gensidigt eksklusive, og der vil altid være meningsfulde temaer, der ikke udnytter omfattende blokke til layout.

Vi nåede endelig Enrico Sorcinelli, WP Core-bidragyder, der delte sine tanker med os:

Hvis du spørger mig, om vi kom her for sent, er det fra mit synspunkt aldrig for sent! Jeg tror, ​​at i fremtiden kan temaudviklere drage fordel af denne mulighed, som ikke udelukker, at den kan bruges i symbiose med den nye redigeringsmetode på fuld side (f.eks. til blokke med dynamisk gengivelse).

Måske er det simpelthen for tidligt at sige, hvordan nøjagtigt denne funktion vil parre med redigering på hele websitet, men en ting synes at være sikker: den fremtidige udvikling giver store muligheder for at opbygge bedre websteder for både brugere og udviklere.

Opdatering af plugins og temaer fra en .zip-fil

Jeg ved, hvad du tænker: Det kan virke ganske “uventet” at se denne funktion vises sammen med automatiske opdateringer. Ikke desto mindre giver det mening.

Før WordPress 5.5, mangler en opdateringsfunktion med et enkelt klik, kunne site-administratorer kun uploade plugin/theme opdateringer via FTP/SFTP eller filhåndtering (lær forskellen mellem FTP og SFTP). Det var mest tilfældet med brugerdefinerede plugins / temaer eller med extensions, der er hosted på tredjeparts markedspladser.

Fra WordPress 5.5 kan du opdatere plugins og temaer ved at uploade en .zip-pakke fra din computer i dit WordPress-dashboard.

Hvis du vil opdatere et plugin, skal du gå til Plugins > Tilføj nyt skærmbillede og klikke på knappen Upload plugin. Hvis du derefter har pluginet installeret på dit websted, fortæller en ny skærm, at “Dette plugin er allerede installeret” og viser den aktuelle version og uploadede versiondetaljer.

Processen er temmelig ens med temaopdateringer.

Gå til skærmbilledet Udseende > Temaer, og klik derefter på Tilføj nyt og derefter på Upload tema. Hvis du allerede har temaet installeret på dit WordPress-websted, fortæller en ny skærm, at “Dette tema er allerede installeret” og viser den aktuelle version og uploadede versiondetaljer.

Yderligere forbedringer til udviklere, der følger med WordPress 5.5

Ud over det, vi har dækket indtil videre, fortjener et par tilføjelser en udviklers opmærksomhed.

New wp_get_environment_type() Function

En new wp_get_environment_type() function giver dig mulighed for at registrere den aktuelle miljøtype på et websted, så udviklere kan tilpasse plugin- og temafunktionaliteter til det aktuelle miljø.

Som standard returnerer wp_get_environment_type() returnerer production. Andre understøttede værdier er development og staging. Uanset hvad har udviklere lov til at definere yderligere miljøtyper om nødvendigt.

Der er tre tilgængelige metoder til at indstille en webside-miljøtype. Fra en prioriteret rækkefølge kan du bruge:

• WP_ENVIRONMENT_TYPE environment variable.
• WP_ENVIRONMENT_TYPE constant.
• wp_get_environment_type filter.

Hvis du f.eks. vil indstille dit miljø til staging, kan du definere WP_ENVIRONMENT_TYPE-konstanten i din wp-config.php-fil som vist nedenfor:

define( 'WP_ENVIRONMENT_TYPE', 'staging' );

Hvis miljøtypen development, indstilles WP_DEBUG automatisk til sandt, selvom du ikke har defineret den eksplicit.

REST API-ændringer i WordPress 5.5

WordPress 5.5 bringer også mange ændringer til REST API. Vi ser flere nye endepunkter, nye parametre og JSON-skemaændringer, nye funktioner og yderligere forbedringer.

Her er en hurtig liste over nye slutpunkter:

Bloktyper

Et nyt slutpunkt gør det muligt at få alle registrerede bloktyper:

• GET /wp/v2/block-types returnerer alle registrerede bloktyper.
• GET /wp/v2/block-types/core returnerer alle blokke inden for core navneområdet.
• GET /wp/v2/block-types/core/quote returnerer definitionen af ​​core quote quote block.

Plugins

Et nyt slutpunkt gør det muligt at administrere plugins:

• GET /wp/v2/plugins returnerer en liste over alle installerede plugins.
• GET /wp/v2/plugins/plugin-name/plugin-name returnerer information om det specificerede plugin.
• POST /wp/v2/plugins { slug: "plugin-name" installerer det specificerede plugin fra Plugins Directory
• PUT /wp/v2/plugins/plugin-name/plugin-name { status: "active" } aktiverer det specificerede plugin
• DELETE /wp/v2/plugins/plugin-name/plugin-name sletter en inaktiv plugin.

Block directory

Et nyt slutpunkt gør det muligt at søge i blokmappen:

• GET /wp/v2/block-directory/search?term=block-name søger i block-biblioteket efter block-name

Billedredigering

Sammen med den nye inline billedredigeringsfunktion giver et nyt slutpunkt mulighed for at redigere billedvedhæftede filer i Mediebiblioteket:

POST /wp/v2/media/5/edit redigerer billedet med ID 5

Se WordPress Core dev-noter for en nærmere oversigt over alle ændringer til REST API, der følger med WordPress 5.5.

Resumé

Vi er begejstrede for alle disse nye funktioner og forbedringer, som WordPress 5.5 bringer i en enkelt version.

Det viser den enorme mængde arbejde, der sker bag kulisserne, og vi værdsætter dybt al den indsats og engagement fra enhver kernemedarbejder.

Hvis ændringerne nævnt ovenfor ikke er nok for dig, her er mere, du skal tjekke for yderligere forbedringer, der følger med WordPress 5.5:

• 65 nye ikoner tilføjet Dashicons icon fonts i WordPress Core
• Lister med tilgængelighedsforbedringer med links i widgets
• Nye CSS-stilarter til deaktiverede knapper
• Opcode Cache ugyldighed
• Bedre kontrol med redirect_guess_404_permalink()
• PHP-relaterede forbedringer
• Codebase ændringer
• Ændringer i brugerdefinerede logo-funktioner og filter
• Bloker API-opdateringer
• Archive page headings filters
• Tilføjelse af ikoner i Twenty Twenty
• Og mange flere

Sørg for at deltage i vores gratis webinar, der er fuldt dedikeret til WordPress 5.5!

Nu er det din tur. Hvad er de funktioner og / eller forbedringer, du kan lide mest i WordPress 5.5? Og hvilke funktioner vil du gerne føje til WordPress 5.6? Del dine tanker i kommentarafsnittet nedenfor!