Piotr Szal wrote:

Hello,

on out 2nd staging server is / and /categories when perform page reload always redirected to /top.

Discourse.Utilities.defaultHomepage() says "latest".

Any suggestions?

Posts: 5

Participants: 2

Read full topic

Michael Downey wrote:

So this morning I got two messages from the system user, both of which read as follows:

This is an automated message.
Parsing an incoming email failed. Please review the following Error:
Email::Receiver::UserNotFoundError

There is nothing with that error message in /logs and I'm not sure if there's anywhere else I should look. Is there anywhere where I can find details?

Also, is it safe to assume that the "black hole" problem has been fixed and the users were notified that their incoming e-mail failed?

Posts: 6

Participants: 3

Read full topic

timeline wrote:

I strongly believe that an anonymous posting feature is a great way to evolve from the usual forum systems - as evidenced by popular boards such as 4chan.

I'm not sure if the developers are too keen on making such a feature but I'm willing to pay for a plugin.

So the specifics are:

• allow a registered user to make posts anonymously via a checkbox
• allow unregistered users to post as anonymous
• allow an option that makes a category anonymous only (wherein all posts within that category will be anonymous, regardless if the user selects the anonymous checkbox or not)

Posts: 1

Participants: 1

Read full topic

Michael Downey wrote:

At the bottom of a private message, the default for the "Watching/Tracking/Muted" dropdown is now missing:

Screenshot 2014-06-23 at 11.29.10.png1662x240 24.2 KB

This seems to be fine on "regular" topics.

Posts: 3

Participants: 3

Read full topic

Justin Mayer wrote:

My personal opinion is that persistent fixed headers provide a suboptimal end-user experience because they:

• do not scroll accurately (e.g., scrolling via spacebar hides the first item on the next page — the user will never see that thread)
• reduce available screen real estate for almost zero benefit — when I'm scrolling down to read content, I do not need the functions provided in the header, and when I do, I can simply scroll up slightly
• are jarring and unexpected — humans naturally expect the entire page to scroll
• distract the user from the conversation at hand

Fortunately, there is a solution to these problems: hide the header when the user scrolls the page down, and show it again when the page is scrolled upward. This eliminates the above-mentioned problems while retaining the ostensible benefits of the persistent header.

Thankfully, there is already an excellent Javascript library that delivers this functionality: Headroom.js

So my question to the Discourse maintainers is... Would you consider utilizing Headroom.js in order to address the above-mentioned problems and improve the usability of Discourse's header behavior?

Posts: 12

Participants: 7

Read full topic

Josh wrote:

Hello all! I am new to discourse and went through the install guide for digital ocean (took me 15 minutes) and I'm impressed! One thing I haven't been able to locate is the badge menu, please point it out for me?

Posts: 4

Participants: 2

Read full topic

Ben Cannady wrote:

We have been bulk inviting users to a group through email. We just had about 90% of them (2,000 users) lose access to that group and move to a trust level 1. Is there a feature in admin we could have accidentally used to cause this? Any ideas why this happen and how we can fix? Without re-inviting? Cheers

Posts: 5

Participants: 4

Read full topic

Sean wrote:

I've participated in a forum where my post was unpopular with the community, so it was flagged as spam as a method of censorship.

As a user, I obviously don't like that.

I understand that some posts are unpopular, but it seems like there is a need for a different type of flag. "Spam" is incorrect, and hiding the topic completely (which would be reasonable if the thread WAS spam) isn't right, in my opinion.

I'm not saying that the topic should be visible to everyone... the community has a right to determine what they feel is appropriate topics of discussion. But there is a disconnect if the community feels the best way to flag an unpopular topic is to mark it as spam.

Posts: 4

Participants: 2

Read full topic

Peter Lewis wrote:

On an iPad, the zooming behaves oddly because the header bar zooms at a faster rate than the body, so you get into situations where the crucial right hand side of the navigation bar is off the page and impossible to access.

