Az egyének megbecsülése egy WordPress csapatban

Ha valaha is volt már „láthatatlan” közreműködőd (szellemszerző, nem szereplő fordító, fiókot nem kérő szerkesztő), és végül össze kellett kaparintanod a megosztott szerepköröket vagy fiókokat, WordPress egy bizonyos ponton változott: abban, ahogyan mi kiemelések emberek anélkül, hogy a szükségesnél több hozzáférést biztosítanánk nekik.

Mi változik

A WordPress 6.9 óta (és így a 2026 áprilisában megjelent WordPress 6.9.4-es verziója óta) az alapcsapat és az ökoszisztéma Gutenberg Egyre erőteljesebben erőltetik azt az ötletet, ami már régóta kering a kiadók és a csapatok között: „Az egyének felemelése” Ez nem egy marketingszlogen, hanem egy termékirány. Konkrétan, olyan primitívek és minták megjelenését (vagy stabilizálódását) látjuk, amelyek lehetővé teszik számunkra, hogy identitások elismerése, bemutatása és kezelése (szerzők, társszerzők, szerkesztők, fordítók, vendégek) anélkül, hogy a klasszikus anti-mintákba esnénk: megosztott fiókok, túlságosan tág „Szerzői” szerepkörök vagy közvetlenül a …-ba író bővítmények post_author biztosítékok nélkül.

Ez a mozgalom három olyan változási területet jelent, amelyeket a 2025–2026-os projektekben láttam kibontakozni:

modellezés : külön a „megjelenített személy” és a „szerkesztési jogokkal rendelkező WordPress-fiók”.
Felhasználói felület / Szerkesztő : az identitáskiválasztás/megjelenítés egységesebbé tétele a blokkszerkesztőben (beleértve az FSE sablonokat is).
API / Interop : szabványosítsa, hogyan olvassák és jelenítik meg a témák és bővítmények ezt az információt (kerülje a megvalósítások hibáit).

A hivatalos forrásokkal kapcsolatban tartsa kéznél a következőket:

Fejlesztői hírek (fejlesztői jegyzetek alapjai) a „mag” változásaihoz.
Gutenberg kiadások a szerkesztőben gyakran korábban végrehajtott változtatásokhoz.
Trac WordPress Core a jegyek nyomon követéséhez (keresés kulcsszavak alapján: „szerző”, „felhasználó”, „byline”, „profil”).

Éberségi pont Az „Egyének Felemelése” egy átfogó téma. Nincs egyetlen „hivatalos” Trac hibajegy, amely mindent lefedne. A gyakorlatban a verziók (alapverzió és Gutenberg) között olyan változásokkal fogsz találkozni, amelyek a szerzőket, a profilok megjelenítését és az engedélyeket érintik. Tanácsom: kezeld úgy, mint egy… adatmodell-migráció és nem „interfész opcióként”.

Gyors összefoglaló

Objektív : személyek kiemelése (szerző, életrajz, hálózatok, szerkesztői szerepkör) sans Adj nekik egy alapértelmezett admin/szerzői fiókot.
Betonváltozás : Kerüljük a túlterhelést post_author; átmegyünk meta (poszt meta) vagy egy taxonómia „személy”, ellenőrzött fordítással.
Bloggereknek : társszerzők, vendégek, dedikált szerzői profilok, jobb következetesség az FSE-sablonokban.
Fejlesztőknek szükség van egy szerződés (belső API) a kreditek olvasásához/írásához, valamint a biztonságos szerkesztéshez (képességek + nonces).
Fő kockázat : átirányítások és kanonikus stratégia nélküli migráció esetén a SEO/szerzői archívumok nem működnek.
Csinálni : szabványosítsd a modelledet (személyek vs. fiókok), adj hozzá egy megjelenítési réteget, és teszteld gyorsítótárral + oldalépítővel.

Előtte/utána a kódban

