@random1 wrote:

I’m having some trouble configuring the DNS. I followed the 30-minute install instructions including choosing the domain. I also added CNAME to point to my domain. I followed the instructions provided here https://meta.discourse.org/t/configure-your-domain-name-for-hosted-discourse/21827

The problem is that I still can’t access Discourse using my domain/subdomain. I can only access it using the IP address. Any help will be appreciated.

Posts: 16

Participants: 5

Read full topic

@Yohan wrote:

Hi,
I have a problem with the polls. When i use Discourse in my localhost, the polls works very well (i can choose my answer). But when i launch my server with the command “bundle exec rails server -d --binding=0.0.0.0”, my polls are displayed but the buttons are NOT displayed, i can’t do any action…
There are some parameters who need to fix? The development mode can be the problem?
Ty for your help, and sorry for my english…

Posts: 1

Participants: 1

Read full topic

@Sergiodev wrote:

Hi everyone.

I want to know if i can retrieve a login session variable from the Discourse login, to use it in another route with NodeJS installed,
so they can only acccess to the content of this page if they are logged in on the forum.

Regards.

Posts: 2

Participants: 2

Read full topic

@alehandrof wrote:

I’m guilty of trying something weird. But the system does allow it

All the users in our Discourse are automatically members of groups based on their institutional affiliation (@myuni.edu or whatever). I’ve made these institutional groups the “primary” groups. I did this because I’m using the group’s “title” field to convey users’ institutional affiliation.

Here’s what it looks like in a topic:

ACRL_Pilot_-_Discussions_-_AMICAL_Connect.png1536x182 10.1 KB

For various reasons, I don’t want these groups to be visible to users. So I’ve made them hidden them (using the Group is visible to all users option).

Unfortunately, when someone clicks on the institution’s name (as shown in the above screenshot) they get taken to a non-existent page (/groups/myuni or whatever). I had tested this at some point and I could have sworn that these titles became unclickable if the group was made hidden.

Next steps:

• Do I need to re-bake all the posts (or whatever the Discourse term turns out to be)?
• Otherwise, it would be swell if these titles can be made non-clickable when the group is not visible to users.

Posts: 4

Participants: 3

Read full topic

@Freso wrote:

I’m trying to move this topic:

Into this topic:

And I keep getting «There was an error moving posts into that topic.» which is not very helpful in determining why it won’t move it. Is there some kind of restriction in place to prevent moving topic OPs into other topics? Or what else might be in play here?

