refs https://github.com/TryGhost/Team/issues/1151
- we were setting `emailOnly` on the publish menu component but not resetting it meaning when you re-opened the menu after previously selecting "Send" the menu would still show "Send" but the state was inconsistent because the underlying `distributionAction` property _was_ reset
- dropped setting `emailOnly` directly in favour of making it a computed property based on `distributionAction === 'send'` so we only have to worry about changing distribution action and everything else updates for us automatically
refs 89a6bc683b
- `options` did not have a default value and it's always passed in. Added a default value of an empty object so we're not tripped up with null/undefined
closes https://github.com/TryGhost/Team/issues/1151
The publish-type state was being set directly on the model in the publish menu rather than being internal to the menu until publishing. A previous attempt had been made to fix that but it wasn't complete and resulted in the menu showing that it would "Publish" after setting it and closing/re-opening when in fact it would "Publish and send".
- moved all state for the distribution type and email settings to be stored in the `<PublishMenu>` component rather than split across the the component and model
- when saving a post from the publish menu, we now pass `emailOnly` as an option to the editor's save task the same as `sendEmailWhenPublished` (corresponding to the `email_recipient_filter` query param) so that we're back to one place controlling email behaviour for a post
- when `emailOnly` is passed as an option to the editor save task it will set the property on the model before saving and reset it back if the save fails. That way the email-only flag behaves as close to the "send when published" flag as possible without it also being sent as a query param.
- added empty archive screen
- added indication of archive offer on detail page
- set default dropdown style to non-selected
- removed archive button for new offers
refs f4596a0add
- when extracting the groups code from component to service some variable names were changed but the assignment was missed meaning we were assigning all settings rather than specific group settings to each `group.settings` array
no issue
- when copying the template parts out of `<GhSitePreview>` the template was left pointing to passed in arguments rather than pulling the data from the settings service
refs https://github.com/TryGhost/Team/issues/1107
- allowing empty colors introduced some edge cases around theme usage and default values
- it makes more sense to force a color setting to always have a color, if a theme wants to make usage of that color optional then it should use a separate boolean or select setting to control that
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
no issue
- removed the duplicated `<GhErrorMessage>` that is shown when the site title is too long
- removed confusing double `class` attribute on general settings form field, browsers were only respecting the latter class attribute
refs https://github.com/TryGhost/Team/issues/1107
- uses the same type of color picker used elsewhere in Admin with some minor changes to allow blank values
- when value is blank it adjusts the background color block to have a border and a diagonal red line to represent no color being present and makes the native color picker that sits on top transparent because native color pickers _always_ have a color
- has it's own invalid handling/display because we're not dealing with a model that has our typical validation at the moment
no issue
- we were sorting by `created_at` when fetching an individual post rather than the intended `published_at` column
- `.sortBy('publishedAtUTC')` didn't work as intended because the raw values are not directly comparable, switched to a manual sort by using `.valueOf()`
refs https://github.com/TryGhost/Team/issues/1106
- removed `'string'` from the `attr()` definition for `customThemeSetting.value` so that we're not coercing the value from the API into something that doesn't work when applied to the `checked` attribute on checkbox inputs
- added initial `<CustomThemeSettings::Boolean>` component and used it for display in theme setting forms when `type === 'boolean'`
refs https://github.com/TryGhost/Team/issues/1136
- adds dropdown for active/archived offers selection
- wires active/archived offers on list screen to API
- filters offers list on archived/active based on selection
refs https://github.com/TryGhost/Team/issues/1136
- adds option to archive/unarchive an offer
- adds new modals for confirmation of archive or unarchive of offer
- wired (un)archiving of offers to API
no issue
- added details to the `marketplaceThemes` array in the `change-theme` controller
- added theme images obtained from https://ghost.org/themes/
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
- ensured that we're only swapping classes on existing elements or inserting/removing elements around the iframe to avoid re-rendering and the associated loading+layout flash
no issue
- icons seemed to disappear when sections above are opened, or they lost attachment when scrolling
- added `position: relative` to the nav item container so the `position: absolute` children are correctly contained
no issue
There was noticeable flickering as content is loaded into the iframe or re-rendered because we show everything from the moment html is injected in, meaning the full loading and layout process is shown.
- changed to using two iframes with one being hidden
- when `@html` changes we inject the html into the hidden iframe
- once all loading finishes on the hidden iframe (or 500ms timeout occurs to account for slower connections) we swap the iframe visibility so we end up switching between two fully (mostly) rendered displays resulting in much less flicker
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
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
no issue
- custom themes settings isn't really usable without the `{{match}}` helper so to help avoid confusion we'll now enable it whenever the custom theme settings flag is enabled
- added `requires` array to the feature definition which when set will enable all flags in the array when the main feature is enabled
no issue
- by using flex display on the outer container we can get rid of the hardcoded height calc style and let the browser handle the layout more naturally
