كما هو موضح في الشكل أدناه، لا تحتوي الإضافات العادية على “css+html” مخصصة، بينما تحتاج معظم “مكونات السمات” عادةً إلى تعديل “css+html”، مما يؤدي إلى قيامنا بإنشاء عدد كبير من ملفات css المخصصة المقابلة، مما يجعل من الصعب علينا تحديدها.
إعجابَين (2)
بشكل عام، نوصي باستخدام نظام التحكم في الإصدار مثل GitHub، حيث يسهل ذلك تتبع التعليمات البرمجية الخاصة بك بمرور الوقت.
في السابق، كان لدينا زر CSS/HTML في جميع السمات ومكونات السمات، ولكن عند تحرير سمة بعيدة، كانت التغييرات في المستودع البعيد تتجاوز التخصيص المحلي وكانت تجربة سيئة للغاية جعلت الناس يخشون التحديث.
أعتقد أن أحد الحلول الممكنة هو إبقاء طبقة التخصيص منفصلة عن المستودع البعيد، ولكن هذا هو ما نوصي به الآن (استخدام مكون سمة للتخصيص المحلي لسمة بعيدة)، ولكن ربما مع عدد أقل من الخطوات.
7 إعجابات
أحد الحلول، خاصة لمكونات القالب، سيكون عمل نسخة من مكونات القالب وإجراء التغييرات الخاصة بك في نسختك الخاصة.
إعجاب واحد (1)
ما أعنيه هو أنه عندما نستخدم إضافات الآخرين، ففي كثير من الحالات نحتاج نحن المستخدمين إلى بعض CSS المخصص لضبط المظهر، ولكن هذه الإضافات لا تحتوي على خيار CSS المخصص، مما يؤدي بنا إلى إنشاء إضافات CSS مستقلة لمطابقة الإضافات المقابلة، مما يؤدي إلى الكثير من الإضافات الفوضوية، وهو أمر مربك للغاية.
لذلك آمل أن يتمكن المسؤولون من توفير الدعم للتخصيص عند استخدام الإضافات على github، على سبيل المثال: إرفاق خيارات CSS + HTML قابلة للتخصيص تلقائيًا بعد تثبيت الإضافة. إذا لم نقم بتعيينها، فلن تكون هناك حاجة لحفظ أي بيانات. إذا قمنا بتعيينها، فسيتم إنشاء البيانات وتخزينها وفقًا لـ “معرف الإضافة”. بالطبع، لا أعرف كيف يتم ذلك على وجه التحديد.
يرجى النظر في كمية CSS المخصصة التي لدي وسوف تفهم حقًا مدى تعقيد هذا. غالبًا ما لا أتمكن من العثور على ملفات CSS المخصصة الخاصة بي بسبب تحديثات إضافات GitHub الخاصة بالآخرين…
إذا كنت تريد أن تكون نسخة Discourse الخاصة بك خالية من مكونات السمات المستقلة المسؤولة عن إضافة CSS مخصص لمكون إضافي معين، يمكنك بدلاً من ذلك إنشاء مكون سمة واحد يكون مسؤولاً عن جميع التخصيصات الفريدة التي تريدها للمكونات الإضافية التي قمت بتثبيتها.
داخل مكون السمة هذا، يمكنك بعد ذلك تقسيم جميع ملفاتك إلى ملفات .scss متعددة واستيرادها في ملف common.scss رئيسي.
my-theme-component/
├── about.json
├── common/
│ ├── common.scss
│ └── head_tag.html
├── scss/
│ ├── announcement-bar.scss
│ ├── banner-featured-links.scss
│ ├── category-banners.scss
│ ├── disco-toc.scss
│ ├── topic-list-excerpts.scss
│ ├── topic-list-thumbnails.scss
│ └── disco-toc.scss
└── settings.yml
3 إعجابات
أعلم أن هناك العديد من الطرق لتطبيق CSS مخصص، لكنني نشرت هذا الموضوع لجعل Discourse أكثر فائدة وتقديم اقتراحات. أتفهم نتيجة ردك. باختصار، أنت لست مهتمًا بجعل Discourse أكثر إيجازًا. قم بتحديث ردك ويمكن إغلاق هذا الموضوع.
أنت على حق، خطأي لقد أسأت الفهم. كنت أرغب بشكل أساسي في تقديم اقتراح للمساعدة في حالتك الخاصة وتسليط الضوء على ميزة تقسيم ملفات .scss التي لدينا لمكونات السمات والتي اعتقدت أنك قد لا تكون على علم بها.
ربما يكون هذا الموضوع مناسبًا بشكل أفضل لـ Feature ومن ثم يمكن لفريق المنتج التدخل وتقييم ما إذا كان إضافة مناسبة.
إعجابَين (2)
أفضل طبقة تخصيص مخصصة متعلقة بـ CSS في إعدادات المكون مع زر لتمكينها أو تعطيلها. بالنسبة لأي شيء متعلق بـ HTML، من الأفضل عمل نسخة متفرعة من المكون، حيث لن يكون ذلك منطقيًا في طبقة منفصلة أعتقد. سيكون من الأسهل على المستخدم إدارته مع تقليل تضخم المكونات غير الضرورية. 
4 إعجابات
هذا شيء ناقشه أنا و @david مؤخرًا.
أعتقد أن الفكرة تستحق النظر، ولكننا بحاجة إلى التفكير مليًا في المخاطر - نظام السمات مرن بالفعل وهناك العديد من الطرق التي يوقع بها الأشخاص أنفسهم في مشاكل، والتي لا تكون واضحة دائمًا على الفور.
مع السمات والمكونات والتخصيصات اليدوية فوق Discourse المتغير، ليس من الصعب جدًا تعريض نفسك لتغييرات كاسرة في بعض عقد الرسم البياني للتبعيات التي يبنونها لأنفسهم.
سنقوم ببعض العمل على السمات في المستقبل القريب الذي سيضع نظام السمات لدينا تحت الاختبار بطرق مختلفة قد تدفعنا إلى إعطاء الأولوية لبعض التغييرات هنا، ولكن عند القيام بذلك، سنفكر بعمق أكبر في كيفية تمكين تخصيصات أكثر قابلية للصيانة. ليس من الواضح بعد إلى أين سيقودنا ذلك، ولكنه قد يؤثر على آرائنا بشأن هذا الطلب.
4 إعجابات