WP Offload Media

Jag har varit ett fan av Advanced Custom Fields (ACF) under en lång tid nu. Det används på nästan alla webbplatser som jag har byggt eller arbetat med de senaste åren.

För den ovetande är ACF ett plugin som ger dig mer kontroll över ditt innehåll. Det använder custom post meta för att berika ditt innehåll med strukturerade data. Det låter dig också bygga och konfigurera datafälten i metarutor när du uppdaterar inlägg, sidor, anpassade posttyper och mycket mer.

Förr har jag använt insticksprogrammet som en del av ett projekt på webbplatsen Delicious Brains. Det här blogginlägget har dock visat mig hur viktig lösningen från tredje part är för WordPress-utveckling. Låt mig förklara…

Hur ACF fungerar

Det tog mig ett tag att förstå vad ACF gör, så här är ett snabbt exempel. Jag har använt det på en webbplats för en välgörenhetsorganisation för hundräddning, där användarna lägger till nya hundar för omplacering som en anpassad posttyp. Förutom hundens namn, beskrivning, rubrik och innehåll vill de också lagra hundens ras och kön, en länk till en video och några foton.

För att göra detta har jag skapat en fältgrupp för dessa data från menyn Anpassade fält > Fältgrupper > Lägg till ny meny:

Du kan lägga till fält av olika typer. Här har jag använt val, textrutor, en enkel boolsk kryssruta och ett gallerifält. Det sistnämnda är ett ACF Pro-alternativ, och jag kommer att diskutera detta lite mer senare.

Här ser du hur du skulle konfigurera en select-ruta, komplett med användaralternativ:

Nästan har jag sagt att den här gruppen bara ska visas på redigeringsskärmar för den anpassade posttypen Dog. Det finns all slags logik som du kan använda här, till exempel inläggstyper, mallar, kategorier och användarroller:

Den verkliga kraften i ACF är dock när du lägger till data.

Läggning av data till ACF-fält

Redigeringsskärmen ser annorlunda ut när du arbetar med ett Dog inlägg. Den visar en anpassad metaruta med de definierade fälten:

Detta gör det enkelt för innehållsredaktörer att lägga till alla extra data. Du kan också ange exakt var du vill att uppgifterna ska visas i temat med hjälp av funktionskoden get_field:

<div class="columns small-12 medium-9"> <a href="<?php get_permalink(); ?>"> <h2 class="icon paw"><?php get_the_title(); ?> <span class="dog-data"> <?php printf( ‘%s %s, get_field( 'gender' ), get_field( 'breed' ) ); ?> </span> </h2> </a></div>

Och utan insticksmodulet måste jag antingen använda WordPress standard anpassade metafält, koda mina egna, mer innehållsrika metafält från grunden eller lägga in hundens ras och kön i anpassade taxonomier. Jag kanske till och med måste använda det ursprungliga galleriet som är inbäddat i inläggets innehåll.

ACF lyfter WordPress

ACF är precis vad WordPress som innehållshanteringssystem (CMS) har saknat när det gäller att ha mer kontroll över ditt innehåll. Med över en miljon aktiva installationer har det bidragit till att göra WordPress-plattformen mer kraftfull och kan till och med ha bidragit till dess tillväxt.

Vad mer, utvecklare och byråer har utnyttjat det för att ge kunderna kontroll över sitt innehåll utan att behöva använda sig av kortkoder, sidbyggare eller till och med post_content överhuvudtaget. Utvecklare har fullständig kontroll över var data visas på webbplatsens front end och undviker de oundvikliga klientredigeringar som förstör det visuella.

Faktiskt är ACF så populärt bland våra kunder att vi var tvungna att lägga till en integration med WP Offload Media. Nu fungerar bilder och beskärning med media som laddas över till Amazon S3, DigitalOcean Spaces eller Google Cloud Storage.

Att lägga till extra fältalternativ till ACF

Den kostnadsfria versionen av insticksmodulen har massor av funktionalitet. Premiumversionen är dock nödvändig för att få tillgång till fält som repeaters, flexibla layouter och gallerier.

Till exempel använder vi repeaterfältet för att låta användare visa utvalda vittnesmål i en slider på produktsidor. Repeater-fältet innehåller ett inbäddat postobjektfält:

Det visas sedan när vi redigerar sidan, så att vi kan styra vilka vittnesmål som ska visas:

