تقدير الأفراد داخل فريق ووردبريس

إذا سبق لك أن تعاملت مع مساهم "غير مرئي" (مؤلف خفي، مترجم غير مذكور اسمه، محرر لا يريد حسابًا) وانتهى بك الأمر إلى تجميع أدوار أو حسابات مشتركة، WordPress لقد تغير الوضع في نقطة محددة واحدة: الطريقة التي... يسلط الضوء الأشخاص دون منحهم صلاحيات أكثر من اللازم.

ما التغييرات

منذ إصدار ووردبريس 6.9 (وبالتالي يصبح ذا صلة كاملة بإصدار ووردبريس 6.9.4 في أبريل 2026)، الفريق الأساسي والنظام البيئي غوتبورغ إنهم يضغطون بقوة أكبر على فكرة كانت متداولة منذ فترة طويلة بين الناشرين والفرق: "الارتقاء بالأفراد" هذا ليس شعارًا تسويقيًا، بل هو توجه للمنتج. بعبارة أخرى، نرى ظهور (أو استقرار) العناصر والأنماط الأولية التي تسمح لنا بـ توثيق الهويات وعرضها وإدارتها (المؤلفون، والمؤلفون المشاركون، والمحررون، والمترجمون، والضيوف) دون الوقوع في الأنماط السلبية الكلاسيكية: الحسابات المشتركة، أو أدوار "المؤلف" الواسعة للغاية، أو الإضافات التي تكتب مباشرة في post_author بدون ضمانات.

يترجم هذا التحرك إلى ثلاثة مجالات تغيير رأيتها تظهر في مشاريع الفترة 2025-2026:

تصميم : فصل "الشخص المعروض" و "حساب ووردبريس الذي لديه حقوق التحرير".
واجهة المستخدم / المحرر : اجعل اختيار/عرض الهوية أكثر اتساقًا في محرر الكتل (بما في ذلك قوالب FSE).
واجهة برمجة التطبيقات / التوافق : توحيد طريقة قراءة وعرض هذه المعلومات في القوالب والإضافات (تجنب تعطيل التطبيقات).

فيما يتعلق بالمصادر الرسمية، احتفظ بما يلي في متناول يدك:

أخبار المطورين (ملاحظات المطورين الأساسية) بالنسبة للتغييرات "الأساسية".
إطلاق غوتنبرغ بالنسبة للتغييرات التي تحدث غالبًا في وقت سابق في المحرر.
Trac WordPress Core لتتبع التذاكر (ابحث باستخدام الكلمات الرئيسية "المؤلف"، "المستخدم"، "السطر"، "الملف الشخصي").

نقطة اليقظة يُعدّ "الارتقاء بالأفراد" موضوعًا شاملًا. لا توجد تذكرة "رسمية" واحدة في نظام Trac تُغطي كل شيء. عمليًا، ستواجه تغييرات بين الإصدارات (الأساسية وGutenberg) تؤثر على المؤلفين، وعرض الملف الشخصي، والصلاحيات. نصيحتي: تعامل مع الأمر على أنه... ترحيل نموذج البيانات وليس كـ "خيار واجهة".

ملخص سريع

هدف : لتسليط الضوء على الأفراد (اسم الكاتب، السيرة الذاتية، الشبكات، الدور التحريري) بلا امنحهم حسابًا افتراضيًا للمسؤول/المؤلف.
تغيير ملموس نتجنب التحميل الزائد post_authorنمر هدف (بعد الميتا) أو أ taxonomie "شخص"، مع عرض مُتحكم به.
للمدونين : المؤلفون المشاركون، والضيوف، وملفات تعريف المؤلفين المخصصة، وتحسين التناسق في قوالب FSE.
للمطورين :احتاج واحد عقد (واجهة برمجة التطبيقات الداخلية) لقراءة/كتابة الاعتمادات، ولتأمين التحرير (القدرات + الأرقام العشوائية).
الخطر الرئيسي : سيؤدي ذلك إلى تعطيل أرشيفات تحسين محركات البحث/المؤلفين إذا قمت بالترحيل بدون عمليات إعادة توجيه وبدون استراتيجية أساسية.
للقيام به : قم بتوحيد نموذجك (الأشخاص مقابل الحسابات)، وأضف طبقة عرض، واختبر باستخدام ذاكرة التخزين المؤقت + أداة إنشاء الصفحات.

