- We use bluebird inconsistently throughout the codebase now
- The original reason why we needed to use it so heavily was so that all promises returned had the bluebird behaviour, including catch predicates
- Most other usage is explicit, but this is really hard to detect and hasn't made it to standard promises, so we should get rid of this pattern
refs https://github.com/TryGhost/Team/issues/856
- These tests were created during work on v4 without a particular goal behind them. Because they don't do anything extra comparing to the existing tests there is no sense to keep them around
- The router bootstrap is no longer allowed to fetch it's own settings, but rather is passed them
- This moves the call to the site routes.js file, which isn't much better but it's a start
- The goal is to always pass these in from the boot process, or from the bridge reloader
- Reduced the number of levels in our debug naming in the frontend
- Unified components like "themes" and "routing" under one name
- Should help to make debug slightly more useful again
refs https://github.com/TryGhost/Team/issues/726
- The refed feature got broken during the refactors. Even though this area is covered by unit tests the "this context" testing should probably done on an integration test level, which we don't have a clear pattern for just yet
- In an ideal world, our acceptance tests would be much, much faster
- ATM we output how much time is spent on reloading Ghost for each suite, but this is output with console
- Changed this to use DEBUG, so we don't clutter the UI normally
- Added further debug statements, and a cumulative time, so we can see where time is spent/wasted
- Added a DEBUG command for running acceptance tests with this output
- This shows us that reloading Ghost accounts for 50% of the test time
- this was skipped on boot, but then called in the test utilities, but only on restart 🙈
- this means that yarn test:acceptance (i.e. running all tests) works, but if you try to run just test/api-acceptance/themes_spec.js it would fail because that uses a fresh boot not a restart/reload
- I've changed this as keeping the test using the real boot, rather than the made-up acceptance-utils tasks as much as possible is way better
refs https://github.com/TryGhost/Team/issues/858
Previously when complimentary access used a Stripe subscription under
the hood, we were able to restrict access to Stripe Checkout based on
whether or not a Member had an active Stripe subscription. This updates
the logic in members-api to instead check for whether or not the member
has 1-or-more products.
refs https://github.com/TryGhost/Team/issues/861
- The test case illustrates that it's already possible to achieve what's described in the referenced issue (bug where the content is not filtered correctly when a single email segment card is present)
- The bug fix for a general issue should be using this parser's ability to properly filter html/plaintext content
refs https://github.com/TryGhost/Team/issues/790
The schema validations are used at the model layer to validate inputs
and need to be updated in order for us to reintroduce the 'comped'
status.
refs https://github.com/TryGhost/Team/issues/790
Since version 4.6 the 'comped' status has not been used. Any members
which were given complimentary plans since then will have had a `status`
of 'paid', and therefore the corresponding members_status_events row
would have a `to_status` of 'paid'.
This migration is designed to fix these members_status_events rows by
ensuring that the last (chronologically) members_status_event row for a
comped member has a to status of 'comped'.
Unfortuantely this migration loses information which makes writing a
perfect inverse migraion impossible. Alternative down migrations were
considered, but these would lose further information.
refs https://github.com/TryGhost/Team/issues/790
In order to track when a member was comped, as well as to differentiate
paid members from comped, we are reintroducing the 'comped' status. This
migration will updated members with a Complimentary Stripe Subscription
to a status of 'comped'. It is essentially a reversal of the 4.6
migration.
refs 7e6800b2b8
- referenced commit deprecated `grunt main` in favor of `yarn main` but
this wasn't updated so we never installed dependencies for Admin,
which caused the build to break
- this commit switches to the new command
no issue
- incorrect syntax was used in the error handlers inside of the `for` loop, by using `return` when logging the whole for-loop was aborted whereas we want to log and continue processing the rest of the items
refs https://github.com/TryGhost/Team/issues/853
A refactor of `urlUtils` usage in 4.6.1 left a buggy 4.0 migration that did not transform URLs inside of mobiledoc cards. Anyone upgrading from 3.x to 4.6.1-4.8.4 would end up with inconsistent URL formats and potentially broken images.
- fixed 4.0 migration by passing our mobiledoc cards list in when transforming mobiledoc urls
- added a new migration that re-applies the missed URL transforms and content re-generation for any site that did a 3.x upgrade to a buggy 4.x version
refs 8a1fd1f57f
refs 5584430ddc
- The change to async/await in the original commit 558443 was causing problems in downstream dependencies (create-error package) where it was loosing a context of "this". It's not a direct dependency so I didn't go yak shaving into where exacly the context is lost.
- The fix to keep a correct context of "this" was sticking to an existing pattern using regular function returning promises. Once we need to redo them into async/await we can investigate if there's a way around create-error's context prolbem
refs: 7e6800b2b8
- I kept flip-flopping on making grunt dev into grunt and removing it so we have to remember to use `yarn dev` and fucked it up entirely
- Do the simple thing for now - and think about how we can make grunt dev better overall
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
With multiple products, we have re-enabled segmentation by product for posts behind alpha feature flag. This change handles the default content cta to show custom message if the post's access is restricted to specific products when behind the flag.
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 https://github.com/TryGhost/Team/issues/849
Custom post visibility (behind alpha flag) is added to the API using new `visibility_filter` attribute that stores the custom filter. This change -
- updates validator for visibility to check new `visibility_filter` property
- cleans usage of i18n in favor of tpl
refs https://github.com/TryGhost/Team/issues/849
With multiple products back behind alpha flag, we want to bring back segmented post access for members which allows site owners to set post access to specific products. This change -
- updates admin-api-schema to allow `visibility_filter` attribute to post/page response
- We have a lot of tests, so it can be hard to see if any are problematic
- We have a problem with some tests being too slow, this highlights these in particular
- Very slow tests that take seconds are not really unit tests, we should look for different ways to run these
- Also we should tailor our mocha settings more, so that we have more lenient settings for acceptance/regression tests but not for unit tests
- Note: You have to wait for all tests to run to see the output
refs https://github.com/TryGhost/Team/issues/727
- The version was forgotten to get a bump durin g 4.0 release. The API version used by update check should be the same as internal default.
- Because the current internal default is mistakenly set to v3 API it's still not optimal but will need a holistic solution in the future
closes https://github.com/TryGhost/Team/issues/781
refs 076ad99593
refs https://github.com/TryGhost/Ghost/commit/2b73d0f66
refs https://github.com/TryGhost/Ghost/commit/bab12ca3d
- With refs 076ad99593
landing in main there is no more 500 error stopping us from bumping the version
- Previous versions of gscan wasn't able to detect partial usage inside
of a helper, e.g.: "{{#if author}}{{> "missing_partial"}}{{/if}}". It's
important to be able to detect these on theme upload/validation stage to
avoid errors during the runtime.
- The updated version provides additional information about used and
unused partials and helpers.
- With this change users might start seeing a "fatal" error during an
upload/activation of a theme previously passing validation. Currently
active themes with partials used in the context will still allow for a
boot, but will log a 422 error pointing to missing partial.
refs https://github.com/TryGhost/Team/issues/781
refs 813d288eb2#
- The 500 error was introduced through a refed commit long time ago when (probably?) there were no other safeguards preventing from serving content through a theme with errors. Since than we have multiple safeguards when aploading/activating the theme with errors and the default handling when such error occurs is more graceful - a 400 with specific error details is shown
- We need this change to land before bumping gscan that introduces more suphisticated error detaction in theme templates. Otherwise, people upgrading to new version and having an error on an unused template or somewhere undetected previously woul end up with a bricked site showing a generic 500 - not a great experience!
