تخصيص CSS غير مطبق على Discourse الخاص بي

الدعم
1

منذ تحديث أمس (لخادمي المستضاف على https://doomemacs.discourse.group)، لم يتم تطبيق أي من تنسيقات CSS المخصصة الخاصة بي. لا تؤثر التغييرات في السمة (السمات) أو تنسيقات CSS للمكونات (رغم أن التغييرات في قسم أو أقسام HTML أخرى تعمل بشكل صحيح).

هناك وسم link مشبوه يشير إلى ورقة تنسيق فارغة، وتتغير قيمة التجزئة (hash) الخاصة به في كل مرة أقوم فيها بتغيير تنسيقات CSS الخاصة بي. يبدو أن Discourse تفشل بصمت في تجميع أوراق التنسيقات الخاصة بي. لا توجد أي إشارات إلى فشل في سجلات الأخطاء الخاصة بي، ويقوم discourse_theme بتحميل أوراق التنسيقات الخاصة بي دون أي اعتراض، لكن دون أي تأثير.

هل يمكن لأي مسؤول التكرم بالنظر في الأمر؟

3 إعجابات
2

~~لست متأكدًا، لكنني أظن أنك قد تواجه هذا التغيير https://meta.discourse.org/t/restrict-editing-of-remote-themes/170051~~
يبدو أن هذا غير صحيح :smiley:

إعجابَين (2)
4

مرحبًا @hlissner، أنا أعمل على إصلاح هذه المشكلة؛ فقد أدى ترقية حديثة للنواة إلى تعطيل مكون السمة في مثيلتك. من المفترض أن يكون الإصلاح جاهزًا قريبًا.

4 إعجابات
5

الإصلاح مدمج الآن في النواة، وتم نشر موقعك @hlissner. يرجى ملاحظة أنني قمت بتعطيل مكونين من مكونات السمة: المكون الذي يحتوي على أنماط مخصصة (يمكنك تمكينه)، و discourse-theme-category-homepage، الذي يحتاج إلى تحديث في المصدر قبل أن تتمكن من تمكينه. مزيد من التفاصيل حول ذلك في Enhanced category-box display component - #7 by pmusaraj

5 إعجابات
6

شكرًا لك! الآن يتم تحميل أوراق الأنماط بشكل صحيح، ولكن متغيرات ألوان SCSS لا يبدو أنها ترث مخطط ألوان قوالب. على سبيل المثال، $secondary تعطي قيمتها الافتراضية #ffffff بدلاً من #282c34. هل هذا ربما عيب آخر ناتج عن e8b8272؟

إعجابَين (2)
7

نعم، إنها انتكاسة أخرى. الإصلاح معقد بعض الشيء… ومعظم متغيرات الألوان، يجب أن تستخدم مكونات السمات خصائص CSS المخصصة. يمكنك الاطلاع على هذا الدليل Update themes and plugins to support automatic dark mode للحصول على نظرة عامة وبعض الأمثلة حول كيفية إضافة تباينات ألوان مخصصة في ملف color_definitions.scss خاص في مكون السمة الخاص بك.

أخبرني كيف سارت الأمور!

إعجابَين (2)
8

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

$primary-low: dark-light-choose(darken($secondary, 12%), lighten($secondary, 10%));

:root {
    --primary-low: #{$primary-low};
}

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

إعجابَين (2)
9

نعم، هذا منطقي. هل جربت إضافة هذا الكود SCSS أعلاه إلى ملف جديد في common/color_definitions.scss؟ يجب أن يعمل ببساطة إذا قمت بإضافته هناك. (يوجد أيضًا علامة تبويب في واجهة المستخدم لتلك ورقة الأنماط الخاصة.)

إعجابَين (2)
10

كنت على وشك تجربة ذلك بالضبط، ثم انقطع discourse برسالة «واجه البرنامج الذي يشغل منتدى النقاش هذا مشكلة غير متوقعة»، ها ها.

إعجاب واحد (1)
11

يمكنك الوصول إلى الموقع عبر /safe-mode، مما يعطل السمات والمكونات، ومن ثم يمكنك رؤية ما حدث.

ومع ذلك، هذا يعتبر انتكاسة أخرى، حيث لا ينبغي لأخطاء SCSS أن تسبب تعطل الموقع بأكمله، وسأقوم بالتأكيد بإصلاح ذلك خلال الأيام القليلة القادمة.

4 إعجابات
12

نجح ذلك! تم ضبط متغيرات الألوان بشكل صحيح ضمن نطاق color_definitions.scss. المشكلة الوحيدة هي أنني لا أستطيع استيراد ملفات تنسيقات أخرى منه. على سبيل المثال:

// scss/globals.scss
$foo: "#000000";

// color_definitions.scss
@import "globals";
:root { --foo: #{$foo}; }

ينتج عن ذلك ما يلي في سجلات أخطاء Discourse:

SCSS compilation error: Error: File to import not found or unreadable: globals.scss.
        on line 129 of color_definitions.scss
>> @import "globals";

يمكنني إعادة تصميم ملفات التنسيقات الخاصة بي لتجنب هذا الاعتماد، لذا الأمر ليس بالأمر الجسيم، لكن هل يمكن اعتبار هذا عيبًا؟

إعجابَين (2)
13

نعم، لدي طلب سحب (PR) لحل مشكلة الاستيراد، ومن المتوقع دمجه غداً.

3 إعجابات
14

شكرًا لمساعدتك! تم دمج طلب السحب (PR)، وتم تحديث مثيلي، وأستطيع الآن استيراد أوراق الأنماط (stylesheets) إلى color_definitions.scss، لكن هذه المشكلة عادت للظهور:

في هذه المرة، تؤثر المشكلة على المتغيرات في color_definitions.scss أيضًا.

إعجاب واحد (1)
15

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

إعجاب واحد (1)
16

من الممكن بالتأكيد، لكنه غير مريح، لأنه سيتطلب مئات الأسطر من كود SCSS القياسي لكل سمة (نظام بناء لمشاركة المتغيرات بينها جميعًا)، وهو ما لم يكن ضروريًا قبل أسبوع. مع ذلك، سيكون من الأفضل على الأرجح القيام بذلك على أي حال لتجنب المشاكل مع عمليات إعادة الهيكلة المستقبلية لعملية بناء Discourse. سأقوم بذلك. شكرًا لك!

إعجاب واحد (1)
17

ربما يجب مراجعة هذا الدليل أو إزالته إذا لم يعد مدعومًا.

إعجابَين (2)
18

نعم، هذا الدليل قديم بعض الشيء، لكن ما يسبب لك مشكلة في حالتك ليس المتغيرات الأساسية، بل ألوان SCSS في مكون لا يرث مخطط ألوان السمة. (ومع ذلك، سأتفقد الدليل وأحدثه.)

قليل من السياق: في أغسطس/سبتمبر 2020، انتقلنا إلى استخدام خصائص CSS المخصصة للألوان. كان السبب الرئيسي لهذا التغيير هو تمكيننا من دعم الوضع المظلم التلقائي بطريقة خفيفة وسريعة. تحتوي السموم على ملفات CSS و JS، لذا لا يمكن التبديل بينها بسرعة، لكن باستخدام خصائص CSS المخصصة، يمكن عكس مخططات الألوان على الفور دون تحديث الصفحة.

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

19

هذا سيكون مثاليًا، لكنني توصلت إلى الإعداد الحالي لأن مخططات الألوان المتعددة لم تكن مناسبة لي. تنتج بعض مخططات الألوان ألوانًا رديئة للمتغيرات المُولَّدة تلقائيًا مثل --primary-low. قد يعمل إعادة تعريف المتغير ببساطة لمخطط ألوان واحد، لكنه لا يعمل لمخطط آخر. يمكن تحقيق حل أكثر شمولاً إذا أعيد تعريفه بناءً على $primary، أو بشكل شرطي بناءً على معرف/اسم مخطط الألوان، ولكن بدون ذلك فإن استخدام سمات متعددة يصبح ضروريًا، مما يسمح لي بوجود ملف color_definitions.scss خاص بكل سمة (وهو التكرار الذي أود تجنبه). أم أن هناك خيارًا أفضل فاتني؟

20

تم إغلاق هذا الموضوع تلقائيًا بعد 27 يومًا. لم يعد مسموحًا بالردود الجديدة.