Az „előtte”, amit leggyakrabban a köztes WordPress oldalakon látok: eltereljük post_author vagy csak azért hozunk létre WordPress fiókokat, hogy megjelenítsünk egy nevet.

Előtte (antiminta): erő `post_author` egy vendégszerző számára

Egyszerűnek tűnik, de összekevered a megjelenített identitást és jogosultságokat. Ráadásul mellékhatásoknak teszed ki magad (szerzői archívumok, REST API, jogosultságok, értesítések).

<?php
/**
 * Anti-pattern : modifier l'auteur WordPress "réel" pour gérer un auteur invité.
 * Problèmes : permissions, archives auteur, audit, SEO, confusion dans l'admin.
 */
add_action('save_post', function ($post_id, $post, $update) {
    // Mauvais : pas de nonce, pas de capability, et déclenché sur autosave/révisions
    if (wp_is_post_revision($post_id) || wp_is_post_autosave($post_id)) {
        return;
    }

    // Exemple : on force l'auteur à l'utilisateur ID 2 (compte "Invité")
    wp_update_post([
        'ID'          => $post_id,
        'post_author' => 2,
    ]);
}, 10, 3);
?>

Utána (minta: „Egyének támogatása”): külön „kiadói fiók” és „jóváírt személy”

Robusztus megközelítés: Ön tartja fenn post_author például egy „felelős WordPress fiók” (audit, jogosultságok), és a jóváírt felhasználókat egy erre a célra létrehozott struktúrában tárolod. Az egyszerűség és a kompatibilitás megőrzése érdekében gyakran ajánlom a következőket:

Rendszertan person (nyilvános vagy félig nyilvános) újrafelhasználható „profilokhoz”.
Bejegyzés metaadatai a kapcsolathoz (kifejezésazonosítók, sorrend, megjelenítési szerepkör).

Minimális példa: teremt egy „Emberek” taxonómia és egy meta mentése byline_person_ids (Kifejezésazonosítók tömbje) elérhetővé tette a REST-et a szerkesztő számára.

<?php
/**
 * Pattern : taxonomie "person" + post meta "byline_person_ids".
 * Compatible WordPress 6.9.4+ / PHP 8.1+.
 */
add_action('init', function () {
    register_taxonomy('person', ['post'], [
        'label'             => 'Personnes',
        'public'            => true,
        'show_in_rest'      => true, // Utile si vous voulez une UI dans l'éditeur via REST
        'show_admin_column' => true,
        'rewrite'           => ['slug' => 'personne'],
        'capabilities'      => [
            // Optionnel : vous pouvez affiner qui peut gérer les profils
            'manage_terms' => 'edit_users',
            'edit_terms'   => 'edit_users',
            'delete_terms' => 'edit_users',
            'assign_terms' => 'edit_posts',
        ],
    ]);
});

add_action('init', function () {
    register_post_meta('post', 'byline_person_ids', [
        'type'              => 'array',
        'single'            => true,
        'show_in_rest'      => [
            'schema' => [
                'type'  => 'array',
                'items' => ['type' => 'integer'],
            ],
        ],
        'auth_callback'     => function () {
            // Sécurité : seuls les utilisateurs pouvant éditer des posts peuvent modifier
            return current_user_can('edit_posts');
        },
        'sanitize_callback' => function ($value) {
            // On force un tableau d'entiers uniques
            if (!is_array($value)) {
                return [];
            }
            $value = array_map('absint', $value);
            $value = array_values(array_unique(array_filter($value)));
            return $value;
        },
        'default'           => [],
    ]);
});

/**
 * Rendu front : utiliser la byline si présente, sinon fallback sur l'auteur WP.
 */
