A user editing a post will no longer get composer messages that are
meant for new users posting replies and threads. These messages don't
make sense in an edit context at all -- they're usually discussing
making salient replies or topics, or adding avatars. They make even less
sense when a user is an admin attempting to change the default topics
for the first time.
Since these messages actually do make sense for a user when they have a
low post count, though, they're still going to occur. They just occur
when a user is creating new content (and thus, more likely to read the
notice), not during edits.
This is in response to this issue:
https://meta.discourse.org/t/education-message-for-editing-wiki-topic/66682
When creating lightboxes we will attempt to create 1.5x and 2x thumbnails
for retina screens, this can be controlled with a new hidden site setting
called responsice_post_image_sizes, if you wish to create 3x images run
SiteSetting.responsive_post_image_sizes = "1|1.5|2|3"
The default should be good for most of the setups as it balances filesize
with quality. 3x thumbs can get big.
If we detect redis is in readonly we can not correctly get a mutex
raise an exception to notify caller
When getting optimized images avoid the distributed mutex unless
for some reason it is the first call and we need to generate a thumb
In redis readonly no thumbnails will be generated
previously admin got a free pass and could set theme via cookie to anything
including themes that are not selectable
this refactor ensures that only "preview" gets a free pass, all the rest
goes through the same pipeline
* When an error is raised when checking route constraints, we
can only return true/false which either lets the request
through or return a 404 error. Therefore, we just skip
rate limiting here and let the controller handle the
rate limiting.
If sidekiq is paused or Discourse is in readonly continue to queue
heartbeats
If we do not do that then a master process can end up reaping sidekiq
workers and causing various badness
This also impacts restore which can do weird stuff TM in cases like this
These site settings are very hard to explain and only applicable for very
specific Discourse setups.
If an admin "enables staged users" which is used in support scenarios then
all staff can send "messages" directly to an "email".
The setting allows you to extend this to TL4 or any trust level.
Actual use case would be a support type setup with restricted staff. It is
quite rare so hiding this for now and re-evaluate keeping the setting in
2019