Med åtgärder och filter utspridda över hela kodbasen har ACF alltid varit ett extremt utvecklingsvänligt och utbyggbart verktyg. Det prioriterar också förbättringar som är viktiga för användarna.

Användning av Local JSON-funktionen

En av de få problem som jag har funnit i det förflutna var dock att lagra fältkonfigurationer i databasen, särskilt anpassade posttyper för fältgrupper och fält.

Detta innebar att om du ändrade fältdefinitionen på en utvecklingssajt kunde du inte trycka tillbaka din databas med en lösning som WP Migrate DB Pro till live. Du skulle upptäcka att tabellen posts skulle ändras och du skulle förlora de nya uppgifterna.

Det här är det urgamla problemet med sammanslagning av databaser (låt mig inte börja…). Jag brukade arbeta runt detta genom att göra fältändringar på den levande webbplatsen först. Sedan drog jag databasen till min lokala webbplats för att fortsätta med utvecklingen. Det var inte idealiskt.

Turligtvis introducerade ACF Local JSON-funktionen. Detta gör det möjligt att spara fältkonfigurationer som JSON-filer, som kan synkroniseras med databasen.

Denna fantastiska funktion löser problemet med sammanslagning av databaser för ACF-data. Det innebär också att du kan hålla JSON-filerna under versionskontroll och göra konfigurationen till en del av din typiska filutplaceringsprocess. När jag arbetade med insticksmodulen på vår webbplats lade jag till några justeringar för att integrera den ännu mer med vår Git- och multimiljöuppsättning:

• Jag definierade JSON-katalogen till vår app/data-katalog utanför temat (eftersom den kan komma att förändras).
• Menyvalet ”Anpassade fält” kommer bara att visas på utvecklingsmiljöer.
• JSON-filer med en föråldrad databaskonfiguration på admin_init kommer automatiskt att synkroniseras.

Även om vi nu har WordPress Block Editor (tidigare känd som Gutenberg) skulle jag vilja hävda att ACF fortfarande är avgörande för att skapa en bra redigeringsupplevelse.

Användning av Block Editor vid sidan av ACF

Blockeditorn erbjuder en annan inriktning för redigering av innehåll än ACF. Du skapar innehåll med hjälp av block i stället för att lagra det som postmetadata, vilket ger dig en viss designflexibilitet.

I början hade blockredigeraren inte stöd för metarutor. De togs till och med bort från skärmen ”Redigera inlägg”, vilket ledde till stor upprördhet. Nu har stöd lagts till för metarutor. De visas under blockredigeraren med ett minimalt, mindre raffinerat användargränssnitt (UI).

Den nya redigeraren, som använder block i stället för fält för anpassade data, har potential att ha en stor inverkan på ACF:s framtid. Dessutom kommer nya webbplatser att vara mycket mindre benägna att installera ett verktyg från tredje part nu när det finns en inbyggd lösning.

Det är dock inte första gången som föreslagna kärnändringar har hotat ACF:s framtid. För några år sedan sattes ett nytt team ihop för Post Meta. Till en början lät detta som om det skulle döda de olika tredjepartslösningarna för anpassade fält:

Det har funnits en mängd bibliotek/ramverk/plugins (CMB, SCB, WPAlchemy, ACF, Pods), som har fyllt denna roll för tillfället. Vi kommer att betrakta dessa som andliga föregångare till en ny kärnvärd plugin.

På den tiden skrev jag om hur detta beslut att införa nya konkurrerande funktioner skulle kunna göra vissa plugins överflödiga. I slutändan gick Post Meta-projektet ingenstans, den nya redigeraren kom och ACF klarade stormen.

ACF studsade inte bara tillbaka, utan anpassade sig också. Resultatet blev något som kombinerade kraften hos ACF och flexibiliteten hos anpassade block. Låt oss prata om detta härnäst.

Hur man bygger block med hjälp av ACF

Oppenbart kan anpassade block vara fördelaktiga. Den tekniska processen för att skapa dem är dock komplex. ACF Blocks fyller luckan.

ACF Blocks integreras med dina nuvarande anpassade fält, är dynamiska och anpassningsbara och låter dig uppnå två saker:

• Du kan ta med dig dina nuvarande anpassade fält in i Block Editor-ekosystemet.
• Du kan skapa anpassade inline-lösningar.