Worse still, on the iPad when it has never seen the site before, its default state is needlessly zoomed in somewhat, and the zooming causes the nav buttons to be cropped and inaccessible.

You can see a variant of this behaviour on the desktop if you zoom in. Because the navigation bar is fixed to the window, you get a case like this:

20140624-12:33:24.png535x581 28.1 KB

Note that that is fully scrolled to the right of the window, but the navigation controls are still further right and inaccessible.

As I say, on the iPad it is particularly bad as unless the user thinks to pinch zoom to reset the scale, they cannot sign in at all and will be thoroughly confused.

Thankfully, once you have pinch zoomed the screen, it behaves normally when zoomed to fit the iPad screen.

I tried to look at the CSS to figure out where things are going wrong, but I'm CSS positioning it beyond me at the moment.

Posts: 13

Participants: 5

Read full topic

tim wrote:

When viewing a topic (seemingly, only when viewing a topic), clicking on the site logo in IE9 throws an exception within Ember.

I know we don't care about IE9, but it's the only annoying piece of functionality that's broken that our users have found

Posts: 8

Participants: 4

Read full topic

Peter Lewis wrote:

Whoever is working on the CSS and HTML might want to run them through the validation tools.

http://jigsaw.w3.org/css-validator/
http://validator.w3.org

While it's not necessarily essential for the code to validate, its certainly a good idea to make an informed choice, especially given the large number of validation errors in the CSS, especially all the parse errors.

The HTML mostly validates except for the duplicate <footer id='bottom'…>

Just a suggestion.

Posts: 3

Participants: 2

Read full topic

Joseph Method wrote:

Seeing this error in Sidekiq jobs that I find hanging out in the Retries group. The problem is intermittent; I can retry the jobs and they will all process after a few attempts. This problem can hold up signup emails though. This is for a multi site installation using the Docker install and most recent Discourse.

NameError: uninitialized class variable @@db_spec_cache in RailsMultisite::ConnectionManagement

I don't see a way to get a more detailed backtrace for this. Looking in the code, this is the only place where @@db_spec_cache is referenced without checking if it's defined first: https://github.com/discourse/discourse/blob/master/vendor/gems/rails_multisite/lib/rails_multisite/connection_management.rb#L180 but I didn't see how this would be called before @@db_spec_cache was set.

Posts: 5

Participants: 3

Read full topic

Piotr Szal wrote:

1. Im on this page: https://meta.discourse.org/t/upgrade-nuked-my-avatar/16226/23(is the 23 change to 21?)

2. Im reload the page and its jump to 21, then -> 20, then -> ...

Posts: 2

Participants: 2

Read full topic

Tuan Anh Tran wrote:

How would i censor a certain words in posts' text?

Posts: 1

Participants: 1

Read full topic

James Finstrom wrote:

When we create a banner post, only done once so far. It appears appropriately at the top in categories. When you go in to a post it sort of obnoxiously floats above the entire post.

bannerpost.png1286x668 145 KB

This is in Chrome Version 35.0.1916.153 on Ubuntu 14.04. One of my colleagues originally informed me of this I believe he is on a Mac but also chrome.

Can we have a checkbox maybe in settings that limits banner posts to category pages only excluding it from individual posts....

Posts: 3

Participants: 3

Read full topic

David Lim wrote:

I'm trying to follow the Discourse as Your First Rails App tutorial to set up Discourse on a Vagrant VM on my Windows machine. When I run 'vagrant up', the VM doesn't start up.

Here is the output I get.

