refs https://github.com/TryGhost/Team/issues/2110
- dynamically defined properties on the config service did not have
autotracking set up properly if they were accessed in any way before the
property was defined, this caused problems in a number of areas because
we have both "unauthed" and "authed" sets of config and when not logged
in we had parts of the app checking for authed config properties that
don't exist until after sign-in and subsequent config re-fetch
- renamed `config` service to `configManager` and updated to only
contain methods for fetching config data
- added a `config` instance initializer that sets up a `TrackedObject`
instance with some custom properties/methods and registers it on
`config:main`
- uses application instance initializer rather than a standard
initializer because standard initializers are only called once when
setting up the test suite so we'd end up with config leaking across
tests
- added an `@inject` decorator that when used takes the property name
and injects whatever is registered at `${propertyName}:main`, this
allows us to use dependency injection for any object rather than just
services or controllers
- using `application.inject()` in the initializer was initially used but
that only works for objects that extend from `EmberObject`, the
injections weren't available in native-class glimmer components so this
decorator keeps the injection syntax consistent
- swapped all `@service config` uses to `@inject config`
no issue
When no custom theme settings exist it's nice to have the brand settings form automatically visible when opening the design settings menu to avoid an extra click and let users make actions immediately. We don't want that behaviour when custom theme settings exist because it would hide useful context and result in extra scroll+clicks to get to the section you're interested in.
- when first rendering the menu, set the open section to `brand` if we're on the design settings index screen
- add an event handler to the router that re-sets the open section to `brand` each time we navigate back to the design settings index screen (leaving the index screen closes all open sections)
no issue
We want to automatically show brand settings expanded in the design menu when the active theme has no custom theme settings, in order to do that without causing visual noise/jank we need to ensure that we have all the data we need up-front before the design menu is rendered.
- optimized `customThemeSettings` loading behaviour
- `.load()` will now only perform a fetch if settings have not previously been loaded so it can be called without causing unnecessary waits
- `.reload()` will force a clear+refetch of the settings - called by `themeManagement.activate()` after successfully changing a theme
- moved fetching of theme settings from the design menu constructor to the `settings.design` route's `model()` hook
- means the app will wait for loading to finish before showing any of the design settings screen so we can guarantee the data we need is available
- moved update of preview html from the design menu constructor to the design settings route as it's a more appropriate place to find screen setup/loading behaviour
refs https://github.com/TryGhost/Team/issues/1149
- added a `@data.onActivationSuccess` option to the upload-theme modal that if present is called when activation of a theme is completed as part of the upload process
- added a `startThemeUpload()` action to the `change-theme` controller so that we can pass in an `onActivationSuccess` which transitions to the `design.settings.index` screen
- removed unnecessary `@tracked` decorators on class properties that have `store.peekAll('theme')` assigned to them
no issue
- `get settingGroups()` was always returning a new object which meant the template was re-rendering unexpectedly which created issues with form fields that lose their focus when re-rendered
- moved group handling into the `customThemeSettings` service as it makes more sense to keep it centralized, that gave us the ability to create a new `settingGroups` array only when the settings list changes keeping the tracked invalidation easier to reason about
closes https://github.com/TryGhost/Team/issues/1103
Custom post settings can be grouped by homepage or post, when set to `'post'` it makes sense to be able to preview a post page rather than the homepage.
- added preview type selection to `themeManagement` service
- `.availablePreviewTypes` is useful for populating selects or other page selection elements
- `.previewType` is set to the currently selected preview type name
- `.setPreviewType()` is for setting the preview type and re-generating the preview html if necessary
- updated `themeManagement.updatePreviewHtmlTask` to fetch the latest published post if we don't already have a published post reference in the store, that post's `url` is then used when fetching the preview html if the preview type is set to `'post'`
- added a select element to the design index header that uses the themeManagement properties/actions to list types and update the preview on change
- updated the design nav menu to switch preview types when different sections are opened so the preview automatically switches to the post preview when making changes to the "post" custom theme settings group
no issue
- fetch themes in the background when sidebar is rendered in case they haven't been loaded so far (current screen design means the first time the nav bar is seen the themes are unlikely to have been loaded already)
- added `activeTheme` getter to grab the active theme from the live themes list
refs bc5be1a808
- after removing duplication for groups in the template we were showing empty groups because the group construction wasn't considering there may be no settings for a group
no issue
- added `settingGroups` array to the nav menu so that it can be looped over rather than having the same template duplicated for hard coded settings arrays
no issue
- custom theme model was missing the `group` attr so the nav menu couldn't see it to assign to groups
- changed homepage group from `home` to `homepage` to match gscan
- added fallback to showing in the "Site-wide" group if an unknown group value is seen
refs https://github.com/TryGhost/Team/issues/1130
- when opening/closing sections or interacting with the general design or custom theme settings we want to switch back to showing the preview so the sidebar acts more like typical navigation and so form changes show their effect
refs https://github.com/TryGhost/Team/issues/1130
- added `ui.contextualNavMenu` property that when set will switch the main nav menu between components, if it's not set then it will show the default "main" menu component
- added `design` menu sub-component of `gh-nav-menu` ready for use via `contextualNavMenu`
- moved sidebar contents from the design modal into this component
- updated design route to set/reset `ui.contextualNavMenu` to `design` on entering/leaving the route
- all other design routes are sub-routes so this works across all other design screens
- moved base design modal preview into the `settings/design/index` controller/template
- using index means that it's the default screen for `/settings/design` but will be automatically replaced by any other `design.x` routes
- moved `design/advanced` modal content into the `settings.design.advanced` controller/template and removed the modal handling from the route