قبل/بعد في الكود

"قبل" الذي أراه غالبًا على مواقع ووردبريس المتوسطة: نحن نحول post_author أو نقوم بإنشاء حسابات ووردبريس لمجرد عرض اسم.

قبل (نمط مضاد): فرض `post_author` لمؤلف ضيف

يبدو الأمر بسيطاً، لكنك تخلط بين الهوية المعروضة والأذونات. كما أنك تعرض نفسك لآثار جانبية (أرشيفات المؤلفين، واجهة برمجة تطبيقات REST، الأذونات، الإشعارات).

<?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);
?>

بعد (نمط "الارتقاء بالأفراد"): افصل بين "حساب الناشر" و"الشخص المذكور اسمه"

نهج قوي: أنت تحافظ post_author مثل "حساب ووردبريس مسؤول" (يخضع للتدقيق والصلاحيات)، وتخزّن بيانات المستخدمين المعتمدين في بنية مخصصة. ولتبسيط الأمور وضمان التوافق، أنصح عادةً بما يلي:

التصنيف person (عام أو شبه عام) لـ "الملفات الشخصية" القابلة لإعادة الاستخدام.
ما بعد الميتا بالنسبة للعلاقة (معرفات المصطلحات، الترتيب، دور العرض).

مثال بسيط: خلق تصنيف "الأشخاص" وحفظ البيانات الوصفية byline_person_ids (مصفوفة من معرفات المصطلحات) تعرض واجهة REST للمحرر.

<?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>';
}
?>

ما الذي يتغير حقًا؟

إفحص يظل حساب ووردبريس الذي يقوم بالتعديل قابلاً للتتبع عبر post_author.
الاطلاع على البيانات الشخصية يمكنك إضافة رصيد إلى حساب شخص واحد أو شخصين أو خمسة أشخاص، وإدارة الطلب.
إمكانية التشغيل المتداخل يمكنك عرض البيانات للناشر عبر REST، واستخدامها في كتلة، نمط، أو أداة إنشاء صفحات.

تأثير ملموس

للمدونين (المتوسطين)

ستحصل على مرونة لم يوفرها ووردبريس "الخالص" بشكل أصلي: عرض المؤلفين المشاركين، والضيوف، وفريق التحرير، أو حتى المترجم، دون الحاجة إلى إنشاء عشرة حسابات ووردبريس. في المدونات متعددة المؤلفين، تُعد هذه الميزة غالبًا الأكثر فعالية في تقليل التعقيدات.

كثيراً ما أرى هذه المشكلة في المواقع التي يستخدم فيها فريق التحرير حساباً مشتركاً باسم "التحرير". عندما تحتاج إلى مراجعة "من قام بالتغييرات؟"، يكون الوقت قد فات.

للمطورين والوكالات

أنت بحاجة إلى صياغة "عقد" مصغر رسمي: أين توجد بيانات "الشخص"، وكيف تتم إدارتها، وكيف يتم إرجاعها. إذا تركت كل المساعد إذا حاولت القيام بأمرك الخاص (واحد في بيانات المنشور، وواحد في بيانات المستخدم، وواحد في الرموز المختصرة)، فسوف ينتهي بك الأمر بقوالب يصعب إدارتها.

الإضافات الموجودة : أولئك الذين يفترضون أن "منشور واحد = مؤلف واحد" قد يعرضون معلومات غير متناسقة (أدوات "مقالات من تأليف المؤلف"، مسارات التنقل، JSON-LD).
المواضيع الكلاسيكية ستحتاج إلى استبدال the_author()/get_the_author_meta() في قوالبك من خلال طبقة "السطر الأول".
سمات FSE (سمات الكتل) ستحتاج إلى إدارة عملية العرض من خلال كتلة (مخصصة) أو من خلال نمط يستهلك البيانات الوصفية.

التأثير على Divi 5، Elementor، Avada

لا تفهم أدوات إنشاء الصفحات قالب اسم المستخدم الخاص بك تلقائيًا. ومع ذلك، فإنها تتكامل بشكل جيد إذا زودتها بمخرج ثابت (رمز مختصر، أو كتلة، أو أداة).

