When using pgbouncer without a transaction, it's possible for the connection to change between statements in a migration. Instead, create a real table, and drop it when the migration is finished
This introduces new APIs for obtaining optimized thumbnails for topics. There are a few building blocks required for this:
- Introduces new `image_upload_id` columns on the `posts` and `topics` table. This replaces the old `image_url` column, which means that thumbnails are now restricted to uploads. Hotlinked thumbnails are no longer possible. In normal use (with pull_hotlinked_images enabled), this has no noticeable impact
- A migration attempts to match existing urls to upload records. If a match cannot be found then the posts will be queued for rebake
- Optimized thumbnails are generated during post_process_cooked. If thumbnails are missing when serializing a topic list, then a sidekiq job is queued
- Topic lists and topics now include a `thumbnails` key, which includes all the available images:
```
"thumbnails": [
{
"max_width": null,
"max_height": null,
"url": "//example.com/original-image.png",
"width": 1380,
"height": 1840
},
{
"max_width": 1024,
"max_height": 1024,
"url": "//example.com/optimized-image.png",
"width": 768,
"height": 1024
}
]
```
- Themes can request additional thumbnail sizes by using a modifier in their `about.json` file:
```
"modifiers": {
"topic_thumbnail_sizes": [
[200, 200],
[800, 800]
],
...
```
Remember that these are generated asynchronously, so your theme should include logic to fallback to other available thumbnails if your requested size has not yet been generated
- Two new raw plugin outlets are introduced, to improve the customisability of the topic list. `topic-list-before-columns` and `topic-list-before-link`
If the user chooses "Later Today" as the reminder for a bookmark, then edits that bookmark, we should pre-select "Later Today" if that time has not changed (e.g. later is still 6pm). We do this to avoid confusion instead of opening the custom date + time section.
* Do not show confirmation modal if deleting bookmark from list unless the bookmark has a reminder
* Remove the deleted bookmark from the in-memory array for the user list so a full reload of the list is not needed and scrolling is maintained
This will make a few minor improvements to the second factor user interface. Highlights include:
- Using the site's title to prefix the backup code filename. If non-ascii characters are detected, then prefix "discourse" instead.
- Add icons and change the text on some of the buttons for better clarity and consistency
- Add an education link to the security key modal
The PR https://github.com/rails/rails/pull/36612 changes the raised exception
if the error message includes the target database name.
Since the error message contains the hostname, this could be triggered when
the hostname contains the database name.
This allows things like `Ember.inject.service` to be used within the raw view. setOwner simply sets one property on the object, and the result is cached along with the other injected properties, so this should have negligible performance impact.
This ensures that at a minimum you are notified once a day of
repeat edits by the same user.
Long term we may consider winding this down to say 1 hour or
making it configurable.
Due to a refactor in e90f9e5cc47 we stopped notifying on edits if
a user liked a post and then edited.
The like could have happened a long time ago so this gets extra
confusing.
This change makes the suppression more deliberate. We only want
to suppress quite/link/mention if the user already got a reply
notification.
We can expand this suppression if it is not enough.
rspec-rails 4.0 was released so we no longer need to depend on a
beta version. Also updates minor on a bunch of rspec gems.
Thanks to @ryanwi for raising this.
* When hovering over the bookmark icon for a post, show the name of the bookmark at the end of the tooltip _if_ it has been set.
* Order bookmarks by `updated_at DESC` in the user list and show that instead of created at.
This change amends it so we use a static service to keep track of
the typing presence.
It correct various edge cases the initial implementation had
- Faster close messages
- When composing on topic 1 and viewing topic 2 we had incorrect
presence
- Changing a running composer to reply as new topic or reply to a
differet topic would not correctly shift presence
Authored by tgxworld, with contributions by sam
