Seems to only be a problem when a markdown.it rule inserts links without a attribute value. There's no test, because it's not reproducible with the markdown rules in core.
Updates automatically data on the stats section of the topic.
It will update automatically the following information: likes, replies and last reply (timestamp and user)
- Sets `https://www.mixcloud.com` as a `requires_iframe_origins` to allow the iframe content to be displayed
- Attempts to render something approximating the Mixcloud content in the preview pane of the Composer, rather than just displaying a large version of the artwork associated with the link
We currently remove the splash screen once Discourse starts booting.
This can be an issue on very slow devices, which can take up to 6 seconds. This PR ensures that we don't remove the splash until the browser has finished parsing all of the site's assets. It won't impact fast devices.
Internal topic /t/65378/60
Hopefully fixes flakes like:
```
not ok 1123 Chrome 102.0 - [undefined ms] - Global error: Uncaught Error: Unhandled request in test environment: /forum/u/eviltrout.json (PUT) at http://localhost:7357/assets/vendor.js, line 38378
While executing test: Unit | Utility | click-track: routes to absolute internal urls
---
browser log: |
{"type":"error","text":"Unhandled request in test environment: /forum/u/eviltrout.json (PUT)"}
{"type":"error","text":"Uncaught Error: Unhandled request in test environment: /forum/u/eviltrout.json (PUT) at http://localhost:7357/assets/vendor.js, line 38378\n","testContext":{"id":1123,"name":"Unit | Utility | click-track: routes to absolute internal urls","items":[],"state":"executing"}}
...
```
There's an obscure bug where really slow devices end up removing the splash screen before they're finished parsing all of the Discourse assets.
This PR won't impact fast devices but should hopefully prevent the premature removal of the splash on super slow devices.
We use javascript to remove the splash screen when the site boots up. If the user has js disabled, they get stuck on the splash screen.
If the user has js disabled. We don't show the splash screen at all.
There's an obscure bug where really slow devices end up removing the splash screen before they're finished parsing all of the Discourse assets.
This PR won't impact fast devices but should hopefully prevent the premature removal of the splash on super slow devices.
We use javascript to remove the splash screen when the site boots up. If the user has js disabled, they get stuck on the splash screen.
If the user has js disabled. We don't show the splash screen at all.
Fixes a flaky spec:
```
1) WordWatcher.word_matcher_regexp format of the result regexp is correct when watched_words_regular_expressions = true
Failure/Error: expect(regexp.inspect).to eq("/(#{word1})|(#{word2})/i")
expected: "/(word35)|(word36)/i"
got: "/(word36)|(word35)/i"
(compared using ==)
# ./spec/services/word_watcher_spec.rb:19:in `block (4 levels) in <main>'
```
This commit does six things
* changes the animation for the splash screen. To a more subtle animation.
* defers displaying the splash by 1.5 seconds
* defers displaying the splash "loading" text by 2.5 seconds
* defers removing the splash until all Discourse initializers have run
* fixes a display issue in Firefox
* Inlines the SVG as a base64 and inlines the required CSS.
The encoded SVG is hard coded for now, but we will use a helper to generate that based on the file after some testing.
We have a `cleanup!` class method on bookmarks that deletes
bookmarks X days after their related record (post/topic) are
deleted. This commit changes this method to use the
registered_bookmarkables for this instead, and each bookmarkable
type can delete related bookmarks in their own way.
When calling the API to delete a user:
```
curl -X DELETE "https://discourse.example.com/admin/users/159.json" \
-H "Content-Type: multipart/form-data;" \
-H "Api-Key: ***" \
-H "Api-Username: ***" \
-F "delete_posts=true" \
-F "block_email=false" \
-F "block_urls=false" \
-F "block_ip=false"
```
Setting the parameters `block_email`, `block_urls` and `block_ip`explicitly to `false` did not work because the values weren't being parsed to boolean.
