Miks ACF plokkide eelvaade pärast WordPressi uuendust katki on?

Leht on korras. Avalik pool on puutumata, külastaja näeb täpselt seda, mida eelmisel nädalal. Aga wp-adminis on redaktor katki. Plokkidel on kujundus ja paigutus kadunud, väljad, mida sai varem otse lehel muuta, on kolinud kitsasse külgribasse, ja mõni plokk ei näita üldse midagi. Inimesed, kes varem panid lehti visuaalselt kokku, täidavad nüüd vorme, nägemata, mis sellest välja tuleb.

Teemas ei muutunud midagi. Muutus WordPress.

Mis päriselt muutus#

WordPress renderdab plokiredaktori lõuendi iframe'i sees. See algas tinglikult versioonist 6.3, ainult neil ekraanidel, kus iga registreeritud plokitüüp deklareerib apiVersion 3 või kõrgema, ja muutus versioonis 7.1 tingimusteta.

Iframe on eraldi dokument. Kõik, mis pannakse järjekorda admin_enqueue_scripts või enqueue_block_editor_assets küljes, jõuab wp-admini dokumenti sellest väljaspool ja ei ületa seda piiri kunagi. Teemad, mis redaktori stiile nii edastasid - ja aastaid oligi see tavaline muster - jäävad olukorda, kus eelvaade ei saa teema CSS-i üldse.

See ei ole valik, mille saab tegemata jätta. ACF PRO otsustab plokiversiooni WordPressi versiooni järgi:

$default_acf_block_version = version_compare( get_bloginfo( 'version' ), '7.1', '>=' ) ? 3 : 1;

Nii et leht, kus uuendatakse ainult WordPressi, saab kaasa korraga V3 plokid, iframe'itud lõuendi ja katkise eelvaate, ilma et keegi teemat puudutaks.

Selgita kõigepealt välja, mis päriselt töötab#

Kolm vastust enne, kui midagi muutma hakata:

wp core version
wp plugin get advanced-custom-fields-pro --field=version

wp eval '$v=[]; foreach (acf_get_block_types() as $b) { $v[$b["acf_block_version"]."/".$b["api_version"]]=1; }
echo implode(",", array_keys($v)), " across ", count(acf_get_block_types()), " blocks\n";'

• 1/1 on puhas vana seis ja migratsioon on sirgjooneline.
• 1/3 on poolik seis, mis annab kõige hullemad sümptomid: teema surub peale api_version = 3, aga ei sea kunagi acf_block_version väärtust, nii et plokid töötavad V1-na V3 jaoks skoobitud redaktoris.
• 3/3 on migreeritud ja tööd võib vajada ainult CSS-i kohaletoimetamine.

Ära eelda, et lõuend on iframe'itud. Alla 7.1 hoiab üksainus plugin, mis registreerib apiVersion 1 või 2 ploki, kogu lõuendi wp-admini dokumendis, ja ainult iframe'i jaoks kirjutatud parandus jätab sellise lehe hoopis ilma teema CSS-ita. Brauseri konsoolis muutmisvaates:

wp.blocks.getBlockTypes().filter(b => (b.apiVersion || 1) < 3).map(b => b.name)

Parandus peab katma mõlemad juhud.

Viga, mille otsimine võtab päeva#

Registreeri plokid väärtusega acf_block_version = 3 ja ära sea api_version väärtust kunagi käsitsi. ACF tuletab ühe teisest ja just mõlema korraga seadmine viibki selle 1/3 seisuni.

Seejärel näeb eelvaade lehe laadimisel õige välja ja läheb tühjaks samal hetkel, kui plokk valida.

Kui plokk valitakse, postitab ACF vormi hetkeseisu aadressile acf/ajax/fetch-block ja renderdab eelvaate sellest. Selles saadetises on $block['data'] võtmestatud välja võtme, mitte välja nime järgi. Iga $block['data']['heading'] päring mallis tagastab null ja mall renderdab tühja karbi. Ajutine logirida render-callbackis näitab seda selgelt: andmed on välja võtme järgi võtmestatud, $block['data']['content'] on null ja get_field('content') tagastab päris väärtuse.

