في رأيي، أعتقد أن وسم Customization > Theme component سيكون أكثر فائدة إذا كان فئة فرعية. على الأقل بالنسبة لي، من الأسهل العثور عليها مقارنة بالوسوم، وفي السنوات الأخيرة، أصبحت مكونات السمات أكثر أهمية تدريجيًا مقارنة بنظيراتها من Customization > Plugin (العديد منها يتم تحويلها إلى مكونات سمات لتسهيل الاستخدام). وبسبب عدم وجود مصطلح أفضل، فهي تستحق… معاملة «متساوية». بعد كل شيء، فهي شائعة للغاية وتشكل جزءًا لا يتجزأ من Discourse في الوقت الحاضر.
آمل أن تأخذ ذلك في الاعتبار. لست متحدثًا أصليًا للغة الإنجليزية، لذا آسف عن قلة فصاحتي.
أعتقد أن هذا الأسلوب سيُحدث لبساً. القائمة “مدير النظام ← تخصيص” مخصصة فقط للقوالب ومكونات القوالب. يحتوي قسم Customization > Theme على كل ما يمكن إضافته إلى الموقع عبر واجهة المستخدم هذه.
نلاحظ بالفعل حدوث مشاكل متفرقة عندما يضع المستخدمون القوالب في ملفات YML ويحاولون إضافة مستودعات Git للإضافات عبر واجهة المستخدم. إزالة هذا التمييز يزيد فقط من احتمالية حدوث تلك الأخطاء.
لا بد أن تبقى الإضافات ضمن فئتها الخاصة، أليس كذلك؟
الفرق بين مكون السمة والإضافة أصبح غامضاً في ذهني بالفعل. أي شيء يمكننا فعله لتسهيل معرفة الناس بالفرق بينهما سيذهب بعيداً، أنا متأكد.
هذا أمر مضحك بعض الشيء، فقد كان لدى مطوري ووردبريس لفترة طويلة استدعاء لاتخاذ قرار حول مكان تضمين الوظائف، وكانت هناك مناقشات حول مقدار الكود الذي ينتمي إلى “سمة” مقابل “إضافة”. هذه المناقشة أصبحت الآن بدائية تقريباً، حيث أصبح كل شيء كتلة JS، ولكن بسبب علاقتها بالبرنامج الأساسي، لا يزال علينا معرفة مكان وضع الكود، في “إضافة” أو “نمط كتلة”.
لم أشعر قط بهذا الإحساس مع الإضافات في Discourse، في الغالب لأن الناس قد ابتكروا حيلاً رائعة لمكونات السمة على مر السنين. إذا سألني شخص ما عن الفرق بين “الإضافات” و"مكونات السمة"، ففكرتي الأولى ستكون: واحدة تأخذ حقل URL للتثبيت، والأخرى تتطلب إعادة بناء الموقع.
ملاحظة فقط حول وضع العلامات: يبدو أنه من الأسهل نسيان وضع علامة على موضوع بدلاً من نسيان اختيار الفئة. توجد بالفعل بعض السمات التي لم يتم وضع علامات عليها.
أنا بالتأكيد مستعد لإجراء فحص صحي للفئات والوسوم. كانت هناك بعض الاقتراحات الجيدة مؤخرًا حول إجراء بعض التعديلات على الهيكل، لذا سأجمع كل ذلك معًا وأرى أين سنصل. أعتقد أن أي شيء يجعل «مايتا» أكثر بديهية للأشخاص الجدد أو المستخدمين العرضيين لا يمكن إلا أن يكون أمرًا إيجابيًا.
ينبغي أن تكون هذه المشكلة أقل حدة الآن بوجود مشرف مجتمع مخصص. () أعتقد أن قيامي بالفرز والتنظيم أثناء تقدمي يجب أن يغطي الكثير من ذلك. ولدينا عدد لائق من المستخدمين من المستوى 3 والمستوى 4، لذا نأمل أن تعزيز نمط متسق سيجعل من السهل على الآخرين الانضمام أيضًا.
ما زلت أفكر في الأمر على أنه تغييرات في الواجهة الأمامية مقابل الواجهة الخلفية، لكن الترقية إلى «إمبر» قد طمست ما يعنيه ذلك بالنسبة لي الآن أيضًا. يبدو أنها جعلت الكثير من الأمور ممكنة في السمة/مكون السمة أكثر من ذي قبل (وهو أمر رائع إذا كنت مستضافًا ولا تملك سهولة الوصول لإضافة إضافة ).
أعتقد أن هذا تمييز مفيد جدًا لغير المطورين. الأحمر = /admin/customize، والأصفر = app.yml. أعتقد أن هذا هو كل ما تحتاج حقًا معرفته إذا كنت مديرًا يقوم بتثبيت تخصيص موجود، بدلاً من مطور يرغب في إنشاء تخصيص جديد.
شكرًا لك على الاقتراح @Decorbuz سأجمع بعض الأفكار، ونرى ما يمكننا فعله.
نفس السؤال مثل الهواتف الذكية أجهزة كمبيوتر أم لا. الحدود ليست حادة جدًا بعد الآن.
لهذا السبب يجب على كل منتدى اتخاذ خيار منطقي لكيفية ترتيب الأشياء: في مكان ما يجب أن يكون لكل فكرة أو استخدام (تجربة المستخدم والهدف مهمان) أم أن الحل التقني أكثر أهمية (تفكير أساسي للمطور/الكود).
لا توجد حلول صحيحة أو خاطئة، طالما أن المستخدمين يجدون ما يبحثون عنه.
حسنًا، هناك حلول خاطئة بين الحين والآخر. خلط الإضافات/السمات/المكونات الصحية مع تلك المعطلة بطريقة يتعين عليك فيها معرفة العلامة الصحيحة، هي فكرة سيئة حقًا: rofl
وبشكل عام، هناك خطأ آخر غالبًا ما ترتكبه الإدارات، وإذا كنت أتذكر بشكل صحيح، حتى وثيقة العلامة أو ما شابهها من قبل Meta تحذر من ذلك: الفئة لا تولد إنشاء محتوى، ولكن الفئات الفارغة أو ذات حركة المرور المنخفضة تجعل الأمور فوضوية.
عدم الوضوح لا يعني بالضرورة أنه يجب دمجها، خاصة تحت الاسم الذي اقترحه جاستن أعلاه. يمكننا بنفس القدر إضافة شروحات أفضل لكل فئة ومعالجة بعض الغموض بهذه الطريقة.
تتطلب مواضيع Customization > Plugin إعادة بناء ولا يمكن إجراؤها إلا بواسطة المستخدمين الذين يمتلكون صلاحيات الجذر (root). إنها تغييرات ذات مخاطر أعلى تؤثر على توافر الموقع.
أنا أفكر فيهم بهذه الطريقة أيضًا. إذا كان يتطلب بعض التغيير في الواجهة الخلفية (كود روبي) سواء لتخزين شيء ما في قاعدة البيانات أو تغيير سلوك واجهة برمجة التطبيقات، فمن المحتمل أنك بحاجة إلى إضافة.
إذا كان التغيير يتعلق فقط بالواجهة الأمامية، فمن الأفضل البدء بمكون سمة والرجوع إلى إضافة لاحقًا إذا تصاعدت الأمور وأصبحت أكثر تعقيدًا وتبين أن التغييرات في الواجهة الخلفية ضرورية.
أعجبني هذا الاقتراح. إنه أكثر تعقيدًا قليلاً من فئة واحدة مع علامات مختلفة، لكنني أحببت وجود حدود أقوى بين عناصر التخصيص المختلفة هذه.
يمكن أن تتعلق السمة بالمظهر فقط بينما تتطلب الإضافة الوصول إلى نظام التشغيل في الجهاز للتثبيت. إنها أشياء مختلفة جدًا والفئات المناسبة تسمح، على سبيل المثال، للموضوع الأول في الفئة بتوفير سياق للمستخدمين الجدد حول الاختلافات بينها. كيفية التثبيت، وثائق التطوير، إلخ.
أي شيء يمكننا فعله لتسهيل معرفة الناس بالفرق بينهما سيذهب بعيداً، أنا متأكد.
أعتقد أن أي شيء يجعل «مايتا» أكثر بديهية للأشخاص الجدد أو المستخدمين العرضيين لا يمكن إلا أن يكون أمرًا إيجابيًا.
