Previously we would issue a 403 for all invalid routes under `/tags/c/...`, which is not semantically correct. In some cases, these 403'd routes would then be handled successfully in the Ember app, leading to some very confusing behavior.
These methods have been natively supported in all our target browsers for many years. We're now feature-detecting `String.prototype.replaceAll`, which is a much more recent addition. If a browser has `replaceAll`, it'll have `padStart` and `padEnd`
This commit is a redo of e21c640a3c
which we reverted to not include half-done work in a release.
This commit is slightly different though, in that it only includes
the creation of the new columns and index, and does not add any
triggers, backfilling, or new data.
A backfill will be done in the final PR when we switch this over.
Intermediate PRs will look something like this:
1. Add an experimental site setting for using polymorphic bookmarks,
and make sure in the places where bookmarks are created or updated
we fill in the columns. This setting will be used in subsequent
PRs as well.
2. Listing and searching bookmarks based on polymorphic associations
3. Creating post and topic bookmarks using polymorphic associations,
and changing special for_topic logic to just rely on the Topic
bookmarkable_type
4. Querying bookmark reminders based on polymorphic associations
5. Make sure various other areas like importers, bookmark guardian,
and others all rely on the associations
6. Prepare plugins that rely on the Bookmark model to use polymorphic
associations
The final core PR will remove all the setting gates and switch over
to using the polymorphic associations, backfill the bookmarks
table columns, and ignore the old post_id and for_topic colummns.
Then it will just be a matter of dropping the old columns down the
line.
If a group's messageable_level is set to nobody then staff can't should not be able to send PMs to it.
Co-authored-by: Martin Brennan <martin@discourse.org>
Plugins like chat add custom score type to override the title in the UI, but that should be reserved for situations when you need to manage the flag priority separately, which is configurable in the queue settings page.
Currently, if a plugin creates a custom score type, it won't be able to associate a priority, so there's no real gain from doing so. Priorities are tightly related to post-action types, which is something we might want to revise. For now, this change lets plugins move away from custom score types without compromises.
Previously we were loading almost all the data in an afterModel hook, storing it temporarily in route properties, and then passing it to the controller in `setupController`.
This does not follow Ember best-practices, and causes a number of unexpected behaviours. For example, Ember only calls `setupController` **when the model value changes**. Since `model()` was only returning the tag, that meant that category changes and `additionalTag` changes wouldn't always trigger a `setupController` call, and things would get into a very weird state. This is visible when using the 'loading-slider' component because the category navigation dropdown gets 'stuck' when switching categories.
This commit moves all the data-fetching into `model()`. To make things cleaner, it also:
- removes most uses of route-level variables
- introduces async/await in the model() function
- removes some unneeded `get()` usage
- re-uses DiscoverySortableController for queryParam default handling
- Removes override of `renderTemplate()` so that queryParams are correctly passed through to the controller
- Removes some `transitionToRoute` hacks which were working around the queryParams issue
- Switches to `@action`
In certain cases (like chat quoting) we need to be able
to call the API with an async AJAX call before copying
the results to the clipboard. The only way to reliably
do this is by handing off the AJAX promise to a ClipboardItem.
This commit introduces a new clipboardCopyAsync function
to handle this, which will stand alongside the existing
clipboardCopy function which can be used when no AJAX
request is necessary.
The meaning of reminder_at and reminder_last_sent_at changed after
commit 6d422a8033. A bookmark reminder
will fire only if reminder_last_sent_at is null, but before that it
fired everytime reminder_at was set. This is no longer true because
sometimes reminder_at continues to exist even after a reminder fired.
When using the loading-slider, the component instance is re-used across different pages and so the didInsertElement/willDestroyElement hooks are not fired during page transitions. Instead, we can lean on `didReceiveAttrs`.
Similar fix to 87b98e2862
Note that the `scrollTop` feature is still problematic under the loading slider. That will need to be addressed in a future commit.
We have 3 branches which we care about, `main`, `beta` and `stable`.
However, each of this branch has different compatibilties with plugins
and we want to respect that.
* DEV: Allow params to be passed on topic redirects
There are several places where we redirect a url to a standard topic url
like `/t/:slug/:topic_id` but we weren't always passing query parameters
to the new url.
This change allows a few more query params to be included on the
redirect. The new params that are permitted are page, print, and
filter_top_level_replies. Any new params will need to be specified.
This also prevents the odd trailing empty page param that would
sometimes appear on a redirect. `/t/:slug/:id.json?page=`
* rubocop: fix missing space after comma
* fix another page= reference
If a user copies a gif from a website into their clipboard and then
tries to paste it into the Discourse composer, we would only paste a
static single frame of the original gif. This happens because the
browser doesn't store the original image in the clipboard, but two
entries:
1. image/png with the frame of the copy moment
2. text/html with the markup of the gif img element
This commit adds an heuristic that detects this and makes us pick the
clipboard content of text/html instead of the image/png when this
happens.
From there our existing HTML paste logic handles and converts the HTML
img tag into markdown, preserving even the alt text.
See https://meta.discourse.org/t/-/218720 for context.
We rolled out a change to disable canonical indexing.
The goal behind it was to limit crawl budget by Google being spent
scanning non canonical topic links.
Since this change was applied we rolled out 2 fixes that made the change
no longer needed.
1. Topic RSS feeds are no longer followed, links in the RSS feeds are
not followed.
2. Post RSS feeds now contain canonical links.
Combined these two changes mean crawlers no longer discover a large
amount on non-canonical links on Discourse sites.
share-topic modal is used everywhere expect when clicking on the top
right corner of the post. This changes standardize on share-topic modal
and add the missing features from share-popup.
The `testem.scss` include triggers a live reload locally. We need these
styles when running `ember test --server`, so this loads that stylesheet
only in that scenario.
Missing plugin gems are installed when the app is being loaded.
That means when you run `bin/rails plugin:install_all_gems` it first installs missing gems and then reinstalls all gems…
Also, the method these rake tasks were using to install gems was very crude, and the regex there was incorrect which resulted in failures in certain cases. Though that didn't matter since those gems were being installed using a correct method just moments before…
* FEATURE: use canonical links in posts.rss feed
Previously we used non canonical links in posts.rss
These links get crawled frequently by crawlers when discovering new
content forcing crawlers to hop to non canonical pages just to end up
visiting canonical pages
This uses up expensive crawl time and adds load on Discourse sites
Old links were of the form:
`https://DOMAIN/t/SLUG/43/21`
New links are of the form
`https://DOMAIN/t/SLUG/43?page=2#post_21`
This also adds a post_id identified element to crawler view that was
missing.
Note, to avoid very expensive N+1 queries required to figure out the
page a post is on during rss generation, we cache that information.
There is a smart "cache breaker" which ensures worst case scenario is
a "page drift" - meaning we would publicize a post is on page 11 when
it is actually on page 10 due to post deletions. Cache holds for up to
12 hours.
Change only impacts public post RSS feeds (`/posts.rss`)