Kui keegi seda ei märka, läheb hullemaks. Salvesta sellest seisust ja välja võtme kuju jõuab post_content sisse, misjärel katkeb samamoodi ka avalik pool.

Paranda see ühes kohas, render-callbackis. Mitte kunagi plokkide mallides:

function normalize_acf_block_data( $block ) {
    if ( empty( $block['data'] ) || ! is_array( $block['data'] ) || empty( $block['id'] ) ) {
        return $block;
    }

    if ( ! array_filter( array_keys( $block['data'] ), 'acf_is_field_key' ) ) {
        return $block;
    }

    $fields = acf_get_block_fields( $block );

    if ( empty( $fields ) ) {
        return $block;
    }

    $block_id = acf_ensure_block_id_prefix( $block['id'] );
    $values   = array();

    foreach ( $fields as $field ) {
        $values[ $field['name'] ]       = acf_get_value( $block_id, $field );
        $values[ '_' . $field['name'] ] = $field['key'];
    }

    $block['data'] = $values;

    return $block;
}

Sissetuleva kuju kontroll on oluline: ainult redaktori värskendus saadab välja võtme järgi võtmestatud andmed ja tavaline post-content'i tee peab puutumata jääma. Ajaks, mil render-callback käivitub, on acf_setup_meta() väärtused juba nime järgi registreerinud, nii et acf_get_value() leiab need üles ükskõik kumb kuju kohale jõudis. Massiivi ülesehitamine täpselt nii, nagu ACF seda ise teeb - samad töötlemata väärtused ja samad _nimi ja välja võtme paarid - tähendab, et malle ei pea muutma ja wpautop() ei rakendu kaks korda.

Kuidas CSS lõuendile saada#

enqueue_block_assets käivitub muutmisvaates kaks korda: üks kord wp-admini dokumendi jaoks ja teine kord iframe'i jaoks funktsioonist _wp_get_iframed_editor_assets(). Tuum sunnib iframe'i käigu ajaks should_load_block_editor_scripts_and_styles väärtuseks false ja just sellest saabki need kaks eristada:

$is_admin_document = apply_filters( 'should_load_block_editor_scripts_and_styles', true );

Samadest stiilidest on vaja kahte buildi ja need ei ole omavahel vahetatavad:

• iframe saab skoobita buildi, sest iframe'i sees ei ole wp-admini, mida kaitsta
• wp-admini dokument saab buildi, mis on skoobitud .editor-styles-wrapper .acf-block-preview alla

Vaheta need ära ja sümptomid on tagantjärele ilmselged. Skoobita build wp-admini dokumendis viskab CSS-i reboot'i admini menüü peale ja lõhub selle kirjatüübi ja taande. Skoobitud build iframe'i sees ei sobitu mitte millegagi. Alates 7.1-st on lõuend alati iframe'itud, nii et wp-admini käik ainult dubleeriks kõik stiililehed admini päisesse selektorite jaoks, mis ei saa sobituda - sealt tuleb lihtsalt varakult välja tulla.

Plokipõhised stiililehed vajavad sama teed. ACF-i enda enqueue_style argument käivitub enqueue_block_editor_assets küljes ega jõua iframe'i, mis tekitab väga äratuntava poolvalmis seisu: üldine tüpograafia jääb alles, aga hero-plokk on eelvaates padding: 0 ja ühtlase värviga seal, kus peaks olema taustapilt. Pane plokkide stiililehed järjekorda samas hookis ja URL-i kaudu, sest ainult avaliku poole handle'id ei ole admini ekraanidel üldse registreeritud ja neid küsiv plokk on seal vaikne tühitöö.

Selektor, mis vaikselt sureb#

V1 all olid .acf-block-body ja .acf-block-preview üksteise sees. V3 all satuvad need samale elemendile, nii et iga reegel, mis oli kirjutatud nende kahe vahelise järglasahelana, ei sobitu enam millegagi:

