OK, I confess that one way I learn is by "monkey see, monkey do".
I have looked at a lot of plugins, and if they worked, analyzed them.
I have seen some that have only a single plugin.rb file with everything in it. * OK for simple plugins I guess, but I'm not a big fan of this when they're more complex.
And I understand that ".handlebars" files are now ".hbs", that ".js" files are now ".js.es6", and that these files are "auto-magically" included. So I guess folder structure isn't all that important? More so it makes sense than it is a necessity?
I'm guessing some of the variations I'm seeing differ depending on whether or not the plugins are doing things RoR or Ember.
I'n any case, I have in the past been known to be inconsistent in such things and have over the years made progress in getter better at being consistent.
If possible, I would like to know the "best practice" conventions so that I won't at some point in the future feel the need to "unlearn" something.
Any pointers on what I should take a look at will be appreciated as I find something like the following confusing.
We are a group of software developers creating a system which includes several components, one of which is Discourse. We are concerned about license restrictions and could not decide if what we are doing is accepted by Discourse license.
We have thought about different approaches to selling our service to clients:
A) SaaS, with every component in our servers and the clients accessing the functionality remotely through an AngularJs application.
B) Keeping public information in our servers but private one in the client servers
C) Deploying the entire solution in client's servers and running the entire system from there.
We believe that option A) is in accordance with the license but we have doubts about option B) and C).
1) We are not selling the software but a service, but the software would need to be installed in client's premises for option B) and C). Is that accepted by the license?
2) Do we need to open source the entire code for the system in case we modify the Discourse code or do we just have to open source the changes made to the Discourse code?
Is there a "watch" level that adds a notification to the little bubble at the top of hte page whenever a thread is updated, but never sends me an email? Probably just want the bubble message to have one notification per updated thread--no need for additional notifications if additional replies.
I log into meta a couple of times a month, and there's a handful of threads that I care about, but I don't want to get an email for them--I get enough email already.
We are looking for a coder to develop a plugin for Discourse to have the following specs: 1. Ability to vote a post Up and Down 2. Sort post based on votes 3. Sort post based on date 4. Sort post based on category 5. Changes in the main layout is needed 6. Ability comment the post/meme (is ok to fork the discussion to permits commenting) 7. Have some modification to the header/menu 8. Ability to share a single post including content preview
Basically we need a set of functionalities to make a http://9gag.com clone using Discourse. The modification should be coded as a plugin to install side by side the Discourse installation. We think this modification would interest a lot of communities. Please send me a PM with the quote. We will crowd-found the sum if needed. We are open to discuss the feature and maybe reduce the scope if too complex.
The ability to see a post's edit history is great for ensuring credibility, as defined in the Muut manifesto.
However, if a user has mistakenly included sensitive data (real names, accounts, passwords etc.) in a post and an admin intervened to edit it, can something be done so that the sensitive data isn't visible in the post history?
Hi, all. I just cloned repo and run autotest. And I got
Finished in 11 minutes 44 seconds (files took 8.74 seconds to load)
4291 examples, 22 failures, 27 pending
Failed examples:
rspec ./spec/components/topic_query_spec.rb:211 # TopicQuery a bunch of topics list_latest sort_order returns the topics in correct order
rspec ./spec/components/topic_query_spec.rb:14 # TopicQuery secure category filters categories out correctly
rspec ./spec/components/search_spec.rb:68 # Search escapes non alphanumeric characters
rspec ./spec/components/search_spec.rb:375 # Search Advanced search can find by status
rspec ./spec/models/topic_spec.rb:830 # Topic scopes #by_most_recently_created returns topics ordered by created_at desc, id desc
rspec ./spec/models/topic_spec.rb:1192 # Topic#listable_count_per_day collect closed interval listable topics count
rspec ./spec/models/top_topic_spec.rb:22 # TopTopic refresh! after calculating should have top topics
rspec ./spec/models/post_spec.rb:663 # Post summary returns the OP and posts above the threshold in summary mode
rspec ./spec/models/post_spec.rb:678 # Post sort_order regular topic defaults to created order
rspec ./spec/components/post_creator_spec.rb:354 # PostCreator existing topic success create correctly
rspec ./spec/components/suggested_topics_builder_spec.rb:91 # SuggestedTopicsBuilder adding results adding topics that are not open adds archived and closed, but not invisible topics
rspec ./spec/components/suggested_topics_builder_spec.rb:101 # SuggestedTopicsBuilder adding results category definition topics doesn't add a category definition topic
rspec ./spec/components/suggested_topics_builder_spec.rb:76 # SuggestedTopicsBuilder adding results adding topics added the result correctly
rspec ./spec/components/onebox/engine/discourse_local_onebox_spec.rb:20 # Onebox::Engine::DiscourseLocalOnebox for a link to a post returns a link if post isn't found
rspec ./spec/components/cooked_post_processor_spec.rb:162 # CookedPostProcessor.post_process_images topic image adds a topic image if there's one in the post
rspec ./spec/models/topic_user_spec.rb:226 # TopicUser can scope by tracking
rspec ./spec/models/report_spec.rb:36 # Report topic report no topics returns an empty report
rspec ./spec/models/report_spec.rb:80 # Report topic report with topics returns total data
rspec ./spec/models/report_spec.rb:36 # Report post report no posts returns an empty report
rspec ./spec/models/report_spec.rb:80 # Report post report with posts returns total data
rspec ./spec/models/report_spec.rb:145 # Report private messages topic report).to not include private messages
rspec ./spec/models/report_spec.rb:153 # Report private messages post report).to not include private messages
We are using SSO for logging in users to our discourse instance. What we want is that user should also be logged out from forum, if he logs out on the main app, and vice versa. The way we are achieving this is, we call the Discourse API to logout when the user logs out on main app to log out from Discourse and the Discourse logout url points to our app logout url.
The only issue occurs is that using the Discourse API, all sessions on all devices are logged out. If we disable strict logout, the logout via API doesn't work.
Would it be possible to achieve this functionality so that we can only logout users on forum, who logged in with a particular session on app? Or else, if somebody could guide how we can achieve such a functionality via a custom plugin.
I'm working on setting up quotas relating to docker instances. It seems this is a combination of the shared directory and docker images, but is this all there is to it? This is on my list of things to do today, but until I know exactly what to account for, I'll have to put it on the back burner.
Who here knows with certainty which files/directories can account for all data relating to an instance of discourse on a docker install? A related question would be how to destroy all traces of an instance. I would gather removing first the containers, then the shared directories, then the image would get rid of the bulk. Is this correct?
I've installed discourse on my own pc running ubuntu 14.04, and another virtual machine running centos 6.6, both works fine. Now the problem comes that When I try to install discourse on a server running CentOS 6.5, everytme I run /var/discourse/launcher bootstrap app, the system crashes and reboot automatically.
Could someone help ? Where should I check for the error log please?
The kernel version is 2.6.32-431.el6.x86_64, I've checked the docker's document, docker should be ok to run on CentOS 6.5 with kernel version 2.6.32-431.
When I drag a bunch of files at once to upload them, I then have to go back and put in line breaks manually so they do not wrap. This is a bit tricky because it's all HTML code.
(aside: is there not a way to make these uploads more user-friendly within markdown? eg just show the resulting URL which then converts automagically to the format below if it's not a file that can be displayed in a onebox?)
A Discourse Plugin to support nestable BBCode tags spawning across multiple paragraphs in your posts. By default, support is provided for the following tags:
[hide=], [nsfw] : works similarly to the discourse-details plugin
[color=] : lets you color text
[rainbow] : colors text with rainbow colors.
[humanism],[corporate],[smartass],[alpha] : special fonts.
[spoiler] : similar to the discourse-spoiler tag
It also features auto-complete to the composer for these tags.
Other features/improvements
fully nestable: you can put colored text inside a hide that is within a spoiler, etc.
spoiler works on links and color text, you can put a hide inside a spoiler.
implements a standalone BBCode interpreter outside Discourse's Markdown pipeline.
At the beginning, I wanted to put the parser into its own separate plugin so that each special tag can be in its own plugin, but my initial attempt at packaging the parser into an es6 module failed:
It's not impossible though, so that in the future I might split each tag's functionality into a separate plugin.
Usage
By pressing [ into the composer, the auto-complete dropdown kicks in to let you choose the tag you want. BBCodes have two modes: block and inline.
block: puts its content in a new <div> block.
inline: puts the first line of its content within the current the line, and each new line in its own nestable <span> tag.
By default, hide and nsfw have block semantics. The other tags have inline semantics by default, unless a line-break is added after the opening tag.
Hey there! We've been working with the amazing support of the Discourse team on the migration of our two communities (TuDiabetes.org and EsTuDiabetes.org) from Ning to Discourse. TuDiabetes.org is already on Discourse, and we're in the process of migrating EsTuDiabetes.
Since both communities are 8+ years old, we were fortunate to be able to get help on the SEO front from an SEO expert that has helped guide our steps to ensure that our previous SEO rankings are preserved as much as possible.
Currently there doesn't seem to be any <H1> tags implemented on Discourse (at least not structurally). This is a missed opportunity, since this tag gets important weight by search engines. So he recommended the following:
Here's what I did to install a successful installation of Discourse for multiple instances on a dedicated server that uses Nginx and Apache.
I decided to create a new topic since my installation seems to be a little unique from what I have seen others having to go through. I am very new to Nginx webservers and thought this might help others who may be struggling to connect the dots. I'm also at a beginner level when it comes to using the terminal to access my server, I still have to look up commands for most of the stuff I want to do, but I am finding it so much faster and powerful vs FTP. I still use FTP for a visual representation to locate files and text editing (I don't like vi or nano editing in the terminal) I use Coda (on a Mac) as my text editor so I have direct access to the server. Which means I can live edit my files just as one would do in the terminal.
I'm using ServerPilot as the control panel to manage my websites on an Ubuntu 14.04 installation. ServerPilot uses Nginx as a reverse proxy in front of the Apache webserver. At first I was a bit confused with this, and basically what they have done is use Nginx as the hub where website requests come into the Nginx server and get routed to Apache to be executed and then back through Nginx to be displayed. This proved to cause some trouble with my installation as I had to figure out where all the config files and such were located.
I started with this tutorial for installing the first instance of Discourse as a dev version ...
Pay special attention to the TCP/IP ports as that was the first place I stumbled, and I see a lot of other posts in the forums from other people who have done the same. If you leave them at the default "80:80" you may get an error stating that port is already in use.
Change the first half of the ports to a port that is not being used, I used 85
This got me through the installation with no errors, but when I went to the url I setup for the forum nothing was showing up. I could connect to the forum using the IP with the port number. Since the forum doesn't need Apache, I found the conf file that was directing the site to the Apache server with a local IP. I changed this IP to the forum IP with port number.
The path to that section (if you're also using ServerPilot)
/etc/nginx-sp/vhosts.d/main.conf (ServerPilot recommends that you change the name of the main.conf file so it is not overwritten on updates)
Now I had a working instance of Discourse, and here's what I did to set up the multiple instances.
I started with this tutorial, but I was having trouble understanding how the structure was supposed to be setup
If you scroll down to this section ...
This is where I based my installation from, however I did not use the hook settings in the original post. Instead, I duplicated the app.yml file for each site I was creating (only two sites) and renamed them for site specific use. I'll use the example - site1 and site2.
So in the /var/discourse/containers the files there are as such ...
app.yml site1.yml site2.yml
(these are your separate containers, which was a term that I didn't understand at first)
For each file you need to make sure to change the following areas to be specific to your instance ...
## which TCP/IP ports should this container expose?
expose:
- "127.0.0.1:4000:80" # fwd host port 80 to container port 80 (http)
- "2222:22" # fwd host port 2222 to container port 22 (ssh)
Notice I changed the first port on both, otherwise you will get port conflict errors.
## TODO: List of comma delimited emails that will be made admin and developer
## on initial signup example 'user1@example.com,user2@example.com'
DISCOURSE_DEVELOPER_EMAILS: 'changeme@site1.com'
change the developer email to the email you will use for the admin account
In the mailserver section that follows, be sure to change any settings that are specific to this site such as the username and password. I ended up using Mandrill so the smtp and port numbers were the same for all instances, but I created two accounts. (one for each website)
This next section to edit is key to you getting a separate database for each site. Be sure to change the 'yoursite' to something unique to each site.
## These containers are stateless, all data is stored in /shared
volumes:
- volume:
host: /var/discourse/shared/yoursite
guest: /shared
- volume:
host: /var/discourse/shared/yoursite/log/var-log
guest: /var/log
The next thing to do is make sure you have the Nginx proxy URL (the one that is pointing to Apache) changed to match the port you configured in the TCP/IP section. So using the port I used as an example your file should look like this and as I mentioned above, ServerPilot recommends changing the name of the file if you MUST edit (that's why they give the do not edit warning)
###############################################################################
# DO NOT EDIT THIS FILE.
#
# Your changes to this file will be overwritten by ServerPilot.
#
# For information on how to customize nginx settings, see
# https://serverpilot.io/community/articles/customize-nginx-settings.html
###############################################################################
# Send all requests to apache.
location / {
proxy_pass http://localhost:4000;
Be sure to restart Nginx if you make changes to the .conf file (I forgot to do this) and with ServerPilot the restart command is a little different than I had seen elsewhere, this is what did it for me ...
service nginx-sp restart
Then start bootstrapping your containers. (do this for each site your configured) Enter these commands in the terminal
./launcher bootstrap site1 (after that is done) ./launcher start site1
You should now be able to load the URL you have for the forum and see your Discourse forum.
I ended up with one of the sites not recognizing the Admin account when I registered with the developer email, and I found I had a stray character at the end of the URL that caused the email to be different. I then went into the /var/discourse/shared/ directory and deleted the folder matching that site. Then I used ./launcher destroy site2 command followed by ./launcher bootstrap site2 and then ./launcher start site2 I'm not sure a rebuild would work since you want the database to be recreated.
I know I probably over-simplified this is some areas, but from what I have seen in other topics/threads, some people need instructions that are overly simplified
Please let me know if I left any holes, or there is any need for clarification as long as you understand I can only speak for what worked for me since I barely understand this myself HA!!!
One more thing ... does any one see any issue with duplicating the app.yml file to be used in this way? It seems this would work perfectly for updating as well.
It's that time of the year again: I strongly dislike how the "x users liked this" text adds a newline with whitespace and crowds up a page if a lot of short posts have received likes.
I really appreciate the way this emphasises Likes without making it a disturbance. The heart and text are also more harmonical when they share the same line.
The big troublemaker was always "N replies", which occupies the left space. I removed the text and moved it directly adjacent to "Reply". See Sam's post in the middle.
I don't find the lack of symmetry to be a big problem, but it could be improved by making the N-replies button the equivalent size of 1 or 2 icons.
Here's the difference on narrow mobile (which excludes "N replies" entirely):
Hi, I am trying to deploy discourse using capistrano 3. 4. I believe I have done all necessary changes but getting some errors while deploying to Ubuntu Server. I have tried to figure it out but still I didn't find any related answer.