function bpcab_get_byline_html(int $post_id): string {
    $person_ids = get_post_meta($post_id, 'byline_person_ids', true);
    if (!is_array($person_ids) || $person_ids === []) {
        $author_id = (int) get_post_field('post_author', $post_id);
        $name = get_the_author_meta('display_name', $author_id);
        return '<span class="byline">' . esc_html($name) . '</span>';
    }

    $names = [];
    foreach ($person_ids as $term_id) {
        $term = get_term($term_id, 'person');
        if ($term && !is_wp_error($term)) {
            $names[] = esc_html($term->name);
        }
    }

    if ($names === []) {
        return '';
    }

    return '<span class="byline">' . implode(', ', $names) . '</span>';
}
?>

Amit valójában megváltoztat

Könyvvizsgálat A szerkesztést végző WordPress fiók továbbra is nyomon követhető marad a következőn keresztül: post_author.
megtekintése : 1, 2, 5 embernek jóváírhatsz, és kezelhetsz egy rendelést.
Interop A REST-en keresztül elérhetővé teheted az adatokat a közzétevő számára, és felhasználhatod azokat egy tömb, egy mintát vagy egy oldalkészítőt.

Betonhatás

(Középhaladó) bloggereknek

Olyan rugalmasságot kapsz, amelyet a „tiszta” WordPress natívan soha nem kínált: társszerzőket, vendégeket, szerkesztői csapatot vagy akár egy fordítót is megjeleníthetsz anélkül, hogy 10 WordPress fiókot kellene létrehoznod. A többszerzős blogokon gyakran ez az a funkció, amely a leginkább csökkenti a súrlódást.

Gyakran láttam ezt a problémát olyan oldalakon, ahol a szerkesztői csapat megosztott „Szerkesztői” fiókot használ. Amikor ellenőrizni kell, hogy „ki mit változtatott”, már túl késő.

Fejlesztőknek és ügynökségeknek

Formalizálnod kell egy mini „szerződést”: hol találhatók a „személy” adatai, hogyan kezelik azokat, és hogyan adják vissza. Ha mindegyiket elhagyod csatlakoztat Ha megpróbálsz a saját utadba kezdeni (egyet a poszt metaadataiban, egyet a felhasználói metaadataiban, egyet a rövidkódokban), akkor kezelhetetlen sablonokat kapsz.

Meglévő bővítmények Azok, amelyek az „1 bejegyzés = 1 szerző” feltételezést feltételezik, következetlen információkat jeleníthetnek meg (például „Cikkek a szerzőtől”, navigációs elemek, JSON-LD).
Klasszikus témák : ki kell cserélned the_author()/get_the_author_meta() a sablonokban a „szerző” réteg szerint.
FSE témák (blokk témák) : a renderelést egy blokkon (egyéni) vagy egy, a meta-t felhasználó mintán keresztül kell kezelned.

Hatás a Divi 5-re, Elementorra, Avada-ra

Az oldalkészítők nem "értik" automatikusan a szerzői sablonodat. Azonban jól integrálódnak, ha stabil kimenetet biztosítasz nekik (rövid kód, blokk vagy widget).

Divi 5 A szerzőt egy „Kód” modulon vagy egy rövidkóddal ellátott „Szöveg” modulon keresztül jelenítheted meg. A Divi néha agresszívan gyorsítótáraz: a migráció után ürítsd ki a Divi és a szerver gyorsítótárát.
Elementor Használj „Rövid kód” widgetet vagy „Dinamikus címkét”, ha a meta-t leképezed. Megjegyzés: egyes témák és az Elementor gyorsítótárazza a sablont, ezért teszteld több bejegyzésen is.
Avada (fúziós építő) Egy „Code Block” vagy „Shortcode” elem elegendő. Az Avada saját SEO/Schema beállításokkal rendelkezik: ellenőrizze, hogy a szerző neve nem ismétli-e meg a szerzői jelölést.

Példa: egy stabil rövidkód, amely mindenhol használható (klasszikus szerkesztő, rövidkód blokk, Divi, Elementor, Avada).

<?php
/**
 * Shortcode [byline] pour afficher les personnes créditées.
 * Utile pour les page builders et les templates.
 */