.acf-block-body .acf-block-preview { /* V3 all surnud */ }

Kaaslaseks on spetsiifilisuse lõks. Teema baasi skoopimine .editor-styles-wrapper .acf-block-preview alla on kolme klassi selektor, nii et hiljem ühe eellasklassiga kirjutatud ülekirjutus kaotab sellele ja näib mitte midagi tegevat. Redaktori ülekirjutused vajavad tervet ahelat.

Plokid, mis on eelvaates tühi ala#

Kerimisanimatsioonid algavad opacity: 0 või transformi pealt ja ootavad klassi, mille JavaScript lisab siis, kui külastaja kerib. Lõuendil ei tööta ühtegi teema JavaScripti, nii et see klass ei jõua kunagi kohale ja terve plokk on eelvaates tühi ala - see ei näe välja peidetud, vaid katki.

Kinnita lõppseisud lahti ainult redaktorile mõeldud stiililehes:

.editor-styles-wrapper .acf-block-preview {
    .fade-in-up,
    .fade-in {
        opacity: 1;
        transform: none;
        transition: none;
    }
}

Tee projekti enda animatsiooniklassidest nimekiri, selle asemel et eeldada kahte. Sinna kuulub kõik, mis algab nullilise läbipaistmatuse, transformi või clip-path'i pealt ja ootab JavaScripti. Plokk, mille väljad on veel tühjad, ei renderda samuti mitte midagi, nii et anna neile miinimumkõrgus - muidu ei ole tühi plokk katkisest eristatav.

Vite ja Tailwindiga ehitatud teemad#

Seal, kus plokid on kaustad oma block.json failiga, on registreerimine deklaratiivne:

{
  "apiVersion": 3,
  "acf": { "blockVersion": 3, "mode": "preview" }
}

Järjekorda panemise loogika on sama. Ainus erinevus on räsitud buildi failide läbikäimine sõltuvuste järjekorras ja skoobitud admini buildi hoidmine iframe'i käigust eemal.

Kaks asja, mida taga ei tasu ajada#

Konsooli hoiatus, et global-styles-css-custom-properties-inline-css was added to the iframe incorrectly, on tuuma hoiatus tuuma enda kohta. See ilmub tavalisel installil ükskõik millise teemaga ja stiil kloonitakse iframe'i sisse niikuinii. Pluginad tekitavad sama rea. Tegutse ainult siis, kui hoiatus nimetab mõnda sinu enda handle'it - siis tähendab see, et CSS päriselt ei jõua kohale õiget teed pidi.

Ja mode: "edit" ei ole tühja eelvaate põhjus. ACF sunnib V3 all serveri poolel niikuinii preview-režiimi peale, nii et selle muutmine block.json failis ei tee midagi. Põhjus on välja võtme järgi võtmestatud saadetis.

Mida enne valmis ütlemist kontrollida#

• kõik plokid raporteerivad 3/3 ja wp-admini käik ei pane 7.1 peal ühtegi lõuendi handle'it järjekorda
• kliki iga ACF plokk järjest läbi ja veendu, et eelvaade jääb renderdatuks - see on ümbervõtmestamise regressioonitest
• eelvaates on ka kujundus, mitte ainult tüpograafia: päris sisepolsterdus, taustapildid, nupud õiges kohas
• wp-admini menüü säilitab oma kirjatüübi ja taande
• konsoolis ei ole ühtegi apiVersion aegumishoiatust
• avaliku poole leht on enne ja pärast identne, sest V3 ei tohi avalikult midagi muuta

Testi WordPressi versioonil, mis V3 peale sunnib, ja värske ACF-iga. Just sinna leht niikuinii jõuab.

Selline rike tuleb rutiinse uuendusega ja sellel ei ole nähtavat põhjust, sest teemas ei muutunud midagi. Kui mõne lehe redaktor on vaikselt lakanud näitamast, milline leht välja näeb, siis sealt tasub otsida - ja just selleks on korralik hooldusleping.