D:\GitHub\discourse [master]> vagrant up
Bringing machine 'default' up with 'virtualbox' provider...
==> default: Importing base box 'discourse-0.9.7'...
==> default: Matching MAC address for NAT networking...
==> default: Destroying VM and associated drives...
==> default: Running cleanup tasks for 'shell' provisioner...
==> default: Running cleanup tasks for 'chef_solo' provisioner...
C:/HashiCorp/Vagrant/embedded/gems/gems/vagrant-1.6.3/plugins/providers/virtualbox/action.rb:56:in `block in action_boot': C:/HashiCorp/Vagrant/embedded/gems/gems/vagrant-1.6.3/lib/vagrant/action/builtin/provision.rb:1: Invalid char `\x10' in expression (SyntaxError)
C:/HashiCorp/Vagrant/embedded/gems/gems/vagrant-1.6.3/lib/vagrant/action/builtin/provision.rb:1: invalid multibyte char (UTF-8)
    from C:/HashiCorp/Vagrant/embedded/gems/gems/vagrant-1.6.3/plugins/providers/virtualbox/action.rb:51:in `tap'
    from C:/HashiCorp/Vagrant/embedded/gems/gems/vagrant-1.6.3/plugins/providers/virtualbox/action.rb:51:in `action_boot'
    from C:/HashiCorp/Vagrant/embedded/gems/gems/vagrant-1.6.3/plugins/providers/virtualbox/action.rb:272:in `block (4 levels) in action_start'
    from C:/HashiCorp/Vagrant/embedded/gems/gems/vagrant-1.6.3/lib/vagrant/action/builtin/call.rb:47:in `call'
    from C:/HashiCorp/Vagrant/embedded/gems/gems/vagrant-1.6.3/lib/vagrant/action/builtin/call.rb:47:in `call'
    from C:/HashiCorp/Vagrant/embedded/gems/gems/vagrant-1.6.3/lib/vagrant/action/warden.rb:34:in `call'
    from C:/HashiCorp/Vagrant/embedded/gems/gems/vagrant-1.6.3/lib/vagrant/action/warden.rb:95:in `block in finalize_action'
    from C:/HashiCorp/Vagrant/embedded/gems/gems/vagrant-1.6.3/lib/vagrant/action/warden.rb:34:in `call'
    from C:/HashiCorp/Vagrant/embedded/gems/gems/vagrant-1.6.3/lib/vagrant/action/warden.rb:34:in `call'
    from C:/HashiCorp/Vagrant/embedded/gems/gems/vagrant-1.6.3/lib/vagrant/action/builder.rb:116:in `call'
    from C:/HashiCorp/Vagrant/embedded/gems/gems/vagrant-1.6.3/lib/vagrant/action/runner.rb:66:in `block in run'
    from C:/HashiCorp/Vagrant/embedded/gems/gems/vagrant-1.6.3/lib/vagrant/util/busy.rb:19:in `busy'
    from C:/HashiCorp/Vagrant/embedded/gems/gems/vagrant-1.6.3/lib/vagrant/action/runner.rb:66:in `run'
    from C:/HashiCorp/Vagrant/embedded/gems/gems/vagrant-1.6.3/lib/vagrant/action/builtin/call.rb:53:in `call'
    from C:/HashiCorp/Vagrant/embedded/gems/gems/vagrant-1.6.3/lib/vagrant/action/warden.rb:34:in `call'
    from C:/HashiCorp/Vagrant/embedded/gems/gems/vagrant-1.6.3/lib/vagrant/action/warden.rb:95:in `block in finalize_action'
    from C:/HashiCorp/Vagrant/embedded/gems/gems/vagrant-1.6.3/lib/vagrant/action/warden.rb:34:in `call'
    from C:/HashiCorp/Vagrant/embedded/gems/gems/vagrant-1.6.3/lib/vagrant/action/warden.rb:34:in `call'
    from C:/HashiCorp/Vagrant/embedded/gems/gems/vagrant-1.6.3/lib/vagrant/action/builder.rb:116:in `call'
    from C:/HashiCorp/Vagrant/embedded/gems/gems/vagrant-1.6.3/lib/vagrant/action/runner.rb:66:in `block in run'
    from C:/HashiCorp/Vagrant/embedded/gems/gems/vagrant-1.6.3/lib/vagrant/util/busy.rb:19:in `busy'
    from C:/HashiCorp/Vagrant/embedded/gems/gems/vagrant-1.6.3/lib/vagrant/action/runner.rb:66:in `run'
    from C:/HashiCorp/Vagrant/embedded/gems/gems/vagrant-1.6.3/lib/vagrant/action/builtin/call.rb:53:in `call'
    from C:/HashiCorp/Vagrant/embedded/gems/gems/vagrant-1.6.3/lib/vagrant/action/warden.rb:34:in `call'
    from C:/HashiCorp/Vagrant/embedded/gems/gems/vagrant-1.6.3/lib/vagrant/action/builtin/box_check_outdated.rb:36:in `call'
    from C:/HashiCorp/Vagrant/embedded/gems/gems/vagrant-1.6.3/lib/vagrant/action/warden.rb:34:in `call'
    from C:/HashiCorp/Vagrant/embedded/gems/gems/vagrant-1.6.3/lib/vagrant/action/builtin/config_validate.rb:25:in `call'
    from C:/HashiCorp/Vagrant/embedded/gems/gems/vagrant-1.6.3/lib/vagrant/action/warden.rb:34:in `call'
    from C:/HashiCorp/Vagrant/embedded/gems/gems/vagrant-1.6.3/plugins/providers/virtualbox/action/check_virtualbox.rb:17:in `call'
    from C:/HashiCorp/Vagrant/embedded/gems/gems/vagrant-1.6.3/lib/vagrant/action/warden.rb:34:in `call'
    from C:/HashiCorp/Vagrant/embedded/gems/gems/vagrant-1.6.3/lib/vagrant/action/warden.rb:95:in `block in finalize_action'
    from C:/HashiCorp/Vagrant/embedded/gems/gems/vagrant-1.6.3/lib/vagrant/action/warden.rb:34:in `call'
    from C:/HashiCorp/Vagrant/embedded/gems/gems/vagrant-1.6.3/lib/vagrant/action/warden.rb:34:in `call'
    from C:/HashiCorp/Vagrant/embedded/gems/gems/vagrant-1.6.3/plugins/providers/virtualbox/action/match_mac_address.rb:16:in `call'
    from C:/HashiCorp/Vagrant/embedded/gems/gems/vagrant-1.6.3/lib/vagrant/action/warden.rb:34:in `call'
    from C:/HashiCorp/Vagrant/embedded/gems/gems/vagrant-1.6.3/plugins/providers/virtualbox/action/import.rb:32:in `call'
    from C:/HashiCorp/Vagrant/embedded/gems/gems/vagrant-1.6.3/lib/vagrant/action/warden.rb:34:in `call'
    from C:/HashiCorp/Vagrant/embedded/gems/gems/vagrant-1.6.3/plugins/providers/virtualbox/action/customize.rb:40:in `call'
    from C:/HashiCorp/Vagrant/embedded/gems/gems/vagrant-1.6.3/lib/vagrant/action/warden.rb:34:in `call'
    from C:/HashiCorp/Vagrant/embedded/gems/gems/vagrant-1.6.3/plugins/providers/virtualbox/action/check_accessible.rb:18:in `call'
    from C:/HashiCorp/Vagrant/embedded/gems/gems/vagrant-1.6.3/lib/vagrant/action/warden.rb:34:in `call'
    from C:/HashiCorp/Vagrant/embedded/gems/gems/vagrant-1.6.3/lib/vagrant/action/warden.rb:95:in `block in finalize_action'
    from C:/HashiCorp/Vagrant/embedded/gems/gems/vagrant-1.6.3/lib/vagrant/action/warden.rb:34:in `call'
    from C:/HashiCorp/Vagrant/embedded/gems/gems/vagrant-1.6.3/lib/vagrant/action/warden.rb:34:in `call'
    from C:/HashiCorp/Vagrant/embedded/gems/gems/vagrant-1.6.3/lib/vagrant/action/builder.rb:116:in `call'
    from C:/HashiCorp/Vagrant/embedded/gems/gems/vagrant-1.6.3/lib/vagrant/action/runner.rb:66:in `block in run'
    from C:/HashiCorp/Vagrant/embedded/gems/gems/vagrant-1.6.3/lib/vagrant/util/busy.rb:19:in `busy'
    from C:/HashiCorp/Vagrant/embedded/gems/gems/vagrant-1.6.3/lib/vagrant/action/runner.rb:66:in `run'
    from C:/HashiCorp/Vagrant/embedded/gems/gems/vagrant-1.6.3/lib/vagrant/action/builtin/call.rb:53:in `call'
    from C:/HashiCorp/Vagrant/embedded/gems/gems/vagrant-1.6.3/lib/vagrant/action/warden.rb:34:in `call'
    from C:/HashiCorp/Vagrant/embedded/gems/gems/vagrant-1.6.3/lib/vagrant/action/builtin/config_validate.rb:25:in `call'
    from C:/HashiCorp/Vagrant/embedded/gems/gems/vagrant-1.6.3/lib/vagrant/action/warden.rb:34:in `call'
    from C:/HashiCorp/Vagrant/embedded/gems/gems/vagrant-1.6.3/lib/vagrant/action/warden.rb:95:in `block in finalize_action'
    from C:/HashiCorp/Vagrant/embedded/gems/gems/vagrant-1.6.3/lib/vagrant/action/warden.rb:34:in `call'
    from C:/HashiCorp/Vagrant/embedded/gems/gems/vagrant-1.6.3/lib/vagrant/action/warden.rb:34:in `call'
    from C:/HashiCorp/Vagrant/embedded/gems/gems/vagrant-1.6.3/lib/vagrant/action/builtin/handle_box.rb:56:in `call'
    from C:/HashiCorp/Vagrant/embedded/gems/gems/vagrant-1.6.3/lib/vagrant/action/warden.rb:34:in `call'
    from C:/HashiCorp/Vagrant/embedded/gems/gems/vagrant-1.6.3/lib/vagrant/action/warden.rb:95:in `block in finalize_action'
    from C:/HashiCorp/Vagrant/embedded/gems/gems/vagrant-1.6.3/lib/vagrant/action/warden.rb:34:in `call'
    from C:/HashiCorp/Vagrant/embedded/gems/gems/vagrant-1.6.3/lib/vagrant/action/warden.rb:34:in `call'
    from C:/HashiCorp/Vagrant/embedded/gems/gems/vagrant-1.6.3/lib/vagrant/action/builder.rb:116:in `call'
    from C:/HashiCorp/Vagrant/embedded/gems/gems/vagrant-1.6.3/lib/vagrant/action/runner.rb:66:in `block in run'
    from C:/HashiCorp/Vagrant/embedded/gems/gems/vagrant-1.6.3/lib/vagrant/util/busy.rb:19:in `busy'
    from C:/HashiCorp/Vagrant/embedded/gems/gems/vagrant-1.6.3/lib/vagrant/action/runner.rb:66:in `run'
    from C:/HashiCorp/Vagrant/embedded/gems/gems/vagrant-1.6.3/lib/vagrant/action/builtin/call.rb:53:in `call'
    from C:/HashiCorp/Vagrant/embedded/gems/gems/vagrant-1.6.3/lib/vagrant/action/warden.rb:34:in `call'
    from C:/HashiCorp/Vagrant/embedded/gems/gems/vagrant-1.6.3/plugins/providers/virtualbox/action/check_virtualbox.rb:17:in `call'
    from C:/HashiCorp/Vagrant/embedded/gems/gems/vagrant-1.6.3/lib/vagrant/action/warden.rb:34:in `call'
    from C:/HashiCorp/Vagrant/embedded/gems/gems/vagrant-1.6.3/lib/vagrant/action/builder.rb:116:in `call'
    from C:/HashiCorp/Vagrant/embedded/gems/gems/vagrant-1.6.3/lib/vagrant/action/runner.rb:66:in `block in run'
    from C:/HashiCorp/Vagrant/embedded/gems/gems/vagrant-1.6.3/lib/vagrant/util/busy.rb:19:in `busy'
    from C:/HashiCorp/Vagrant/embedded/gems/gems/vagrant-1.6.3/lib/vagrant/action/runner.rb:66:in `run'
    from C:/HashiCorp/Vagrant/embedded/gems/gems/vagrant-1.6.3/lib/vagrant/machine.rb:196:in `action_raw'
    from C:/HashiCorp/Vagrant/embedded/gems/gems/vagrant-1.6.3/lib/vagrant/machine.rb:173:in `block in action'
    from C:/HashiCorp/Vagrant/embedded/gems/gems/vagrant-1.6.3/lib/vagrant/environment.rb:434:in `lock'
    from C:/HashiCorp/Vagrant/embedded/gems/gems/vagrant-1.6.3/lib/vagrant/machine.rb:161:in `call'
    from C:/HashiCorp/Vagrant/embedded/gems/gems/vagrant-1.6.3/lib/vagrant/machine.rb:161:in `action'
    from C:/HashiCorp/Vagrant/embedded/gems/gems/vagrant-1.6.3/lib/vagrant/batch_action.rb:82:in `block (2 levels) in run'
