no issue
- the first check when uploading a theme is the same as the second but without returning a specific error message so it shouldn't be necessary
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
no issue
- by using `innerHTML` we were missing the lang and class attributes on the `<html>` element that are added by themes, breaking things like dark mode
- switching to `outerHTML` includes the `<html>` element and is handled automatically by iframes when writing to the `contentWindow`
refs https://github.com/TryGhost/Team/issues/1111
We now have a situation where we have modals on modals and we've lost the straightforward built-in "Data down, actions up" communication methods that we'd have workaround across nested routes/controllers. The upshot of that is we didn't have a way to trigger a refresh of the preview when a new theme was activated.
- moved the task responsible for fetching preview html from the design modal onto the `theme-management` service and adjusted it to set a tracked `previewHtml` property rather than updating an iframe directly
- added a `<GhHtmlIframe>` component that renders a basic iframe element and updates it's contents each time the `@html` argument changes
- updated design modal preview to use the new iframe component
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
