refs https://github.com/TryGhost/Team/issues/1306
- This adds a `MemberPageViewEvent` event when a page is viewed by a member (post/page/tag/author/...)
- Integrates the `LastSeenAtUpdater` service that listens to the `MemberPageViewEvent` events to update `member.last_seen_at`
- Follows the latest testing recommendation (end to end test + testing for side-effects)
refs https://github.com/TryGhost/Team/issues/1306
- Updates once every day (in the publication timezone)
- Also updates when the value is `NULL`
- This is implemented as a SQL query as the code is on the job and doesn't have visibility to the members code
- throughout the migration utils we use the passed in DB connection or
fallback to the `db.knex` instance
- this works, but it means we have places we need to make sure to
implement `(transaction || db.knex)` everywhere
- as I'm working on refactoring the utils, this was also causing
problems because I'd be checking the `transaction` instance but that may
be null/undefined
- this commit pulls the fallback into the function parameters where it's
evaluated at runtime
- this also has the added benefit that we get jsdoc typing now because
the types are easy to figure out
- note: `transaction` should probably be renamed to `connection` because
it's not necessary a transaction... but baby steps 🤓
- this section of code handles the errors that arise when we add a
foreign key to a table
- locally, I get different errors than the one listed - `ER_FK_DUP_KEY`
and `ER_FK_DUP_NAME`
- I've been trying to find a good source for what each code is but it
looks highly likely to be differences in DB engines
- we should probably handle these errors anyway because we don't want
migrations to error out
refs https://github.com/TryGhost/Toolbox/issues/219
- These two APIs similarly to Images API should be accessible by the Admin-API SDK. Opens up a way to write custom scripts uploading files and media
refs https://github.com/TryGhost/Team/issues/1387
We are moving away from the portal_products setting to instead store
each tiers visiblity on the tier itself. This column will be used for
that data.
Both of the default Tiers should be visible, but newly created tiers
should not be.
refs https://github.com/TryGhost/Team/issues/1029
- members browse endpoint didn't have `include` in its option list, so `?include...` was ignored in the api
- endpoint always reverted to using default relations in output, so `product` was never attached even if added in `include`
refs https://github.com/TryGhost/Team/issues/1382
- PR feedback
- Self hosters don't have the option to add a site description when setting up
- Update the logic to continue with the settings setup, even when no description is given
refs https://github.com/TryGhost/Team/issues/1382
- Added two possible new setup values: `accentColor` and `description` to define the brand colour and site description on initial setup
- Updated tests to reflect those changes
- Only the params when passed and fall back to default site description
refs https://github.com/TryGhost/Team/issues/1313
Rather than removing the /products API we're adding a /tiers API as
a first step towards renaming "products" to "tiers". The initial idea was
to alias the URL's but out API framework doesn't easily allow for this so
we've duplicated it instead.
- I recently added a bunch of strict rules to our eslint plugin around returns: ca9af37866
- These mostly are issues that occur whilst writing code, that you spot and fix as you're developing, but they're annoying to notice/find and eslint can be used to flag them quickly
- There are of course, edge cases where you don't need to return from array fns, but this rule also suggests better patterns might be available
- For our excert helper and new assertEvent helper, I've updated the code to use simpler patterns that are easier to read, so as to avoid the warnings
- For our old API I've simply disabled the rule as we're about to delete this code
refs https://github.com/TryGhost/Toolbox/issues/202
- during DB init, we have to create all the tables
- right now we loop over all tables and call the `createTable` command
- this command checks if the table exists and if not, creates the table
- this works fine but it means we query the database for every table
- in MySQL, we query the information_schema table, which we've seen
issues with before because it doesn't have indexes
- the smarter thing to do here is to get all the tables that already exist,
remove them from the list, and just straight up create them without
further checks
- this entire thing should be protected by the migration lock so we
shouldn't encounter issues from multiple processes initializing the DB
and tables existing after the initial check
- this commit also removes the check from `createTable` because this isn't
really needed. We should be using the migration utils, which do
check for existing tables. I've added a note to the function and
audited anywhere we still call the function
- this commit removes (- 49 tables + 1 initial check) 48 queries from
the initial DB init
refs https://github.com/TryGhost/Toolbox/issues/214
- Having this config for test environment allows to pre-populate default settings values in the settings table
- Right now the default-settings.json is an exact copy of the original "/data/schema/default-settings/default-settings.json". Having a starter file as an exact copy, allows to track the differences between environments as they are introduced easier
refs https://github.com/TryGhost/Toolbox/issues/214
- The values configuration for the settings table need to become configurable to be able to run our test environment with a pre-defined set of configurations (e.g Stripe-related values).
- This change makes it possible to define the default settings file location (currently a JSON)
- A new key is now exposed through the "paths.defaultSettings" key in settings, which can be overloaded for the needs of the environment
refs https://github.com/TryGhost/Toolbox/issues/214
- The `defaultSettings` path name in the config (one pointing to routes yaml file) creates confusion with the `defaultSettings` which populate defaults for in the database settings table.
- Furthermore, the name collision creates a problem when trying to make database default settings dynamic - being able to load them from configurable file path.
- Rename makes "routing" explicit to avoid ambiguity and free up the name for the database defaults
- The value seems to be safe to be renamed as all keys used in `overrides.json` are taking priority - the name "defaultRouteSettings" hasn't surfaced at any point in the git history
- Fixed test fixtures so that members with subscriptions also have products/tiers
- Fixed test fixtures so that default&free tiers can be updated for tests
- Added tests for the signin functionality and welcome page redirects
- Extended `setupStripe` to setup other Members settings - this needs some more
thought around how we proceed
refs https://github.com/TryGhost/Toolbox/issues/163
- as of Node 15, unhandled rejections will exit the process so if
Ghost is running on Node 15+ and encounters one, it will kill Ghost
- if Sentry is enabled, it will add a handler for the event that will
send it to Sentry but the logging is sent to stdout/stderr, which means
we lose it in Ghost logs
- this commit adds a process handler for the `unhandledRejection` event
which will log the reason to Ghost logs and prevent Ghost from
exiting
- Ghost themes are allowed to define the API version they want to use, but this concept has never really worked correctly
- We have a theory that it doesn't ever do quite what people want, and so always loading latest would not really break anything - this commit tests that theory
- We're pinning to canary, as we're aiming to get rid of the concept of versions altogether
- I could have done return config.get('api:versions:default');, but this actually returns v4 (although the same as canary, conceptually different)
and it also seemed like an unnecessary level of indirection. This change should be easy to understand and to revert if we are wrong
refs https://github.com/TryGhost/Team/issues/1322
Since the Members service is no longer started when Stripe is
reconfigured the url config used for checkout sessions was not updated.
This moves all of the default Stripe urls into the Stripe service, where
they will be updated as/when Stripe is connected/disconnected.
refs: https://github.com/Ghost/Ghost/commit/b5ee17b25
- When moving the site tests into e2e-api they broke because they were getting the changed settings value from the settings test
- The solution is to ensure the settingsCache is reset between tests, which is what this commit does
- This commit also renames the shutdown method to reset, because this is not a permanent operation
- It also renames the resetDb method to resetData, because the concept is we want the internal data to be reset, not just the DB
no-issue
The way we choose which email to send is too tightly coupled with the
magic link generation, which meant that when we added the new paid
signup email, the magic link looked like <url>?action=signup-paid rather
than <url>?action=signup - our welcome page logic was working off of
only using welcome pages for action=signup and so this broke.
- When starting ghost for e2e tests we create a content folder in the os tmp dir
- This means that the folder can change between suites as ghost is started and restarted
- For the most part this is fine, but theme storage caches the path to config (which makes sense, it's not meant to change whilst Ghost is in-memory)
- This is a quick-n-dirty fix that just makes it possible to update that path in the tests, so we know it's in sync
- Ideally we'd not cache the path, use a function to fetch it etc, or fully reset the theme storage layer, but this is the fix I have working today
and so it's going in to unblock things for now
refs https://github.com/TryGhost/Team/issues/1071
We switched to using tiers pivot table that stores list of tiers with access to post when visibility is set to `tiers`. For themes using v3 API while having posts restricted to specific tiers visibility, the post data will not include the list of tiers, which caused an unexpected error while trying to determine post access from tiers list. This change blocks access to post if specific tiers visibility is enabled without data available for list of tiers on post.
refs daeb06e835
- This is an additive change, and the parameter is optional so it's better to ship it right away (testing was hard as it's a chicken and an egg problem to have a feature flag in the setup route).
refs https://github.com/TryGhost/Team/issues/1321
- when updating the Email record after submitting all email batches we have a `catch` call but it was only logging the error
- added a call to Sentry so there's more visibility if those saves fail
refs https://github.com/TryGhost/Toolbox/issues/202
- this code suffers from two problems:
- when we don't have any new settings to insert, we still end up
fetching the columnInfo and owner info, even though we only need
them if we're inserting data. This results in 3 extra queries upon
boot
- secondly, we insert every setting with a separate query - MySQL and
SQLite both support batch inserts and knex has a utility to help us
that I've [used
before](38821c5242).
With 95 settings at the time of writing, this adds 94 extra queries
during the DB init
- this commit refactors the code so that we only fetch the columnInfo and
owner data if we've got new settings to insert, and batches the
inserts using knex's batchInsert util
- this query results in ~95 less queries during DB init and saves a
couple of queries during boot
loses TryGhost#13971
This fixes an issue with links containing # anchor. It makes sure the # part is at the end of the url like url?v=hash#anhor
Co-authored-by: Hannah Wolfe <github.erisds@gmail.com>
no issue
- the new eslint bump seems to flag this line up for using camelcase
- i'm not sure why this hasn't flagged before but it seems we want to
keep the naming because the function name has the same linting exemption
refs https://github.com/TryGhost/Team/issues/1296
- The `theme` must be a github `org/repo` string
- This uses the internal API instead of the services because the API has extra implementation details not present in the services.