D:\GitHub\discourse [master]>

I have not programmed in Ruby before.

Thanks in advance!

Posts: 2

Participants: 2

Read full topic

Dean Taylor wrote:

Error logs contain:

PG::Error: ERROR:  duplicate key value violates unique constraint "post_timings_unique"
DETAIL:  Key (topic_id, post_number, user_id)=(26652, 1, 613) already exists.
: INSERT INTO post_timings (topic_id, user_id, post_number, msecs)
                  SELECT 26652, 613, 1, 1000
                  WHERE NOT EXISTS(SELECT 1 FROM post_timings
                                   WHERE topic_id = 26652
                                    AND user_id = 613
                                    AND post_number = 1)

Backtace:

/var/www/discourse/vendor/bundle/ruby/2.0.0/gems/logster-0.0.10/lib/logster/logger.rb:47:in `add'
/usr/local/lib/ruby/2.0.0/logger.rb:454:in `error'
/var/www/discourse/vendor/bundle/ruby/2.0.0/gems/activerecord-4.1.1/lib/active_record/connection_adapters/abstract_adapter.rb:360:in `translate_exception_class'
/var/www/discourse/vendor/bundle/ruby/2.0.0/gems/activerecord-4.1.1/lib/active_record/connection_adapters/abstract_adapter.rb:375:in `rescue in log'
/var/www/discourse/vendor/bundle/ruby/2.0.0/gems/activerecord-4.1.1/lib/active_record/connection_adapters/abstract_adapter.rb:373:in `log'
/var/www/discourse/vendor/bundle/ruby/2.0.0/gems/activerecord-4.1.1/lib/active_record/connection_adapters/postgresql/database_statements.rb:127:in `execute'
/var/www/discourse/lib/freedom_patches/active_record_base.rb:7:in `exec_sql'
/var/www/discourse/app/models/post_timing.rb:43:in `record_timing'
/var/www/discourse/app/models/post_timing.rb:69:in `block in process_timings'
/var/www/discourse/app/models/post_timing.rb:67:in `each'
/var/www/discourse/app/models/post_timing.rb:67:in `process_timings'
/var/www/discourse/app/controllers/topics_controller.rb:318:in `timings'

