no issue
- While working on https://github.com/TryGhost/Team/issues/726 have questioned some of the options that were passed along to the `send` method. Documented findings and refactored the code slightly while touching it
- calling i18n as a global const like this requires it to be loaded before anything else, when we have to manage this with the init() flow
- wrapping it inside the function where it's used ensures we don't call i18n til we need it
- also improved the i18n called without init error to include the key it was called with
refs 829e8ed010
- i18n is used everywhere but only requires shared or external packages, therefore it's a good candidate for living in shared
- this reduces invalid requires across frontend and server, and lets us use it everywhere until we come up with a better option
- Having these as destructured from the same package is hindering refactoring now
- Events should really only ever be used server-side
- i18n should be a shared module for now so it can be used everywhere until we figure out something better
- Having them seperate also allows us to lint them properly
no issue
- By default, GhostMailer throws EmailError with statusCode as `500` for any failure in sending mail
- In case of failure due to `RecipientError`, status code as now correctly sent as `400` as its a bad request and not an error we can't handle.
* moved `server/config` to `shared/config`
* updated config import paths in server to use shared
* updated config import paths in frontend to use shared
* updated config import paths in test to use shared
* updated config import paths in root to use shared
* trigger regression tests
* of course the rebase broke tests
- Use array destructuring
- Use @tryghost/errors
- Part of the big move towards decoupling, this gives visibility on what's being used where
- Biting off manageable chunks / fixing bits of code I'm refactoring for other reasons
* Added from parameter for member emails
no issue
- Passed in the `from` parameter when initializing members mailer to be able to customize outgoing address
- Extends GhsotMailer to accept a from parameter from the outside
no-issue
Until now, we've used ghost@siteurl.com as the default from address for system emails, like user invitations and password resets. This was fine, because all system emails were going to people who would interact with "ghost" the app in some way, so the naming made sense.
Now we're introducing members, which will send emails on behalf of of the site owner, to their readers. If all goes to plan, they should be able to set a custom from address, however our default mail config will still be the fallback if no other value is available.
If you run "magazine.com" and you send someone a link to "login to magazine.com" then it's pretty weird for that email to come from "ghost@magazine.com" - so this PR changes the default value from ghost to noreply for an equally generic, but less opinionated default.
closes#10773
- The refactoring is a substitute for `urlService.utils` used previously throughout the codebase and now extracted into the separate module in Ghost-SDK
- Added url-utils stubbing utility for test suites
- Some tests had to be refactored to avoid double mocks (when url's are being reset inside of rested 'describe' groups)
* Updated docs links to best equivalents
- Our documentation has been overhauled, this updates the all the old links sprinkled through Ghost
* Update integrity hash
refs #9742
- Ghost 2.0 is coming
- all doc links in 1.0 must use concrete links e.g. docs.ghost.org/v1 or themes.ghost.org/v1.23.0/
- if we release Ghost 2.0, docs.ghost.org will show 2.0 docs
