- The snake case pattern is used in all the rest of test suite file names
- Cleaned up these two files as they were sticking out in the folder I was touching
refs https://github.com/TryGhost/Ghost/commit/abeabb764
- Continued work started in referenced commit in making sites_spec more manageable.
- Extracted out separate v2/v3/canary specs for each site configuration
- Now these files are easily diff'able and introducing new API version would include copying a file over instead of adding up to a gigantic file
refs https://github.com/TryGhost/Ghost/commit/2f20930ff
- The aim is to split site test suite into separate files v2/v3/v4 after this move
- It is hard to grep or diff the file of this size.
- Having separate files per ghost-api engine will allow tracking changes between different API versions in the future
- It's a continuation of work started in refed commit
no issue
- The site_spec is a catch all suite with too many moving parts. While adding a new tests suite for v4 frontend configuration it felt overwhelming to add hundreds of lines to a >5000 line monstrocity
refs https://github.com/TryGhost/Team/issues/467
refs https://github.com/TryGhost/Team/issues/221
- we've introduced backwards-compatible changes to rendering in 3.0 such as srcset and sizes which will only have taken effect on posts created or edited since the changes were made
- 4.0 brings additional changes such as image card width/height
- re-generating the `html` field of all posts from the `mobiledoc` brings all content up to latest rendering output
- Continuing cleanup and clarification of the boot process
- By locating requires and inits more closely together its easier to see what happens where and to get timings
- Improved consistency of the debug begin/end statements
- Added "Step" comments to the main process
- Inlined the mountGhost function, for readability and consistency with the other steps
refs https://github.com/TryGhost/Team/issues/469
The initial implementation was just to get us going with the dashboard
but the requirements have changed now, rather than updating the code we
allow to pass the `limit` options so the Admin can choose how many
events to display.
- There is now one true way to start Ghost - you create a server, and then call start with an express app
- We may well expand this again to improve testing pathways in future, but it will be done with a bit more clarity about expectations
- moved logging variable outside of the try-catch block, so it doesn't need a 2nd require
- I was considering having config,logging etc shared components required in a function together, but it's less readable
- Having a try-catch for loading shared components before main boot is also confusing
- This is simplest and most readable IMO
refs dd715b33dc
- this is the last event that is used to trigger part of the standard boot process
- events make the code harder to read/reason about
- the urlservice is one of the most core and critical components in Ghost, possibly the biggest consumer of time and memory
- we want to have the work it is doing front and center so that we can improve it
closes https://github.com/TryGhost/Ghost/issues/12506
- adds an error handler that will rename the backup folder to the original name if the newly uploaded theme wasn't saved successfully
refs https://github.com/TryGhost/Team/issues/221#issuecomment-759105424
- Mailgun responds to an email send with a provider id in the format `<x@y.com>` but everywhere else it's used in their API it uses the format `x@y.com`
- updates email batch save to strip the brackets, and migration removes brackets from existing records so we no longer have to add special handling for the stored id any time we use it
refs b1a98b0b67
- note: I already replaced server.start with themes.ready in the above commit
- events make the code harder to read/reason about
- long term it would be nice to have a concept of hooks for services, but for now explicit is clearer
refs https://github.com/TryGhost/Ghost/issues/12496
- having the logging require here means that workers wanting to use the db are unable to do so without requiring logging as a side-effect
- `connection.loggingHook` does not appear to be widely used for anything outside of specific debugging scenarios when using MySQL so it should be safe to disable until a proper fix is found for workers+logging leaking file descriptors
refs https://github.com/TryGhost/Ghost/issues/12496
By requiring the models layer the shared logging util was being required as a side-effect causing the open file descriptors problem to continue. Removing logging from the models layer isn't feasible due to deep require chains spreading across the codebase, it's much quicker to remove the need for models in the analytics job.
- models layer was only needed because it's used by the session service
- updated analytics job to create it's own instance of `EmailAnalyticsService` rather than the default instance in order to pass in custom dependencies
- pass in custom `logging` object that uses `parentPort.postMessage` as a way of writing log output
- pass in custom `settings` object that returns settings that have been manually fetched and cached during job instantiation
refs https://github.com/TryGhost/Ghost/issues/12633
Adds new `browse` endpoint for emails that allows Admin to check performance of newsletters over time and show stats on dashboard as primary usecase
refs https://github.com/TryGhost/Ghost/issues/12496
- Handling logging in the main thread avoids file handle leaks which happen due to leaky implementation of bunyan logger (see referenced issue for more context)
- Bumped job-manager version to allow for `workerMessageHandler` callback funciton
refs https://github.com/TryGhost/Ghost/issues/12496
- Using ghost-ignition logging caused file handle leaks. As there is no straight-forward way to handle write streams with bunyan (ghost-ignition's underlying logging library) this method of logging was chosen as an alternative to keep the amount of open file handles to minimum
- The follow up changes will include custom formatter for jobs service which should make logging match the same format as has been used inside the jobs
refs https://github.com/TryGhost/Ghost/pull/12598
- This changeset adds idepmotence to situations where unique contraint has to be dropped or added to the table
- Note '4.0/07-alter-unique-constraint-for-posts-slug.js` was migration that was effected by lack of idempotence
refs https://github.com/TryGhost/Ghost/issues/10318
- Storing JSON object in settings has caused multiple bugs in the past and was considered an antipattern
- This is a last bit in the long process of getting rid of "object" settings in the database. At this point there should be no settings with this type. Yey!
- In the old boot the server wasn't started til we were ready
- In new boot, we start the server immediately and send the old started event
- Then, when we are ready to accept some traffic, we send a ready event
- At the moment, ready isn't quite sent at the right time:
- It _should_ be when we're ready to serve real traffic, not just send 503s
- This is after the URL generation has finished
- But this requires more refactoring work :(
- So for now we send when everything else is ready
- This really needs some tests
- Notify is a more familiar name e.g. systemd has the sd_notify system which this is similar to
- We're actually announcing the server started, it's not actually ready for traffic (will serve 503s)
