Hey all, I hope I’m posting this in the right place. I’m trying to develop a plugin for my new Discourse website. I forked the example repo here, got a Plugin Outlet working, then hit a wall and started to feel pretty lost and confused. I’m recently starting to get the hang of MVC PHP frameworks like Laravel, but I am VERY new to JS frameworks. I’ve never touched Ruby, Rails, or Ember before. The Problem My website is for an HOA community. What I’m trying to do is collect and save a few extra fields of data per user: legal_name (string) is_owner (bool) is_resident (bool) building (string) - representing their building number unit (string) - representing their unit number … and a few other internal variables, like whether a moderator has confirmed them. I want to make these fields required for user signup. That means modifying the user signup form. I hooked into the create-account-after-password outlet and got some extra fields to display, but obviously this doesn’t make it functional. I think I need to extend the controller in app/assets/javascripts/discourse/app/controllers/create-account.js, not only to catch the new form values when submitted but even for something as (seemingly) basic as using the site name this.siteSettings.title in a client.en.yml translation field! (Right now the extra fields in my signup form are headed, “What’s your connection to [missing %{title} value]?” Which is obviously not good.) The more I tried to look for answers, the more questions I had and the bigger they became. Different guides I tried to follow were apparently written for different versions of Discourse. The example plugin repo has things I don’t understand. What’s the difference between a clientside route and a serverside route? What’s the difference between a plugin and a module? I’m so lost. If anybody could offer some help, I will be very grateful. Thank you in advance.

[תמונה] Richard - Communiteq: Forget about the moderation by owners (if I understood you correctly) and leave that to staff. [תמונה] Jay Pfaffman: I suggest that whoever it is that would do that should just manage all of the users. Honestly I’m starting to think you guys are right about this. If I remove that requirement from the project, suddenly the burden of the system shrinks pretty much to existing/core functionality in Discourse. For the sake of anyone who searches about my original specific issue, I suspect this comment is technically the solution: Extend Existing Controller? - #21 by petermarkley But for the sake of my real project … The more I actually explored the Groups (thanks to RGJ here & here) and Custom User Fields features (thanks to Moin & RGJ), the more comfortable I became with them. I especially appreciate the “avatar flair” part of Groups, honestly I did not expect that to exist and it’s basically what I was picturing with the SVG icon stuff that I mentioned here. It’s very classy, I must confess. The only remaining thing I am still considering, since I’ve already started plugin development anyway, is to extend the signup modal controller so that a user’s selection in the “building number” field can filter the options in the “unit number” field–down from 200 to about 6. I guess I have to weigh how much nicer that will be for users against the time it would take to develop. But at this point I’m thinking that I can start accepting users anyway and start getting content on the site … Thanks everyone!

[תמונה] petermarkley: What I’m trying to do is collect and save a few extra fields of data per user: I think you could do that with Creating and configuring custom user fields

Thank you! That doesn’t provide all of the functionality that I think I want, but it definitely makes me pause to consider whether that feature can help me toward my goals. Either way I think I still need to answer the original question of how to extend existing controllers using a plugin. Is such a thing possible?

[תמונה] petermarkley: What I’m trying to do is collect and save a few extra fields of data per user [תמונה] petermarkley: That doesn’t provide all of the functionality that I think I want, but it definitely makes me pause to consider whether that feature can help me toward my goals. save it just to display somewhere? what is it you want to do with this data? i’m under the impression you want store it for some other functionality rather than just display it somewhere on the forum.

[תמונה] petermarkley: What I’m trying to do is collect and save a few extra fields of data per user: … I want to make these fields required for user signup. That means modifying the user signup form This can be accomplished without any programming with Creating and configuring custom user fields

