According to Zlib documentation, this is not a fatal error. In this case
we attempt to deflate the asset three times before giving up.
Sprockets will be replaced in the long term and this is an acceptable fix.
When a tag has a description defined, we should use that in the `<meta
name="description"...` tag on the tagged topic list page. This matches
the behaviour on the equivalent category pages.
Fixes the same issue that
e9387e238c
did for twitter.com, but for x.com. Since they redirect
on our first FinalDestination call with onebox, the request
fails even with `twitter_consumer_secret` and `twitter_consumer_key`
settings set.
Continues the work done on
https://github.com/discourse/discourse/pull/30815.
Adds an `html_block` node and its parsing/serialization logic.
It's rendered as a code block with HTML syntax highlighting, and
serialized as-is to the Markdown output.
Continues the work done on
https://github.com/discourse/discourse/pull/30815.
Adds an `html_inline` node for a subset for allowed HTML, its
parsing/serializing logic, and an input rule to auto-trigger the node
creation when a `<allowedtag>` is typed.
Not related to the above, but I also renamed the tests that don't define
a template from `gjs` to `js`.
Continues the work done on
https://github.com/discourse/discourse/pull/30815.
Extends the ProseMirror-markdown `code-block` node by integrating our
existing HighlightJS pipeline for code highlighting and adding a node
view with a `<select>` to change the language of the block.
We're also adding the markdown paste extension, which handles converting
pasted text/plain to rich content if it contains Markdown.
---------
Co-authored-by: Martin Brennan <martin@discourse.org>
We were using a zero width space added by CSS here, but have run into
occasional encoding issues for some reason? a couple people have
reported getting this instead of an empty space:
I can't repro the issue, but we can avoid it by removing this space in
CSS — setting the container height to `1em` along with `line-height:
normal` should make it consistent with the height of the text within.
In the blame it seems this static height on the container was added
after the pseudo hack, and achieves the same goal when I test it across
a Firefox/Chrome/Safari
This is the beginning of a longer process to merge our stylesheets under
the common directory.
I also converted a SCSS variable to a CSS custom property along the way.
In the case of the lightbox styles, this seemed more appropriate to
distinguish by primary input type (touch vs mouse) rather than
breakpoint sizes.
This gems bring a whole improved fluentui emoji set. Each image has been
recomputed to optimise the size of the emoji and remove useless margins.
For this reason the version has been bumped.
Other changes:
- not loading rake task dependencies in production
- renamed yo_yo/yo-yo to yoyo
When the upgrade process from 29a8c6ee498999f114f933d2de2b46989a407660 is run, there's a deployment race condition where old code can write a Reviewable to the database without a `type_source` (incorrectly defaulting it to "unknown").
This change adds a post-deploy migration script that populates any such Reviewables with the correct `type_source` value.
This reverts commit 7e65cdbc9aa86677a2f6f7a8d4f1b8e87da07ff1.
It broke the production build, as it's trying to load
`selenium-webdriver` (a dev dep) in the production env.
In the `discourse/discourse_test:release` base image, the minio binaries
are already being installed and updated on a daily basis. There is also
no
real need for us to have to run the latest minio binaries once it is
released. As such, we can drop the step in the `tests` workflow.
This gems bring a whole improved fluentui emoji set. Each image has been
recomputed to optimize the size of the emoji and remove useless margins.
For this reason the version has been bumped.
Other notable change: the emoji yo-yo can now be called "yoyo".
Calling `<field.Calendar>` will ultimately call `componentFor` which
will mutate the type of the field. Problem is the way we use a hash to
define all the available controls, would work correctly on first render,
but because of the mutation in `componentFor` if something would trigger
a re-render it would have to evaluate all the `componentFor` calls, and
the last one would "win" (currently calendar), which would mean that a
field rendered as custom would for example become calendar.
The easiest repro was:
```gjs
<Form as |form|>
<form.field as |field|>
{{log field}}
<field.Custom>
Hello world
</field.Custom>
</form.field>
</Form>
```
The fix for now is to mutate the value at the point where the component
is actually rendered, in control-wrapper.
A possibly more correct longer term fix could be to change the API, to
set the type on the field when defined in the template, and render a
generic component which would use this type to know what to render:
```gjs
<form.field @type="calendar" as |field|>
<field.Control @someCalendarOption="bar" />
</form.field>
```
Follow up from https://github.com/discourse/discourse/pull/31559.
We expect some standard headers to be added from
`Rails.application.config.action_dispatch.default_headers` for
responses, however these were found to be removed in some error paths.
For more detail on this behaviour, refer to https://github.com/discourse/discourse/pull/31619#issuecomment-2699644232.
This PR adds those headers back if they aren't there, with the caveats
that we don't add headers that are irrelevant for non-HTML responses,
and neither do we add X-Frame-Options which is intentionally removed for
embeddables.
* Added a subtle left border to the indented field to improve visual
hierarchy
* Updated the caret to align with other expandable elements for
consistency
This change ensures that queued posts that have ended up in the review queue due to matched a watched word display correctly.
It also improves the data checking to ensure that any other reviewables with watched words don't break the review queue, either.
We are developing our new composer, and it would be useful
if we could know how posts are being created by members.
To this end, we are going to start storing the following
on post_stats, which are created at the same time as a post
is created:
* writing_device - Based on `BrowserDetection.device`, which in
turn is based on user agent. Will store .e.g iphone, android,
mac, windows etc.
* writing_user_agent - Stores the full user agent (truncated at
400 chars) of the device/browser the member used to write the post.
* composer_version - Either `1` for our old composer, or
`2` if the new rich composer is enabled in site settings and
the user has toggled it on
Only notable changes is that we added
internal support for TimeWithZone which
was absent from previous release
We also improved error messages for T_OBJECT
