في رأيي، أعتقد أن وسم Theme component سيخدم غرضه بشكل أفضل كفئة فرعية. على الأقل بالنسبة لي، يسهل العثور عليها مقارنة بالوسوم، وفي السنوات الأخيرة، أصبحت مكونات الثيمات أكثر أهمية مقارنة بنظيراتها من Plugin (العديد منها يتم تحويلها إلى مكونات ثيمات لسهولة الاستخدام). لعدم وجود مصطلح أفضل، فهي تستحق… معاملة “متساوية”. في النهاية، إنها شائعة للغاية وهي جزء لا يتجزأ من Discourse في الوقت الحاضر.
آمل أن تأخذ ذلك في الاعتبار. لست متحدثًا أصليًا باللغة الإنجليزية، لذا آسف لعدم قدرتي على التعبير بشكل جيد.
أعتقد أن هذه اللغة ستؤدي إلى الارتباك. Admin->Customize مخصص فقط للسمات ومكونات السمات. Theme يحتوي على كل ما يمكن تقديمه إلى موقع عبر واجهة المستخدم هذه.
نحن نرى بالفعل مشكلات عرضية مع المستخدمين الذين يضعون السمات في ملفات YML الخاصة بهم ويحاولون إضافة مستودعات git للمكونات الإضافية عبر واجهة المستخدم. إن إلغاء التمييز يجعل هذه الأخطاء أكثر احتمالاً.
هل تحتاج المكونات الإضافية حقًا إلى البقاء في فئتها الخاصة؟
الفرق بين مكون الثيم والإضافة ضبابي بالفعل في ذهني. أي شيء يمكننا فعله لتسهيل معرفة الناس أيها هو أيها سيقطع شوطًا طويلاً، أنا متأكد.
هذا مضحك نوعًا ما، لفترة طويلة كان مطورو ووردبريس يواجهون قرارًا بشأن مكان تضمين الوظائف، وتم إجراء مناقشات حول مقدار الكود الذي ينتمي إلى “ثيم” مقابل “إضافة”. هذا النقاش يكاد يكون غريبًا الآن، حيث أصبح كل شيء وكل شيء عبارة عن كتلة JS، ولكن بسبب علاقته بالبرنامج الأساسي، لا يزال يتعين علينا معرفة مكان وضع الكود، في “إضافة” أو “نمط كتلة”.
لم أشعر بهذا الشعور أبدًا مع الإضافات في Discourse، ويرجع ذلك أساسًا إلى أن الناس توصلوا إلى بعض اختراقات مكونات الثيمات الرائعة على مر السنين. إذا سألني أحدهم عن الفرق بين “الإضافات” و “مكونات الثيمات”، فإن أول ما سيخطر ببالي هو: أحدهما يتطلب حقل URL للتثبيت، والآخر يتطلب إعادة بناء الموقع.
ملاحظة فقط حول وضع العلامات: يبدو أنه من الأسهل نسيان وضع علامة على موضوع بدلاً من نسيان اختيار الفئة. توجد بالفعل بعض السمات التي لم يتم وضع علامات عليها.
أنا بالتأكيد على استعداد لإجراء فحص شامل للفئات والأوسمة. لقد كان هناك عدد قليل من الاقتراحات الجيدة حول إجراء تعديل بسيط على الهيكل مؤخرًا، لذلك سأقوم بتجميع كل هذا معًا وأرى إلى أين نصل. أعتقد أن أي شيء يجعل المنتدى أكثر سهولة للمستخدمين الجدد / العرضيين هو أمر جيد.
يجب أن يكون هذا أقل مشكلة الآن بعد وجود مشرف مجتمع مخصص. () أعتقد أن وجودي لفرز وتنظيم الأمور أثناء تقدمي سيغطي الكثير من ذلك. ولدينا عدد لا بأس به من المستخدمين ذوي المستويات TL3 و TL4، لذا آمل أن يؤدي تعزيز نمط متسق إلى تسهيل انضمام الآخرين أيضًا.
ما زلت أفكر في الأمر على أنه تغييرات الواجهة الأمامية مقابل الواجهة الخلفية، لكن الترقية إلى ember طمست ما يعنيه ذلك بالنسبة لي الآن أيضًا. يبدو أنها جعلت الكثير من الأشياء ممكنة في سمة / مكون سمة أكثر من ذي قبل (وهو أمر رائع إذا كنت مستضافًا ولا تملك وصولاً سهلاً لإضافة مكون إضافي ).
أعتقد أن هذا تمييز مفيد جدًا لغير المطورين. أحمر = /admin/customize، أصفر = app.yml. أعتقد أن هذا هو كل ما تحتاج إلى معرفته إذا كنت مسؤولاً تقوم بتثبيت تخصيص موجود، بدلاً من مطور يرغب في إنشاء تخصيص جديد.
شكرًا على الاقتراح @Decorbuz سأقوم بتجميع بعض الأفكار، وسنرى ما يمكننا فعله.
نفس السؤال مثل الهواتف الذكية أجهزة كمبيوتر أم لا. الحدود ليست حادة جدًا بعد الآن.
لهذا السبب يجب على كل منتدى اتخاذ خيار منطقي لكيفية ترتيب الأشياء: في مكان ما يجب أن يكون لكل فكرة أو استخدام (تجربة المستخدم والهدف مهمان) أم أن الحل التقني أكثر أهمية (تفكير أساسي للمطور/الكود).
لا توجد حلول صحيحة أو خاطئة، طالما أن المستخدمين يجدون ما يبحثون عنه.
حسنًا، هناك حلول خاطئة بين الحين والآخر. خلط الإضافات/السمات/المكونات الصحية مع تلك المعطلة بطريقة يتعين عليك فيها معرفة العلامة الصحيحة، هي فكرة سيئة حقًا: rofl
وبشكل عام، هناك خطأ آخر غالبًا ما ترتكبه الإدارات، وإذا كنت أتذكر بشكل صحيح، حتى وثيقة العلامة أو ما شابهها من قبل Meta تحذر من ذلك: الفئة لا تولد إنشاء محتوى، ولكن الفئات الفارغة أو ذات حركة المرور المنخفضة تجعل الأمور فوضوية.
لا يعني الافتقار إلى الوضوح تلقائيًا أنه يجب دمجها، لا سيما تحت الاسم الذي اقترحه جاستن أعلاه. يمكننا بنفس القدر إضافة شروحات أفضل لكل فئة ومعالجة بعض الغموض بهذه الطريقة.
Theme و Theme component يغلفان التخصيصات المعبأة مسبقًا والتي يمكن إجراؤها في وقت التشغيل.
مواضيع Plugin تتطلب إعادة بناء ولا يمكن إجراؤها إلا من قبل المستخدمين الذين لديهم وصول الجذر. إنها تغييرات أعلى خطورة تؤثر على توفر الموقع.
أنا أفكر فيهم بهذه الطريقة أيضًا. إذا كان يتطلب بعض التغيير في الواجهة الخلفية (كود روبي) سواء لتخزين شيء ما في قاعدة البيانات أو تغيير سلوك واجهة برمجة التطبيقات، فمن المحتمل أنك بحاجة إلى إضافة.
إذا كان التغيير يتعلق فقط بالواجهة الأمامية، فمن الأفضل البدء بمكون سمة والرجوع إلى إضافة لاحقًا إذا تصاعدت الأمور وأصبحت أكثر تعقيدًا وتبين أن التغييرات في الواجهة الخلفية ضرورية.
أعجبني هذا الاقتراح. إنه أكثر تعقيدًا قليلاً من فئة واحدة مع علامات مختلفة، لكنني أحببت وجود حدود أقوى بين عناصر التخصيص المختلفة هذه.
يمكن أن تتعلق السمة بالمظهر فقط بينما تتطلب الإضافة الوصول إلى نظام التشغيل في الجهاز للتثبيت. إنها أشياء مختلفة جدًا والفئات المناسبة تسمح، على سبيل المثال، للموضوع الأول في الفئة بتوفير سياق للمستخدمين الجدد حول الاختلافات بينها. كيفية التثبيت، وثائق التطوير، إلخ.
أي شيء يمكننا فعله لتسهيل معرفة الناس أيها هو أيها سيقطع شوطًا طويلاً، أنا متأكد.
أعتقد أن أي شيء يجعل المنتدى أكثر سهولة للمستخدمين الجدد / العرضيين هو أمر جيد.