add_shortcode('byline', function ($atts) {
    $post_id = get_the_ID();
    if (!$post_id) {
        return '';
    }
    return bpcab_get_byline_html((int) $post_id);
});
?>

Kockázatok, kompatibilitások és éberségi pontok

Újdonságok és változások

Új (megközelítés) : olyan adatszerkezeteket részesítünk előnyben, amelyek a WP-fiókoktól függetlenül „embereket” képviselnek.
Változás (gyakorlatok) : abbahagyjuk a „csalást” post_author és megosztott fiókok.
Eltörhet : szerzői archívumok, SEO (szerzői séma), „szerzői cikkek” widgetek, „A szerzőről” oldalak, és néha REST szűrők a headless oldalon.

SEO kockázatok (az igazi csapda)

Ha „WP szerző” modellről „személy taxonómia” modellre váltasz, elveszítheted a következőket:

szerzői archívum URL-címei (/author/nom/) ha indexelnék őket,
a téma/SEO bővítmény által generált JSON-LD (Szerző) jelölőkód,
belső linkek a szerzői oldalakhoz.

Azt javaslom, hogy egyértelműen döntsék el:

vagy te megőrizni a WP szerzői archívumában, és a „person” → „user” párosítást találjuk (összetettebb),
vagy te teremt „Személy” oldalak (taxonómia), és beilleszted 301 átirányítás a régi szerzői archívumból.

Gyorsítótár és renderelési kompatibilitás

Gyakori hiba: migrálsz, tesztelsz, és „semmi sem változik”. A probléma gyakran a gyorsítótárból ered.

oldal gyorsítótár (bővítmény / szerver),
eszköz gyorsítótár (CSS/JS),
gyorsítótár-készítő (Divi/Elementor/Avada),
Szerveroldali PHP OPcache.

Egy szerzői jogok migrálása után szisztematikusan törlöm a böngésző gyorsítótárát, a builder gyorsítótárát és a szerver gyorsítótárát, majd újra tesztelem privát böngészésben.

Biztonság és engedélyek

A kockázat egyszerű: ha kiteszed magad byline_person_ids REST-en keresztül anélkül auth_callback Szigorúan véve bárki megváltoztathatja a stáblistát. Egy médiaoldalon ez egy valós eset (aláírás-hamisítás).

Egy másik gyakori hiba: nem megfelelő kötőszó használata (pl. init vs rest_api_init) vagy túl későn regisztrálja a metaadatot. Eredmény: a metaadat nem jelenik meg a REST-ben, és a JS felhasználói felülete „semmit sem lát”.

Értékcsökkenési ütemterv (pragmatikus)

A WordPress magja nem „elavul” post_author (Ez nem fog megtörténni). Az értékcsökkenés főként funkcionális Egyre több eszköz (blokkok, minták, sablonok) feltételezi, hogy a megjelenített identitás nem csak egyetlen felhasználó lehet. Az „1 szerző = 1 felhasználó” kód továbbra is működni fog, de egyre kevésbé lesz összhangban a szerkesztői igényekkel.

Hogyan kell migrálni

Egy 6 lépéses migrációt javaslok, amely jól működik a meglévő webhelyeken, a termelés megzavarása nélkül. Az elv: hozzáadjuk az új sablont, kompatibilissé tesszük, majd fokozatosan átállunk.

1. lépés – Biztonsági mentés és tesztelési környezet

Klónozza az adatbázist, és töltse fel egy üzem előtti környezetbe.
Ellenőrizd a PHP 8.1+ verzióját (különben csak időt pazarolsz "buta" hibákra).
Fagyaszd le a bővítmények frissítéseit a migráció idejére (különben nem fogod tudni, hogy mi változott).

2. lépés – Hozza létre a „személy” taxonómiáját és a metaadatbázist

Használd újra a fenti „After” kódot, ideális esetben egy mini bővítményben (ahelyett, hogy… functions.php). Realisztikus hiba: a kód rossz helyre másolása (egy túl későn futó kódrészlet bővítmény, vagy egy szülőtéma a gyermektéma helyett).