ديفي 5 يمكنك عرض اسم المؤلف عبر وحدة "البرمجة" أو وحدة "النص" باستخدام رمز مختصر. قد يقوم Divi أحيانًا بتخزين البيانات مؤقتًا بشكل مكثف: بعد التحديث، امسح ذاكرة التخزين المؤقت لـ Divi وذاكرة التخزين المؤقت للخادم.
Elementor استخدم أداة "الرمز المختصر" أو "الوسم الديناميكي" إذا كنت تقوم بربط البيانات الوصفية. ملاحظة: بعض القوالب وElementor تخزن القالب مؤقتًا، لذا اختبره على عدة منشورات.
أفادا (منشئ الاندماج) يكفي استخدام عنصر "كتلة برمجية" أو "رمز مختصر". لدى Avada خيارات تحسين محركات البحث/البيانات المنظمة الخاصة بها: تأكد من أن اسم المؤلف لا يكرر بيانات المؤلف.

مثال: رمز مختصر مستقر، قابل للاستخدام في كل مكان (المحرر الكلاسيكي، كتلة الرموز المختصرة، 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);
});
?>

المخاطر، والتوافقات، ونقاط اليقظة

ما الجديد مقابل ما يتغير

نهج جديد نحن نفضل هياكل البيانات التي تمثل "الأشخاص" بشكل مستقل عن حسابات ووردبريس.
التغيير (الممارسات) نتوقف عن "الغش" مع post_author والحسابات المشتركة.
يمكن أن ينكسر : أرشيفات المؤلفين، وتحسين محركات البحث (مخطط المؤلفين)، وأدوات "مقالات المؤلفين"، وصفحات "حول المؤلف"، وأحيانًا مرشحات REST على الجانب غير الرأسي.

مخاطر تحسين محركات البحث (الفخ الحقيقي)

إذا قمت بالترقية من نموذج "مؤلف ووردبريس" إلى نموذج "تصنيف الأشخاص"، فقد تفقد ما يلي:

روابط أرشيف المؤلف (/author/nom/) إذا كانت مفهرسة،
ترميز JSON-LD (المؤلف) الذي تم إنشاؤه بواسطة قالبك/إضافة تحسين محركات البحث،
روابط داخلية لصفحات المؤلفين.

أنصح باتخاذ القرار بشكل صريح:

إما أنت يحفظ أرشيفات مؤلفي ووردبريس، وتطابق "شخص" → "مستخدم" (أكثر تعقيدًا)،
إما أنت يخلق صفحات "الشخص" (التصنيف) وتقوم بإدخالها 301 عمليات إعادة التوجيه من أرشيفات المؤلفين القدامى.

توافق التخزين المؤقت والعرض

خطأ شائع: تقوم بالترحيل، وتختبر، و"لا شيء يتغير". غالباً ما تنشأ المشكلة من ذاكرة التخزين المؤقت.

ذاكرة التخزين المؤقت للصفحة (المكون الإضافي / الخادم)،
ذاكرة التخزين المؤقت للأصول (CSS/JS)،
منشئ ذاكرة التخزين المؤقت (Divi/Elementor/Avada)،
OPcache PHP من جانب الخادم.

بعد عملية نقل البيانات، أقوم بمسح ذاكرة التخزين المؤقت للمتصفح + ذاكرة التخزين المؤقت للمنشئ + ذاكرة التخزين المؤقت للخادم بشكل منهجي، ثم أعيد الاختبار في وضع التصفح الخاص.

الأمان والصلاحيات

الخطر بسيط: إذا كشفت byline_person_ids عبر REST بدون auth_callback من الناحية القانونية، يمكن لأي شخص تغيير بيانات الاعتماد. أما في موقع إعلامي، فهذا يُعد حادثة حقيقية (تزوير التوقيع).