In the log I see NoMethodError (undefined method ``id' for nil:NilClass) /var/www/discourse/app/models/post_action.rb:317:in ``copy' (’`'s changed to ‘``’ since you apparently can’t backslash escape them.):

/var/www/discourse/app/models/post_action.rb:317:in `copy'
/var/www/discourse/app/models/post_mover.rb:96:in `create_first_post'
/var/www/discourse/app/models/post_mover.rb:77:in `block in move_each_post'
/var/www/discourse/vendor/bundle/ruby/2.4.0/gems/activerecord-4.2.8/lib/active_record/relation/delegation.rb:46:in `each'
/var/www/discourse/vendor/bundle/ruby/2.4.0/gems/activerecord-4.2.8/lib/active_record/relation/delegation.rb:46:in `each'
/var/www/discourse/app/models/post_mover.rb:76:in `move_each_post'
/var/www/discourse/app/models/post_mover.rb:46:in `move_posts_to'
/var/www/discourse/app/models/post_mover.rb:18:in `block in to_topic'
/var/www/discourse/vendor/bundle/ruby/2.4.0/gems/activerecord-4.2.8/lib/active_record/connection_adapters/abstract/database_statements.rb:213:in `block in transaction'
/var/www/discourse/vendor/bundle/ruby/2.4.0/gems/activerecord-4.2.8/lib/active_record/connection_adapters/abstract/transaction.rb:184:in `within_new_transaction'
/var/www/discourse/vendor/bundle/ruby/2.4.0/gems/activerecord-4.2.8/lib/active_record/connection_adapters/abstract/database_statements.rb:213:in `transaction'
/var/www/discourse/vendor/bundle/ruby/2.4.0/gems/activerecord-4.2.8/lib/active_record/transactions.rb:220:in `transaction'
/var/www/discourse/app/models/post_mover.rb:17:in `to_topic'
/var/www/discourse/app/models/topic.rb:797:in `move_posts'
/var/www/discourse/app/controllers/topics_controller.rb:518:in `merge_topic'
/var/www/discourse/vendor/bundle/ruby/2.4.0/gems/actionpack-4.2.8/lib/action_controller/metal/implicit_render.rb:4:in `send_action'
/var/www/discourse/vendor/bundle/ruby/2.4.0/gems/actionpack-4.2.8/lib/abstract_controller/base.rb:198:in `process_action'
/var/www/discourse/vendor/bundle/ruby/2.4.0/gems/actionpack-4.2.8/lib/action_controller/metal/rendering.rb:10:in `process_action'
/var/www/discourse/vendor/bundle/ruby/2.4.0/gems/actionpack-4.2.8/lib/abstract_controller/callbacks.rb:20:in `block in process_action'
/var/www/discourse/vendor/bundle/ruby/2.4.0/gems/activesupport-4.2.8/lib/active_support/callbacks.rb:117:in `call'
/var/www/discourse/vendor/bundle/ruby/2.4.0/gems/activesupport-4.2.8/lib/active_support/callbacks.rb:555:in `block (2 levels) in compile'
/var/www/discourse/vendor/bundle/ruby/2.4.0/gems/activesupport-4.2.8/lib/active_support/callbacks.rb:505:in `call'
/var/www/discourse/vendor/bundle/ruby/2.4.0/gems/activesupport-4.2.8/lib/active_support/callbacks.rb:92:in `__run_callbacks__'
/var/www/discourse/vendor/bundle/ruby/2.4.0/gems/activesupport-4.2.8/lib/active_support/callbacks.rb:778:in `_run_process_action_callbacks'
/var/www/discourse/vendor/bundle/ruby/2.4.0/gems/activesupport-4.2.8/lib/active_support/callbacks.rb:81:in `run_callbacks'
/var/www/discourse/vendor/bundle/ruby/2.4.0/gems/actionpack-4.2.8/lib/abstract_controller/callbacks.rb:19:in `process_action'
/var/www/discourse/vendor/bundle/ruby/2.4.0/gems/actionpack-4.2.8/lib/action_controller/metal/rescue.rb:29:in `process_action'
/var/www/discourse/vendor/bundle/ruby/2.4.0/gems/actionpack-4.2.8/lib/action_controller/metal/instrumentation.rb:32:in `block in process_action'
/var/www/discourse/vendor/bundle/ruby/2.4.0/gems/activesupport-4.2.8/lib/active_support/notifications.rb:164:in `block in instrument'
/var/www/discourse/vendor/bundle/ruby/2.4.0/gems/activesupport-4.2.8/lib/active_support/notifications/instrumenter.rb:20:in `instrument'
/var/www/discourse/vendor/bundle/ruby/2.4.0/gems/activesupport-4.2.8/lib/active_support/notifications.rb:164:in `instrument'
/var/www/discourse/vendor/bundle/ruby/2.4.0/gems/actionpack-4.2.8/lib/action_controller/metal/instrumentation.rb:30:in `process_action'
/var/www/discourse/vendor/bundle/ruby/2.4.0/gems/actionpack-4.2.8/lib/action_controller/metal/params_wrapper.rb:250:in `process_action'
/var/www/discourse/vendor/bundle/ruby/2.4.0/gems/activerecord-4.2.8/lib/active_record/railties/controller_runtime.rb:18:in `process_action'
/var/www/discourse/vendor/bundle/ruby/2.4.0/gems/actionpack-4.2.8/lib/abstract_controller/base.rb:137:in `process'
/var/www/discourse/vendor/bundle/ruby/2.4.0/gems/actionview-4.2.8/lib/action_view/rendering.rb:30:in `process'
/var/www/discourse/vendor/bundle/ruby/2.4.0/gems/rack-mini-profiler-0.10.5/lib/mini_profiler/profiling_methods.rb:76:in `block in profile_method'
/var/www/discourse/vendor/bundle/ruby/2.4.0/gems/actionpack-4.2.8/lib/action_controller/metal.rb:196:in `dispatch'
/var/www/discourse/vendor/bundle/ruby/2.4.0/gems/actionpack-4.2.8/lib/action_controller/metal/rack_delegation.rb:13:in `dispatch'
/var/www/discourse/vendor/bundle/ruby/2.4.0/gems/actionpack-4.2.8/lib/action_controller/metal.rb:237:in `block in action'
/var/www/discourse/vendor/bundle/ruby/2.4.0/gems/actionpack-4.2.8/lib/action_dispatch/routing/route_set.rb:74:in `dispatch'
/var/www/discourse/vendor/bundle/ruby/2.4.0/gems/actionpack-4.2.8/lib/action_dispatch/routing/route_set.rb:43:in `serve'
/var/www/discourse/vendor/bundle/ruby/2.4.0/gems/actionpack-4.2.8/lib/action_dispatch/journey/router.rb:43:in `block in serve'
/var/www/discourse/vendor/bundle/ruby/2.4.0/gems/actionpack-4.2.8/lib/action_dispatch/journey/router.rb:30:in `each'
/var/www/discourse/vendor/bundle/ruby/2.4.0/gems/actionpack-4.2.8/lib/action_dispatch/journey/router.rb:30:in `serve'
/var/www/discourse/vendor/bundle/ruby/2.4.0/gems/actionpack-4.2.8/lib/action_dispatch/routing/route_set.rb:817:in `call'
/var/www/discourse/vendor/bundle/ruby/2.4.0/gems/rack-protection-1.5.3/lib/rack/protection/frame_options.rb:31:in `call'
/var/www/discourse/vendor/bundle/ruby/2.4.0/gems/omniauth-1.6.1/lib/omniauth/strategy.rb:189:in `call!'
/var/www/discourse/vendor/bundle/ruby/2.4.0/gems/omniauth-1.6.1/lib/omniauth/strategy.rb:167:in `call'
/var/www/discourse/vendor/bundle/ruby/2.4.0/gems/omniauth-1.6.1/lib/omniauth/strategy.rb:189:in `call!'
/var/www/discourse/vendor/bundle/ruby/2.4.0/gems/omniauth-1.6.1/lib/omniauth/strategy.rb:167:in `call'
/var/www/discourse/vendor/bundle/ruby/2.4.0/gems/omniauth-1.6.1/lib/omniauth/strategy.rb:189:in `call!'
/var/www/discourse/vendor/bundle/ruby/2.4.0/gems/omniauth-1.6.1/lib/omniauth/strategy.rb:167:in `call'
/var/www/discourse/vendor/bundle/ruby/2.4.0/gems/omniauth-1.6.1/lib/omniauth/strategy.rb:189:in `call!'
/var/www/discourse/vendor/bundle/ruby/2.4.0/gems/omniauth-1.6.1/lib/omniauth/strategy.rb:167:in `call'
/var/www/discourse/vendor/bundle/ruby/2.4.0/gems/omniauth-1.6.1/lib/omniauth/strategy.rb:189:in `call!'
/var/www/discourse/vendor/bundle/ruby/2.4.0/gems/omniauth-1.6.1/lib/omniauth/strategy.rb:167:in `call'
/var/www/discourse/vendor/bundle/ruby/2.4.0/gems/omniauth-1.6.1/lib/omniauth/strategy.rb:189:in `call!'
/var/www/discourse/vendor/bundle/ruby/2.4.0/gems/omniauth-1.6.1/lib/omniauth/strategy.rb:167:in `call'
/var/www/discourse/vendor/bundle/ruby/2.4.0/gems/omniauth-1.6.1/lib/omniauth/strategy.rb:189:in `call!'
/var/www/discourse/vendor/bundle/ruby/2.4.0/gems/omniauth-1.6.1/lib/omniauth/strategy.rb:167:in `call'
/var/www/discourse/vendor/bundle/ruby/2.4.0/gems/omniauth-1.6.1/lib/omniauth/builder.rb:63:in `call'
/var/www/discourse/vendor/bundle/ruby/2.4.0/gems/rack-1.6.8/lib/rack/conditionalget.rb:38:in `call'
/var/www/discourse/vendor/bundle/ruby/2.4.0/gems/rack-1.6.8/lib/rack/head.rb:13:in `call'
/var/www/discourse/lib/middleware/anonymous_cache.rb:138:in `call'
/var/www/discourse/vendor/bundle/ruby/2.4.0/gems/actionpack-4.2.8/lib/action_dispatch/middleware/params_parser.rb:27:in `call'
/var/www/discourse/vendor/bundle/ruby/2.4.0/gems/actionpack-4.2.8/lib/action_dispatch/middleware/flash.rb:260:in `call'
/var/www/discourse/vendor/bundle/ruby/2.4.0/gems/rack-1.6.8/lib/rack/session/abstract/id.rb:225:in `context'
/var/www/discourse/vendor/bundle/ruby/2.4.0/gems/rack-1.6.8/lib/rack/session/abstract/id.rb:220:in `call'
/var/www/discourse/vendor/bundle/ruby/2.4.0/gems/actionpack-4.2.8/lib/action_dispatch/middleware/cookies.rb:560:in `call'
/var/www/discourse/vendor/bundle/ruby/2.4.0/gems/activerecord-4.2.8/lib/active_record/query_cache.rb:36:in `call'
/var/www/discourse/vendor/bundle/ruby/2.4.0/gems/activerecord-4.2.8/lib/active_record/connection_adapters/abstract/connection_pool.rb:653:in `call'
/var/www/discourse/vendor/bundle/ruby/2.4.0/gems/actionpack-4.2.8/lib/action_dispatch/middleware/callbacks.rb:29:in `block in call'
/var/www/discourse/vendor/bundle/ruby/2.4.0/gems/activesupport-4.2.8/lib/active_support/callbacks.rb:88:in `__run_callbacks__'
/var/www/discourse/vendor/bundle/ruby/2.4.0/gems/activesupport-4.2.8/lib/active_support/callbacks.rb:778:in `_run_call_callbacks'
/var/www/discourse/vendor/bundle/ruby/2.4.0/gems/activesupport-4.2.8/lib/active_support/callbacks.rb:81:in `run_callbacks'
/var/www/discourse/vendor/bundle/ruby/2.4.0/gems/actionpack-4.2.8/lib/action_dispatch/middleware/callbacks.rb:27:in `call'
/var/www/discourse/vendor/bundle/ruby/2.4.0/gems/actionpack-4.2.8/lib/action_dispatch/middleware/remote_ip.rb:78:in `call'
/var/www/discourse/vendor/bundle/ruby/2.4.0/gems/actionpack-4.2.8/lib/action_dispatch/middleware/debug_exceptions.rb:17:in `call'
/var/www/discourse/vendor/bundle/ruby/2.4.0/gems/actionpack-4.2.8/lib/action_dispatch/middleware/show_exceptions.rb:30:in `call'
/var/www/discourse/vendor/bundle/ruby/2.4.0/gems/logster-1.2.7/lib/logster/middleware/reporter.rb:31:in `call'
/var/www/discourse/vendor/bundle/ruby/2.4.0/gems/railties-4.2.8/lib/rails/rack/logger.rb:38:in `call_app'
/var/www/discourse/vendor/bundle/ruby/2.4.0/gems/railties-4.2.8/lib/rails/rack/logger.rb:22:in `call'
/var/www/discourse/config/initializers/100-quiet_logger.rb:17:in `call_with_quiet_assets'
/var/www/discourse/config/initializers/100-silence_logger.rb:29:in `call'
/var/www/discourse/vendor/bundle/ruby/2.4.0/gems/actionpack-4.2.8/lib/action_dispatch/middleware/request_id.rb:21:in `call'
/var/www/discourse/vendor/bundle/ruby/2.4.0/gems/rack-1.6.8/lib/rack/methodoverride.rb:22:in `call'
/var/www/discourse/vendor/bundle/ruby/2.4.0/gems/rack-1.6.8/lib/rack/runtime.rb:18:in `call'
/var/www/discourse/vendor/bundle/ruby/2.4.0/gems/rack-1.6.8/lib/rack/sendfile.rb:113:in `call'
/var/www/discourse/vendor/bundle/ruby/2.4.0/gems/rack-mini-profiler-0.10.5/lib/mini_profiler/profiler.rb:171:in `call'
/var/www/discourse/vendor/bundle/ruby/2.4.0/gems/message_bus-2.0.2/lib/message_bus/rack/middleware.rb:62:in `call'
/var/www/discourse/lib/middleware/request_tracker.rb:73:in `call'
/var/www/discourse/vendor/bundle/ruby/2.4.0/gems/railties-4.2.8/lib/rails/engine.rb:518:in `call'
/var/www/discourse/vendor/bundle/ruby/2.4.0/gems/railties-4.2.8/lib/rails/application.rb:165:in `call'
/var/www/discourse/vendor/bundle/ruby/2.4.0/gems/railties-4.2.8/lib/rails/railtie.rb:194:in `public_send'
/var/www/discourse/vendor/bundle/ruby/2.4.0/gems/railties-4.2.8/lib/rails/railtie.rb:194:in `method_missing'
/var/www/discourse/vendor/bundle/ruby/2.4.0/gems/rack-1.6.8/lib/rack/urlmap.rb:66:in `block in call'
/var/www/discourse/vendor/bundle/ruby/2.4.0/gems/rack-1.6.8/lib/rack/urlmap.rb:50:in `each'
/var/www/discourse/vendor/bundle/ruby/2.4.0/gems/rack-1.6.8/lib/rack/urlmap.rb:50:in `call'
/var/www/discourse/vendor/bundle/ruby/2.4.0/gems/unicorn-5.3.0/lib/unicorn/http_server.rb:606:in `process_client'
/var/www/discourse/lib/scheduler/defer.rb:85:in `process_client'
/var/www/discourse/vendor/bundle/ruby/2.4.0/gems/unicorn-5.3.0/lib/unicorn/http_server.rb:702:in `worker_loop'
/var/www/discourse/vendor/bundle/ruby/2.4.0/gems/unicorn-5.3.0/lib/unicorn/http_server.rb:549:in `spawn_missing_workers'
/var/www/discourse/vendor/bundle/ruby/2.4.0/gems/unicorn-5.3.0/lib/unicorn/http_server.rb:563:in `maintain_worker_count'
/var/www/discourse/vendor/bundle/ruby/2.4.0/gems/unicorn-5.3.0/lib/unicorn/http_server.rb:293:in `join'
/var/www/discourse/vendor/bundle/ruby/2.4.0/gems/unicorn-5.3.0/bin/unicorn:126:in `<top (required)>'
/var/www/discourse/vendor/bundle/ruby/2.4.0/bin/unicorn:22:in `load'
/var/www/discourse/vendor/bundle/ruby/2.4.0/bin/unicorn:22:in `<main>'

Which might be related?

Posts: 3

Participants: 3

Read full topic

@cryptochrome wrote:

Hi,

we have set the “notification email” address in the basic settings to a “noreply@ourforum.address”. However, notifications for topic replies etc. seem to always come from the email address of the poster instead, exposing the email addresses of forum users. What am I missing here?

Thanks

Posts: 2

Participants: 2

Read full topic

@abhigyank wrote:

I have my Discourse set up in mydomain[dot]com/discourse in a subfolder. Everything is working fine and I had setup everything according to the steps in https://meta.discourse.org/t/subfolder-support-with-docker/30507.

However I am having an issue, whenever a user logins or signups, at mydomain[dot]com/discourse he is redirected to mydomain.com/discoursediscourse/discourse instead of mydomain[dot]com/discourse/discourse.

You can see the continuation in the URL. I cannot find a cause as all other URLs are properly working without with the subfolder any errors.

env of my app.yml:

env:
  LANG: en_US.UTF-8`
  DISCOURSE_HOSTNAME: 'domainname.com'
  DISCOURSE_RELATIVE_URL_ROOT: /discourse

part of my run in app.yml

- exec:
  cd: $home
  cmd:
    - mkdir -p public/discourse
    - cd public/discourse && ln -s ../uploads && ln -s ../backups
    - rm public/uploads
    - rm public/backups
- replace:
  global: true
  filename: /etc/nginx/conf.d/discourse.conf
  from: proxy_pass http://discourse;
  to: |
    rewrite ^/(.*)$ /discourse/$1 break;
    proxy_pass http://discourse;
- replace:
  filename: /etc/nginx/conf.d/discourse.conf
  from: etag off;
  to: |
    etag off;
    location /discourse {
      rewrite ^/discourse/?(.*)$ /$1;
    }

I have also set long polling base url: /discourse/.
Note: The code is app.yml is properly indented and working, I am just unable to indent it in this post.

Posts: 1

Participants: 1

Read full topic

@Sujan wrote:

Is there a way to automatically “unbump” topics (meaning: not show them at the top of the list any more) when a moderator removed or split into its own topic the newest post that bumped the topic in the first place?

So many users abuse old topics with slightly related topics, so moderators regularily do this, but the (now unchanged) old topic still gets listed for these changes (and also adds the avatar of the moderator for added credibility).

Posts: 5

Participants: 4

Read full topic

@cryptochrome wrote:

Hi,

I am trying to get my emails out using GSuit (Google Apps). If using the Gmail SMTP server with user authentication, email works fine, but all emails will be sent from the user account authenticating with Google.

When using the preferred way, sending mails through the GSuit SMTP Relay server (smtp-relay.gmail.com) without user authentication, then I am getting this error in the logs:

422 Unprocessable Entity

Full log excerpt:

Started GET “/admin/email.json?=1498667751835" for 46.237.212.130 at 2017-06-28 17:14:50 +0000
Processing by Admin::EmailController#index as JSON
Parameters: {"”=>“1498667751835”}
Completed 200 OK in 6ms (Views: 0.5ms | ActiveRecord: 0.0ms)
Started POST “/admin/email/test” for 46.237.212.130 at 2017-06-28 17:14:52 +0000
Processing by Admin::EmailController#test as /
Parameters: {“email_address”=>"email@removed.com"}

Sent mail to email@removed.com (13.4ms)
Completed 422 Unprocessable Entity in 381ms (Views: 0.2ms | ActiveRecord: 3.1ms)

Discourse at this point says that the email couldn’t be sent and I should check my mail host.

I am pretty sure the GSuit part is configured correctly (fixed IP set, set to no authentication, set to allow any from: address).

This error doesn’t really make sense to me. I found another thread that reported the same error, but that was never fixed because the guy switched to a different mail provider.

Any clues?

Thanks

Posts: 9

Participants: 2

Read full topic

@Simon_Cossar wrote:

Version 1.4.0 of the WP Discourse is now available in the WordPress plugin repository. The code is also on GitHub.

The big changes in this release are adding an option to sync Discourse topics to their associated WordPress posts with a webhook, and adding support for connecting a single Discourse forum to a WordPress multisite network. Check out the Webhook Settings and Multisite Support sections of the WP Discourse installation and setup topic for details about both of these features.

Other changes include:

• adding a featured_link option to the Publish options - thanks @iamntz! I’m finding this works very well with a customized publish_format_html template that removes the {blog_url} template tag.

• adding an option to not display the Discourse Name field on the WordPress user’s profile page. Enabling this will cause all posts to be published by the name supplied in the publishing_username field.

• removing the debug_mode option and adding a wpdc_comment_sync_period filter that can be used in its place. The problem with the debug_mode option was that if it was left checked by mistake, it would have a huge impact on the plugin’s performance. If people are missing this option, it could be added back, but changed so that it’s only enabled for a single request.

Comment sync period filter example

Unless you are using a webhook to sync comments, the plugin defaults to syncing comments every 10 minutes. To change the sync period, you can do something like this:

// Sync comments once every hour.
add_filter( 'wpdc_comment_sync_period', 'my_namespace_sync_period' );
function my_namespace_sync_period( $sync_period ) {

	return 60 * 60; // 60 seconds * 60 minutes.
}

Coming Soon

• a webhook option to automatically populate the Discourse Name field with the Discourse username. This will be able to be used when WordPress is the SSO provider for your forum, or when, through some other login system, you can guarantee that the user credentials on Discourse and WordPress match.

Let me know if you have any problems with the update. Previous versions of the plugin can be downloaded from the bottom of this page: https://en-ca.wordpress.org/plugins/wp-discourse/advanced/

Posts: 1

Participants: 1

Read full topic

@Brock_Busby wrote:

I hope someone who is an expert at Google Tag Manager & Google Analytics may be able to help answer this question…

I followed these instructions to set up my GA within GTM for our Discourse site (which is at the subdomain, https://discussions.ftw.in)

My question is: do I need to set an exception for our default GA site tag within GTM to to exclude our Discourse subdomain? Or set the trigger described in the instructions above (“virtualPageView”) to only trigger if the hostname begins with our Discourse subdomain?

Thanks in advance

Posts: 1

Participants: 1

Read full topic

@Martin_Cash wrote:

If I only want a one-way Discourse > Slack setup, could I just leave the “slack incoming webhook token” blank? This is how I have my settings and it doesn’t seem to be working

image.png765x576 22.1 KB

Posts: 4

Participants: 2

Read full topic

@pfaffman wrote:

I’m working on theming a new site. I was thinking that I could include logos (e.g., logo url, logo small url and so on) as part of the theme and then link to those in SystemSettings, but that seems to be wrong.

Am I missing something? Do we still have to upload all of the images into Assets for Site design? If so, that means that it’s not yet possible to completely separate theming from posts. What I’d like to do is be able to get all of the theme stuff straight on one site and then install that on another instance where the data has been imported.

Posts: 2

Participants: 2

Read full topic

@tophee wrote:

I just want to share my experience with SparkPost support here because O am simply blown away by their service (I’m still on their free plan).

I contacted them because I had a couple of bounces where the reason was that the sending IP was on a blacklist (spamhaus.org and dnsbl.sorbs.net, to be precise). Here is their response:

Thank you for reaching out and reporting the blacklisted IP issue!

Sparkpost IP’s can get blacklisted for a number of different reasons. A customer may not be following good data hygiene practices such as validating all of their recipient lists and as a result, they may hit a honeypot. A honeypot is a recycled email address ISP’s can use to monitor whether or a not a sender is legitimate or a spammer. Another reason why an IP can be listed is due to poor sending practices such as sending out prohibited content, unsolicited bulk email, and etc. We do our best to monitor anything sent through Sparkpost on a daily basis, however spammers and poor sending practices of other customers may affect the sending reputation of a shared pool as whole.

That being said, it is also important to note that we do actively monitor blacklists and any blacklists that affect our customers we work to resolve. There are literally thousands of blacklists for thousands of reasons and most of which do not affect you. We don’t spend our time on blacklists that do not affect our users or blacklists that will be automatically de-listed after a preset time. Major ISPs and Filters generally don’t use blacklists as they have their own scoring system.

I looked at IP’s you provided and they are listed on the following blacklists, CASA CBL, DNS Realtime Blackhole List, SORBS SPAM, and UCEPROTECTL1, which we consider to be minor actors as they are not reputable players in the anti-spam community. As well, they never respond to delisting requests, and often attempt to charge a fee for delisting. We have found that blacklistings by them do not impact sending in the vast majority of case

However, after a review of your account and sending history, we were able to make an adjustment to your sending pool. This change will take effect immediately for all new sends however, retries will continue to go out over the existing pool until they time out.

Should you have any further questions or concerns, please do not hesitate to reach out!

I think I have never received such an extensive and non-blah response from any support agent ever.

I followed up on this response because I was curious what kind of adjustments they made to “my” IP pool. I also asked whether they had higher and lower quality IP pools and how they decided to move customers from one to another. Their response came within less than an hour:

The adjustment I made was to move you into a new sending pool that was showing improved deliverability rates. We make these types of changes based on a number of different factors and if everything looks good, we move you into a different sending pool.

Overall, I would say it’s not about higher vs. lower quality pools because the sending reputation of each IP in the various pools can change hourly or day by day just based on what kind of activity goes through each one. For example, if Pool A with 3 IP’s had a 100% deliverability rate but an SP customer was sending bulk Rayban spam, then the IP that was used to send out the spam will obviously get reported and put on a blacklist. But again, we do our best to monitor and resolve blacklists that do affect our customers and actively educate everyone on sending best practices!

Hopefully this answers all of your questions, otherwise please let me know if there’s anything else you need.

Posts: 2

Participants: 2

Read full topic

@ked wrote:

What would you like done?
Matching - as reasonably possible - the “look and feel” of a current site with a new Discourse site.

When do you need it done?
I’d like to identify someone to do this work as soon as practical, but won’t begin for another week or so likely.

What is your budget, in $ USD that you can offer for this task?
I’m happy to offer a rate consistent with experience and quality of work. I’d guess this will fall in the $40 to $70/hr range.

Other condidtions?
That you have specific experience with Discourse, as demonstrated by examples of work you’ve done, along with access to a reference or two from those you’ve worked with.

Posts: 1

Participants: 1

Read full topic

@Hossein_Amerkashi wrote:

Hi,

How do we view previously-viewed private messages? Earlier, I read a user-reply to my private message. In a new session, I’m trying to re-read the message, but don’t know how to access it.

THANKS

Posts: 4

Participants: 4

Read full topic

@chaoschao11 wrote:

Hello Folks,

Hoping one of you can help me out with this.

I have recently set-up discourse to my server and for whatever reason it is unable to send emails. I have tried going through Gmail and Zoho but have had no luck.

Thanks!

Posts: 2

Participants: 2

Read full topic

@modius wrote:

We have an old Discourse instance (running latest version but initially installed a while back). It’s running under HTTP with all its images stored on an AWS S3 bucket with . (dots) in the name.

We want to move to HTTPS – configuring for Lets Encrypt works a treat but all the images are broken as S3 buckets with (dots) don’t appear to do SSL.

I’m thinking the simplest option would be to migrate all the images to the local instance – as its not an image heavy forum. But I can’t seem to work out how that would be done.

The alternative would be to migrate all the images to a new S3 bucket with an appropriate name. But I can’t seem to work out how that would be done either.

Can someone point me in the right direction?

Posts: 1

Participants: 1

Read full topic

@manishramteke wrote:

Hi Team,

Does discourse support adding security site seal and do you recommend adding.

Regards
Manish

Posts: 2

Participants: 2

Read full topic

@Pad_Pors wrote:

we have a Persian forum, all the emails are sent in an Arabic font.

to change the font to a Persian one, which is much more beautiful, can I use some html-css styling for mailgun (our email service)? like this one: http://blog.mailgun.com/transactional-html-email-templates/

is the font of the email changeable? It seems to me that the emails are sent directly from discourse forum and not mailgun. is it so?

Posts: 1

Participants: 1

Read full topic