اعتقدت أن الترحيل كان يجب أن ينقل إعدادات @Richie من المكون إلى الإعدادات الأساسية، وكان يجب أيضًا أن يقوم بتمكين إعداد الموقع المخفي show_additional_about_groups. أحد الأسباب التي قد تفسر عدم نجاح ذلك هو أنه قام بتغيير الاسم، لأن هذا قابل للتنفيذ بسهولة في الواجهة.
هل هناك سبب لكون الترحيل يعتمد فقط على الاسم بدلاً من التحقق أيضًا من وجود مكون حيث يتطابق remote_url من جدول remote_themes؟ من شأن ذلك أن يلتقط المكونات التي أعيدت تسميتها طالما أنها مثبتة من المستودع الرسمي.
إعداد الموقع المخفي، الذي لم يتم تمكينه لأن الترحيل لم يحدث، منع النواة من إظهار المجموعات، وبدلاً من ذلك، استمر المكون في إظهار المجموعات. لكن الإشعار العام من المكون أخبره بحذف المكون. ثم لم تعرض النواة المجموعات أيضًا لأن show_additional_about_groups كان لا يزال معطلاً، ولم يكن من الممكن تمكينه بسهولة.
لذلك إذا لم ينجح الترحيل التلقائي، فكيف يقوم المسؤولون بالترحيل يدويًا؟ نسخ التكوين ليس هو المشكلة. ولكن متى ينتقلون بين عرض المكون للمجموعات وعرض النواة للمجموعات دون الحاجة إلى تمكين الإعداد المخفي؟
ربما كان من الأفضل تمكين show_additional_about_groups للجميع أو إظهاره في الواجهة قبل إضافة إشعار إلى المكون بأنه يجب حذفه. ثم كان الترحيل اليدوي سينجح، وكانت النواة ستعرض المجموعات بعد ذلك، لذلك لن يترك حذف المكون المسؤولين بدون أي مجموعات في صفحة “حول”.
الآن، عندما يضيف المسؤول مجموعات إلى إعداد الموقع about page extra groups، لا يحدث شيء لأن الإعداد المخفي show_additional_about_groups غير مفعل. هذا يبدو وكأنه خطأ، على الرغم من أنه من وجهة نظر المطور، كل شيء يعمل كما هو متوقع. أعتقد أنه سيكون من الأسهل على المسؤول أن يفهم ما يحدث إذا كان الإعداد مرئيًا بدلاً من أن يكون مخفيًا.