خطأ شائع آخر: استخدام خطاف غير مناسب (مثلاً: init vs rest_api_initأو تسجيل البيانات الوصفية متأخرًا جدًا. النتيجة: لا تظهر البيانات الوصفية في REST، ولا ترى واجهة المستخدم الخاصة بك المكتوبة بلغة جافا سكريبت أي شيء.

الجدول الزمني للاستهلاك (عملي)

لا يقوم نظام ووردبريس الأساسي بـ "إيقاف" الميزات. post_author (لن يحدث ذلك). الاستهلاك هو في الأساس وظيفي تعتمد العديد من الأدوات (كالكتل والأنماط والقوالب) على افتراض أن الهوية المعروضة قد تكون أكثر من مجرد مستخدم واحد. سيظل رمز "مؤلف واحد = مستخدم واحد" يعمل، ولكنه سيصبح أقل توافقًا مع احتياجات التحرير.

كيفية الترحيل

أقترح عملية نقل بيانات من ست خطوات تُناسب المواقع الحالية دون التأثير على الإنتاج. المبدأ: نضيف القالب الجديد، ونجعله متوافقًا، ثم ننتقل إليه تدريجيًا.

الخطوة 1 - النسخ الاحتياطي وبيئة الاختبار

استنسخ قاعدة البيانات وقم بتحميلها إلى بيئة ما قبل الإنتاج.
تحقق من PHP 8.1+ (وإلا ستضيع وقتك على أخطاء "تافهة").
قم بتجميد تحديثات المكونات الإضافية أثناء عملية النقل (وإلا فلن تعرف ما الذي تغير).

الخطوة الثانية - إنشاء تصنيف "الشخص" والبيانات الوصفية

أعد استخدام كود "After" المذكور أعلاه، ويفضل أن يكون ذلك في إضافة صغيرة (بدلاً من functions.php). خطأ واقعي: نسخ الكود إلى المكان الخطأ (إضافة مقتطفات تعمل متأخرة جدًا، أو قالب رئيسي بدلاً من القالب الفرعي).

إضافة صغيرة (البنية الموصى بها):

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

الخطوة 3 - إنشاء "الأشخاص" من المؤلفين الحاليين

يمكنك إجراء عملية نقل تدريجية: أنشئ مصطلح "شخص" لكل مستخدم قام بالنشر، ثم قم بتعبئته byline_person_ids بهذا المصطلح.

مثال على واجهة سطر الأوامر لـ WP (موصى بها). تنبيه: اختبرها أولاً على مجموعة صغيرة.

<?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.');
    });
}
?>

الأخطاء الشائعة:

نسيان الفاصلة المنقوطة قد يؤدي إلى تعطيل WP-CLI بالكامل.
ابدأ الإنتاج دون حفظ البيانات.
لا تقم بتصفية أنواع المحتوى (ستقوم أيضًا بنقل الصفحات/المنتجات عن غير قصد).

الخطوة 4 - تبديل الشاشة دون الإخلال بالنمط

في قالب كلاسيكي، استبدل عرض اسم المؤلف بوظيفة "اسم الكاتب". مثال:

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

فيما يتعلق بموضوع ESF، لديك ثلاثة خيارات واقعية:

un كتلة مخصصة (نظيف، لكن أطول)
un النمط باستخدام رمز مختصر [byline] (سريع، مقبول)
un خطاف الرسم إذا كان قالبك/مجموعتك يسمح بذلك (يختلف ذلك حسب القالب).

الخطوة 5 - تعديل تحسين محركات البحث/البيانات المنظمة

إذا كنت تستخدم إضافة لتحسين محركات البحث، فتحقق من كيفية توليدها للنتائج. المؤلفة في المخطط. إذا قمت بعرض سطر متعدد ولكن المخطط ظل "مستخدم واحد"، فأنت ترسل إشارة غير متسقة.

لا أقدم هنا رمزًا "عامًا" لأنه يعتمد بشكل كبير على إضافة تحسين محركات البحث، لكن قائمة التحقق الخاصة بك ثابتة:

السطر الظاهر في الصورة يطابق ترميز المخطط.
تحتوي صفحات "الشخص" (التصنيف) على title ووصف ميتا مناسب،
إذا كنت تقوم بإعادة توجيه أرشيفات المؤلفين، فافعل ذلك باستخدام إعادة توجيه 301، وليس إعادة توجيه 302.

الخطوة 6 - التحقق باستخدام مخطط تشخيصي

