This commit achieves a few things:
- ☑️ No longer having to remember whether a command is yarn something or grunt something
- ☑️ Simplification of tools hopefully making them easier to remember and use
- ☑️ Complete removal of the need for grunt from our test tooling
Several of the tools still use grunt under the hood, but the **entrypoint** should aways be `yarn xxx`.
- `grunt main` -> `yarn main`
- `grunt dev` -> `yarn dev`
- `grunt build` -> `yarn build`
- `grunt test:file-or-folder` -> `yarn test file-or-folder`
- `grunt test-unit` -> `yarn test:unit`
- `grunt test-acceptance` -> `yarn test:acceptance`
- `grunt test-regression` -> `yarn test:regression`
- `grunt validate` -> removed due to lack of use
There is now also `yarn test:all` to run all 3 classes of tests
This PR also reorders & restructures the Gruntfile extensively so that:
- The remaining useful commands are all at the top of the file
- Config and other blah happens after all the useful commands
- All release-only config happens in the release task at the very end of the file
---
DONE:
* Removed all references to npm/bower
* Removed all references to lint / deprecated command
* Moved debug to yarn dev:debug
* Removed all references to travis
* Removed broken help task + useless comment
* Removed unused knex-migrator and clean:test setup tasks
* Added new test commands, removed grunt validate
* Moved stubClientFiles to test utility and use in the few tests that need it
* Used mocha in yarn directly except grunt test:x
* Swapped grunt test for yarn test
* extensive cleanup and reshuffling
closes https://github.com/TryGhost/Team/issues/817
refs 6d083ee00e/packages/bookshelf-pagination/lib/bookshelf-pagination.js (L256)
- The 500 error is not the best we can do in this situation and throwing a 400 just like we doo in a referenced commit would keep the convention
- The underlying problem of the bug is bigger - we allow the fields named the same way as relations to leak into the db query and that causes an incorrect SQL syntax. It's a bigger problem which would need a separate, holistic approach
refs https://github.com/TryGhost/Team/issues/849
As part of work for segmented post access with multiple products, the custom filter for post access is stored in `visibility` field on posts but passed with `visibility_filter` property on API. This change -
- updates input serializer of posts to transform `visibility` and `visibility_filter` properties correctly
- updates output serializer for canary to transform and send `visibility_filter` attribute with filter value
- updates output serializer for v3 to ignore any custom filter on visibility and return `paid` instead as v3 didn't have a concept of custom filter
refs: fbf0636936
- I renamed this pattern in a bunch of places, but missed a few, leaving the code messy and confusing
- This makes the naming consistent
refs https://github.com/TryGhost/Team/issues/828
- Before sending out batches with members we need to partition all members based on the segment they belong to. Special segment "unsegmented" is used in case none of the segments used in the emal cards cover part of the members set (for example only free members card used when emailing all members)
refs https://github.com/TryGhost/Team/issues/845
refs 517d2abc5c
- updated router response formatting functions and `{{#get}}` helper response handling to make any `feature_image_caption` properties in the response a `SafeString` instance so triple-curlies are not needed when using the property in themes
- This function is quite different to the others, as it generates an excerpt from HTML (truncating)
- Most functions in the meta data folder just contain content negotiation logic, like if post then feature_image else cover_image type things
- This function is more like a library and shouldn't live in Ghost, it should probably be in @tryghost/helpers
- It's definitely something we'd love to rewrite to work better tooooo
- we moved the meta folder out of data a really long time ago
- we also moved the sitemap out of data/xml into a service
- this moves the tests to roughly match
- This is part of the quest to separate the frontend and server & get rid of all the places where there are cross-requires
- At the moment the settings cache is one big shared cache used by the frontend and server liberally
- This change doesn't really solve the fundamental problems, as we still depend on events, and requires from inside frontend
- However it allows us to control the misuse slightly better by getting rid of restricted requires and turning on that eslint ruleset
- requiring lib/common/events makes the settings cache tightly coupled to the server
- moving this up to settings index means the cache itself can be moved to a shared component/moved out of Ghost
- the index then becomes the settings manager
- questionable whether the event listeners & updater part of this shouldn't be part of a manager, independent of the actual cache 🤔
- shutdown removed listeners, which should really be done before adding them anyway!
- reset sets the cache back to an empty object, which was already done by init
- merge these into one reset function that fully resets the cache
- all instances of shutdown were called before an init call, and now called during init, therefore these can be removed
- acceptance utils had an instance of calling shutdown and reset together as part of stopping Ghost, reworked that to be clearer
refs https://github.com/TryGhost/Team/issues/828
- When detecting email segments and later creating a member filter out of this data we only care about unique segments otherwise we'd be creating multiple batches with the same segment filter
refs https://github.com/TryGhost/Team/issues/828
- This is experimental segment extraction logic, more to follow. Alllows to extract arrays of email segments used in the email's HTML content
- Makes the logic for determining the admin and frontend vhost args independent and easier to test
- Moved the tests to specifically test the vhost utils & removed proxyquire as a dependency
- We want to breakdown the current parent app into the existing core/app.js and boot code, allowing us to decouple the backend and frontend further
- This is all part of the refactoring to separate server and frontend completely
refs d9ddc2db6a
refs https://github.com/TryGhost/Team/issues/754
- The tests were written with falsy assumptions and validation added in refed commit have uncovered it!
- A secondary issue touched here is additional JSON object serialization that is used in the "input serializer" -d9ddc2db6a/core/server/api/v2/utils/serializers/input/settings.js (L107-L110)
- The additional stringification should not be there at all. It covers for a mistaken internal use of Settings API where raw objects are passed around instead of serialized JSON Objects (see commets left with this changeset for details)
refs https://github.com/TryGhost/Team/issues/754
refs a7dec233ba
- Additional validation protects from problems like the ones in refed commit from even getting through to the database.
- At the moment only used notificatons and couple more settings to ensure they are arrays when passed into the API. This is to avoid making big change in settings straight away - this is a problematic area which needs cautious approach.
- Ideally in the future the list of settings to check the "array" type (and other types) should be automatically generated based on the default-settings.json (or whatever way we define settings in the db a that moment)
- There's an ugly code-tripplication going on in this change. This is a separate topic that will be addressed once we work on API cleanup.
refs https://github.com/TryGhost/Team/issues/804
The associative table is used to implement the many-to-many relationship
between Products and Benefits. The `sort_order` column is needed because
a product's benefits should be orderable by an admin.
refs https://github.com/TryGhost/Team/issues/804
Benefits are tag-like resources which will be associated with Products.
The first iteration just requires a name for the benefit, which will be
stored as plaintext.
refs https://github.com/TryGhost/Team/issues/754
closes https://github.com/TryGhost/Ghost/issues/13088
refs a7dec233ba
- The corrupted data recovery mechanism for notifications is needed to be able to fix the data stored in `settings` table under `notifications` key. There was no validation in place, which has caused some instances to store data in unreadable/writable state
- The recovery mechanism is in place to avoid adding migrations every time we spot a broken notifications data (will be fixed by validation soon).
- The notification data is also NOT critical but valuable for system functioning properly, that's the reason why the data "healing" happens in less secure "fire-and-forget" way
- The referenced commit is where the "bigger" problem that was causing the data corruption was at. This change is a "cleanup" after what has happened there - storing Ghost error object in `value` for `notifications` key
issue https://github.com/TryGhost/Team/issues/750
- Only accessible by admins
- Resets all staff users' passwords and prevents them to log-in
- Sends them a reset email password to give them back access to their account
- Closes all existing staff user sessions
refs 474e6c4c45
- The method was not easy to understand after skimming through it.
- As we are working on developing a similar pattern for upcoming similar featured created a basic test suited to see input/output relation clearly
refs https://github.com/TryGhost/Team/issues/793
New settings added for newsletter customisation options:
- `newsletter_header_image` - `null/"$url"`
- `newsletter_show_header_icon` - `"true/false"`
- `newsletter_show_header_title` - `"true/false"`
- `newsletter_title_alignment` - `"center/left"`
- `newsletter_title_font_category` - `"serif/sans_serif"`
- `newsletter_show_feature_image` - `"true/false"`
`newsletter_show_header` has been dropped because the same functionality can be achieved by setting both `newsletter_show_header_icon` and `newsletter_show_header_title` to `false`
---
- migration to convert and delete `newsletter_show_header` setting
- removed `newsletter_show_header` from default settings to ensure it doesn't get re-created
- replaced main labs template and template settings generation with the labs template
- deleted labs template
- stubUrlUtils is now doing the same thing as our existing configUtils but is slightly harder to use
- swapped this out, and made stubUrlUtils an internal-only utility
refs https://github.com/TryGhost/Team/issues/768
- `portal_products` stores list of products available in Portal
- adds new `portal_products` setting to default settings
- adds migration to populate `portal_products` with current product so its available by default
- update tests
- We were using the same bind pattern for both internal-only and public helpers
- Binding helpers to config makes them available throughout the codebase
- Removing the binding doesn't make the code much more complicated, but it does make the Public API of the config module a lot clearer
- Renamed the file in line with our rules around index.js files
- Cleaned up some outdated code patterns
- Want to make the config module a little clearer in what it does
- Part of the effort to split Ghost down into smaller, decoupled pieces
- Moved out our internal validator tooling to a separate library
- Replaced all usage of our own tooling and validatorjs directly with @tryghost/validator
- Removed the validatorjs dependency and removed the renovate pin
- This gives us a consistant, smaller, clearer public API for validations
- It will eventually be used on Ghost Admin too
- This way we can start getting up to date with validator whilst not increasing build size
no issue
- we're going to pull this out into the framework monorepo but
refactoring it here first makes it a lot easier to extract without
losing the history
no issue
The only pieces of Ghost-Ignition used in Ghost were debug and
logging. Both of these modules have been superceded by the Framework
monorepo, and all usages of Ignition have now been removed, replaced
with @tryghost/debug and @tryghost/logging.
no issue
- we're going to pull this out into the `framework` monorepo but
refactoring it here first makes it a lot easier to extract without
losing the history
- note: this is very temporary and will be extracted soon
- renamed our internal validation library to "validator" - which is the same as the tool it wraps
- updated the public api so that validator methods are directly exposed
- this will make it a drop-in replacement for validator-js
- in turn, this allows us to pull this out into @tryghost/validator, and use our own wrapper instead of the 3rd party library
- General code cleanup
- Removed unused notContains rule
- Swapped custom empty rule for builtin isEmpty rule
- Dropped usage of .extend on validator, as this was removed 2 years ago!
- This will allow us to upgrade the validator dependency to a much newer version
- Changed our internal validator module to only expose the functions we use.
- This gives us a clearer Public API
- It makes it easier to see if we are affected by changes in validator
- It's still easy to add another validator, we just have to update what we require
- We can potentially use this to make smaller builds esp for client-side usage
- Once ripped out into a module we can use ES imports :D
- Rejigged and _slightly_ improved the tests
refs:
- cf15f60085
- dd20cc649b
- ccf27f7009
- abf146d61f
- 2b54c92a14
- bb029a53f6
- 95bd7ee675
- 9018b4df22
- df01a6e5f4
- d313726b34
- these plugins were in a state where they were independent enough to be
pulled out into their own packages, which is what we did in the
referenced commits above
- each package is named like `@tryghost/bookshelf-<plugin>`
- to avoid requiring multiple packages into Ghost, we've also created a
wrapper package called `@tryghost/bookshelf-plugins` which re-exports
all these plugins, so the changes in Ghost are very simple - dbebdd43b5
- this commit deletes the plugins + tests, and replaces with our new
package with some minor code changes
- This is super specific code relating only to validating passwords.
- It's needed as a shared validator as we use other funnels to help people setup Ghost on Pro, but currently it's hard-baked into Ghost
- It's also not the greatest code. It'd be nice to be able to rework it and know that would automatically update everywhere passwords are set
- This is a really specific piece of code related to validating models against our internal schema.js format
- This doesn't make sense without a schema.js file
- It does depend on the internal validator and validate tools - but those are used elsewhere too, and can reasonably be moved out of the codebase
- I don't see schema.js moving out of the codebase any time soon. We can move the validator but it would be a class that requires schema via DI
- For now my focus is on getting the data/validation tooling separated and making clear sense
- Improving data/schema can come later :)
- The data/validation module is made up of several loosely related things with lots of dependencies
- Separating out the various components makes it possible to see what's what, and importantly what has complex dependencies
- validator + validate probably go togetheri in an external module, the other two files should probably have their own homes in related areas of ghost e.g. schema -> data/schema/validate.js
refs https://github.com/TryGhost/Team/issues/770
We want post feature image functionality to better match what's available inside the editor, to do that we'll need somewhere to store alt and caption meta data. `posts_meta` chosen because even though we want to make this generic for other tables in the future those tables also have a `feature_image` (or closely related) field.
- updated schema with new columns
- added migration to create columns
- cleaned new columns from API output
- not output on v2/v3
- conditionally output on v4/canary output based on labs flag
- bumped `@tryghost/admin-api-schema` to allow new columns through in canary API requests
- silently clean properties from input when labs flag is disabled
- updated acceptance tests so they fail if `admin-api-schema` is not letting the new fields through
no issue
Shows impact of new code behind labs flags through the existing acceptance/regression tests. Allows for existing tests to be updated to match new behaviour rather than requiring separate tests where individual flags are enabled. Should result in minimal test updating once code reaches GA.
- adds a forced `'labs:enabled'` fixture op that edits the `labs` setting to enable all flags then restarts the settings service to pick up the new setting
- modifies labs service to not remove ALPHA_FEATURE labs settings when running in a testing environment
- Traditionally all of Ghost's public-facing text was written in British English
- We're changing that to US English because that's more common
- US English should also be used in code e.g. properties are called color not colour
- most of these changes are in comments, but I've changed them so that we have US English in front of us always
- fixed a few other typos I noticed whilst there
refs https://github.com/TryGhost/Team/issues/772
- When the feature is introduced into Ghost at it's first lifecycle stage - "alpha" the rule is to have a "enableDeveloperExperiments" flag along with labs toggle turned on before it's usagble in the codebase
- The changeset introduced a "ALPHA_KEYS" concept which should allow distinguishing alpha flags from beta flags.
closes https://github.com/TryGhost/Team/issues/761
With multiple products, each product can have an active monthly/yearly price, so we no longer store the monthly/yearly price ids in global settings but instead store them in product table directly. This means we need to update our global `@price` helper to also use the updated schema and use the monthly/yearly prices from product table instead of settings data.
refs: https://github.com/TryGhost/Team/issues/759
- wired up a matchHelper feature flag & used the labsEnabledHelper tool to gate the helper
- added a first version of the match helper, which is intended to replace the has helper
- this is an experimental helper and may or may not make it to GA
- match is a simple comparison helper, right now it does a very basic equals or not equals comparison
- much more functionality is needed to reach parity with has
refs https://github.com/TryGhost/Team/issues/757
- The "type" value in settings is meant to be representing the data type stored in the "value" field. It was an overlooked bug in v4 API adding a mapper to group->type
refs https://github.com/TryGhost/Team/issues/757
- Groups are meant to represent the group to which the settings key belongs and have the same value as stored in the DB. This was an evolution of v2/v3 API's "type"
- Having a fixed value for groups in a test will make it easier to track the "type" change that is about to land
refs https://github.com/TryGhost/Team/issues/757
- There is no usecase for editing "labs" settings outside of canary/v4 API versions. Removing support for older versions makes the supported API surface smaller (easy maintenance).
refs https://github.com/TryGhost/Team/issues/757
- To safeguard from mise of a very permissing "object" value of the "labs" setting this change introduces an "allowlist" approach to filtering unrecognized labs flags
- Should allow maintainers to have a clear view of which labs flags are currently in use and manage them accordingly
refs https://github.com/TryGhost/Team/issues/757
refs https://github.com/TryGhost/Team/issues/332
refs ea6d656457
- We have a need a quick way to add features behind flags. The old way of "labs" is the quickest way to achieve this. It has ready tooling around it and well understood pitfalls. This change reintroduces "labs" group & key in settings table in the same shape it used to be (see reffed commit)
- Next step will be introducing very basic guard rails to protect from pitfalls previous implementation of "labs" had. This will include an allowlist based input validation for lab's object's data
- The labs being an "object" type is an EXCEPTION. Even though it's an antipattern we aim to move away from, for now it's the lowest impact solution that will unblock the use of flags in the system. A proper solution will come at some point.
- we don't need to use _.escape from lodash as we already have escapeExpression from handlebars
- it's more correct to use the escape utility from our theme engine when escaping strings _for_ our theme engine!
- Note there is a minor difference between the two:
- Lodash: &, <, >, " and '
- refs: https://lodash.com/docs/4.17.15#escape
- Handlebars: &, <, >, ", ', ` and =
- refs: https://handlebarsjs.com/api-reference/utilities.html#helper-utilities
- This could cause slightly weird behaviour in themes around ` and = characters, but as it's just convering to html entities it should be fine
* 🐛 Fixed saving Members with Complimentary plans
refs https://github.com/TryGhost/Team/issues/758
Since 4.6 The Admin is using the comped flag again, rather than creating
subscriptions for zero-amount prices directly. With the `comped` flag
removed, the default state was for it to be falsy in the Admin, and when
saved would trigger the legacy comped flow, cancelling the subscription.
This reverts commit 57a176ff3d.
refs https://github.com/TryGhost/Team/issues/728
- The code of update check has been extracted into it's own package as a part of TryGhost/Core monorepo. This commit is a cleanup of the leftover files
refs https://github.com/TryGhost/Team/issues/728
- This is continuation of the previous commit. TLDR: Passing only the necessary parameter data makes it easier to reason about what dependencies the UpdateCheckService has to deal with
- Instead of passing in a whole GhostMailer instance passing only an email sending function, which again - makes things way more manageable to reason about
- The end of refactor, next will be a move of the UpdateCheckService into a separate module in tryghost/core
refs https://github.com/TryGhost/Team/issues/728
- This is continuation of the previous commit. TLDR: Passing only the necessary parameter data makes it easier to reason about what dependencies the UpdateCheckService has to deal with
- Burned ghostVersion module passing in vafor of just one additional config parameter. Now the module along with unit tests can be easily extracted out of the codebase!
refs https://github.com/TryGhost/Team/issues/728
- This is continuation of the previous commit. TLDR: Passing only the necessary API endpoint function makes it easier to reason about what dependencies the UpdateCheckService has to deal with
- Substituted a parameter with already existing 'siteUrl' config value. No need to duplicate work!
refs https://github.com/TryGhost/Team/issues/728
- This is continuation of the previous commit. TLDR: Passing only the necessary API endpoint function makes it easier to reason about what dependencies the UpdateCheckService has to deal with
- Limited urlUtils to only one function as that's all the UpdateCheck uses. Next step will be removing the function completely as and passing a 'blogURL' as a config value (way better readability this way)
refs https://github.com/TryGhost/Team/issues/728
- This is continuation of the previous commit. TLDR: Passing only the necessary API endpoint function makes it easier to reason about what dependencies the UpdateCheckService has to deal with
- There are 8 different configs that NotificationService depends upon it will need some further investigation around which ones are even needed anymore and the naming is not the best. To keep the time cap at bay leaving it at what it is.
refs https://github.com/TryGhost/Team/issues/728
- Previous name was after the do-all-the-things mega module that have now become an "initializer" for the UpdateCheckService class. The unit tests are testing the latter, so the rename is a cleanup from the previous ways
refs https://github.com/TryGhost/Team/issues/728
- This is the end of the refactor for update check tests. There are no dependencies for Ghost server process to run this test suite!
- Next steps will be extracting the service to an outside module
refs https://github.com/TryGhost/Team/issues/728
- Rewire is usually a sign of massive module that is impossible to unit test without mocking big parts of that module. With a refactored UpdateCheckService and a brand new test coverage there is no need to use rewire and leave the "smell"
refs https://github.com/TryGhost/Team/issues/728
- This is a continuation of the test coverage for the UpdateCheckService.
- Covers scpecial cases of notification processing within Update Check
- The refactor inside the update check service was a convenience to get rid or the Bluebird dependency completely. Also, some minor preventative code added to avoid errors from referencing undefined objects
refs https://github.com/TryGhost/Team/issues/728
- This is a continuation of the test coverage for the UpdateCheckService.
- Covers a basic check for what kind of data is sent from the service to external analytics
refs https://github.com/TryGhost/Team/issues/728
- This approach is moving away from stubbing and "rewiring" massive internal modules and instead only stubs needed dependencies for the UpdateCheckService class
- Also eliminates the need to depend on the database fixtures which should speed up test execution and move it to proper "unit test" class when the test rewrite is complete
- starting and stopping Ghost is part of our rather unloved acceptance test framework
- moving them into their own file to make the different pieces clearer and also to start to make improvements
- first improvement had to happen as an aside - exposing the existingData property via a function and making the API clearer
- this was a weird thing set on module.exports, very hidden and hard to follow
- Note: stopGhost is only used once in the regression/modles/model_posts_spec.js file to make the test run fast enough...
- These tests are effectively "DB integration" tests e.g. non-unit tests because they do use the DB, they need their own framework
refs https://github.com/TryGhost/Team/issues/710
refs https://github.com/TryGhost/Team/issues/725
Products will now have a single monthly and yearly price which will be
used throughout Themes, Portal & Admin. These columns will be used to
track the current prices for each of them, and will update anytime we
change the pricing of a product.
Due to a circular table dependency we have not added a foreign key
constraint to the new columns, this will be handled at a later date. It
is tracked in issue 725 references above
- use testUtils.startGhost() directly
- use async+await for tests
- simplify tests down using expect(fn) to make them more readable
- don't require config directly
- removed TODO which is no longer valid
- All this is essentially ground work before introducing a better framework for running acceptance tests
- These tests protect some advanced, yet important behaviour around URLs
- Moved them out of regression tests into acceptance, as we're slowly trying to clean up regression tests :)
- Checking for differences in behaviour when urls are configured with or without slashes should fall to unit testing
- Generally testing that a correctly configured subdirectory site does what's expected is an acceptance test
- Ghost's 301 to trailing slash behaviour is also well tested, and doesn't need extensive acceptance tests when using a subdir
- Instead, test that the non-subdirectory equivalent route is 404ing as expected, to check that routes are ONLY mounted on the subdir, as well as mounted at all
refs a1556797b6
- The test was using an outdated syntax which broke after migration to async/await in the tested funciton
- Updated test is much more readable and should handle promise rejections (async function throws) universally
refs https://github.com/TryGhost/Team/issues/726
- When UpdateCheck service sends a notification with "type: 'alert'" an email goes out to admin users with the "message" content of the notification.
- This functionality is aimed to handling critical messages like urgent instance updates
- Next step will be getting as much of the update check code extracted into a "service" and then moved out of Ghost's codebase
closes https://github.com/TryGhost/Ghost/issues/12986
refs 1345268089
As part of changes in 4.6, the default price ids for monthly/yearly prices are stored in new settings - `members_monthly_price_id`, `members_yearly_price_id` - which are used to determine current active prices for the site from list of all existing prices. While the last commit updated the prices to use the settings, the data for currency was still used from non-zero prices instead of the new settings value.
- Updated tests to check price currency
closes https://github.com/TryGhost/Ghost/issues/12980
closes https://github.com/TryGhost/Team/issues/730
As part of changes in 4.6, the default price ids for monthly/yearly prices are stored in new settings - `members_monthly_price_id`, `members_yearly_price_id` - which are used to determine current active prices for the site from list of all existing prices. The `@price` helper was incorrectly still relying on the old logic for active monthly/yearly price using the first active price with matching nickname, and resulted in showing incorrect price data on the theme.
- Updated tests to check price data using settings value
refs: 895bffec1f
- Allowing tests to be skipped masks issues where people temporarily skip tests to fix later and accidentally commit
- Converting this to an error allows us to see when this happens easily
- In future, when we're done with the dance of using ESLint rules to signpost codebase improvements, we may want to downgrade this back to a warning
- This would enable us to have deliberate, temporarily skipped tests in the codebase, if there's a usecase for that with pushing to main regularly
refs: f1be3418d9
- Since I refactored the boot process & subsequently the test tools, I have been hitting an issue where subdirectory tests don't work if the app has already been started without a subdirectory
- Turns out it's due to the rootApp getting cached, and not replaced no matter what you do, even though if you debug it _looks_ like it's been replaced
- This makes sense as the rootApp is in a separate file and therefore subject to the node module cache and we're using const everywhere
- Therefore, I have added a single line to the test utils to destroy this cache for this file, and the tests now work perfectly
- Next: refactor the test utilities some more to make all this much, much more straightforward and easy to understand
refs https://github.com/TryGhost/Team/issues/694
- This refactor is not ideal but moves us closer to the desired form of class with injectable (and testable) parameters. Allowed to refactor the test slightly so at least we can check if schedulerd subscribed events work and if they trigger the adapter with correct data
- Ideally the api/model calls shoudl be abstracted away as well, but that's for another time
- Also got rid of completely pointless "adapters/scheduling" unit test. All it was checking was if the "init" method was called int the passe in object
no-issue
These tests were previously skipped due to the NONE algorithm tests
failing. These were failing for good reason, we do NOT want the none
algorithm to be accepted. The tests have been updated to reflect that,
and unskipped.
no-issue
These tests were skipped out due to adding with the subscriptions
relation not working. However this functionality is redundant, as it is
not used anywhere. The tests have been updated to test that we can read
the subscriptions relation correctly.
no-issue
We no longer want to include skipped tests in the codebase. These tests
were added as placeholders until a point at which we were able to mock
Stripe.
We haven't got time during cleanup to mock Stripe so removing these
tests for now.
refs https://github.com/TryGhost/Team/issues/694
- Unskipping the test does not seem to be causing a failure any longer. Removed the skip as it would be causing linting errors as we tighten up the `.skip` rules
refs https://github.com/TryGhost/Team/issues/694
- The previous `.then` chaining was outdated, while in this part of code did a tiny cleanup which should improve future maintenance slightly
refs https://github.com/TryGhost/Team/issues/694
- The previous `.then` chaining was outdated and was causing 2x ghost instance initialization per test suite
- With a refactor there's only one intance initialization per suite (saves running time!) and we use more readable async/await syntax, which should make things more maintainable
refs https://github.com/TryGhost/Team/issues/694
- The tests were skipped and were throwing an eslint warning, which soon will become an error.
- They were skipped initially as they used an outdated authorization mechanism. With migration to token based auth the tests are green again
no issue
- The test was skipped, which should not have been commited into the trunk in the first place. The checks were reworked to reflect the reality - the endpoint ignores the "group" qurey parameter
refs https://github.com/TryGhost/Team/issues/610
- When either schema or default settings changes it's often forgotten to check if exporter handles updated tables/keys properly
- These tests are meant to serve as a reminder to check exporter and modify what's needed when changes are introduced into schema/default settings
no-issue
This protects our tests against changes to the database schema, which
helps us decouple the API from the database, and make tests less
brittle. It also forces us to manually update the tests if we do make a
change to the API!
refs https://github.com/TryGhost/Team/issues/693
Since we've got rid of the concept of Complimentary with the Custom
Prices work, we're removing the 'comped' status from members. This
involves a migration for existing members, a schema update for the
validation, and a bump to members-api to no longer use the 'comped'
status for new members.
We also update the aggregation of the MemberStatusEvent to consider the
'comped' status as 'paid', and that there are 0 'comped' status events
in the database.
We can consider a migration for this data in the future, either adding
new status events moving from 'comped' to 'paid', or by modifying
existing status events. However both of these are very difficulty to
write a down migration for, and might be best saved for a major version.
- @tryghost/members-api@1.7.0 is the version that includes the required
changes, however we have already bumped to 1.8.0 in Ghost
closes https://github.com/TryGhost/Team/issues/699
With custom products, saving a member with subscriptions on member detail page in Admin throws errors on console, though the save is successful. This breaks the Admin as user needs to refresh the screen again to get rid of error. This change -
- updates the response on member save to return `price` object in subscription
- updates tests
no refs
Since backend now allows multiple prices but we want the prices to be currently limited to monthly/yearly on UI, we need new settings to store the current monthly/yearly price by the site owner. These settings determine the active prices shown in Admin / Portal for the site till we allow all custom products/prices again.
refs 06dd9bac59
- This is a continuation of the work started in the refed commit. In short: allowlisting response checks wherever possible
- The file is now "schema" depencency free. Should serve as an example for other test "utils" modules.
refs https://github.com/TryGhost/Team/issues/560
refs 196cdafe6b
Last commit updated the response status for member endpoint - `/members/api/member` - from 401 to 204. This change updates the test to handle new response code.
refs https://github.com/TryGhost/Team/issues/687
- The frontmatter field has leaked into the API layer unintentionally when it was introduced into the DB schema during 4.0 release.
- The fix add the field to "trim" list in all API. A proper validation and handling will be add per API as usecase for the field becomes clear
refs https://github.com/TryGhost/Team/issues/687
- The approach of generating validation properties using `/server/data/schema` package's tables object is prone to leaking unwanted database fields into API responses
- This refactor takes a tiny step into direction of relying on "allowlist" approach for properties in the API response resources.
- Apart from solving the described property leak problem it also moves toward decoupling tests from `/core/server` dependencies!
refs https://github.com/TryGhost/Team/issues/581
closes https://github.com/TryGhost/Team/issues/582
Emails can now be sent to members with specific associated labels or products by specifying an NQL string. We want to bring the same members segment feature to content by allowing `visibility` to be an NQL filter string on top of the `public/members/paid` special-case strings.
As an example it's possible to set `posts.visibility` to `label:vip` to make a post available only to those members with the `vip` label.
- removed enum validations for `visibility` so it now accepts any string or `null`
- bumped `@tryghost/admin-api-schema` for API-level validation changes
- added nql validation to API input validators by running the visibility query against the members model
- added transform of NQL to special-case visibility values when saving post model
- ensures there's a single way of representing "members" and "paid" where NQL gives multiple ways of representing the same segment
- useful for keeping theme-level checks such as `{{#has visibility="paid"}}` working as expected
- updated content-gating to parse nql from post's visibility and use it to query the currently logged in member to see if there's a match
- bumped @tryghost/members-api to include label and product data when loading member
refs https://github.com/TryGhost/Team/issues/671
When turning on custom products, existing sites should have default price descriptions that match existing values for prices. This change sets the default description for Free price to match existing hardcoded value.
- Not sure why, but this is set to off in our base plugin
- It masks issues where people have temporarily skipped tests to fix later and then forgot
- Enabling this to allow us to review all those places, but we should also try to leave it on and set to error
no-issue
Our base model will only automatically convert numbers to booleans if
the type is 'bool' - however this column was incorrectly added with a
type of 'boolean'. Lucklily - knex with both MySQL & SQLite3 will add
a column with the same type for both of these, so no migration is needed
to fix it.
refs https://github.com/TryGhost/Team/issues/668
Since we no longer store price data in the settings we must use the api
to read the stripe prices for the default price, so that we can maintain
backwards compatibility for the `@price` data in themes.
refs https://github.com/TryGhost/Team/issues/637
The "free" price - when Members signup without using Stripe, should have
a name and description, so that it can be displayed in Portal in a
similar way to paid price's. As there is only ever one, and it is not a
fully fledged price, a setting makes more sense than a dedicated db
table.
refs https://github.com/TryGhost/Team/issues/586
We are no longer using the `stripe_plans` setting, instead we are using
the `stripe_prices` database table. However, we must keep the setting as
the migration from the setting to the database is not done as a standard
migration, but in code. This means our code has to still read and pass
the setting because we will never know if the migration in code has run
yet.
The `portal_plans` setting has been updated to only include 'free' by
default, because the setting must include id's now rather than names.
refs https://github.com/TryGhost/Team/issues/586
A discussion in the Members team resulted in us determining that we do
not need to enforce unique names for Products. Stripe does not enforce
uniqueness for their Products, and we feel it's not necessary for us to.
refs 37ebe723c6
- `package-json` was a standalone library using dependency injection so
we could pull it out into its own package in Utils
- this was done in the commit referenced above
- this commit removes the implementation and tests in Ghost and replaces
the require in the initialization wrapper with the new package
refs https://github.com/TryGhost/Team/issues/581
refs https://github.com/TryGhost/Team/issues/582
When publishing a post via the API it was possible to send it using `?email_recipient_filter=all/free/paid` which allowed you to send to members only based on their payment status which is quite limiting for some sites.
This PR updates the `?email_recipient_filter` query param to support Ghost's `?filter` param syntax which enables more specific recipient lists, eg:
`?email_recipient_filter=status:free` = free members only
`?email_recipient_filter=status:paid` = paid members only
`?email_recipient_filter=label:vip` = members that have the `vip` label attached
`?email_recipient_filter=status:paid,label:vip` = paid members and members that have the `vip` label attached
The older `free/paid` values are still supported by the API for backwards compatibility.
- updates `Post` and `Email` models to transform legacy `free` and `paid` values to their NQL equivalents on read/write
- lets us not worry about supporting legacy values elsewhere in the code
- cleanup migration to transform all rows slated for 5.0
- removes schema and API `isIn` validations for recipient filters so allow free-form filters
- updates posts API input serializers to transform `free` and `paid` values in the `?email_recipient_filter` param to their NQL equivalents for backwards compatibility
- updates Post API controllers `edit` methods to run a query using the supplied filter to verify that it's valid
- updates `mega` service to use the filter directly when selecting recipients
refs https://github.com/TryGhost/Team/issues/581
Editors are allowed to restrict post visibility and send emails to particular member segments, they need to be able to read labels so that they can select them in a member segment.
- Using JS files to configure eslint gives us more power, e.g. being able to calculate paths
- We already use JS in pretty much every other repo we own, including admin... it's just Ghost we don't, and it's time!
refs https://github.com/TryGhost/Team/issues/496
We want to give more control over the default selection of email recipients when publishing a post, to do that we need somewhere to store those settings. These settings are site-wide and intended for use by admins to control the default editor behaviour for all staff users. They _do not_ control API behaviour, if you want to send email when publishing via the API it's still necessary to explicitly opt in to that using the `?email_recipients_filter=` query param.
- new `editor` settings group to indicate that these settings only affect the UI rather than the API
- `editor_default_email_recipients` controls overall behaviour, string/enum with these allowed values:
- `'disabled'`: no option to send email is shown in the editor's publishing dropdown
- `'visibility'`: (default) selected member segment is dynamic and matches the post visibility filter
- `'filter'`: specific member filter defined in `editor_default_email_recipients_filter` setting
- `editor_default_email_recipients_filter` is an NQL string for selecting members, used when `editor_default_email_recipients` is set to `'filter'`
- default value is `'all'`
- the segment string can be any valid NQL filter with the additional special-case values of `'all'` and `'none'`
- final preparation for moving i18n out of Ghost core
- logging is passed in via DI
- theme i18n needs a config value, but no need to pass all of config for one parameter, a better pattern is to pass the one value needed
- preparation for moving the base class out of Ghost
- refactored so that all the logic for file loading and fallbacks live in the base class
- theme i18n now only overrides init with the properties it needs, filepath generation and error handling
- this makes it much easier to move the i18n file out, and eventually have theme i18n live elsewhere too
- also prepares for using DI for logging
- when activating a theme, we need to load the current locale
- this request used to be buried deep in the themeI18n init call
- now we surface it in the bridge and pass it down, which is closer to what we want to do with eventually initialising the frontend
with everything it needs up front (or not initialising it, if it isn't needed)
- in the related helpers we depend on the site.locale value instead of proxy -> themeI18n -> settingsCache drastically simplifying the code and removing deep requires
- site.locale is updated via middleware and can be relied upon
- the core i18n library and theme i18n library have slightly different methods of getting a candidate string
- both of them use forms of jsonpath, meaning they both require jsonpath as a dependency
- to try to get to a point of being able to rip more things out of ghost, we want to have less dependencies
- so instead of overloading the method, we pass in a stringMode as an argument
- eventually we might not need an overloaded class for themeI18n at all, which would simplify the codebase
- preparation for using DI instead of requires, so we can move this out of Ghost
- have done this for both the main i18n and theme i18n file
- refactored the constructor
refs https://github.com/TryGhost/Team/issues/586
The `products` and `stripe_prices` tables are missing a description
column which will be used by Portal to display information about the
products and prices
- Preparing to cleanup / change how we use events across Ghost
- Removing this unused bit of additional complexity makes it easier to reason about what we need
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
refs https://github.com/TryGhost/Team/issues/588
- This check allows for a on/off switch to be set up on the instance and control limits around sending emails
- An example configuration for such check would look like following in config's hostSettings section, e.g.:
```
"emails": {
"disabled": true,
"error": "Email sending has been temporarily disabled whilst your account is under review."
}
```
refs: bf0823c9a2
refs: ae86254972
- continuing the work of splitting up the theme service into logical components
Themes Service
- The serverside theme service now serves just the API and boot
- It loads the theme and passes it to the theme-engine via the bridge
This achieves the bare minimum goal of removing all the cross requires between server and frontend around themes
There is still a lot more to do to achieve an ideal architecture here as laid out in ae86254972
refs https://github.com/TryGhost/Team/issues/616
We need a way to assign Products to Members via a Subscription, and we've
followed the same pattern as the editSubscription method for the Members API
controller, which acts upon Subscriptions as a nested resource.
Subscriptions now are linked to products, and we've included those links by
default in the Member Admin API as we already include subscriptions by
default, and Products are now a core part of the Members feature-set.
- the themeService.loadAll method was refactored out ages ago, so this clearly isn't used in tests
- the rest are requires I spotted whilst working around the codebase
- note: we have noUnusedVars disabled as a linting error in tests because else should complains everywhere
refs: bf0823c9a2
- continuing the work of splitting up the theme service into logical components
- This one is a little more involved, as the i18n initialisation was unnecessarily spread over several locations.
- I moved it into being part of the ActiveTheme class and called in the constructor, meaning we don't need the services.theme.activated event anymore as the constructor is called in the same cases.
- Also moved the event listener for locales into the bridge, as I don't want that inside of theme-engine, and we don't want circular dependencies. We'll figure out a wayto refactor this soon too.
refs: bf0823c9a2
- Added a new bridge class that lives in shared. This should eventually be responsible for all cross-communication between the frontend and the server
- Having all the gnarly shared bits in one place should help us refactor more easily
- For now it also reduces requires between the core/server and core/frontend folders that are meant to be separate
- All calls to getApiVersion have also been renamed to getFrontendApiVersion, as this is different to the "default" API version
- Slowly getting to the point where frontend/services/themes can be moved to server/services/themes :)
refs: bf0823c9a2
- continuing the work of splitting up the theme service into logical components
- this is where it starts to get fiddly as the getActive function in themeService index is required across the frontend/backend mostly due to its use in the getApiVersion method
- for now left one usage of the getActive method in place in ghost-locals middleware ready for the next phase of the refactor, which will move some of the themeService index into a shared location
refs: 9f50e941eb
refs: bf0823c9a2
- Still working towards splitting the theme service into logical components
- The engine defaults were required in the index file, in a way that creates tight coupling across what would otherwise
be distinct components
- Also meant there was another hardcoded 'v4' in the codebase
- This fixes both issues by depending on the value from config
- Currently this adds Yet Another Config Require, but it should be fine for now until we have a new pattern for the frontend
- Note: We only care about the ghost-api engine, we used to care about both ghost and ghost-api. Now that there is only one there was no need for the more complex code structures
refs c873899e49
- as of `bson-objectid` v2.0.0, this library exports the function
to generate an ObjectID directly, and then you need to use `.toHexString()`
to get the 24 character hex string - 6696f27d82
- this commit removes all uses of `.generate()` and replaces with this
change
refs https://github.com/TryGhost/Team/issues/579
- when members signup is enabled returns `#/portal` otherwise returns feedly subscription URL
- allows for themes to have subscription buttons without condititionals, eg `<a href="{{@site.signup_url}}">Subscribe</a>`
refs 08fbcf1d90
- I didn't quite finish this commit before, and also forgot to write a proper commit message 🙈
- Having the theme service required and referenced in lots of different ways contributes to it being very hard to refactor and break down into smaller pieces
- This is just one simple nice-to-have so we can search the codebase for references more easily
- At some point we have updated the path that should be required to get helpers, but missed updating the path in this test
- When run with the full suite, the test still passed, but when run independently it threw the error loadCoreHelpers is not a function
- This is to do with some interaction with the middleware_spec.js tests
- I'm working on breaking all this down so hopefully will get rid of any further weird test independence issues
refs https://github.com/TryGhost/Team/issues/619
As part of the Custom Products work, we are linking members to products
when updating their subscriptions. This requires that we have at least
one product in the database. For existing sites that are using Members
this is handled by the v4.3 03 migration. But for new sites we must
include a fixture.
Also fixes the tests to not reply on the order of the fixtures
refs https://github.com/TryGhost/Team/issues/586
- Adds new `stripe_price_id` column to subscriptions table to store stripe price ids with `index`
- Populates `stripe_price_id` column value to current `plan_id` making the `plan_*` values redundant
- Updates tests
refs https://github.com/TryGhost/Team/issues/586
If a product inside Ghost is deleted, we want to cascade delete all associated Stripe products and prices as they always need to refer back to a ghost product and will hang without any reason otherwise. This change adds cascade delete for products -> stripe_products -> stripe_prices to avoid broken states
- This is the beginning of splitting up the theme service into:
- Storage components used by the API (should be a server service)
- Theme engine & rendering components used by the frontend (this new engine service)
- The code to activate a theme which is shared code where the API & frontend need to communicate
- This is needed because currently the frontend theme service is required and used by the API, creating tight coupling.
- In my quest to truly separate the API and frontend, this is one of many battles that needs winning
refs https://github.com/TryGhost/Team/issues/579
- setting `members_signup_access` to `'none'` effectively disables all built-in members functions on the front-end so setting `@labs.members` to `false` allows themes to react accordingly
- `@labs.members` keeps backwards compatibility with pre-4.0 versions where themes were using it to toggle member-related functionality
refs https://github.com/TryGhost/Team/issues/579
- skips insertion of members-related scripts and styles when `members_signup_access` setting is set to `'none'`
- adds `id="gh-members-styles"` to the inserted style script tag for reference in tests and JS
refs https://github.com/TryGhost/Team/issues/579
Currently the members signup setting is explicitly yes/no to allowing free members signup, with the implication that when set to "no" members is still active but members have to be created via Stripe or the admin API.
This change renames the setting and changes its type to allow more than a binary option.
- migration to create/update the new setting based on the old value
- free signup = "all", no free signup = "invite"; matches the current UI for this setting
- rename setting everywhere it's used/tested against
- modify `getAllowSelfSignup()` used to configure members packages to only return `true` when the new setting is set to `'all'` to match behaviour to the older setting
- update importer to rename the setting when importing from an older Ghost version
refs https://github.com/TryGhost/Team/issues/618
- The `oauth_client_id` and `oauth_client_secret` are placeholders to store OAuths related data.
- The flag for `oauth_enabled` or anything along those lines was not added intentionally in favour of checking if the `oauth_client_id` & `oauth_client_secret` are null.
refs https://github.com/TryGhost/Team/issues/616
All roles which can publish posts should be able to read/browse products, as content gating
will be based on products going forward.
Creating, updating & destroying products will often make modifications to Stripe which requires
Administrator or Owner roles.
We also improve the permissions tests so that we no longer rely on things being in a particular
order.
refs https://github.com/TryGhost/Team/issues/586
- Change the interval column to be `nullable` as one time payments won't have any interval
- Remove the `livemode` column as we store the connected account's livemode status at top level
https://github.com/TryGhost/Team/issues/599
- When custom integration limit is enabled all requests from existing integrations should not be accepted. With the exception of internal integrations like backup and scheduler
refs https://github.com/TryGhost/Team/issues/599
- This is a precursor change to tests which verify the hostSettings limits are working correctly
- Bumped limits-service version which allows for multiple calls of loadLimits on the same service instance
refs https://github.com/TryGhost/Team/issues/586
- Member model now has `products` relation, sorted using `sort_order`, following convention from `labels`
- Product model has handling to set `slug` from name, following convention of Label model
- Updated filter plugin to handle filtering Member models by their `product` relations e.g. `product:[slug, slug]`
refs https://github.com/TryGhost/Team/issues/586
- Add the `stripe_products` table, so that we can map Stripe Products to Products in Ghost
- Add the `stripe_prices` table, so that we can associate Stripe Prices to Products table
refs https://github.com/TryGhost/Team/issues/586
- Add the products table, so that we can store Products in Ghost
- Add the members_products table, so that we can associate Members w/ Products
- Use sort_order on the members_products table to follow the same convention in members_labels
- Populate the products table with a single product, using the name from the stripe_product_name setting
- Populate the members_products table with relations based on the status column of the members table
Populating the tables allows us to transition from the current system, which does not care about products, into the
new system, where Products are used to group members. The intention is that all existing paid members have the
same product
refs https://github.com/TryGhost/Team/issues/585
- adds `DELETE /members/` route to the Admin API
- supports `?filter`, and `?search` query params to limit the members that are deleted
- `?all=true` is required if no other filter or query is provided
- uses `models.Member.bulkDestroy` which _will not_ cancel any Stripe subscriptions if members have them but _will_ clean up the Stripe relationship data in Ghost's database
no issue
- During an investigation of a possible Zapier bug discovered there was no coverage at all for sending emails for new member signups. This changeset adds coverage for basic case of `send_email` and `email_type` behavior
no refs
- Removes old `/members/stats` endpoint in favor of new `/members/stats/count` in canary/v4 which captures members counts using new events table
- Removes tests for old `/members/stats` endpoint
- Added test for new `/members/stats/count` endpoint
refs https://github.com/TryGhost/Team/issues/555
- Export files included a lot of data which was not used in the importer, for example: members, labels, migrations and many more. This lead to a lot of clutter in the import files and made it hard to reason about their purpose.
- The main purpose of exports - is to export importable resources. These are posts, tags, and users. The rest of data like members or migrations either have their own importer (like CSV importer for members) or does not and should not have any ways to be imported.
- These changes are in now way complete. It's a first step towards resource-based exports which could be properly versioned in the future on API level and not be a mirror of the DB structure.
- This is sort of a breaking change. But we are doing it because: (1) its an internal API that should not be used by external clients, (2) there was no public contract to have this API stable at any point, (3) we really need to get back the control over export files structure and size
- In case an external client was dependent on some structure of the exported json file they can still pass in ALL of previously exported data by passing table names in `include` query parameter.
refs https://github.com/TryGhost/Team/issues/555
- This version is dynamic and depends on latest Ghsot version. It's unrealistic to expect test maintainer to update this version regularly, instead opted into checking the format of the version property
refs https://github.com/TryGhost/Team/issues/555
- Fixed "skipped" test which was useful to have for scenarios when "include" parameters are passed into exporter
- Also updated assertions to explicitly list calls to tables - these tests should break and should be fixed when exporter is modified!
refs https://github.com/TryGhost/Team/issues/555
- Previous blocklist approach was resulting in adding every single new table into an export automatically. Which creates possibility to leak sensitive data if not used porperly. Allowlist approach gives better control over what is exported, makes this information explicit, and version-control friendlier
refs 74cdbadedb
- Fixes failing test by enforcing ordering through `sort()` call. Doing this to avoid differences between node versions' `Object.keys()` ordering
refs https://github.com/TryGhost/Team/issues/555
refs 080a8fc082
- The `have.keys` assertion was not doing strict comparison neither provided any useful output when changed to `have.only.keys`.
- Rewrote the tests to use manual assertion through array comparison which checks exactly what it's supposed to and gives a visual diff in case there are any missing/extra properties in config
no issue
- The test was designed to fail when `exactly the right keys` were modified. This was not happening! The `have.keys` assertion was not doing strict comparison neither provided any useful output when changed to `have.only.keys`.
- Rewrote the test to use manual assertion through array comparison which checks exactly what it's supposed to and gives a visual diff in case there are any missing/extra properties in config
no issue
- in very rare circumstances it's possible that a navigation url in settings can be blank, we should not throw errors in this case as it appears as a theme/routing problem which is difficult to diagnose and much worse than simply not outputting a link class
refs https://github.com/TryGhost/Team/issues/555
- This test fixure is up to date and contains real export from Ghost 2.9. This file should not be edited any more as it represents a "snapshot" of 2.9 (don't really know why this version was chosen to be tested, so didn't change the convention).
- Ideally in the future we should maintain snapshots of export from major releases (or at least first non-broken releases after major release) AND a snapshot of the latest ghost version export file (canary of a sort). This way we'll be able to build up confidence of older export files still working and keep good track in export file changes with every new version
- Updated db spec suite to remove "fixture" user before each import to reduce a variable amount of import errors (star from the same state). It has to be done through an API call because restarting Ghost instance to have clean slate before each test case times out the suite
refs https://github.com/TryGhost/Team/issues/555
- This test fixure is up to date and contains real export from Ghost 4.0. Previous file was just an old 2.x export file which was updated manually on "as needed bases"
- See 3240d4adf0 for more context
- Updated README.md for exports generations with more accurate instructions (previous one contained a typo)
refs https://github.com/TryGhost/Team/issues/555
- This test fixure is up to date and contains real export from Ghost 3.0. Previous file was just an old 2.x export file which was updated manually on "as needed bases"
- The aim is to keep these files as close to real world as possible instead of manually making up data for the needs of test suites
- Fixed test suite which was using the v3 export file
refs https://github.com/TryGhost/Team/issues/555
- There were no automations or instructions for updating or creating new export fixtures. This redme should put a start for faster fixture generation process and possibly automation in the future
closes https://github.com/TryGhost/Team/issues/571
- `post.plaintext` values were being transformed with the markdown URL transformer but that wasn't picking up the link format used in our plaintext fields resulting in absolute URLs being stored in the database rather than `__GHOST_URL__` URLs
- meant that if the `url` config is changed then plaintext and other calculated fields that used it would have URLs that referred to the old domain rather than the new one
- re-saving the posts would have updated it but that's not feasible to do manually for large sites
- bumped `@tryghost/url-utils` to a version that has plaintext transform utils and updated the post model's transform map
