Développement de plugins Discourse - Partie 3 - Ajouter des paramètres de site personnalisés

Précédent tutoriel : Developing Discourse Plugins - Part 2 - Connect to a plugin outlet


Paramètres du site

Si vous visitez /admin/site_settings sur un Discourse sur lequel vous avez des capacités d’administrateur, vous verrez une liste de paramètres de configuration. Dès l’installation, nous fournissons ce que nous pensons être les meilleurs paramètres pour une installation de Discourse, mais nous comprenons également que les gens veulent ajuster leurs installations pour que leur forum soit exactement comme ils le souhaitent.

Il y a de fortes chances que, à moins que votre plugin ne soit très simple, vous souhaitiez ajouter des paramètres que les utilisateurs de votre plugin peuvent modifier et utiliser pour configurer les fonctionnalités. Heureusement, c’est assez facile à faire !

config/settings.yml

La première chose que vous devrez faire est de créer config/settings.yml dans votre dossier de plugin. Ce fichier décrira tous les paramètres dont votre plugin aura besoin. Voici un exemple de fichier :

plugins:
  awesomeness_enabled:
    default: true
    client: true
  awesomeness_max_volume:
    default: 10
    client: true

Le fichier doit être au format YAML. Le YAML peut être assez pointilleux, donc si Discourse a des difficultés à charger vos paramètres, je vous suggère d’essayer de valider votre YAML avec un outil comme YAMLint.

Je vais expliquer l’exemple de fichier en détail. Le niveau supérieur est plugins et cela indique à Discourse que nous voulons que ces paramètres apparaissent sous « Plugins » dans les paramètres du site.

Ensuite, deux paramètres sont déclarés, awesomeness_enabled et awesomeness_max_volume. Discourse déduit le type des paramètres à partir de la valeur par défaut, donc awesomeness_enabled est un booléen et awesomeness_max_volume est un nombre.

Le client: true est important à comprendre. Discourse est composé de deux applications principales, l’API côté serveur écrite en Ruby on Rails, et l’application côté client écrite en Ember.js. Par défaut, nous n’exposons pas les paramètres à l’application client Ember.js à moins que vous n’ajoutiez client: true. Nous faisons cela parce que certains paramètres sont privés, comme les clés API, et ne doivent pas être envoyés aux utilisateurs finaux. De plus, si nous envoyions tous les paramètres au client, cela pourrait représenter un téléchargement important pour les utilisateurs finaux !

Dans notre exemple, nous voulons que ces deux paramètres soient accessibles dans le monde JavaScript ainsi que dans le monde côté serveur.

Une deuxième étape importante

Avant de pouvoir utiliser vos paramètres de site nouvellement ajoutés, vous devez ajouter des traductions pour eux. Puisque Discourse prend en charge de nombreuses langues, tout texte que vous ajoutez devra prendre en charge la traduction dans d’autres langues.

Créons les traductions pour nos paramètres en anglais :

config/locales/server.en.yml

en:
  site_settings:
    awesomeness_enabled: "Ce plugin est-il génial ?"
    awesomeness_max_volume: "Quel est le volume maximum possible ?"

Les étiquettes que nous avons ajoutées dans ce fichier seront affichées dans la section d’administration. C’est une bonne idée d’être aussi clair que possible sur ce que le paramètre accomplit.

Déclarer le paramètre comme le ‘paramètre activé’

Maintenant que nous avons notre paramètre de site, nous devons indiquer à Discourse que c’est celui qui active et désactive nos fonctionnalités.

Ouvrez votre fichier plugin.rb et ajoutez la ligne suivante sous les commentaires de métadonnées :

enabled_site_setting :awesomeness_enabled

Assurez-vous de commencer tous vos autres paramètres par « awesomeness_ » afin que le bouton de paramètres à /admin/plugins fonctionne correctement.

Accéder à vos nouveaux paramètres

Tout d’abord, vous devrez redémarrer votre serveur de développement pour que les paramètres prennent effet. Une fois que vous l’aurez fait, les paramètres devraient être disponibles pour votre code côté serveur et côté client.

Nous injectons automatiquement les paramètres du site dans la plupart des objets JavaScript, donc si vous déclarez un Component, Controller, Route, View ou Model, vous devriez pouvoir accéder au paramètre du site simplement en utilisant this.siteSettings.awesomeness_enabled. Dans la plupart des modèles handlebars, vous devriez également pouvoir dire {{siteSettings.awesomeness_enabled}} et la valeur du paramètre sera affichée.

