I have come across this link,
The problem this solves is website owners being limited, for whatever reason, to one application for their entire service.
Example: An indie gaming company can’t afford heroku instances: A Spree shopping cart for their game and a discourse forum for their customers.
Having this be an engine capable rails application allows you to have 1 rails process and essentially 2 applications. In the above example spree would be mounted on “/shop” and discourse mounted on “/forum”, and maybe a further ActiveAdmin on “/admin”.
They share databases, resources, etc.
I thought license wouldn’t be much of a problem due it being used in the Web Backend and not front End?
I agree that having Discourse available as a Rails engine would be awesome. The ability to deeply integrate into an existing site strikes me as invaluable. For instance, having a common user model allows one to associate activity and reputation in the forum with permissions in the rest of the site.
I agree! I’d like to use Discourse as an engine for my open source app. A community for people to talk about PCI Compliance issues.
Having to re-authenticate is a really big pain and makes the UX suffer greatly.
@codinghorror Hope you don’t mind, I might ask questions later when I write up my user story and figure out how to integrate discourse into Compliance chimp. Thank you!
I managed to get shared cookie authentication working to have Discourse appear a part of my main application with completely seamless auth flows and yet, hosted separately using the standard docker install - so the best of both worlds. SSO couldn’t meet all my requirements so I had to patch Discourse in a few places. Some of these patches may become redundant when Discourse move towards Rails 4.2 conventions. But it would be nice to have this usecase supported.
We’d like to use Discourse as an engine for a Rails app wherein we use Alchemy (also as an engine) to drive the content side of the site. It would be nice to be able to serve the entire app as a singular application, if possible, vs having to set things up as disparate apps.
What would be your recommended solution in such a scenario? Is there any way that this is possible at this time or are we going to have to stick with disparate apps for the time being?
Discourse can run engines but its not designed to run as a rails engine. Use SSO and site customisations
@nileshtrivedi are your shared cookie authentication patches available somewhere?
I’m facing a similar use-case where I’d like to have login sessions seamlessly shared between a Discourse installation and a separate Rails app without any extra user steps required. My understanding is that the existing SSO implementation does not currently support this scenario, because separate login/logout steps are required for the Discourse install and the main Rails site, which is a point of UI friction on my user-base that I’d like to avoid. Is this something that can be improved within the existing SSO implementation, or is a separate shared-cookie auth implementation (such as the one Nilesh got working) the better way to support this?
@wjordan I ended up using SSO which does support seamless login/logout flows.
- When you send the user from your main site to the forum, don’t send him to http://yourforum.com, instead send him to http://yourforum.com/login?return_path=/ . This way, he will be automatically logged in when he goes to the forum.
- When you logout the user from your main site, call the Discourse API to log the user out from the forum as well.
- If the user logs out from the forum, use the Discourse setting called “logout redirect url” with value such as “http://yourmainsite.com/signout” to make sure that he is logged out from the main site too.
I like this better because (1) this method works even if the forum is on a completely different domain, which is not possible with shared cookies and (2) I do not have to maintain patches anymore. I simply use Discourse off the shelf.
hi @sam, could you elaborate or point me towards an example on how to run an engine inside of Discourse?
for instances, I’m playing around with installing a non-ember CMS engine (GitHub - comfy/comfortable-mexican-sofa: ComfortableMexicanSofa is a powerful Ruby on Rails 5.2+ CMS (Content Management System) Engine) to my Discourse app or building my own.
I’m getting lost on how to properly configure routing for a mountable engine – any insights?
ps, I read through the guide on creating plugins, but I’d rather not use that approach.
That is the only approach that will work, look at the polls plugin shipped with core as an example.
I’m new in the community and I’ve started reading the docs yesterday.
I saw the source code of the poll plugin at - discourse/plugins/poll at master · discourse/discourse · GitHub
I saw that you made an engine inside the plugin.rb
I would like to know if it’s possible to pack a plugin as a rails gem. Because I found it a little bit messy - maintaing all the logic in a single file.
Probably, you can require a gem from a plugin.rb file but not following why you would want that extra level of abstraction, also dev would not be fun
I will try to follow the established conventions. If it starts to bother me I will try the gem approach.
I forgot it was Ruby Code and I could do requires.
recommend you look at some of the larger plugins out there to see examples in the wild.
And congratulations for your work.
I hope to collaborate soon.