More backtrace:
https://gist.github.com/DeanMarkTaylor/4bcb0a4a9893f56b050a

and this one seams related:
Error:

ActiveRecord::RecordNotUnique (PG::Error: ERROR:  duplicate key value violates unique constraint "post_timings_unique"
DETAIL:  Key (topic_id, post_number, user_id)=(39986, 1, 613) already exists.
: INSERT INTO post_timings (topic_id, user_id, post_number, msecs)
                  SELECT 39986, 613, 1, 202
                  WHERE NOT EXISTS(SELECT 1 FROM post_timings
                                   WHERE topic_id = 39986
                                    AND user_id = 613
                                    AND post_number = 1))

Backtrace

/var/www/discourse/vendor/bundle/ruby/2.0.0/gems/rack-mini-profiler-0.9.1/lib/patches/sql_patches.rb:160:in `exec'
/var/www/discourse/vendor/bundle/ruby/2.0.0/gems/rack-mini-profiler-0.9.1/lib/patches/sql_patches.rb:160:in `async_exec'
/var/www/discourse/vendor/bundle/ruby/2.0.0/gems/activerecord-4.1.1/lib/active_record/connection_adapters/postgresql/database_statements.rb:128:in `block in execute'
/var/www/discourse/vendor/bundle/ruby/2.0.0/gems/activerecord-4.1.1/lib/active_record/connection_adapters/abstract_adapter.rb:373:in `block in log'
/var/www/discourse/vendor/bundle/ruby/2.0.0/gems/activesupport-4.1.1/lib/active_support/notifications/instrumenter.rb:20:in `instrument'
/var/www/discourse/vendor/bundle/ruby/2.0.0/gems/activerecord-4.1.1/lib/active_record/connection_adapters/abstract_adapter.rb:367:in `log'
/var/www/discourse/vendor/bundle/ruby/2.0.0/gems/activerecord-4.1.1/lib/active_record/connection_adapters/postgresql/database_statements.rb:127:in `execute'
/var/www/discourse/lib/freedom_patches/active_record_base.rb:7:in `exec_sql'
/var/www/discourse/app/models/post_timing.rb:43:in `record_timing'
/var/www/discourse/app/models/post_timing.rb:69:in `block in process_timings'
/var/www/discourse/app/models/post_timing.rb:67:in `each'
/var/www/discourse/app/models/post_timing.rb:67:in `process_timings'
/var/www/discourse/app/controllers/topics_controller.rb:318:in `timings'

More backtrace
https://gist.github.com/DeanMarkTaylor/52244e6941fec23f6dd2

Posts: 3

Participants: 2

Read full topic

Mynethoster Malaysia wrote:

Because of Mandrillapp's support very slow like snail, im need to get opinion from you guys.

Recently we are on mandrillapp network to send the emails but lately some of the email never been received by receivers and sometimes need to send 3-5 times to get it delivered.

We have check the notification from admins where (outbound >> activity) and the status delivered. But it endup as NOT DELIVER and not in inbox or spam box. NOTHING, the receiver not receive any.

Anyone of you experience the same issue? How to fix this? While mandrillapp support's people just busy telling their system the best but keep thier weekness by their side hence it just turn we down as the people which not technically hero with IT stuffs.

Could anyone of you guide me what to do to solve this issue? Or perhaps reducing the tension we experiencing now?

Posts: 2

Participants: 2

Read full topic

Ova Light wrote:

Could you provide some info this please? The moment I add another .conf file inside /etc/nginx/conf.d/ it completely ignores discourse and instead shows the "Welcome to nginx!" page in both my subdomains. Any ideas?

Posts: 7

Participants: 2

Read full topic

Sam Saffron wrote:

Discourse Docker should alert users if the container they have is tracking the master branch as opposed to anything else (tests-passed, stable or custom)

master is considered unstable at least until the tests pass.

Message should inform users and explain how to correct the situation (editing app.yml and reboostrapping)

@techAPJ would you like to take this?

Posts: 1

Participants: 1

Read full topic