WordPress 4.9 i tilbakeblikk: versjonen før Gutenberg

WordPress 4.9 “Tipton” (lansert i 2017) var en spesiell versjon. Det var den siste store versjonen før WordPress 5.0, som gjorde Gutenberg til standardeditor.

Les mer om WordPress-utvikling hos WPPoland.

Kortversjonen: WordPress 4.9 er viktig fordi det forbedret de faktiske arbeidsflytene til redaktører og utviklere rett før Gutenberg snudde redigeringsmodellen helt på hodet. Dette tilbakeblikket holder seg til det den offisielle kunngjøringen, feltguiden for 4.9 på make.wordpress.org og versjonssiden i WordPress-dokumentasjonen faktisk sier, med lenker slik at du kan sjekke hvert punkt.

#Når WordPress 4.9 kom ut, og hvem som ledet arbeidet

WordPress 4.9 “Tipton”, oppkalt etter jazzmusikeren og orkesterlederen Billy Tipton, ble kunngjort 16. november 2017 i den offisielle kunngjøringen. Versjonssiden i WordPress-dokumentasjonen daterer lanseringen til 15. november, som er det samme tidspunktet sett fra en amerikansk tidssone. Det var den siste store versjonen der den klassiske editoren var standard.

Ifølge kunngjøringen ble arbeidet ledet av Mel Choyce og Weston Ruter. Den krediterer 443 bidragsytere, 185 av dem for første gang, og versjonen var fullt oversatt til 43 språk ved lansering. Dokumentasjonssiden legger til to tall som er nyttige når du undersøker en gammel installasjon: databaseversjonen ble stående på 38590, og versjonen tilsvarer Trac-revisjon 42195.

Feltguiden for 4.9, publisert før lanseringen, teller rundt 400 feil, 181 forbedringer, 7 funksjonsønsker og 42 oppgaver lukket i syklusen.

Hvorfor 4.9 betyr noe i ettertid:

• det var den siste versjonen med den klassiske editoren som standard,
• det tok CodeMirror inn i kjernen, og det biblioteket driver fortsatt kodefeltene i kontrollpanelet,
• det fullførte changeset-arbeidet i Customizer som startet i 4.7,
• selve kunngjøringen ble skrevet i Gutenberg og ba leserne teste den nye editoren.

#Hva som endret seg i Customizer i WordPress 4.9

#Utkast og planlagte endringer i Customizer

For første gang kunne du gjøre designendringer (farger, CSS, widgeter, menyer), lagre dem som utkast og komme tilbake senere, uten å publisere noe.

Teknikken var eldre enn knappen. Changesets, en måte å lagre ventende Customizer-endringer som et innlegg av typen customize_changeset identifisert med en UUID, kom i WordPress 4.7. Som Weston Ruter forklarer i utviklernotatet om changesets i 4.9, hadde 4.7 ikke noe grensesnitt for dem. Et changeset lå i et auto-draft-innlegg som ble ryddet bort etter en uke hvis du ikke rørte det igjen.

WordPress 4.9 la til grensesnittet. Etter første endring dukker det opp et tannhjul ved siden av publiseringsknappen, som åpner publiseringsinnstillingene: publiser, lagre utkast eller planlegg. En lenke for å forkaste endringer setter Customizer tilbake til sist publiserte tilstand.

Før 4.9 betydde designendringer:

• å redigere det levende nettstedet (risikabelt),
• å bruke et staging-miljø (mer oppsett),
• å lime inn CSS for hånd (vanskelig å angre).

Planleggingen virker fordi et changeset går live når innlegget skifter til statusen publish. Notatet viser at mekanismen fantes før grensesnittet, med en WP-CLI-kommando som planlegger en endring av nettstedstittelen:

wp post create \
    --post_type=customize_changeset \
    --post_name=$( uuidgen ) \
    --post_status=future \
    --post_date="2018-01-01 00:00:00" \
    --post_content='{"blogname":{"value":"Happy New Year!"}}'