عرض	السبب المحتمل	التحقق	الحلول
لا يظهر اسم الكاتب في محرر / REST	ميتا غير مسجلة لدى `show_in_rest` أو التحميل متأخرًا جدًا	للحصول على `/wp-json/wp/v2/posts/<id>` وانظر `byline_person_ids`	احفظ البيانات الوصفية على `init` (أو قبل ذلك)، تحقق `show_in_rest` et `auth_callback`
لم يطرأ أي تغيير على خط المواجهة.	صفحة التخزين المؤقت / منشئ	اختبر في وضع التصفح الخاص + امسح ذاكرة التخزين المؤقت للملحقات + ذاكرة التخزين المؤقت لـ Divi/Elementor/Avada	قم بمسح جميع ذاكرات التخزين المؤقت، وقم بتعطيل شبكة توصيل المحتوى (CDN) إذا لزم الأمر.
خطأ 500 بعد إضافة المقتطف البرمجي	تم نسخ الكود إلى المكان الخطأ / بناء جملة PHP	تفعيل سجلات PHP `WP_DEBUG_LOG` في مرحلة ما قبل الإنتاج	أضف إلى الملحق، وصحح الصياغة، وتأكد من توافقه مع PHP 8.1+
لم تعد أرشيفات المؤلفين متطابقة	أنت تعرض كلمة "شخص" ولكن الروابط تشير إلى `/author/`	افحص روابط ونماذج أسماء المؤلفين	أنشئ صفحات تصنيف "شخص" وعمليات إعادة توجيه 301، أو احتفظ بنموذج المستخدم
بإمكان المساهم تعديل بيانات المساهمين.	صلاحيات مفرطة على التصنيف/التصنيف الوصفي	الاختبار باستخدام دور "المساهم"	تصلب `auth_callback`راجع إمكانيات التصنيف، وأضف قيمًا عشوائية إلى واجهة المستخدم.

هل نتصرف الآن أم ننتظر؟

إذا كان لموقعك مؤلف واحد فقط، يمكنك الانتظار. لن تستفيد كثيراً من إضافة طبقة "شخصية" إذا لم تكن ستستخدمها.

إذا كان موقعك الإلكتروني يحتوي على واحدة على الأقل من هذه الخصائص، فبادر باتخاذ الإجراءات اللازمة الآن (في مرحلة ما قبل الإنتاج):

مؤلفون مشاركون بشكل متكرر، ومؤلفون ضيوف، ومحتوى دعائي يحمل علامة تجارية محددة،
فريق التحرير الذي لا يرغب في إنشاء حسابات ووردبريس متعددة،
إعادة تصميم FSE / الانتقال إلى تصميم الكتلة
يلزم إجراء تدقيق (من قام بالتحرير مقابل من تم ذكر اسمه).

بحسب تجربتي، كلما طال الانتظار، زادت "الاستثناءات" المتراكمة (مثل المنشورات الموقعة بشكل مختلف، والحسابات المشتركة، وقواعد تحسين محركات البحث الخاصة). عندها تتحول عملية النقل إلى عملية تحسين محركات بحث عالية المخاطر بدلاً من مجرد إعادة هيكلة بسيطة.

نصائح الصيانة

اختبر مع كل إصدار من ووردبريس (6.9.x → 6.10): محرر + REST + عرض الواجهة الأمامية. تظهر الأخطاء بسرعة في البيانات الوصفية المعروضة.
أضف اختبارات عدم الانحدار إذا كان لديك نظام تكامل مستمر (CI): كحد أدنى، اختبار يتحقق من ذلك byline_person_ids موجود في REST والعرض ليس فارغًا.
قم بتوثيق عقدك الداخلي (README): "يتم قراءة اسم المؤلف هنا، ويتم تعديله على هذا النحو." هذا يمنع المطور من إضافة حقل "اسم المؤلف" الثاني في مكان آخر.
عالمه فى أمرأة إذا كنت تعرض اسم الكاتب في القوائم (الصفحة الرئيسية، التصنيفات)، فتجنب get_term() قم بالتكرار بدون تخزين مؤقت. استخدم ذاكرة تخزين مؤقتة للكائنات الدائمة إن أمكن.
تجنب استخدام الخطافات العالمية بشكل مفرط (على سبيل المثال the_content) لإدخال توقيع: غالبًا ما يؤدي ذلك إلى تعطيل أدوات البناء والاستخراج. يُفضل استخدام قالب أو كتلة مخصصة.

تحسين بسيط إذا كنت تعرض اسم المؤلف في الحلقات: قم بتحميل المصطلحات مسبقًا وحدد عدد الاستعلامات.

<?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];
}
?>