Nous n’avons pas encore beaucoup couvert les choses en Ruby dans cette série, mais si vous souhaitez accéder aux paramètres du site dans l’application Ruby, vous pouvez le faire via : SiteSetting.awesomeness_enabled

Maintenant, allez de l’avant et ajoutez des paramètres personnalisés à vos plugins !


Plus dans la série

Partie 1 : Bases des plugins
Partie 2 : Points de sortie des plugins
Partie 3 : Ce sujet
Partie 4 : Configuration git
Partie 5 : Interfaces d’administration
Partie 6 : Tests d’acceptation
Partie 7 : Publiez votre plugin


Ce document est contrôlé par version - suggérez des modifications sur github.

34 « J'aime »

For those more familiar with YAML, this was probably obvious, and thanks to YAMLint that you referenced I was able to figure this out pretty quick, but I thought it was worth mentioning that the format for the config/locales/server.en.yml needs to specifically be:

en:
  site_settings:
    awesomeness_enabled: "Is this plugin awesome?"
    max_volume: "What is the maximum volume possible?"

Correct?

Another quick question, it’s great that I can get to the settings by clicking on the Change Settings button, but how do I get the plugin specific Settings button directly to the right of the plugin like the poll plugin?

https://s3.amazonaws.com/f.cl.ly/items/162n220f0M0P3e0j2U3M/Image%202015-07-29%20at%207.29.28%20PM.png

Or is that a little too much for a Beginner’s Guide?

4 « J'aime »

I updated the guide to fix both of those :smile:

4 « J'aime »

How do you get the settings button to pre-populate the search field like Discourse Tagging does? I feel like I’m missing something obvious.

Edit: Nevermind, I figured it out. You had to use *_enabled to get it to filter. I originally didn’t have an enabled setting because the URL was simply the factor for determining if it is enabled.

1 « J'aime »

For some reason, {{siteSettings}} in the poster-name-right outlet returns undefined. I tested with other outlets and the return the expected value. I’m not sure why :sadpanda:

Had to work around it by using {{Discourse.SiteSettings}}

1 « J'aime »

This isn’t working because the Post view code path is some of the oldest code we have and it doesn’t do all the automatic stuff newer code can do :frowning:

I’ve come up with a fix that I think will solve your problem:

In the future I’ll be able to remove this hack and it’ll just work.

3 « J'aime »

Hey @eviltrout how can I add a user setting? I mean a setting for a plugin that every user can change on his profile? Can I set a default too?

I guess is the same as an Custom User Field, so can I create a new User Field from a plugin?

Unfortunately there’s no easy way to do this right now. There is probably a good argument to be made for such an API for plugin authors.

Until then the way to do it is to add the fields via plugin outlets to the user preferences, tap into serializers and saving logic to store the setting the PluginStore.

1 « J'aime »

I ran into this a while back too. We have to expose the field in the site settings too. I’ll see if I can add a PR to make this easier.

1 « J'aime »

For anyone following this tutorial and trying to get SiteSettings.awesomeness_enabled to return anything in a rails console, be aware that the tutorial is wrong. It should be SiteSetting.awesomeness_enabled (Setting without the s at the end!)

1 « J'aime »

Hmmm, this works for me in the hbs files

{{#if siteSettings.plugin_outlet_locations_enabled}}

Different syntax depending on where it’s being called from?

EDIT
Ah, the singular - plural Rails “magic” thing.

Nope, your first guess was correct >.>

JS has Discourse.SiteSettings but Rails has SiteSetting.

3 « J'aime »

Oops! Thanks for letting me know. I’ve updated the tutorial.

2 « J'aime »

Well, I believe some infrastructure are not complete yet. But I am refurnishing old login plugins while it’s worthwhile to asking the future change to plugin infra. Shall I move settings from login to plugin prefix?

I would recommend to do that, yes.

1 « J'aime »

Just to clarify, this is only the case if you say client: true, right?

Yes, that is correct. Javascript gets access to the “client side” site settings.

2 « J'aime »

I do not completely understand this statement. I set it to client: false but it was still visible in admin settings. What exactly happens if you set client to false.

Thank you.

We ship up a big JSON object of all the site settings that have client: true to all users, so those are considered public and viewable.

If they don’t have client: true then they are meant to be available from the server side. The admin section is an exception - we need to return all site settings to admin users so they can be changed! It uses a different API to get them all.

9 « J'aime »

Work for me! 2018-4-28

Code

config/settings.yml

config/locales/server.en.yml

plugin.rb

Result

http://localhost:3000/admin/site_settings/category/plugins


(oh, I saw the translation missing hint)

Thanks!

3 « J'aime »