En praktisk advarsel fra samme notat gjelder fortsatt. Planlagte changesets publiseres via WP-Cron, normalt innen ett minutt etter planlagt tidspunkt. På et nettsted med få besøkende kan cron komme for sent, og notatet anbefaler en system-cron som kaller wp-cron.php hvert minutt når tidspunktet betyr noe.

#Forhåndsvisningslenker for kunder

Å forhåndsvise et changeset er en ren leseoperasjon, så alle med UUID-en kan se nettstedet med de ventende endringene, innlogget eller ikke. WordPress 4.9 gjorde dette til en forhåndsvisningslenke du kan sende til kolleger og kunder. Kunngjøringen beskriver den som en måte å samle tilbakemeldinger før du planlegger at endringene går live, og det var slik byråer brukte den.

#Designlås og autolagring i Customizer

Siden et lagret utkast nå lastes for alle brukere som åpner Customizer, kunne to personer overskrive hverandre. Svaret i 4.9 var changeset-lås etter modell av innleggslås: en annen bruker ser et låsvarsel og kan gå tilbake eller ta over, og Customizer bruker WP Heartbeat for å holde låsen aktiv.

Autolagringen ble også bedre. Hvis du lukket nettleseren ved et uhell, tilbød Customizer å gjenopprette siste auto-draft neste gang du åpnet den, og sider eller innlegg opprettet fra Customizer mens et utkast var aktivt, ble merket som Customizer-utkast i adminlisten.

#Lineære og forgrenede changesets

Kjernen bruker det notatet kaller lineær modus: bare ett changeset kan være lagret som utkast eller planlagt om gangen. Planlegger du en tittelendring til neste uke, kan du ikke publisere en uavhengig endring av slagordet i dag uten å forkaste eller publisere begge. Temabytte er også blokkert så lenge det finnes et changeset som utkast eller planlagt.

Nettsteder med flere tunge Customizer-brukere kan hente tilbake den gamle oppførselen, der hver økt får sitt eget changeset, med ett filter:

add_filter( 'customize_changeset_branching', '__return_true' );

#Bla gjennom og bytte temaer i Customizer

Customizer fikk en ny temaleser. Kunngjøringen sier at du kunne søke i, bla gjennom og forhåndsvise over 2600 temaer direkte i Customizer, med filtre for emne, funksjoner og oppsett, og feltguiden påpeker at du for første gang kunne installere temaer fra WordPress.org i samme flyt.