الموارد

الأسئلة الشائعة

هل ميزة "رفع مستوى الأفراد" موجودة في ووردبريس 6.9.4؟

لا، ليس زرًا واحدًا. إنه اتجاه يتجسد من خلال تغييرات متفرقة (المحرر، والأنماط، وREST، والقوالب) وقبل كل شيء من خلال أفضل الممارسات: فصل الهوية المعروضة وحساب ووردبريس.

هل أنا بحاجة ماسة إلى إنشاء تصنيف "شخصي"؟

لا، يمكنك أيضًا استخدام نوع منشور مخصص باسم "شخص". غالبًا ما يكون التصنيف أبسط للملفات الشخصية البسيطة (الاسم + الرابط + بعض البيانات الوصفية). تصبح أنواع المنشورات المخصصة مثيرة للاهتمام إذا كان لديك حقول غنية، ومجموعات، وعلاقات، وصفحة ملف شخصي معقدة.

لماذا لا يتم استخدام مستخدمي ووردبريس فقط؟

لأن "عرض التوقيع" و"منح حقوق التحرير" حاجتان مختلفتان. إنشاء حسابات مستخدمين ضيوف يزيد من احتمالية التعرض للهجمات (الحسابات غير المستخدمة، وكلمات المرور، وعمليات إعادة التعيين) ويعقد عملية التدقيق.

هل هذا متوافق مع سمات FSE؟

نعم، ولكن عليك تحديد طريقة عرض اسم الكاتب: باستخدام رمز مختصر، أو كتلة مخصصة، أو نمط. الرمز المختصر هو الأسرع، بينما الكتلة المخصصة هي الأفضل على المدى الطويل.

تتضمن إضافة تحسين محركات البحث الخاصة بي بالفعل اسم المؤلف في بيانات الموقع. ماذا عليّ أن أفعل؟

تحقق من التناسق. إذا كان اسم المؤلف يظهر عدة أشخاص، بينما لا يظهر في البيانات المنظمة سوى شخص واحد، فسيكون هناك تناقض. اعتمادًا على إضافة تحسين محركات البحث التي تستخدمها، قد تتمكن من تصفية البيانات المنظمة أو تحديد شخص "رئيسي" واحد. اختبر ذلك في أداة اختبار النتائج المنسقة.

إنه يدمر الأرشيفات `/author/` ?

ليس تلقائيًا، ولكنك على الأرجح ستفضل صفحات "الشخص" بدلاً من ذلك. إذا كانت أرشيفات مؤلفيك مفهرسة، فخطط لعمليات إعادة التوجيه 301 واستراتيجية الوسوم الأساسية.

لا أستطيع رؤية الوسم الوصفي في المحرر. لماذا؟

الحالة الأكثر شيوعاً: register_post_meta() ليس show_in_rest، أو الauth_callback هذا يُرجع قيمة خاطئة لدورك، أو أن الكود الخاص بك قد تم تحميله متأخرًا جدًا. تحقق من استجابة REST لطلب POST.

هل يمكنني تخزين معرفات الأشخاص في حقل ACF بدلاً من ذلك؟

نعم، ولكن انتبه للتوافق بين الأنظمة. إذا كان ACF يخزن بنية مختلفة، فستحتاج إلى طبقة تكيف. في الأنظمة التي تستخدم أدوات إنشاء الصفحات، غالبًا ما يكون استخدام بيانات تعريف المنشور القياسية (مصفوفة من الأعداد الصحيحة) أسهل في كل مكان.

ما هو الخطأ الأكثر شيوعًا أثناء عملية الترحيل؟

تعديل العرض في مكان واحد مع إهمال مكان آخر (على سبيل المثال، قالب واحد مقبول، لكن بطاقات المقالات، والأدوات، وOpen Graph، وJSON-LD غير مقبولة). أنشئ قائمة بجميع الأماكن التي يظهر فيها اسم المؤلف.

هل أحتاج إلى إعادة إنشاء الروابط الدائمة؟

إذا أضفت قاعدة إعادة كتابة لتصنيف "الشخص"، نعم: انتقل إلى الإعدادات ← الروابط الدائمة واحفظها. إنها مشكلة شائعة: إذ يُظهر خطأ 404 ببساطة لأن القواعد لم تُحدّث بعد.