هذا ممكن تقنيًا، ولكن كما ذكر ديفيد أدناه، يرجى عدم استخدامه
لقد ألقيت نظرة لأنه سؤال مثير للاهتمام للغاية!
يوجد مكان في discourse/lib/theme-settings-store حيث يتم تخزين إعدادات السمة ويمكن استخدام دوال التصدير مثل getObjectForTheme أو getSetting.
يمكنك استرداد قيمة إعداد لأي مكون سمة طالما لديك معرفه.
ومع ذلك، لم أتمكن من العثور على طريقة سهلة لاسترداد تعيين معرف الترجمة ↔ الاسم.
ومع ذلك، يمكنك القيام بالخدعة التالية:
// استرداد من علامات <link> اسم السمة <-> تعيين المعرف لمكونات السمة النشطة
const themesComponents = Array.from(
document.querySelectorAll("link[data-theme-name]")
).reduce((acc, link) => {
acc[link.dataset.themeName] = parseInt(link.dataset.themeId, 10);
return acc;
}, {});
// الحصول على معرف السمة بناءً على اسم مكونها
const themeId = themesComponents["discotoc"];
// الحصول على جميع الإعدادات
const themeSettings = getObjectForTheme(themeId);
// الحصول على إعداد محدد
const themeSetting = getSetting(themeId, "anchor_icon");
الإعدادات من السمات/مكونات السمات المختلفة معزولة عمدًا. وجود تبعيات متبادلة بين السمات/مكونات السمات يجعل تطويرها ودعمها صعبًا للغاية.
كما أوضح @Arkshine، من الممكن تقنيًا اختراق طريقك للعثور على البيانات، لكنني أوصي بشدة بعدم القيام بذلك. ستتعطل الاستراتيجية إذا قام مسؤول بتغيير اسم سمة في لوحة الإدارة، ومن المحتمل جدًا أن تتعطل بشكل عشوائي مع التغييرات الأساسية المستقبلية.
عذراً، لقد أدركت أن الرمز الذي قدمته قد لا يكون موثوقاً به. كان يجب أن أكون حذراً حقاً بشأن ما أعرضه هنا. القرصنة ممتعة، لكنها تستمر حتى تؤدي إلى استخدامات ومشاكل غير مرغوب فيها في المستقبل.
لا تقلق على الإطلاق يا @Arkshine - من الجيد دائمًا التجربة. وجود ملاحظة [details] في منشورك أمر جيد للتأكد من أن الأشخاص يعرفون المخاطر التي يتعرضون لها
إذا أصبح مشاركة الإعدادات بهذه الطريقة بين المكونات الإضافية و/أو مكونات السمات مطلبًا شائعًا، فيمكننا بالتأكيد إيجاد خيارات أكثر قوة. ربما يمكننا استخدام هذا الموضوع لوضع حالات استخدام كمثال.
شعوري هو أنه إذا كانت سمة تحاول استخدام إعدادات من سمة أخرى… فربما يجب دمجها في مستودع واحد؟