De återges med hjälp av en PHP-mallfil eller callback-funktion – så det är precis som att utveckla ett tema. De behåller också WordPress-kärnkompatibilitet, så du kan till och med skapa återanvändbara block genom ramverket.

Men även om ACF Blocks inte är en krycka skulle jag säga att om dina React-kunskaper fortfarande är bristfälliga, så vill du definitivt undersöka dem närmare. De kommer att låta dig utnyttja kraften i Block Editor samtidigt som du håller dig inom den välbekanta functions.php-filen.

Byggandet av ett ACF Block

Låt oss visa dig hur du bygger ett ACF Block. Pro-versionen av verktyget har inkluderat den här funktionen från ACF 5.8, så den har funnits med oss i ungefär två år nu. Här är den superenkla exempelkoden för blockregistrering:

add_action('acf/init', 'my_acf_init');function my_acf_init() { // check function exists if( function_exists('acf_register_block_type') ) { // register a testimonial block acf_register_block_type(array( 'name' => 'testimonial', 'title' => __('Testimonial'), 'description' => __('A custom testimonial block.'), 'render_template' => 'template-parts/blocks/testimonial/testimonial.php', 'render_callback' => 'my_acf_bock_render_callback', 'category' => 'formatting', 'icon' => 'admin-comments', 'keywords' => array( 'testimonial', 'quote' ), )); }}

Från här vill du skapa en fältgrupp och rendera blocket. För det förstnämnda gör du detta från skärmen Custom Fields > Field Groups i WordPress:

Här lägger du till din fältgrupp och fyller den som vanligt. I metarutan ”Location” vill du dock använda regeln ”Block” för att välja (i det här fallet) Testimonial Block.

Slutligt måste du återge blocket. Detta följer samma process som du kanske redan är van vid med anpassade fält:

• Skapa en mallfil för ditt tema baserat på den parameter som anges i inställningen render_template när du initialt registrerar blocket.
• Choose the right method for rendering the Block.
• Enqueue your styles and scripts.

Note that the acf_register_block_type() function offers enqueue_styleenqueue_script and enqueue_assets settings.

On the whole, Blocks shouldn’t replace every custom field meta box where they’re needed, but they will let you take advantage of crafting content in the editor.

’InnerBlocks’ Support

The Block Editor also has functionality that helps you work with ACF Blocks. InnerBlocks essentially let you insert any new Block into your ACF Block.

They can be custom or core Blocks, and you’re able to use the current ”Title”, ”Content”, and ”Button” fields in your own ACF Blocks.

Here’s a quick tutorial to get up and running. För att börja använda InnerBlocks inkluderar du 'jsx' => true i arrayen supports:

acf_register_block_type( array( 'name' => 'testimonial', 'title' => __( 'Testimonial' ), 'render_template' => 'template-parts/blocks/testimonial/testimonial.php', 'mode' => 'preview', 'supports' => ));

Du måste sedan echo<InnerBlocks /> HTML-tagg i din Block-mall:

 echo '<div class="block-about__content">'; echo '<InnerBlocks />';

Detta är bara ett enkelt exempel, men det finns mycket mer du kan göra med InnerBlocks.

Alternativ till ACF Blocks

Självklart kommer ACF inte att vara den enda lösningen för att skapa Blocks. Som sådan kommer din första instinkt troligen att vara ett skräddarsytt bygge.

Vi har tidigare behandlat hur man skapar ett ”vaniljblock”, men innan du börjar behöver du kunskaper om React.

Det finns också WordPress-plugins som låter dig sätta ihop Blocks från olika komponenter, men jag skulle säga att de egentligen inte är avsedda för utvecklare utan för ”slutanvändare som pysslar med saker och ting”. Lazy Blocks uppdateras regelbundet, så detta är ett bra alternativ om du vill experimentera med vad det erbjuder.

Framtiden för ACF

Sedan lanseringen har ACF varit ett viktigt kompletterande plugin för WordPress. Det utökar, berikar och gör plattformen mer användbar. Jag tror inte att jag skulle kunna bygga webbplatser utan det.

Hur som helst är kombinationen av blockredigeraren och ACF Blocks pricken över i:et – det är en utmärkt investering i CMS:ets framtid. Det kommer att bidra till att sänka inträdesbarriären för utvecklare som vill utöka Block Editor utan att börja med den branta inlärningskurvan för React. I det långa loppet kan de som trycker så hårt på utvecklingen av blockredigeraren se detta som en vinst.