refs https://github.com/TryGhost/Team/issues/559
refs 054a5f15f5
- with the update of `ember-promise-modals` we started to get deprecation warnings when using `modals.open('modal-component-name')`
- upcoming Ember build updates will introduce tree shaking but using run-time lookup of modal components by name works against that because it's not statically analysable
- switched to importing components and passing the component class directly, eg. `modals.open(ModalComponent)`
- standardized modal component class names with a `MyModal` style to get better behaviour in code editors when it auto generates imports
- dropped the modal defaults from the modals service because we can now use a static `modalOptions` property on the modal components themselves when we want to override the defaults
no issue
- since `ember-concurrency@2.0` it's possible to use the standard imports as decorators removing the need for the extra `ember-concurrency-decorators` dependency and imports
refs https://github.com/TryGhost/Team/issues/1310
- we had a `<GhBrowserPreview>` component but it wasn't being used everywhere because it's behaviour didn't match the mobile/desktop switch with no iframe re-render that we needed for some screens
- updated component to match all required behaviour
- include a switch between desktop and mobile views
- default fallbacks for `@title` and `@icon` arguments
- switched design settings themes over to using the component instead of repeating the same set of markup
no issue
- This will help with the octane migration and you can still run the lint rules even when they are todos. (Checkout the docs at 158b119667/docs/todos.md) The good news is any new code will be checked against the recommended config.
- I fixed all the auto fixable things we could get in this PR as well
no issue
- fixed typo in the install-theme modal that meant we weren't correctly identifying Casper as the default theme meaning an attempt to install it was made instead of activating it
no issue
When we were given a source+ref we were using that to find a theme object from the built-in list of marketplace themes and if it wasn't found redirecting to the change-theme screen. That redirect didn't need to happen because we only need the `ref` and can determine the theme name from that.
- passed `ref` through to the install modal as a data argument
- updated install modal to get theme name from passed in theme or extracted from passed in `ref` when theme is not known
- adjusted "isDefaultTheme" so it always checks against Casper rather than using the `ref: 'default'` value from the list of marketplace themes
refs https://github.com/TryGhost/Team/issues/1164
- removed conditional logic for links on settings index now that the old theme settings routes do not exist
- updated error handling test to use new design settings screens
- modified templates' test attributes to work with new design
- fixed `enableLabsFlag()` test helper error when fixtures have already been loaded
no issue
- moved navigation settings tests from old settings/design tests to a separate file and unskipped them
- added happy-path acceptance tests for
- rendering design screen
- installing an official theme from the themes list
- uploading a custom theme
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
- if a theme was uploaded with the same name as a previously deleted theme it was not being shown in the themes list, and if activated could not be found/seen as active breaking the design menu
refs https://github.com/TryGhost/Team/issues/1149
- added Casper to the hardcoded official themes list with a ref of `'default'` so that the install theme process knows to process it differently
- updated the install-theme modal
- removed the `willOverwriteDefault` getter because it's a path that can't be reached and is now handled differently
- changed `installThemeTask` to only perform an activation when a default theme is passed in
closes https://github.com/TryGhost/Team/issues/1130
- migrated install theme process to new modal system and changed to install+activate
- added "Use theme" button that opens the new install+activate modal
- when the view theme screen opens the install modal, an `onSuccess` callback is passed which sets a property that will skip closing the install modal when the view theme modal is closed and transitions to the `settings.design` route leaving the "success" modal state on screen
- added a `skipErrors` option to `themeManage.activateThemeTask` so that it can be used from processes that already handle theme errors without opening extra modals on top
refs https://github.com/TryGhost/Team/issues/1130
- added new route for viewing themes so back/forward buttons can be used
- takes theme name as a parameter
- opens a fullscreen modal with an iframe containing the theme demo
- changed installable themes list to link to new route
- swapped `previewUrl` in theme data to point at the real demo rather than the ghost.org demo page
refs https://github.com/TryGhost/Team/issues/1130
- copied theme upload modal to new modals system and refactored for Octane syntax
- updated to use `themeManagement` service rather than passed in actions so the modal-based process can be opened from any screen
- added default `beforeClose()` for the modal to the modals service so it won't close if an upload is in-progress (defaults were moved directly into the class so it had access to services)
- added `themeManagement.upload` action for triggering the upload modal and providing a central place for limit checks
- added upload-triggering buttons to change-theme and advanced design screens
refs https://github.com/TryGhost/Team/issues/1130
- added link to design sidebar
- dropped change-theme modal and associated route behaviour
- copied basic themes marketplace list into the change-theme controller/template
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
refs https://github.com/TryGhost/Team/issues/1111
Extracted functionality for listing, downloading, activating, and deleting from the theme controller/template into separate components and services so that they are more composable/reusable in different situations.
- moved theme activation to a new `theme-management` service that uses the `modals` service to open the theme warnings modal or limits upgrade modal as required
- the activate process is a task so that consumers can store a reference to the task instance and cancel it to close any related warning/limit modals (eg, when navigating away from the route or closing the modal that kicked off the process)
- created new-pattern modals for custom theme limit upgrade, theme errors, and delete confirmation so that we can treat them as promises and close where needed from parent
- duplicated theme table component as `<GhThemeTableLabs>` with an actions redesign and a refactor to handle download, activation, and deletion itself making use of the new theme-management service and modals
- fixed some oddities with design modal's transition/modal close handling by simplifying the async behaviour and being more explicit
- added advanced design modal that contains the new theme table component and linked to it from footer of design modal's sidebar
refs https://github.com/TryGhost/Team/issues/1111
refs https://github.com/TryGhost/Team/issues/1103
- moved customize modal from a link on the design screen to the main design screen
- changed modal design to be a full-screen overlay with side bar that emulates standard Admin design
- added toggled groups of settings in sidebar
- added `{{set-has}}` helper for use in conditionals matching when a Set contains an object
- added grouping of theme settings
- dropped unfinished advanced/change theme modals
no issue
- copy pasta for the general settings form meant that unsaved settings changes were rolled back when the form was destroyed meaning settings were lost when switching across to the theme settings tab
- rollback is handled higher up at the custom design modal so we don't need to handle it in the form
closes https://github.com/TryGhost/Team/issues/1101
- added `d` param with the description value to the preview header
- updated description input to trigger preview update on blur
refs https://github.com/TryGhost/Team/issues/1097
- added `customThemeSettings.keyValueObject` which returns a plain object with setting values assign to the setting keys on the object
- updated customize modal's preview data generation to use `customThemeSettings.keyValueObject` to assign a JSON-stringified version to the `custom` param on the `x-ghost-preview` header
- updated theme settings `<Select>` component to call the passed through `updatePreview()` action when the value changes
refs https://github.com/TryGhost/Team/issues/1070
- split select form component into it's own component so it's cleaner when we get to additional setting types
- added change handler that updates the setting record's value when a new option is selected
- added `.isDirty` to the custom-theme-settings service so we can warn of unsaved changes and revert any changed values when needed
- added save of custom theme settings to the customize design modal's save routine
- added missing `notifications` service import to customize design controller
refs https://github.com/TryGhost/Team/issues/1070
- adds a `customThemeSettings` service that handles overall setting loading and saving to avoid components having to know any of the intricacies of the model setup
- adds `custom-theme-setting-list` model so that we can save multiple setting records as embedded relations
- custom adapter ensures requests go to the `/custom_theme_settings` base route as a `PUT` request
- custom serializer drops the default `models: []` wrapper in the save request data so the format matches the `PUT /settings` endpoint, then converts the response to look like a `custom-theme-setting-list` response
refs https://github.com/TryGhost/Team/issues/1045
- update of the preview was being triggered by the general settings tab rendering (copy/paste from branding setup) meaning the iframe reloaded when switching between general/theme tabs
- moved the preview update task into the `customize` modal so that it can be called by the general/theme settings components as needed
- moved initial preview rendering to the iframe registration method
refs https://github.com/TryGhost/Team/issues/1045
- added tabs to the the customise design modal's sidebar for general settings and theme settings
- copied settings from the existing branding modal plus site description from general settings screen into the general settings tab
- theme settings tab left blank ready for static design
- `saveTask` put on the controller so that we can access it from the route, allowing us to pause modal closing when navigating away (implementation left for later)
refs https://github.com/TryGhost/Team/issues/559
refs https://github.com/TryGhost/Team/issues/1045
- removed need for `{{will-destroy}}` in the modal template by using `willTransition()` in the route that opened the modal instead
- used the property of new modals acting as promises to implement an unsaved changes confirmation modal
- added `confirmUnsavedChanges()` method that opens a "are you sure you want to leave?" modal that is treated as a promise. If the modal is closed by the "Leave" button the promise returns true in which case we rollback the unsaved changes. The modal is returned so that other behaviour can use this method and wait for the confirmation result
- added `willTransition()` route hook that calls `confirmUnsavedChanges()` when there are unsaved changes and will only continue to transition if the "Leave" button is pressed
- added `beforeClose()` hook to the customize modal when opening so that we can prevent the customize modal from closing when "Stay" is clicked in the confirmation modal
- updated `activate()` hook to store the modal instance so it can be closed later
- updated `deactivate()` hook to call `.close()` on the modal instance rather than using private data/methods on the modals service
refs https://github.com/TryGhost/Team/issues/1045
- added new `settings.design.customize` route
- used the route's `activate` and `deactivate` hooks to trigger and close the customize modal
- added `modals/design/customize` component that uses the existing branding modal design without it's contents as a base
- has `{{will-destroy}}` hook that transitions back to the settings screen so the route will update when the modal gets closed
