Follow-up to https://github.com/discourse/discourse/pull/31742
This commit adds a color palettes list to the new color palette edit page
that was introduced in the linked PR to allow navigating between color
palettes. It reuses the same UI that we already have in the legacy color
palette UI (`/admin/customize/colors`), but we may redesign the page in
the future.
There are instances of posts being deleted by system_user where the context is left blank in the staff action logs, leading to confusion about why exactly they have been deleted.
This change deprecates using the PostDestroyer as system_user without providing a context, and adds a context to all call sites currently missing it in core. Plugins to be done after this is merged.
This is a rewrite of the Getting Started guide, focused on reducing the amount of text and number of links, and restructuring the doc to better meet the needs of new admins.
Even when these plugin outlets are unused we end up with empty spans in
the layout, which can get in the way (especially for grid and flex
layouts where empty containers are not collapsed).
These are fairly hard to target without classes present anyway, they'd
have to be picked up with `:has()` or something like `#main-outlet >
span`. I did a quick spot check of themes/components that use these
outlets in http://github.com/discourse and I didn't see any obvious
cases where they were being targeted.
In any cases where the removal does cause issue, the theme can be
updated to target a container added by it, or a wrapping `span` can be
added there.
This is a straightforward case of porting mobile styles to a breakpoint
in the common file, almost all the mobile styles concern a special
layout for the messages page.
No visual changes.
Previously we were compiling core and theme CSS into two targets:
Desktop and Mobile. The majority of both files was the 'common' css.
This commit splits those common styles into their own targets so that
there is less duplication. This should improve compilation times + cache
reuse, as well as opening the door for experiments with
media-query-based mobile-modes.
The only functional change is that we can no longer use `@extend` to
copy 'common' rules in core to mobile/desktop. This is probably for the
best. Duplication and/or mixins are a more native-css pattern for this.
Plugins already have a common / mobile / desktop pattern, so are
unchanged by this commit.
`github.ref_name` is
> The short ref name of the branch or tag that triggered the workflow
run. This value matches the branch or tag name shown on GitHub. For
example, feature-branch-1.
>
> For pull requests, the format is <pr_number>/merge.
Not sure why we use `github.run_number` when it is a unique number for
each run of a workflow. `github.head_ref` is only present on pull
request events so it is blank when the workflow is ran on
other branches.
By updating the key to `github.ref_name` + `github.job` we ensure that
only one workflow will be running for a given PR or branch.
In this PR we hide search input.
https://github.com/discourse/discourse/pull/32485
However, search input is much more intuitive. Therefore, input was
brought back and opens modal on click. In addition, search link was
removed.
In https://github.com/discourse/discourse/pull/31375, the
glimmer_post_stream_mode_auto_groups setting was added. While
translating, I noticed its description is identical to the one for
glimmer_topic_list_mode - both say "post menu implementation". I assume
this was actually meant to refer to the "post stream" instead? Since
glimmer_post_stream_mode uses "post stream implementation", I expected
this setting - also related to the post stream - to follow the same
wording.
I had also mentioned this on Crowdin about two weeks ago, but didn’t get
a reply.
Usage:
```js
@service capabilities;
...
this.capabilities.viewport.sm; // True when viewport is sm or larger
this.capabilities.viewport.md; // True when viewport is md or larger
// etc.
```
These booleans will update live when the browser is resized. Therefore,
they should only be used in an autotracking context, so that Ember will
re-render things appropriately when they change.
- Move some data transforming into contracts.
- Add some missing specs.
- Use the `try` step.
- Improve the `model` step a bit by allowing to catch any exception,
and not only `ArgumentError`. We already had the mechanism to inspect
which exception was caught.
We are no longer using any of the transpilation/bundling features of
Sprockets. We only use it to serve assets in development, and then
collect & fingerprint them in production. This commit switches us to use
the more modern "Propshaft" gem for that functionality.
Propshaft is much simpler than Sprockets. Instead of taking a
combination of paths + "precompile" list, Propshaft simply assumes all
files in the configured directory are required in production. Previously
we had some base paths configured quite high in the directory structure,
and then only precompiled selected assets within the directory. That's
no longer possible, so this commit refactors those places (mostly
plugin-related) to use dedicated directories under
`app/assets/generated/`.
Another difference is that Propshaft applies asset digests in
development as well as production. This is great for caching & dev/prod
consistency, but does mean some small changes were required in tests.
We previously had some freedom-patches applied to Sprockets. Some of
those had to be ported across to Propshaft. We now have three patches:
1. Skip adding digest hashes to webpack-generated chunks (which are
already digested, and referred to from other js files)
2. Avoid raising errors for missing assets in test mode. We don't always
compile assets before running basic RSpec tests.
3. Maintain relative paths for sourcemap URLs, so that files don't need
to be recompiled depending on their CDN path
Significant refactors are made to the `assets.rake` and `s3.rake` tasks,
which rely on implementation details of Sprockets/Propshaft.
Follow on from https://github.com/discourse/discourse/pull/32285:
This replaces the use of the scrolling-based load-more mixin in
DiscoveryTopicsList with the IntersectionObserver-based LoadMore
component.
I insert the LoadMore component in the parent template for more precise
control over where the sentinel element is placed - right after the List
collection.
Also lifted up the `loadMore` action to the topics glimmer component so
it can be passed directly into LoadMore, and refactored away the jquery
dependency.
This is a breaking change to the behaviour of DiscoveryTopicsList, so
it'll require updates to any other repositories depending on this
component.
This commit introduces various enhancements and refactoring to the
Glimmer Post Stream codebase, focusing on the integration and usage of
`PluginOutlet` components, improved handling of post attributes, and the
introduction of new properties and methods. Key changes include:
1. **`PluginOutlet` Integration**:
- Added `PluginOutlet` components across multiple files, such as
`post.gjs`, `post/avatar.gjs`, and `post-stream.js`, to allow plugins to
extend the functionality of posts, avatars, and metadata more
effectively.
- Introduced `postOutletArgs` to pass structured arguments, enabling
better customization and extensibility for plugins.
- Added PluginOutlet usage in `post/avatar.gjs` for avatar-related
customizations.
2. **Refactored Post Attributes**:
- Enhanced handling of post attributes by deprecating the
`includePostAttributes` method in favor of `addTrackedPostProperties`
for improved compatibility with the Glimmer Post Stream.
- Added a new `isSmallAction` computed property to the `Post` model to
identify small actions or split topics.
3. **Improved Query Parameters**:
- Introduced `topicPageQueryParams` to manage query parameters for
topics more effectively, facilitating smoother updates and interactions
in components that won't need to inject the topic controller or the
router service to get these parameter values.
---------
Co-authored-by: David Taylor <david@taylorhq.com>
Extend the `import_site_settings` import step to enable the
`migrated_site` flag if possible.
It also includes an escape hatch via the
`SKIP_MIGRATED_SITE_FLAG_UPDATE` flag for cases where you really don't
want to toggle it on.
