Our Discourse instance is private and we use the discourse-slackdoor plugin to allow Slack to unfurl the contents of posts that are shared in our private Slack.
But Slack still tries to do it’s own unfurling of the links, which is kind of annoying because all it is able to get is the site title and description.
So every link shared in Slack ends up getting the same, additional attachment from Slack that looks kinda like this:
I’m getting notified by discourse’s system user about that my backup has failed. On the doc it says that Discourse accepts Postgres 9.3+ versions and i’m using 9.6.3.
[2017-12-02 03:32:09] [STARTED]
[2017-12-02 03:32:09] 'system' has started the backup!
[2017-12-02 03:32:09] Marking backup as running...
[2017-12-02 03:32:09] Making sure '/var/www/discourse/tmp/backups/default/2017-12-02-033209' exists...
[2017-12-02 03:32:09] Making sure '/var/www/discourse/public/backups/default' exists...
[2017-12-02 03:32:09] Pausing sidekiq...
[2017-12-02 03:32:09] Waiting for sidekiq to finish running jobs...
[2017-12-02 03:32:09] Dumping the public schema of the database...
[2017-12-02 03:32:09] perl: warning: Setting locale failed.
[2017-12-02 03:32:09] perl: warning: Please check that your locale settings:
[2017-12-02 03:32:09] LANGUAGE = (unset),
[2017-12-02 03:32:09] LC_ALL = (unset),
[2017-12-02 03:32:09] LANG = "pt_BR.UTF-8"
[2017-12-02 03:32:09] are supported and installed on your system.
[2017-12-02 03:32:09] perl: warning: Falling back to the standard locale ("C").
[2017-12-02 03:32:09] pg_dump: server version: 9.6.3; pg_dump version: 9.5.10
[2017-12-02 03:32:09] pg_dump: aborting because of server version mismatch
[2017-12-02 03:32:09] EXCEPTION: pg_dump failed
[2017-12-02 03:32:09] /var/www/discourse/lib/backup_restore/backuper.rb:170:in `dump_public_schema'
/var/www/discourse/lib/backup_restore/backuper.rb:35:in `run'
/var/www/discourse/lib/backup_restore/backup_restore.rb:163:in `block in start!'
/var/www/discourse/lib/backup_restore/backup_restore.rb:160:in `fork'
/var/www/discourse/lib/backup_restore/backup_restore.rb:160:in `start!'
/var/www/discourse/lib/backup_restore/backup_restore.rb:15:in `backup!'
/var/www/discourse/app/jobs/regular/create_backup.rb:8:in `execute'
/var/www/discourse/app/jobs/base.rb:134:in `block (2 levels) in perform'
/var/www/discourse/vendor/bundle/ruby/2.4.0/gems/rails_multisite-1.1.2/lib/rails_multisite/connection_management.rb:77:in `with_connection'
/var/www/discourse/app/jobs/base.rb:129:in `block in perform'
/var/www/discourse/app/jobs/base.rb:125:in `each'
/var/www/discourse/app/jobs/base.rb:125:in `perform'
/var/www/discourse/vendor/bundle/ruby/2.4.0/gems/sidekiq-5.0.5/lib/sidekiq/processor.rb:188:in `execute_job'
/var/www/discourse/vendor/bundle/ruby/2.4.0/gems/sidekiq-5.0.5/lib/sidekiq/processor.rb:170:in `block (2 levels) in process'
/var/www/discourse/vendor/bundle/ruby/2.4.0/gems/sidekiq-5.0.5/lib/sidekiq/middleware/chain.rb:128:in `block in invoke'
/var/www/discourse/lib/sidekiq/pausable.rb:80:in `call'
/var/www/discourse/vendor/bundle/ruby/2.4.0/gems/sidekiq-5.0.5/lib/sidekiq/middleware/chain.rb:130:in `block in invoke'
/var/www/discourse/vendor/bundle/ruby/2.4.0/gems/sidekiq-5.0.5/lib/sidekiq/middleware/chain.rb:133:in `invoke'
/var/www/discourse/vendor/bundle/ruby/2.4.0/gems/sidekiq-5.0.5/lib/sidekiq/processor.rb:169:in `block in process'
/var/www/discourse/vendor/bundle/ruby/2.4.0/gems/sidekiq-5.0.5/lib/sidekiq/processor.rb:141:in `block (6 levels) in dispatch'
/var/www/discourse/vendor/bundle/ruby/2.4.0/gems/sidekiq-5.0.5/lib/sidekiq/job_retry.rb:97:in `local'
/var/www/discourse/vendor/bundle/ruby/2.4.0/gems/sidekiq-5.0.5/lib/sidekiq/processor.rb:140:in `block (5 levels) in dispatch'
/var/www/discourse/vendor/bundle/ruby/2.4.0/gems/sidekiq-5.0.5/lib/sidekiq.rb:36:in `block in <module:Sidekiq>'
/var/www/discourse/vendor/bundle/ruby/2.4.0/gems/sidekiq-5.0.5/lib/sidekiq/processor.rb:136:in `block (4 levels) in dispatch'
/var/www/discourse/vendor/bundle/ruby/2.4.0/gems/sidekiq-5.0.5/lib/sidekiq/processor.rb:204:in `stats'
/var/www/discourse/vendor/bundle/ruby/2.4.0/gems/sidekiq-5.0.5/lib/sidekiq/processor.rb:131:in `block (3 levels) in dispatch'
/var/www/discourse/vendor/bundle/ruby/2.4.0/gems/sidekiq-5.0.5/lib/sidekiq/job_logger.rb:7:in `call'
/var/www/discourse/vendor/bundle/ruby/2.4.0/gems/sidekiq-5.0.5/lib/sidekiq/processor.rb:130:in `block (2 levels) in dispatch'
/var/www/discourse/vendor/bundle/ruby/2.4.0/gems/sidekiq-5.0.5/lib/sidekiq/job_retry.rb:72:in `global'
/var/www/discourse/vendor/bundle/ruby/2.4.0/gems/sidekiq-5.0.5/lib/sidekiq/processor.rb:129:in `block in dispatch'
/var/www/discourse/vendor/bundle/ruby/2.4.0/gems/sidekiq-5.0.5/lib/sidekiq/logging.rb:44:in `with_context'
/var/www/discourse/vendor/bundle/ruby/2.4.0/gems/sidekiq-5.0.5/lib/sidekiq/logging.rb:38:in `with_job_hash_context'
/var/www/discourse/vendor/bundle/ruby/2.4.0/gems/sidekiq-5.0.5/lib/sidekiq/processor.rb:128:in `dispatch'
/var/www/discourse/vendor/bundle/ruby/2.4.0/gems/sidekiq-5.0.5/lib/sidekiq/processor.rb:168:in `process'
/var/www/discourse/vendor/bundle/ruby/2.4.0/gems/sidekiq-5.0.5/lib/sidekiq/processor.rb:85:in `process_one'
/var/www/discourse/vendor/bundle/ruby/2.4.0/gems/sidekiq-5.0.5/lib/sidekiq/processor.rb:73:in `run'
/var/www/discourse/vendor/bundle/ruby/2.4.0/gems/sidekiq-5.0.5/lib/sidekiq/util.rb:16:in `watchdog'
/var/www/discourse/vendor/bundle/ruby/2.4.0/gems/sidekiq-5.0.5/lib/sidekiq/util.rb:25:in `block in safe_thread'
[2017-12-02 03:32:09] Notifying 'system' of the end of the backup...
the sitemap plugin of discourse do not update the sitemap urls to https:// (as usually seen in wordpress). It still shows http://. Please solve this issue. As it helps in faster https:// indexing after migrating to SSL
I wonder if someone here has set up Mastodon so it reuses the data and redis images from Discourse docker, or how to do it.
I wish we document it, since there’s no reason why running Mastodon from Docker would create extra instances for services that already come with Discourse. Therefore this post is set to evolve and integrate the step-by-step modifications to Mastodon install so that it can co-exist with an existing Discourse multisites install with separate containers for PostgreSQL and Redis.
Then it can also include extra documentation, such as:
adding a user field for the local Mastodon instance
integrating the local Mastodon instance feeds into a dedicated Discourse category, with a topic for each user feed (I see the autobot plugin may do that, but I’d rather use an ATOM/RSS specific plugin for that. Should we think about a dedicated Mastodon plugin?)
One of my discoure install has particular majority of users using Microsoft outlook/hotmail email accounts and the microsoft spam rejection system does some weird filtering and puts almost every email sent via relay smtp (e.g. services like mailgun, elasticemail etc.) This had been creating a lot of trouble lately. I’ve spent days talking to mailgun support and after all the logs and tests, their final word was to try sending mails via their API instead of SMTP credentials.
I believe this may be an issue with the server’s originating IP. When sending via SMTP, the server that creates the message has its IP added as the “originating IP” into the headers. If the IP is not properly configured for SMTP, the recipient’s filters may flag the messages as Spam. I would recommend sending via our API instead. Messages sent through our API will use the sending IP assigned by Mailgun as the Originating IP, instead of the IP for your server.
as most reputable email services support API, can discourse support emails via their API instead of SMTP?
Maybe an odd request, but I’m interested in creating an “opt in” poll that just has one option, but the poll is throwing an error. Is there any way, even a workaround, that can work?
I think the users on our Discourse forum have discovered a bug. One of our user’s accounts was silenced and their place in the Top Likes Received (daily) leaderboard (/u?period=daily) has not changed at all since. They have been frozen there with the same amount of Likes as they had the day they were silenced, leading us to believe that there’s an issue with silenced accounts not having their stats updated on the leaderboards.
i am doing a trial for a nonprofit group with a lot of senior citizen members who are not so cyber social savvy. Is there a chat client already integrated in Discourse or does it need to be external via an integration?
If the latter what chat clients are super simple, safe and close to free? Is there a reason that Google hangouts is not on the integration list?
SELECT username, trust_level, last_seen_at from users
WHERE trust_level_locked = true AND trust_level != 4
GROUP BY users.trust_level, users.last_seen_at, users.username
ORDER BY trust_level asc
It returns a list among which, 821 TL1s. < groan >
If I understand correctly, that’s because we assign customers to TL1 even if they haven’t earned it, so there’s some sort of auto-lock going on.
So I start working my way through the list to unlock them.
I unlock several and re-run the query.
Everyone I’ve unlocked still shows up on the query results. I’ve double-checked, each profile in admin/users/ is unlocked.
How do I write a query that will show me only those users whose trust level is currently locked?
I’m running a pagespeed test on my site, discuss.endurancelab.fit. One result indicates the logo is not cached. Is there something I can do to cache the logo, or should I forget this?
I have been using discourse for a long time, running fine on RHEL 7. I waited about 2 - 3 months and upgraded from 1.8 something to the latest version. CHAOS has ensued. The filesystem check has forced me to abandon RHEL entirely. No amount of adding extra hard drives and trying to modify the backing filesystem to allow d_type worked (even with a new hard drive set up for ext4 and xfs ftype=1). Nothing changed the running docker’s backing filesystem. So I switched to Ubuntu. I still can’t get things running. Amazon simple email service has forward slashes in their generated passwords. Ok, so I make a fake password to start. I tried using my old app.yml file. Ha! No way. So, I finally give up and run through an entirely fresh install. That seems to get the juices flowing but now I’m left trying to restore my old data and plugins and pray everything works. Somehow I doubt I’ll have any luck. It may not be intentional sabotage, but it sure seems like the discourse team is trying extra hard to make running discourse yourself very hard.
update: yep, i was right. Adding the plugins and running rebuild I now get “undefined method `skip_before_filter’” and the build terminates unsuccessfully.
For moderators, some of this space is taken by the “official warning” checkbox.
Can I revisit an old suggestion? I think the composer would work a lot better if the “Submit” button is positioned absolutely at the top of the screen, and the user is able to scroll freely vertically down through the PM with the button visible at all tiles.
In the “Nextdoor” app - a native mobile forum - their composer looks like this, and is much easier to use:
Is there any reason I should NOT enable compression on cloudfront by selecting YES to Compress Objects Automatically?
I read here on the forum that compression should be handled elsewhere, but I have not changed any settings that would impact built in compression handled by Discourse.
We report results from an exploratory analysis examining “last-minute” self-censorship, or content that is filtered after being written, on Facebook. We collected data from 3.9 million users over 17 days and associate self-censorship behavior with features describing users, their social graph, and the interactions between them. Our results indicate that 71% of users exhibited some level of last-minute self-censorship in the time period, and provide specific evidence supporting the theory that a user’s “perceived audience” lies at the heart of the issue: posts are censored more frequently than comments, with status updates and posts directed at groups censored most frequently of all sharing use cases investigated. Furthermore, we find that: people with more boundaries to regulate censor more; males censor more posts than females and censor even more posts with mostly male friends than do females, but censor no more comments than females; people who exercise more control over their audience censor more content; and, users with more politically and age diverse friends censor less, in general.
Do you show the list of live users on your website, which is part of your community?
For example, you might run Discourse and WordPress. Then the question is regarding WordPress: do you show which users are live (online)? If you don’t, why not? If you do, then:
is it on the home page only, or some specific page?
is it static or live content? (live gets autoupdated every N seconds)
Hello fellow users. I have a new install and I have checked the box for “Suppress this category from the homepage.” for some subcategories, which works as intended for the HOMEPAGE. But this option also hides it from the /categories page.This behavior is not expected, as it should hide it from the main page, but it should still show it under /categories page.
We’ve had quite a few reports on PNG’s failing image uploads on our install at v1.9.0.beta15 +27. It seems to only be certain PNG’s and not just based on size. It is particularly unfortunate for us because it now fails on the screenshots of a game the forum is based on, so many users are finding the issue. It has only recently started to happen (my guess would be around the Rails 5 or so update for 1.9, but not sure).
I’ve recreated a test case on try.discourse.com and will try to recreate here.
Do you know of any cases when a community was built first by enthusiasts, and only then came an idea for industry-specific software, then the software was built and sold successfully to the community?