Mini-bővítmény (ajánlott struktúra):

wp-content/plugins/byline-persons/byline-persons.php

3. lépés – Hozza létre az „embereket” a meglévő szerzőkből

Fokozatos migrációt is végrehajthat: hozzon létre egy „személy” kifejezést minden olyan felhasználóhoz, aki közzétett valamit, majd töltse ki a következőt: byline_person_ids ezzel a kifejezéssel.

WP-CLI példa (ajánlott). Figyelem: először kis tételen tesztelje.

<?php
/**
 * Commande WP-CLI : wp byline migrate
 * Crée des termes "person" pour les auteurs existants et renseigne byline_person_ids.
 * À placer dans un plugin mu-plugin ou un plugin standard chargé en CLI.
 */
if (defined('WP_CLI') && WP_CLI) {
    WP_CLI::add_command('byline migrate', function () {
        $args = [
            'post_type'      => 'post',
            'post_status'    => 'any',
            'posts_per_page' => -1,
            'fields'         => 'ids',
        ];
        $post_ids = get_posts($args);

        foreach ($post_ids as $post_id) {
            $post_id = (int) $post_id;

            // Si déjà migré, on saute
            $existing = get_post_meta($post_id, 'byline_person_ids', true);
            if (is_array($existing) && $existing !== []) {
                continue;
            }

            $author_id = (int) get_post_field('post_author', $post_id);
            if ($author_id <= 0) {
                continue;
            }

            $display = get_the_author_meta('display_name', $author_id);
            if (!$display) {
                $display = 'Auteur #' . $author_id;
            }

            // Crée ou récupère le terme "person" correspondant
            $slug = sanitize_title($display);
            $term = term_exists($slug, 'person');
            if (!$term) {
                $created = wp_insert_term($display, 'person', [
                    'slug' => $slug,
                ]);
                if (is_wp_error($created)) {
                    WP_CLI::warning("Impossible de créer la personne pour {$display} (post {$post_id})");
                    continue;
                }
                $term_id = (int) $created['term_id'];
            } else {
                $term_id = (int) (is_array($term) ? $term['term_id'] : $term);
            }

            update_post_meta($post_id, 'byline_person_ids', [$term_id]);
        }

        WP_CLI::success('Migration byline terminée.');
    });
}
?>

Gyakori buktatók:

Egy pontosvessző kihagyása a teljes WP-CLI működését tönkreteheti.
Indítás éles környezetben mentés nélkül.
Ne szűrj tartalomtípusokat (ezzel akaratlanul is migrálhatsz oldalakat/termékeket).

4. lépés – Váltsd a kijelzőt a téma megszakítása nélkül

Egy klasszikus témán cseréld le a szerzői megjelenítést a „byline” függvénnyel. Példa:

<?php
// Avant : the_author();
echo bpcab_get_byline_html(get_the_ID());
?>

Egy ESZA témában három reális lehetőséged van:

un egyéni blokk (tiszta, de hosszabb)
un minta rövidkóddal [byline] (gyors, elfogadható)
un renderelési horog ha a témád/vermed megengedi (témától függően változik).

5. lépés – A SEO/séma adaptálása

Ha SEO bővítményt használsz, ellenőrizd, hogyan generálódik szerző a sémában. Ha több szerzői jogot jelenít meg, de a séma továbbra is „egyetlen felhasználó” marad, akkor inkonzisztens jelet küld.

Nem adok itt „univerzális” kódot, mert az nagymértékben függ a SEO bővítménytől, de a listád stabil:

A megjelenített szerzői sor a sémajelölésnek felel meg.
a „személy” oldalakon (taxonómia) van egy title és egy megfelelő meta leírás,
Ha szerzői archívumokat irányítasz át, azt 301-es átirányítással tedd, ne 302-essel.

6. lépés – Ellenőrizze diagnosztikai táblázattal

