تحسين سهولة الاستخدام لإعدادات المكونات الإضافية

[terraboss (Markus)]

Hi guys,
you might struggle with the same issue as I do:

We’ve installed various plugins with a lot of settings at admin panel. Discourse settings are pretty well grouped by their kind. Plugins not. We can’t say which option belongs to which plugin. I’d like to suggest a little improvement…

Is it possible to expand / collapse plugin specific options like the details view? (collapsed by default)

Some other ideas:

• altering background color (white / gray / white / …)
• a thin line between each plugin settings group

In addition to this, I’d like to have some basic information about the plugin on top of each group (1-2 sentences description), latest version and the installed one (date and build version), a link to the offical support site and a link to the plugin author’s site, and if available a shortcut to the docker manager to install updates.

Any thoughts on this?

[Falco]

When you go to /admin/plugins and click on the settings button of a specific plugin, it will filter only the settings for the one you selected.

[terraboss (Markus)]

This is not working e.g. with unofficial plugins like events and locations.

[simon]

When you click on the settings link for a plugin, it works by filtering the settings based on the plugin name. For example, if you click on the settings for discourse-solved, it will bring you to this URL:

http://forum.example.com/admin/site_settings/category/plugins?filter=solved

This means that any of a plugins settings that cannot be found through that filter will not be displayed. With the discourse-solved plugin, the setting for accept_all_solutions_trust_level is not displayed when you click on the Settings button.

[codinghorror (Jeff Atwood)]

We could probably use a better and more structured solution here @sam.

[sam (Sam Saffron)]

For starters though we should be more consistent about naming in our plugin site settings. I agree a better structure makes sense here, we can associate the plugin settings with the particular plugin and then always be able to find them regardless of naming.

I really like the idea of allowing you to expand plugin settings directly near the plugin, somewhat similar to how theme settings work.

[Mittineague]

fAs I understand it, I know of two approaches. One is for a plugin to have its own settings menu under Settings. For a plugins settings to be shown from the Plugins page the settings need to follow the convention of setting names being prefixed with the plugins name.

For example, the setting name for the data explorer plugin begins with “data_explorer_” if it was not so it would not be found from the Plugins page.

I’m guessing the settings are being searched for setting names that begin with the same string as the plugin name. I’m also guessing it would be easiest to make this behavior known to plugin authors and put the onus on them to follow the convention.

[polarathene]

هل يُقصد أن يكون زر الإعدادات/التصفية هذا متاحًا لكل إضافة؟ لدي واحدة فقط مدرجة هنا (هناك عدد قليل تم تثبيته مسبقًا افتراضيًا، وتُدرج إعداداتها مع إضافات هذه جميعها في /admin/site_settings/category/plugins، ولا يوجد تمييز أو فصل واضح، وجدت ذلك غريبًا جدًا.

التفاعل الوحيد لقسم /admin/plugins في الصورة هو النقر على رابط الإضافة، مما ينقلني إلى مستودع GitHub الخاص بالإضافة. أنا قلق فقط من مدى الفوضى/عدم التنظيم الذي يمكن أن يحدث مع إضافة المزيد من الإضافات من قبل مسؤولي المجتمع.

على الرغم من أنني لا أملك زر رابط إعدادات في حالتي، إلا أنه بناءً على مثال URL الذي قدمه @simon، يمكنني استخدام openid لتصفية النتائج، على الرغم من أن هذا ليس الاسم الكامل للإضافة، وإذا كان هناك إضافة أخرى تحمل اسم openid ربما لا يعمل هذا؟ (openid-connect يغير النتائج من 9 إلى 1، و openid كان لها أيضًا نتيجتان في إعدادات تسجيل الدخول غير ذات صلة).

تعديل: openid_connect هي القيمة الصحيحة، أعتقد أنه يتم التصفية بناءً على مفاتيح التكوين هذه.