mirror of
https://github.com/TryGhost/Ghost.git
synced 2024-11-27 10:42:45 +03:00
cc88757e2a
ref https://app.incident.io/ghost/incidents/107 - We have a rare bug that causes the initial `POST` request to create a new post from the editor to be skipped or fail. Subsequent `PUT` requests then fail because there is no post ID, potentially resulting in data loss. The aim of this commit is to start saving revisions of posts in the editor to the browser's localStorage, as a last-ditch option to restore lost work. - Since we don't know where the bug is yet, and to protect against future bugs, we've deliberately avoided depending too heavily on the `lexical-editor` controller or the ember store. We've aimed to create a direct route to the state in the editor, by hooking into the `updateScratch` method (effectively the `onChange` handler for the editor). - The `scheduleSave` function on the new `local-revisions` service is called immediately upon any changes to the state of the lexical editor, which is effectively every keystroke. The service has some logic and timeouts, so it doesn't actually save a revision on every change to the editor. - The "schema" of the datastore is a simple key-value store, where the key is of the format: `post-revision-${postId}-${timestamp}` if the post has an ID, or `post-revision-draft-${timestamp}` for an unsaved draft. There is also an array of all the revisions' keys, which allows us to clear all the revisions without having to loop over every key in localStorage (along with some other conveniences, like filtering). - There is currently no UI for viewing/restoring revisions. In the event that you need to restore a revision, you can access the service in the browser console. You can access all the saved revisions using the `list()` method, which logs all the revisions to the console by title & timestamp. You can then choose a revision to restore, and call `restore(revision_key)`, which will `POST` the revision's data to the server to create a new post. - Since localStorage data is limited to a 5mb quota in most browsers, the service has a mechanism for evicting the oldest revisions once it meets the quota. If a save fails because it would exceed the quota, the `performSave` method will evict the oldest revision, then recursively try to save again. --------- Co-authored-by: Steve Larson <9larsons@gmail.com> |
||
|---|---|---|
| .. | ||
| adapters | ||
| authenticators | ||
| components | ||
| controllers | ||
| decorators | ||
| errors | ||
| helpers | ||
| initializers | ||
| instance-initializers | ||
| mixins | ||
| models | ||
| modifiers | ||
| routes | ||
| serializers | ||
| services | ||
| session-stores | ||
| styles | ||
| templates | ||
| transforms | ||
| transitions | ||
| utils | ||
| validators | ||
| app.js | ||
| index.html | ||
| README.md | ||
| router.js | ||
| transitions.js | ||
Ghost Admin App
Ember.js application used as a client-side admin for the Ghost blogging platform. This readme is a work in progress guide aimed at explaining the specific nuances of the Ghost Ember app to contributors whose main focus is on this side of things.
CSS
We use pure CSS, which is pre-processed for backwards compatibility by Myth. We do not follow any strict CSS framework, however our general style is pretty similar to BEM.
Styles are primarily broken up into 4 main categories:
- Patterns - are base level visual styles for HTML elements (eg. Buttons)
- Components - are groups of patterns used to create a UI component (eg. Modals)
- Layouts - are groups of components used to create application screens (eg. Settings)
All of these separate files are subsequently imported and compiled in app.css.
Front End Standards
- 4 spaces for HTML & CSS indentation. Never tabs.
- Double quotes only, never single quotes.
- Use tags and elements appropriate for an HTML5 doctype (including self-closing tags)
- Adhere to the Recess CSS property order.
- Always a space after a property's colon (.e.g, display: block; and not display:block;).
- End all lines with a semi-colon.
- For multiple, comma-separated selectors, place each selector on its own line.
- Use js- prefixed classes for JavaScript hooks into the DOM, and never use these in CSS as per Slightly Obtrusive JavaScript
- Avoid over-nesting CSS. Never nest more than 3 levels deep.
- Use comments to explain "why" not "what" (Good: This requires a z-index in order to appear above mobile navigation. Bad: This is a thing which is always on top!)