tünet	Valószínű ok	igazolás	Megoldás
A szerző nem jelenik meg a szerkesztőben / REST-ben	A meta nincs regisztrálva a következővel: `show_in_rest` vagy túl későn töltődött be	GET `/wp-json/wp/v2/posts/<id>` és nézd `byline_person_ids`	Metaadatok mentése `init` (vagy korábban), ellenőrizze `show_in_rest` et `auth_callback`
A frontvonal változatlan marad	Gyorsítótár oldal/készítő	Privát böngészési módban tesztelés + bővítmény gyorsítótár ürítése + Divi/Elementor/Avada gyorsítótár	Töröld az összes gyorsítótárat, szükség esetén tiltsd le a CDN-t
500-as hiba a kódrészlet hozzáadása után	Rossz helyre másolt kód / PHP szintaxis	PHP naplók, Engedélyezés `WP_DEBUG_LOG` előkészítés alatt	Bővítményhez való hozzáadás, szintaxis javítása, PHP 8.1+ ellenőrzése
A szerzői archívumok már nem egyeznek	A „személy” szót jeleníti meg, de a linkek erre a személyre mutatnak: `/author/`	Szerzői hivatkozások és sablonok ellenőrzése	Hozz létre „személy” taxonómiai oldalakat és 301-es átirányításokat, vagy tartsd meg a felhasználói modellt
A közreműködő szerkesztheti a stáblistát.	Túlzott jogosultságok a meta/taxonómián	Tesztelés „Közreműködő” szerepkörrel	Megkeményedik `auth_callback`Tekintse át a taxonómiai lehetőségeket, adjon hozzá nonce-okat a felhasználói felülethez

Cselekedjünk most, vagy várjunk?

Ha az oldaladnak csak egy szerzője van, várhatsz. Nem sokat nyersz egy „személy” réteg hozzáadásával, ha nem fogod használni.

Ha webhelye a következő jellemzők közül legalább eggyel rendelkezik, tegyen lépéseket most (az előkészítés során):

gyakori társszerzők, vendégszerzők, szponzorált tartalmak meghatározott márkajelzéssel,
szerkesztői csapat, amely nem akar több WordPress fiókot létrehozni,
FSE újratervezés / átállás blokkos témára
audit szükséges (ki szerkesztette, illetve ki szerepel a forrásként).

Tapasztalataim szerint minél tovább vársz, annál több "kivétel" halmozódik fel (különböző aláírású bejegyzések, megosztott fiókok, specifikus SEO szabályok). A migráció ezután egy magas kockázatú SEO műveletté válik az egyszerű refaktorálás helyett.

Karbantartási tippek

Tesztelés minden WordPress kiadással (6.9.x → 6.10): szerkesztő + REST + front-end renderelés. A regressziók gyorsan láthatók a közzétett meta-ban.
Nem regressziós tesztek hozzáadása Ha CI-veremmel rendelkezik: legalább egy teszt, amely ellenőrzi, hogy byline_person_ids jelen van a REST-ben, és a renderelés nem üres.
Dokumentálja a belső szerződését (README): „A szerzőt itt olvassuk be, így módosítjuk.” Ez megakadályozza, hogy a fejlesztő máshol hozzáadjon egy második „szerző_neve” mezőt.
Teljesítményfigyelés : ha listákon (főoldal, kategóriák) megjeleníted a szerzőt, kerüld a get_term() Ciklus gyorsítótár nélkül. Használjon perzisztens objektumgyorsítótárat, ha lehetséges.
Kerüld a túlságosan globális horgokat (Pl. the_content) aláírás befecskendezéséhez: ez gyakran megzavarja a buildereket és a kivonatokat. Használjon inkább sablont vagy dedikált blokkot.

Egyszerű optimalizálás, ha a szerzőt megjeleníted a ciklusokban: töltsd be előre a kifejezéseket és korlátozd a lekérdezéseket.

<?php
/**
 * Exemple simple : réduire les appels get_term() en boucle.
 * Ici, on met en cache (statique) les termes déjà chargés.
 */
