refs https://github.com/TryGhost/Toolbox/issues/292
- The version notification data service serves as data manger for version compatibility service
- There's not much logic mostly fetching data from proficed services and filtering/serializing it into a needed format
refs https://github.com/TryGhost/Toolbox/issues/292
- There can be multiple users in the Ghost instance that should be notifiied about version mismatch. Following the logic of the security notifications these are users with 'Owner' and 'Administrator' roles. To have the most up to date list of the emails to notify the emails fetching was made dinamic and is now passed in as a 'fetchEmailsToNotify' function.
- Also fixed the subject of the email to match the final copy
refs https://github.com/TryGhost/Toolbox/issues/292
- There's a need to distinguish different types of RequestNotAcceptableError erros by their code. The code is also having an instructional name to give it more explicit utility (nice clue for a developer seeing the error)
refs https://github.com/TryGhost/Toolbox/issues/292
- This middleware is meant to deal with version missmatch erros and call a service that does all the business logic. Having this handling in a separate module allows for thisngs to be loosely coupled
refs https://github.com/TryGhost/Toolbox/issues/292
- The standard sendEmail function used in Ghost accepts three non-optional parameters: to, subject, and html. Have extended the usage with these three required fields
refs https://github.com/TryGhost/Toolbox/issues/292
- Super happy path scenario which handles sending information with some basic incompatibility information
- It's meant to be built up upon! More to follow :)
refs https://github.com/TryGhost/Toolbox/issues/280
- When an outdated client receives a 404 as a response there's no clear way to act on it. Plain 404 says nothing about need to update.
- In such cases the resourceNotFound handler should return a 406 error indicating the Ghost instance needs an update.
refs https://github.com/TryGhost/Toolbox/issues/280
- When an outdated client receives a 404 as a response there's no clear way to act on it. Plain 404 says nothing about need to update.
- In such cases the resourceNotFound handler should return a 406 error indicating the client need to update.
no issue
- When adding more methods under test to this file the require statement will becom difficult to read in one long line. Multiline statement is way nicer to track in git history too
refs bd6a295674
- earlier this week I refactored this block of code to get rid of
explicit `stat` calls, to make the fs operations a little more
lightweight
- I inadvertantly forgot that readdir doesn't follow symlinks, and we
were previously use stat that does, so it was ignoring themes that were
symlinked into `content/themes`
- instead of rolling back my change, I've added an if-statement to call
`fs.stat` and check the origin of the symlink to see if it's a
directory
- also added a test that fails without this change
- we don't need to do both a `fs.readdir` and a `fs.stat` because
`fs.readdir` has the `withFileTypes` which returns the directory entry
info and so this avoids an extra stat syscall
- in the event we get an unknown error bubble up, we don't handle the
templating on the error name
- `@tryghost/tpl` throws an error because we pass an undefined string:
`Cannot read properties of undefined (reading 'replace')`
- this commit adds handling to fallback to a different user message in
that event so we don't cause a 500 error
no issue
Change to error handling caused all theme errors to be reported in Sentry, this fix (and a respective fix in Ghost) allows the error to be prepared for sentry before replacing the stack