what is it you want to do with this data? i’m under the impression you want store it for some other functionality rather than just display it somewhere on the forum. Well, my ultimate hope/vision was: 1. Tiered moderation Grant owners of each unit in the community moderator powers over ONLY the residents of their unit. Bearing in mind that there are close to 200 units in our community, it didn’t seem feasible to use the groups feature to accomplish this. See also #3 below, which groups would also conflict with. 2. Signup UX The perfect UX in my mind would also make the drop menu for “unit” on the signup form dynamically react to the user’s choice in the “building” field, so as to offer only units that are in that building. (I was going to figure out some way to parse a JSON config file for this when Discourse initialized.) 3. Field privacy settings I wanted to offer each user the choice whether to hide their building and/or unit number from other users not in their unit. My impression is that the core custom fields feature offers this option only per field (not per user) and also only to admins, not to the users themselves. 4. Fancy styling This would be more of an icing-on-the-cake thing, but instead of displaying it as something like “Owner: yes,” I wanted to give the system special knowledge of these fields to style them differently on user summaries. Like put an SVG deed icon, and a check mark if a moderator has confirmed their status (or a house icon for residents). That sort of thing. So, yeah … Maybe I’m being too picky here, but I feel like once I’m past the learning curve to accomplish the core functionality then the smaller wish list items will become almost trivial. Many of the residents in my community are older people with little to no computer knowledge. I have serious concerns about some of the residents not wanting to adopt and use my Discourse website just because it’s new and not Facebook, let alone because of genuine usage issues like address privacy or unvalidated input of building/unit numbers.

[תמונה] petermarkley: Bearing in mind that there are close to 200 units in our community, it didn’t seem feasible to use the groups feature to accomplish this. See also #3 below, which groups would also conflict with. Groups will work fine for that purpose, and you can easily have 200 groups. All you would need to do is to manually or programmatically map the field onto a group. But you might also want to have people send in some kind of "proof’ after registration. You could do it manually, code that yourself, use Pavilion’s custom wizard plugin for that. [תמונה] petermarkley: My impression is that the core custom fields feature offers this option only per field (not per user) That’s true, but you could have users who want to make it public display that field somewhere else, i.e. have a “private” building field and a “public” building field.

If you do need to add features, you want to create a plugin or theme component, not fork discourse. [תמונה] petermarkley: Signup UX You can do that in a theme component, so you don’t need a plugin for that, but if you are making a plugin, you can include the front end changes in the plugin too. Developing Discourse Plugins - Part 1 - Create a basic plugin. Looking for plugins that add similar functionality is also a good way to go. There is a Discourse repo called all-the-plugins that you can use to be able to search for examples. [תמונה] petermarkley: Field privacy settings Having public vs private versions of those fields as suggested seems like a good solution, but you can also add user fields in a plugin and control how and whether those fields are added to the serializer to display them. [תמונה] petermarkley: Fancy styling This is what theme components do. Theme Developer Quick Reference Guide could be a start.

[תמונה] Jay Pfaffman: you want to create a plugin or theme component, not fork discourse. I don’t think TS intended to fork discourse?? [תמונה] petermarkley: I’m trying to develop a plugin for my new Discourse

[תמונה] Richard - Communiteq: I don’t think TS intended to fork discourse?? It looks like the repo he linked to is a fork and not a plugin.

[image] Forking discourse-plugin-skeleton seems a good start for writing a plugin to me…

להאריך בקר קיים?

מפתח

Moin 28 במאי,‏ 2023,‏ 3:46am 2

I think you could do that with Creating and configuring custom user fields

נושא		תגובות	צפיות
Alternative sign up pathways Product Support	38	1249	17 בנובמבר,‏ 2024
Theme-Component v Plugin: What's the difference Development	22	6207	9 ביוני,‏ 2020
Creating and configuring custom user fields Site Management how-to , user-custom-fields , users	26	19241	3 בנובמבר,‏ 2026
Topic OP moderation Plugin Plugin	11	1955	22 באפריל,‏ 2025
How to add custom fields to models Extras pavilion	48	9774	30 בספטמבר,‏ 2025

להאריך בקר קיים?

נושאים קשורים