function bpcab_get_person_term_name_cached(int $term_id): ?string {
    static $cache = [];

    if (array_key_exists($term_id, $cache)) {
        return $cache[$term_id];
    }

    $term = get_term($term_id, 'person');
    if (!$term || is_wp_error($term)) {
        $cache[$term_id] = null;
        return null;
    }

    $cache[$term_id] = $term->name;
    return $cache[$term_id];
}
?>

erőforrás

FAQ

A „Személyesek támogatása” funkció a WordPress 6.9.4-es verziójának része?

Nem, egyetlen gomb sincs. Ez egy olyan irány, ami elszórt változtatásokon (szerkesztő, minták, REST, sablonok) és mindenekelőtt a legjobb gyakorlatokon keresztül valósul meg: a megjelenített identitás és a WordPress fiók szétválasztásán.

Feltétlenül létre kell hoznom egy „személy” taxonómiát?

Nem. Használhatsz egyéni bejegyzéstípust is, például „személy”. A taxonómia gyakran egyszerűbb a könnyű profilok esetében (név + slug + néhány metacímke). Az egyéni bejegyzéstípusok akkor válnak érdekessé, ha gazdag mezőkkel, blokkokkal, kapcsolatokkal és összetett profiloldallal rendelkezel.

Miért nem csak WordPress felhasználókat használsz?

Mivel az „aláírás megjelenítése” és a „szerkesztési jogok megadása” két különböző igény. A vendégfelhasználók létrehozása növeli a támadási felületet (nem használt fiókok, jelszavak, alaphelyzetbe állítások) és bonyolítja az auditálást.

Ez kompatibilis az FSE témákkal?

Igen, de el kell döntened, hogyan jeleníted meg a szerzőt: rövidkód, egyéni blokk vagy minta. A rövidkód a leggyorsabb, az egyéni blokk a legtisztább hosszú távon.

A SEO bővítményem már tartalmazza a szerzőt a sémában. Mit tegyek?

Ellenőrizd az egységességet. Ha a szerző több személyt jelenít meg, de a séma csak egyet, akkor eltérés lesz. A SEO bővítményedtől függően szűrheted a sémát, vagy kiválaszthatsz egyetlen „elsődleges” személyt. Teszteld ezt a bővített találatok tesztelőeszközében.

Feltöri az archívumot `/author/` ?

Nem automatikusan, de valószínűleg „személyes” oldalakat szeretnél használni. Ha a szerzői archívumaid indexelve vannak, tervezz 301-es átirányításokat és kanonikus címkestratégiát.

Nem látom a metacímkét a szerkesztőben. Miért?

A leggyakoribb eset: register_post_meta() nem rendelkezik show_in_rest, vagy aauth_callback Ez hamis értéket ad vissza a szerepkörödre, vagy a kódod túl későn töltődött be. Ellenőrizd a poszt REST válaszát.

Tárolhatom az emberek azonosítóit egy ACF mezőben?

Igen, de légy óvatos az interopcióval. Ha az ACF más struktúrát tárol, akkor egy adaptációs réteget kell fenntartanod. Az oldalépítőket tartalmazó stackeken egy szabványos poszt meta (egész számok tömbje) gyakran egyszerűbb mindenhol felhasználni.

Mi a leggyakoribb hiba a költözés során?

A megjelenítés módosítása egy helyen, de egy másik elhanyagolása (pl. egyetlen sablon rendben van, de cikkkártyák, widgetek, Open Graph, JSON-LD nem). Készítsen egy listát az összes helyről, ahol a szerző megjelenik.

Újra kell generálnom a permalinkeket?

Ha hozzáadsz egy átírási szabályt a „személy” taxonómiához, akkor igen: menj a Beállítások → Állandó linkek menüpontra, és mentsd el. Ez egy klasszikus probléma: 404-es hibát dob, egyszerűen azért, mert a szabályok nem egyértelműek.