Temabytte ble også mindre ødeleggende. Dokumentasjonen nevner en tilordning av menyer og widgeter basert på kvalifisert gjetning (Trac #39692), slik at menyer og widgeter oftere havnet et fornuftig sted i det nye temaet. Flyten for å lage menyer i Customizer ble også gjort om, med nye instruksjoner for å opprette en meny og knytte den til en plassering.

#Hvordan CodeMirror endret koderedigering i WordPress 4.9

Kodeeditorene i kontrollpanelet fikk endelig syntaksutheving, linting og autofullføring. Utviklernotatet om koderedigering lister fire steder som fikk CodeMirror: Ekstra CSS i Customizer, widgeten Egendefinert HTML og fil-editorene for temaer og utvidelser.

Det var andre forsøk. Syntaksutheving i fil-editorene kom allerede i WordPress 2.8 med et bibliotek kalt CodePress, men ble fjernet i 2.8.1 på grunn av problemer med nettleserkompatibilitet. Funksjonen ble foreslått på nytt i Trac-sak #12423 og brukte åtte år på å komme tilbake.

Dette la CodeMirror til i 4.9:

• Syntaksutheving med medfølgende moduser, blant annet css, htmlmixed, javascript, php, sql, markdown og yaml.
• Automatisk lukking og matching av parenteser og tagger.
• Linting med CSSLint, JSHint, HTMLHint og JSONLint.
• Autofullføring for CSS-egenskaper, HTML-tagger og JavaScript DOM-objekter.

Når en linter finner en feil, ber WordPress deg rette den før du lagrer. I Ekstra CSS og widgeten Egendefinert HTML er lagring blokkert til koden er gyldig; i fil-editorene kan du overstyre varselet og lagre likevel. I 4.7 telte Ekstra CSS bare klammeparenteser og hakeparenteser, noe som ga falske alarmer når en klamme sto i en kommentar. Den serverside-sjekken ble fjernet til fordel for CSSLint.

To detaljer viser hvor nøye omfanget ble valgt. CodeMirror ble ikke lagt inn i tekstfanen i innleggseditoren, på grunn av tilgjengelighetshensyn for skjermleserbrukere og fordi Gutenberg uansett skulle erstatte den editoren. Og hver bruker fikk et valg i profilen for å slå av syntaksutheving.

#Sikrede PHP-endringer i tema- og utvidelseseditoren

Kunngjøringen beskriver det som å unngå den fryktede hvite skjermen. Mekanismen fra Trac #21622 er en tilbakerulling. Når du lagrer en PHP-fil i tema- eller utvidelseseditoren, tar WordPress vare på en kopi av det gamle innholdet, skriver endringen og sender så en loopback-forespørsel til editorsiden med dine informasjonskapsler. Gir forespørselen en fatal feil, gjenopprettes den gamle filen. Hvis ikke, sjekker en ny loopback-forespørsel forsiden. Ved enhver fatal feil får du meldingen, og endringen din blir liggende i editoren slik at du kan rette den. Kan ikke loopback-forespørslene fullføres, rulles endringen tilbake og du blir bedt om å bruke SFTP.

Lagring skjer nå via Ajax, og forlater du siden med ulagrede endringer, får du en bekreftelsesdialog. Før 4.9 prøvde utvidelseseditoren å fange fatale feil ved å deaktivere og reaktivere utvidelsen, noe som kunne etterlate en kritisk utvidelse avslått. Temaer hadde ingen beskyttelse i det hele tatt.

Editorene endret seg også rundt kantene. Første besøk viser en advarsel om at direkte filredigering er risikabelt, og temaeditoren viser deg videre til Ekstra CSS. Flere filtyper ble redigerbare (blant annet js, json, scss, md, svg og yml), filer dypere enn to katalognivåer kunne åpnes, og fillisten ble et sammenleggbart tre.

#Bruke kodeeditoren i WordPress i din egen utvidelse

CodeMirror i 4.9 er også et API. Funksjonen wp_enqueue_code_editor() tar en fil-type, et file-navn eller en codemirror-innstillingstabell, velger fornuftige standardverdier for språket og returnerer innstillingene, eller false når brukeren har slått av syntaksutheving. Eksemplet i notatet gjør biografifeltet på profilsiden om til en HTML-editor:

add_action( 'admin_enqueue_scripts', function() {
	if ( 'profile' !== get_current_screen()->id ) {
		return;
	}

	// Last inn kodeeditoren og innstillinger for HTML.
	$settings = wp_enqueue_code_editor( array( 'type' => 'text/html' ) );

	// Avbryt hvis brukeren har slått av CodeMirror.
	if ( false === $settings ) {
		return;
	}

	wp_add_inline_script(
		'code-editor',
		sprintf(
			'jQuery( function() { wp.codeEditor.initialize( "description", %s ); } );',
			wp_json_encode( $settings )
		)
	);
} );

Før innstillingene returneres, går de gjennom filteret wp_code_editor_settings, som du kan bruke til å endre valg som lineWrapping globalt. Kjernen registrerer biblioteket under håndtaket wp-codemirror og eksponerer det som wp.CodeMirror i stedet for et globalt CodeMirror-objekt, slik at det ikke kolliderer med utvidelser som har med sin egen kopi. I Customizer finnes samme editor som kontroll via WP_Customize_Code_Editor_Control.

#Endringer i widgeter i WordPress 4.9

#Galleri-widget og medier i tekst-widgeten

Fotogallerier i sidefeltet ble en innebygd funksjon. Galleri-widgeten fulgte etter bilde- og mediewidgetene fra WordPress 4.8, og dokumentasjonen fører den som Trac #41914.

Tekst-widgeten endret seg også. Den fikk en knapp for å legge til medier (bilder, video og lyd) og begynte å kjøre kortkoder. Det ønsket (Trac #10457) hadde stått åpent i over åtte år, og det betydde at utvidelser og temaer ikke lenger trengte add_filter( 'widget_text', 'do_shortcode' ). Tekst-widgeter godtar også oEmbeds, så en YouTube-adresse i widgeten blir en innebygd spiller, og video-widgeten lærte å håndtere andre leverandører enn YouTube og Vimeo.

På widgetsiden i admin viser en ny endringsstatus når en widget er lagret, og du blir bedt om å bekrefte hvis du prøver å forlate siden med ulagrede endringer.

#Sikkerhet, roller og utviklerendringer i WordPress 4.9

#Nye rettigheter og kontosikkerhet

Dokumentasjonssiden og feltguiden lister flere endringer som betyr noe for den som administrerer brukere:

• egne rettigheter activate_plugin og deactivate_plugin, sjekket mot en bestemt utvidelse, slik at en rolle kan få slå av og på noen utvidelser og ikke andre,
• egne rettigheter for å installere og oppdatere språkfiler,
• en bekreftelseslenke på e-post når en bruker prøver å endre e-postadressen sin (Trac #16470),
• mer pålitelig initialisering av roller og rettigheter når kode bytter mellom nettsteder i multisite, pluss den nye funksjonen get_site_by().

#Customizer JS API, MediaElement og fjerninger

For utviklere ble mange irritasjonsmomenter i Customizers JavaScript-API fjernet, slik feltguiden lister dem: standardparametere for konstruksjoner, basismaler for kontroller, en dato- og tidskontroll og varsler på globalt nivå, panelnivå og seksjonsnivå. MediaElement.js ble oppgradert til 4.2.6, som ifølge kunngjøringen fjerner avhengigheten av jQuery, bedrer tilgjengeligheten og retter mange feil.

Noe forsvant fra kjernen. SWFUpload ble fjernet, og Press This ble flyttet ut i en egen utvidelse. REST API-et begynte å kreve navngitte URL-parametere i rutenes regulære uttrykk, så numeriske treff virker ikke lenger. Dokumentasjonen nevner også at kjernen og enhetstestene var fullt kompatible med den da kommende PHP 7.2.

#Fra WordPress 4.9 til 5.0 og Gutenberg

#Tidslinje for WordPress fra 4.9 til 6.x

2017 (4.9):

• Siste versjon med den klassiske editoren som standard
• Gutenberg under utvikling som utvidelse, og kunngjøringen etterlyste testere
• CodeMirror holdt utenfor innleggseditoren fordi Gutenberg skulle erstatte den

2018 (5.0):

• Gutenberg ble innført som standardeditor
• Utvidelsen Classic Editor var tilgjengelig for nettsteder som ville beholde den gamle skjermen

2019 til 2021:

• Gutenberg modnet med hver oppdatering
• Blokkmønstre ble innført
• Full Site Editing (FSE) tok form

Fra 2022:

• Blokktemaer og nettstedseditoren i kjernen
• Klassiske temaer og Customizer støttes fortsatt

#Classic Editor og Gutenberg etter 4.9

Bare et år etter 4.9 kom WordPress 5.0 med Gutenberg. Miljøet delte seg i to leirer:

Tradisjonalister:

• Holdt seg til utvidelsen “Classic Editor”
• Fortsatte med PHP-baserte temaer
• Foretrakk sidebyggere (Elementor, Divi, WPBakery)
• Utvidelsen Classic Editor har fortsatt millioner av aktive installasjoner

Moderne skapere:

• Tok i bruk modellen Full Site Editing (FSE)
• Alt, også topptekst og bunntekst, bygget med blokker
• Valgte blokktemaer som Twenty Twenty-Three og Twenty Twenty-Four
• Brukte blokkmønstre og maler

#Hvilke funksjoner fra WordPress 4.9 som fortsatt gjelder

#CodeMirror og Customizer-utkast i dag

CodeMirror:

• Brukes fortsatt i fil-editorene for temaer og utvidelser og i Ekstra CSS
• Fortsatt tilgjengelig for utvidelser via wp_enqueue_code_editor()

Customizer-utkast:

• Fortsatt tilgjengelig i klassiske temaer som bruker Customizer
• Planlegging avhenger fortsatt av WP-Cron, så cron-rådet fra 2017 gjelder fortsatt
• Blokktemaer bruker nettstedseditoren, med egne revisjoner og egen forhåndsvisning

Sikkerhet i fil-editoren:

• Loopback-tilbakerullingen fra 4.9 er fortsatt grunnen til at en ødelagt PHP-endring i kontrollpanelet sjelden tar ned nettstedet
• Konstanten DISALLOW_FILE_EDIT i wp-config.php slår fortsatt av fil-editorene helt i produksjon

#Forskjeller mellom WordPress 4.9 og WordPress 6.x

#Hvordan temautvikling har endret seg siden WordPress 4.9

Temautvikling:

• 4.9: PHP-maler, functions.php, hooks og filtre
• 6.x: Blokktemaer, theme.json, nettstedseditoren

I 4.9-æraen krevde et tema god kjennskap til PHP, malhierarkiet i WordPress og hook-systemet. Blokktemaer defineres hovedsakelig gjennom theme.json og HTML-maler, og PHP brukes til enkeltfunksjoner.

Innholdsredigering:

• 4.9: Klassisk editor, kortkoder, widgeter
• 6.x: Gutenberg-blokker, mønstre, maler

Tilpasning:

• 4.9: Customizer, temainnstillinger
• 6.x: Nettstedseditoren, blokkinnstillinger

Utviklerverktøy:

• 4.9: CodeMirror, WP_DEBUG
• 6.x: Verktøy for blokkutvikling som @wordpress/scripts

#Funksjoner som er erstattet og lagt til siden WordPress 4.9

Erstattet eller valgfritt:

• Klassisk editor (tilgjengelig som valgfri utvidelse)
• Mange Customizer-funksjoner (erstattet av nettstedseditoren i blokktemaer)
• Widgetskjermer (blokkbaserte widgetområder)

Fortsatt der:

• CodeMirror i kodefelt
• Sikrede PHP-endringer i fil-editorene

Nytt:

• Gutenberg-blokkeditoren
• Full Site Editing
• Blokkmønstre
• theme.json for temakonfigurasjon
• React-basert editorutvikling

#Hva utviklere kan lære av WordPress 4.9

#1. Infrastruktur først, grensesnitt etterpå

Changesets kom i 4.7 uten grensesnitt, og 4.9 la utkast, planlegging og lås oppå. Å skille lagring fra grensesnitt gjorde det mulig å levere funksjonen over to versjoner uten å ødelegge eksisterende nettsteder.

#2. Bakoverkompatibilitet i WordPress

WordPress holdt seg bakoverkompatibelt også gjennom store endringer. Utvidelsen Classic Editor holdt gamle nettsteder i gang etter 5.0, og kortkodestøtten i tekst-widgeten fjernet et filter som temaer og utvidelser hadde lagt til for hånd.

#3. Sikkerhetsnett for dem som redigerer i produksjon

Loopback-tilbakerullingen, lintingen som stopper lagring og advarselen i fil-editorene tar utgangspunkt i at folk redigerer levende nettsteder. Å planlegge for det viste seg mer nyttig enn å late som det ikke skjer.

#Oppsummering av WordPress 4.9 og de viktigste nyhetene

WordPress 4.9 “Tipton” var den siste versjonen av “klassisk” WordPress før Gutenberg-editoren.

Viktigste nyheter:

• Utkast, planlegging, lås og forhåndsvisningslenker i Customizer
• CodeMirror med linting i Ekstra CSS, widgeten Egendefinert HTML og fil-editorene
• Sikrede PHP-endringer som ruller tilbake fatale feil
• Galleri-widget, kortkoder og medier i tekst-widgeten
• Nye rettigheter og bekreftelse ved endring av e-post

For utviklere:

• Les feltguiden for 4.9 når du vedlikeholder et klassisk tema, for mye av Customizer- og kodeeditor-API-et du bruker, stammer derfra
• Bruk wp_enqueue_code_editor() i stedet for å pakke med din egen CodeMirror
• Sett opp en ekte cron hvis du er avhengig av planlagte changesets