no issue
- Secondary navigation means most nav concepts are supported, e.g. header & footer, or left & right
- The UI is added separately, this PR adds supporting concepts:
- make sure the default value is an empty array
- add support in the API (v3 only)
- add handling in the navigation helper
no issue
- additional migration for the column added since the last 3.1 beta release to allow beta upgrades without rollbacks
- will be a no-op for upgrades from 3.0 as it's covered by `3.1/05-add-emails-table.js`
We want to allow admin users to trigger a retry of failed emails without having to go through the unpublish/republish dance.
- fixed resource identifier in email permissions migration so email permissions are added correctly
- added new email permissions migration so that beta releases can be upgraded without rollback (will be a no-op for any non-beta upgrades)
- added `/emails/:id/retry/` canary Admin API endpoint
- follows same URL pattern as theme activation
- only triggers mega service retry endpoint if the email has a `'failed'` status
no issue
- Increased default mailgun retry limit to 5
- Handling retry logic closer to SDK layer gives less future manual handling
- Allowed failing request to be passed through to the caller
- To be able to handle failed requests more gracefully in the future we need all available error information to be given to the caller
- The previous method with `Promise.all` would have rejected a whole batch without providing details on each specific batch.
- Limited data returned with a failed message to batch values
- Added better error handling on mega layer
- Added new column to store failed batch info
- Added reference to mailgan error docs
- Refactored batch emailer to respond with instances of an object
- It's hard to reason about the response type of bulk mailer when multiple object types can be returned
- This gives more clarity and ability to check with `instanceof` check
no issue
- The limitation on Mailgun side of API seems to be 1000 emails per message.
- The only place where I could find a hard limit of 1000 emails per
batch was this PHP SDK issue: https://github.com/mailgun/mailgun-php/issues/469
- To store ids of sent messages introduce a mega column on the emails table. They can be synced with stats or other metrics during even pooling in the future
- Removed redundant `join(',')` statement.The SDK accepts an array of emails as well. Less code - better code :)
no issue
- Fixed default email property output when the empty value is returned
- This is needed for consistency with other endpoint properties like primary_tag which are null when there is no value assigned
- Updated acceptance tests to handle email property
- Schema had to be updated to not use reference so that the information about email can be independent of the post - can still exist if the post is deleted
- Renames were done as that suits how emails would be handled by the bulk email handler
- These statuses are only for internal representation of the state and don't represent what happens to emails delivery-wise
- There is no need for 'sent' status as emails are "never done" and stats wold be checked for stats field would be used to check on details of the status
refs https://github.com/TryGhost/Ghost/pull/11270
- Fixed 3.0/11-update-posts-html migration which failed in scenario when more than 999 posts with posts_meta relation were present
- The issue was originally spotted here: https://github.com/TryGhost/Ghost/pull/11270#issuecomment-546248308
- The main problem is in the `SELECT` statement which is generated for `findAll` method in Bookshelf which creates `WHERE IN(post_ids_here)` statement with all posts in the database
- Using knex directly as that's a preferred way to write migrations (does not depend on the model layer)
closes#11263
- Fixed `3.0/05-populate-posts-meta-table.js` migration failure when having >999 posts with metadata in the database
- The issue here is with hitting SQLite's internal SQLITE_LIMIT_VARIABLE_NUMBER limit when updating with a large amount of posts having metadata fields set (ref.: https://sqlite.org/limits.html#max_variable_number)
- Transforming migration to iterative method avoided inserting lots of records at once
no issue
We split `posts` table into 2 in v3 with a new `posts_meta` table. Since migrations always use the version of code which is being migrated to - in this case the Post model - which in v3 relies on the posts_meta table, `2.x` migrations relying on post model will fail as it doesn't exist in the expected state. This PR updates all 2.x migrations using `models.Post` to use knex queries directly to access database and perform operations.
no issue
We added 2 new member subscription settings - `allowSelfSignup` and `fromAddress`- with defaults as `true` and `noreply`, this migration sets default values for both settings for users migrating from previous version and cleans up intermediate naming for `allowSelfSignup`.
no issue
Since we removed subscribers code in v3, we cannot use `models.Subscribers` for migration, and instead switch to using db directly for fetching existing subscribers before migrating them to members.
refs https://github.com/TryGhost/Ghost/pull/11152
- Added subscribers table drop migration
- Removed subscribers from schema
- Removed subscribers controllers/routes/regression tests
- Removed subscriber related API code
- Removed subscribers from internal apps
- Removed subscriber importer
- Removed subscriber model
- Removed subscriber related permissions
- Removed webhook code related to subscribers
- When upgrading to v3 it is on the site admin to migrate all zapps or any other webhook clients to use members
- Removed subscriber-specific translation
- Removed subscriber lab flag
* Added new `requirePaymentForSignup` setting for members
no issue
- Adds new `requirePaymentForSignup` setting flag for members, `false` by default.
- Wired members API `allowSelfSignup` to `requirePayment` setting
closes#11207
MySQL doesn't allow unqiue keys with a length of more than 191 when using InnoDB with utfmb4. These changes will ensure any incorrect tables created are fixed and have the
correct length for customer_id
* Changed `customer_id` to non-unique column
* Nooped the 2.32 `members_stripe_customers` migration
* Added migration to recreate `members_stripe_customers` table
* sqlite doesn't allow `ALTER TABLE` queries so this is the cleanest solution considering the table is not yet in use
no issue
- Moved default_content_visibility out of labs as we should be extra careful with what is exposed in the labs + it doesn't really belong there.
no issue
- Removed uses of `visibility` column in frontend url service configs
- The value of `visibility` is always set to 'public' in posts at the moment and doesn't serve any specific purpose when used with these filters.
- Allowed new visibility attributes in post model
- `posts.visibility` column is being repurposed for the needs of member content gating
- Added test for visibility editing in Admin API
- Corrected test schema checks for Admin API post/page responses
no issue
- Populates members table with existing subscribers. Only takes into account columns we know already exist and need to be copied i.e `name`/`email`
no-issue
This will be used to store stripe specific information for members
customer_id has a max length of 255 https://stripe.com/docs/upgrades
member_id is not unique as we cannot ensure that a member doesn't have
more than one customer object associated with them. e.g. if they signup
twice, or if they cancel, and signup again, creating a new customer.
We probably won't handle this case to begin with, but we will keep the
data intact.
no issue
- bumps `knex-migrator` so it supports irreversible migrations
- marks the `03-drop-client-auth` migration as irreversible because it destroys data that is not recoverable and is required for earlier versions of Ghost to function
no issue
- rollbacks have switched to using transactions but the migration code was copied from an old migration coded before that switch
- `down()` is no longer called with an object that contains a `connection` key, it has `transacting` instead
no issue
- `knex-migrator` will run migrations in the order that nodejs provides when running `fs.readDirSync` which in most cases is strict alphabetical
- 3.0 will shortly have more than 9 migrations which was resulting in the migration order being 1, 10, 2
- prefixing all single-digit migrations with `0` means that strict alphabetical ordering results in the expected order
refs https://github.com/TryGhost/Ghost/issues/10922
- adds migrations to...
1. add `post.type` column
2. populate `post.type` column based on `post.page` value
3. drop `post.page` column
- updates all code paths to work with `post.type` in place of `post.page`
- adds `nql-map-key-values` transformer for mapping `page`->`type` in `filter` params when using the v2 API
- modifies importer to handle `post.page`->`post.type` transformation when importing older export files
NOTE: The post metadata table split is purely an internal optimization for v3 and doesn't require or expect any external actions including related API usage in v3
We keep running into issues adding new fields to the post table because there are too many fields making the post table "too wide". We have also hit MySQL limitations in how many bytes can be in a row (64kb) with post table.
In v3, we decided to split the 8 post fields (meta, twitter and og) used for meta data into a posts_meta table as these 8 fields are all "problem" `varchar` fields and make sense logically grouped together. The API layer is unaffected by the split as input/output serializers ensure the data flow works the same way as it was in v2. Only thing to note is json export in v3 will have slightly different structure with posts meta fields as separate.
- Creates new post_meta schema/table with 8 fields (2 meta_* , 3 twitter_* and 3 og_*)
- Update relations between post and post_meta table
- Update input/output serializers to keep existing API behavior
- Avoids new entry in post_meta table for post where all meta fields are null
- Keeps the current fields API param behavior
- Handles migration of existing posts to new table structure
- Updates importer/exporter to work seamlessly with table changes
no issue
- drops now-unused `accesstokens`, `refreshtokens`, `clients`, and `client_trusted_domains` tables
- no rollback because the db schema for the tables no longer exists
no issue
- v0.1 is ☠️ so the access/refresh token based auth is no longer used
- removed all code related to the `accesstokens` and `refreshtokens` tables
- removed all `passport` related dependencies as it's no longer used
no issue
- v0.1 is ☠️ so there's no longer any use of client auth
- removes all code related to `clients` and `client_trusted_domains`
- noops the "add backup client" migration in 1.7 because the referenced fixture no longer exists causing migrations and consequently all regression tests to fail
no issue
- Drops `ghost_auth_access_token` and `ghost_auth_id` fields since not used anymore
- Adds migration for dropping these columns from users table
- Drops Auth strategy - `ghostStrategy` - since its not used anymore
no issue
- we recently started wrapping rollbacks in transactions (https://github.com/TryGhost/knex-migrator/pull/161)
- in a number of migrations we were calling `model.destroy()` without passing through the options which includes the current transaction
- for models which are using `bookshelf-relations` this could result in an internal `SQLITE_BUSY: database is locked` error because it tries to run queries against tables that have been locked by previous queries in the transaction
- by passing through the options when calling `.destroy()` it allows the `bookshelf-relations` to re-use the same transction avoiding the database lock problems
no issue
- the column addition/removal can be too slow for large sites
- will be added back in 3.0
---
Revert "Fixed canary api for page/type column"
This reverts commit a5a7e7e919.
Revert "Updated frontend canary url config for page/type"
This reverts commit 19100ec5e6.
Revert "Updated canary api to handle type column correctly (#11006)"
This reverts commit c3e8ba0523.
Revert "Ensured `page` filter works in routes.yaml"
This reverts commit 9037c19e50.
Revert "Replaced usage of mongo util with nql-map-key-values"
This reverts commit 8c5f1d0ef0.
Revert "Added shared nql-map-key-values module"
This reverts commit ef4fd4b8ef.
Revert "Ensured page prop is present on content api response"
This reverts commit cfa0a0862b.
Revert "Fixed failing regression tests"
This reverts commit 9c2bb3811f.
Revert "Updated xmlrpc and slack service to use type column"
This reverts commit 44a02c7d36.
Revert "Updated v0.1 posts api to work with type column"
This reverts commit 2c81d7c914.
Revert "Removed updates to v0.1 specific code"
This reverts commit 08d83c1f53.
Revert "Added missing context from ValidationError"
This reverts commit cd45ab4f54.
Revert "Renamed page->type in the page&posts serializers"
This reverts commit df99e724e3.
Revert "Added mongo helper to input serializers"
This reverts commit fb8eadb4a8.
Revert "Passed mongoTransformer through to NQL"
This reverts commit 0ae3f0fdfc.
Revert "Permitted mongoTransformer option for read methods"
This reverts commit a89376bf26.
Revert "Updated the count plugin to reference the type column"
This reverts commit a52f15d3d3.
Revert "Updated hashes for db integrity check"
This reverts commit bb6b337be3.
Revert "Remove page column and remaining references"
This reverts commit 9d7190d692.
Revert "Added type column to data generator"
This reverts commit e59806cb45.
Revert "Removed references to page column in rss tests"
This reverts commit 04d0f855de.
Revert "Removed page column references in validation tests"
This reverts commit f0afbc5cc0.
Revert "Updated the post model to use the `type` column"
This reverts commit 1189bc823a.
Revert "Updated url service to use type column"
This reverts commit 61612ba8fd.
Revert "Updated the v2 api to deal with type column"
This reverts commit 57afb2de2b.
Revert "Added type property to post model defaults"
This reverts commit dc3345b1c5.
Revert "Added type property to the default post fixtures"
This reverts commit 82d8c38033.
Revert "Added type column to posts table"
This reverts commit 9b85fc6a69.
no issue
- updates the attribute sanitiser of the posts importer to convert `post.page=true/false` to `post.type='page'/'post'
- gives precedence to `post.type` if an imported post somehow has both `post.page` and `post.type` attributes
no issue
- the `mobiledoc_revisions` table can grow very large in certain circumstances which can result in Out-Of-Memory errors when performing backups, resulting in failed upgrades
- adds `mobiledoc_revisions` to the exporter excluded tables list as a temporary solution until we have safer export creation and/or improved revision handling
refs #8717
- The posts without slugs should not be taken into account when detecting duplicates as slug field is not required when importing.
- Ideal solution would require generating slug before duplicate detection phase. This would cause duplicate detection to take 'title' into account which didn't happen before.
refs #10922
When rolling back the removal of the page column, we must re-add it, but
the definition for it has been removed from the schema, so we must
hardcode the definition.
closes#10060
- Implemented scheduling for posts and pages
- Added cache invalidation when scheduling
- Refactored admin token eneration function to accept existing key as parameter in tests
- Added Ghost Scheduler Integration fixture
- Added fixture for permissions for post publish action
- Migrated getScheduled method to v2
- Did not add support for 'from' and 'to' parameters as they were not used by DefaultScheduler
- This method needs rethinking in a long run as it's an ugly hack and should rather become proper endpoint that returns JSON data instead of models
- Removed unused auth middleware from v2 routes
- Added internal scheduler role
- Implemetnted transactions in v2 frame
- This takes into account scenario mentioned in c93f03b87e
- Specifically:
>if two queries happening in a transaction we have to signalise
knex/mysql that we select for an update
otherwise the following case happens:
you fetch posts for an update
a user requests comes in and updates the post (e.g. sets title to "X")
you update the fetched posts, title would get overriden to the old one
closes#10788
This adds an extra filter to the preImport method of the settings
importer to removes settings with the key `is_private`
This message is specifically only for when an import has privacy mode ON
and the current site has privacy mode OFF.
no issue
- we try to store all urls as relative paths where possible in Ghost so that the `config.url` value can be changed
- all relative paths are stored as root-relative except for the `post.canonical_url` field which was storing subdirectory-relative paths
- adds a migration to put the subdirectory prefix onto any relative canonical_url paths
- updates the canonical_url input serialiser to keep the subdirectory rather than stripping it to match all other url fields
* Simplified db controller permissions options
The existing objects were confusing because they did the same thing as
setting permissions to true, but gave the impressions that something
special was happening/required.
* Added DB Backup Integration Role
This will allow us to assign certain api_keys this role, in order to
automate db backups
* Allowed admin api_keys to have configurable roles
This will allow keys for the admin api to do customised things such as db export
* Added ghost-backup integration to fixtures
* Added migrations for DB Backup Integration and role
no-issue
This module was first created (AFAICT) in c09c20ad8d (diff-20a31f345ca2643b2602224678bb8d5b) and
has since undergone some filename renames and eslint refactors - we don't support
PostgreSQL and have no immediate plans to do so.
refs #10921
- New SEO related fields will now be available as a part of Admin API /settings endpoint
- The ordering of fields is taken from post's schema
- Extended settings test suite with new SEO fields
- Adjusted settings model unit test
closes#10785
- The behavior for tags will now be similar to posts' one described in the docs
- "The only strictly required field when importing posts is the title. Ghost will automatically generate slugs and set every other field to the default or empty."
- The breaking change was introduced with: 68d8154d4f (diff-e712df50c0dc7cf33746eeff0564003cR97) (assumed there's always slug in the imported object which is not true)
- Added originalIdMap to the importer base class to track id
substitution so it can be used when dealing with relational resource
updates
- Removed explicit use of 'this.stripProperties(['id']);' in
beforeImport of base class because we need to assign and remove the id
property in the same place to track this change
- Only calling 'this.stripProperties(['id']);' in
settings/trusted_domain imports as the method won't be called otherwise
- Expanded regression tests with new supported import case
no issue
- Updated Test & linting packages
- Updated use of hasOwnProperty
- Using Object.prototype.hasOwnProperty instead (ref. eslint.org/docs/rules/no-prototype-builtins)
- Removed already defined built-in global variable Intl
- Applied `--fix` with lint command on `core/test` folder
- The rules were broken because some of them were made stricter for `eslint: recommended` ruleset (ref. https://eslint.org/docs/user-guide/migrating-to-6.0.0#eslint-recommended-changes)
- Removed redundant global variable declarations to pass linting
refs #10790
- The code was moved out of controllers to reduce the number of coupling points between the API controllers and "frontend" services
- A nice side effect of this move is a decreased amount of code that will need to be maintained and reusability between existing controllers
- Calling just a few methods from frontend services on API level makes it easier to abstract fronted away from API
refs #10790
- Moved /core/apps into core/frontend
- Moved /core/server/helpers to /core/frontend/helpers along with /core/server/services/themes
- Changed helper location in overrides
- Moved /core/server/services/routing to /core/frontend/services
- Moved /core/server/services/url to /core/frontend/services
- Moved /core/server/data/meta to /core/frontend/meta
- Moved /core/server/services/rss to /core/frontend/services
- Moved /core/server/data/xml to /core/frontend/services
closes#10773
- The refactoring is a substitute for `urlService.utils` used previously throughout the codebase and now extracted into the separate module in Ghost-SDK
- Added url-utils stubbing utility for test suites
- Some tests had to be refactored to avoid double mocks (when url's are being reset inside of rested 'describe' groups)
refs #10618
- Visibility methods don't belong on model, but are generic utils
- Used directly from ghost helper's visibility methods, cleans up core
- Removes direct model dependency of theme helper
- Updated `foreach_spec` to correct test data as per schema - visibility property cannot be empty
refs https://github.com/TryGhost/Ghost/issues/9414
refs c9b95b4bbd
- Removed package version from asset hash calculation
- Package version doesn't introduce any value when calculating a hash because Date.now() provides enough randomization on its own
closes#10706
- Fixed a bug where we weren't assigning `summary_large_image` as Twitter card property when no feature image is provided, but a dedicated Twitter image
- Updated test to reflect this case to be tested better
no-issue
It turned out that due to the mismatch between `"members"` and
`"member"`, that not a single row was added to the database via this
migration. Clearing the file for simplicity.
no-issue
The original migration read data from the fixtures, and ensured the
relations were made. Now the fixtures have been corrected, we can use
the same migration for 2.22
no-issue
The previous relations were setup to match against "members", which is
plural, but the object_type on the permission is "member". This was
causing the permissions to not be added as a relation to the role.
* Removed support for cookies in members auth middleware
no-issue
The members middleware will no longer be supporting cookies, the cookie
will be handled by a new middleware specific for serverside rendering,
more informations can be found here:
https://paper.dropbox.com/doc/Members-Auth-II-4WP4vF6coMqDYbSMIajo5
* Removed members auth middleware from site app
no-issue
The site app no longer needs the members auth middleware as it doesn't
support cookies, and will be replaced by ssr specific middleware.
https://paper.dropbox.com/doc/Members-Auth-II-4WP4vF6coMqDYbSMIajo5
* Added comment for session_secret setting
no-issue
We are going to have multiple concepts of sessions, so adding a comment
here to be specific that this is for the Ghost Admin client
* Added theme_session_secret setting dynamic default
no-issue
Sessions for the theme layer will be signed, so we generate a random hex
string to use as a signing key
* Added getPublicConfig method
* Replaced export of httpHandler with POJO apiInstance
no-issue
This is mainly to reduce the public api, so it's easier to document.
* Renamed memberUserObject -> members
no-issue
Simplifies the interface, and is more inline with what we would want to export as an api library.
* Removed use of require options inside members
no-issue
This was too tight of a coupling between Ghost and Members
* Simplified apiInstance definition
no-issue
* Added getMember method to members api
* Added MembersSSR instance to members service
* Wired up routes for members ssr
* Updated members auth middleware to use getPublicConfig
* Removed publicKey static export from members service
* Used real session secret
no-issue
* Added DELETE /members/ssr handler
no-issue
This allows users to log out of the theme layer
* Fixed missing code property
no-issue
Ignition uses the statusCode property to forward status codes to call sites
* Removed superfluous error middleware
no-issue
Before we used generic JWT middleware which would reject, now the
middleware catches it's own error and doesn't error, thus this
middleware is unecessary.
* Removed console.logs
no-issue
* Updated token expirty to hardcoded 20 minutes
no-issue
This returns to our previous state of using short lived tokens, both for
security and simplicity.
* Removed hardcoded default member settings
no-issue
This is no longer needed, as defaults are in default-settings.json
* Removed stripe from default payment processor
no-issue
* Exported `getSiteUrl` method from url utils
no-issue
This keeps inline with newer naming conventions
* Updated how audience access control works
no-issue
Rather than being passed a function, members api now receives an object
which describes which origins have access to which audiences, and how
long those tokens should be allowed to work for. It also allows syntax
for default tokens where audience === origin requesting it. This can be
set to undefined or null to disable this functionality.
{
"http://site.com": {
"http://site.com": {
tokenLength: '5m'
},
"http://othersite.com": {
tokenLength: '1h'
}
},
"*": {
tokenLength: '30m'
}
}
* Updated members service to use access control feature
no-issue
This also cleans up a lot of unecessary variable definitions, and some
other minor cleanups.
* Added status code to auth pages html response
no-issue
This was missing, probably default but better to be explicit
* Updated gateway to have membersApiUrl from config
no-issue
Previously we were parsing the url, this was not very safe as we can
have Ghost hosted on a subdomain, and this would have failed.
* Added issuer to public config for members
no-issue
This can be used to request SSR tokens in the client
* Fixed path for gateway bundle
no-issue
* Updated settings model tests
no-issue
* Revert "Removed stripe from default payment processor"
This reverts commit 1d88d9b6d73a10091070bcc1b7f5779d071c7845.
* Revert "Removed hardcoded default member settings"
This reverts commit 9d899048ba7d4b272b9ac65a95a52af66b30914a.
* Installed @tryghost/members-ssr
* Fixed tests for settings model
no-issue
This is so that someone with empty defaults for installed_apps and
active_apps, or someone without the defaults at all, will not see the
warning message when importing.
no issue
- the `{active,installed}_apps` settings related to a very old, minimally implemented, unreleased, and problematic approach to custom apps
- this is the first step towards full removal of the old "apps" concept
Credits: Kacper Szurek
closes#10640
- Updated sitemap resources data to include certain fields
- Fixes sitemap date and images value
- Updated date handling for sitemap nodes
no-issue
The 2.17 migration included a bug which set the `is_private`, `amp` and `force_i18n` setting values to `'false'` when they should have been `'true'`
We've reverted these changes by reading the most recent backup file, and setting the value to `'true'` if the backup has it set to `'true'` AND the current db has it set to false.
We've also amended the broken migration, so that it does not cause this issue for future installs
no-issue
Currently if you run two migrations on the same day, the backup is overwritten. This change adds the `HH-mm-ss` to the file name, meaning that you get a unique backup for each migration.
refs #10599
- meta_description output wrong meta description
Only solves meta_description for this use case:
```
routes:
/:
data: page.{slug}
template: t
```
refs #10082
```
routes:
/news/:
data: post.news
```
The twitter_image was not available, because the context is [news, post] and the data is in `data.post`.
The context helper was incorrect. I think it is still not fully correct, but only focused on this use case.
The meta layer needs a full refactoring.
refs #10593
- Added `canonical_url` field to post&pages resources in Admin & Content APIs
- Support for canonical URL on metadata layer (used in {{ghost_head}} helper)
- Made sure the new field is not accessible from API v0.1
- Added handling same domain relative and absolute URLs
closes#10580
- The validation was failing because boolean values in settings can also be "0" and "1". 04c60b4ce1 explains the reason why these 2 new values are allowed
no issue
- Additional JSON.stringify call is redundant because it is already happening internally in Ignition (https://github.com/TryGhost/Ignition/blob/master/lib/logging/GhostLogger.js#L241)
- Left stringification in importer as is, because the use case there is also
putting errors into 'problems' array and seems like those values have to
be stringified
no issue
A new Zapier app will be released that uses the v2 Admin API which means it will require an ApiKey that is linked to an Integration.
- adds a `type` column to the `integrations` table with the following types allowed:
- `custom` (default) used by custom integrations added by users
- `builtin` used by built-in integrations that have their own UI and won't show up in the "Custom Integrations" list
- `internal` used by "internal" integrations such as the scheduler
- adds a `zapier` "builtin" integration to the fixtures
refs #10431
- migration script to add permissions for actions
- restricted to owner & admin & integration role for now
- we will add permissions for other rules too, but we need add more granular restrictions
- e.g. contributors can only read actions for posts which he created
refs #10174
- Improved importer cleanUp method usage, so the cleanup is called in cases when there is an error during an import stage
- Simplified files to clean up tracking as removal of files is now partially handled in uploader middleware
no-issue
- revert the migration because migrations that (potentially) touch every row should be kept to major releases where possible
- the migration was safe to run and won't cause any problems for anyone who has already upgraded
- reversion keeps the migration file but changes the contents to a no-op so that `migrations` table state is the same for all users whether they migrated with the full migration or the no-op version
closes#10388
This migration finds all tables with nullable columns, it then loops through the tables and their nullable columns, updating each column to a null when its current value is an empty string.
* Updated docs links to best equivalents
- Our documentation has been overhauled, this updates the all the old links sprinkled through Ghost
* Update integrity hash
closes#10062
- return `post.excerpt` for Content API v2
- do not use `downsize`, because we might want to get rid of it if we drop v0.1 (downsize does not create good excerpts)
- simple substring of the plaintext field
refs #10318
- cheap and dirty way of removing settings we don't use
- rewritten the settingsFilter function as that was unnecessarily complex
- aslo fixed the require of default-settings in the importer
* Removed unused fields from v2 Content API
- We want to ship the v2 Content API as clean and lean as we can
- Many fields in the DB aren't actually used, we shouldn't return these values
- Other values aren't useful outside of Admin clients, and shouldn't be returned either
Fields removed:
- tags: created_at, updated_at, parent
- authors: locale, accessibility, tour
- posts: locale, author status, page
refs #10124
- Author model returns only users that have published non-page posts
- Added a public controller for tags (should be extracted to separate Content API controller https://github.com/TryGhost/Ghost/issues/10106)
- Made resource configuration dynamic based on current theme engine
- This needs a follow-up PR with fixes to the problems described in the PR
refs #9584
- The Importer checks if a user reference is null. But if the post is a draft and published_by is null, we should ignore the user reference detection.
- This change will avoid showing an incorrect user reference warning in the importer report for draft posts.
no issue
Assets moved from gh-pages to https://github.com/tryghost/static and hostname changed, redirects already in place. Can be tested on https://demo.ghost.io (image should all work fine, try visiting one directly to verify redirect works)
no issue
- When importing Ghost 2.0 blogs into 2.0 blogs...
- The Koenig image card would lose it's cardWidth setting,
- because it'd be overridden by the imageStyle setting, which was null
- The importer previous _only_ kept the width if importing 1.0 blogs
no issue
- webhooks UI requires the ability to edit webhooks
- added `edit` permission for `webhook`
- added `edit` method to v2 webhook controller
- added `PUT /webhooks/:id` route to v2 Admin API routes
* Extended webhooks schema/model and connected with integrations
refs #9942
- Updated webhooks schema with new columns - name, integration_id, secret, last_triggered_at, api_version
- Updated webhooks and integration model to map relationships
- Updated schema hash
- Updated test utils to exclude new webhooks columns for response comparison
* Added migration script for new webhooks columns
refs #9942
- Added migration script in 2.3 to add new columns to webhooks
* Updated schema hash
* Updated maxLength for api_version in schema
* Removed concurrency value from migration script
* Added defaults for webhooks model
* Added status field to webhooks for last trigger status
* Updated schema hash
* Fixed tests with status field
* Removed concurrency value in migration script
* Cleanup
* Updated schema with new fields
- last_triggered_status, last_triggered_error
closes#9983
- everything is described in the target issue
- this PR fixes both problems described in the issue
- TryGhost/Ghost-CLI#839 was raised to avoid this problem in the future
refs https://github.com/TryGhost/Ghost/issues/9865
- schema migrations
- adds `integrations` and `api_keys` tables
- inserts `integration` and `api_key` permissions and Administrator role relationships
- inserts `Admin Integration` role and permissions
- adds `Integration` model
- adds `ApiKey` model
- creates default secret if not given
- hardcodes associated role based on key type
- `admin` = `Admin API Client`
- `content` = no role
- updates `Role` model to use `bookshelf-relations` for auto cleanup of permission relationships on destroy
no issue
- do only look for published old fixture posts
- otherwise we detect draft old fixture post
- and then we would replace them with published new fixture posts, which is not a very nice experience for the user
- ensure, if we have found all old fixture posts, replace all of them with the correct date
- otherwise they are getting replaced and the date is "now"
- in general, this migration script is tricky and it tries to be smart, but there are so many cases we can run into
- to remember: the goal was to replace all old with new fixture posts (e.g. you just installed 1.25 and straight migrate to 2.0 - the old fixture posts should get replaced)
- added more protections to ensure we never delete custom posts using the same fixture post slugs
no issue
- Organising your content
From: Here, the theme would assign the post publicly displayed tags of Blog - but it would also keep a private record of the post being tagged with #video.
To: Here, the theme would assign the post publicly displayed tags of News - but it would also keep a private record of the post being tagged with #video.
closes#9774, refs #9742
- added new fixture posts for Ghost 2.0
- added migration file to remove old fixture posts
- only remove them if they are owned by the Ghost author and if they are tagged with getting-started
- added new fixture posts if you had all (!) old fixture posts
- ensure on rollback we remove the new fixture posts again
- updated default settings
refs #9742
- removed usage of single permalink setting
- with dynamic routing this configuration does no longer makes sense
- because you can configure your permalinks in the routes.yaml
- furthermore you can have multiple collections with multiple permalinks
- removed @blog.permalinks
- do not export permalink setting
- do not import permalink setting
- permalink setting UI will be removed soon
- get rid of {globals.permalink} completely
- remove yaml in-built migration
- do not expose settings.permalinks via the private API
- do not allow to edit this setting
- keep phyiscal value in case a blog needs to rollback from v2 to v1
- sorted out when the routers should be created
- ensure routes.yaml file doesn't get validated before Ghost is fully ready to start
refs #9742, refs #9724
- handle König Editor format for 2.0
- adapted importer to be able to import 1.0 and 2.0 exports
- added migration scripts
- remove labs flag for Koenig
- migrate all old editor posts to new editor format
- ensure we protect the code against mobiledoc or html field being null
- ensure we create a blank mobiledoc structure if mobiledoc field is null (model layer)
- ensure you can fully rollback 2.0 to 1.0
- keep mobiledoc/markdown version 1 logic to be able to rollback (deprecated code)
refs #9742
- rebase against master updated some docs links again
- go over code base again and double check that all docs links are correct
- 2.0 will become the latest version on our readme pages
refs #9742, refs https://github.com/TryGhost/Ghost-CLI/issues/759
- required a reordering of Ghost's bootstrap file, because:
- we have to ensure that no database queries are executed within Ghost during the migrations
- make 3 sections: check if db needs initialisation, bootstrap Ghost with minimal components (db/models, express apps, load settings+theme)
- create a new `migrator` utility, which tells you which state your db is in and offers an API to execute knex-migrator based on this state
- ensure we still detect an incompatible db: you connect your 2.0 blog with a 0.11 database
- enable maintenance mode if migrations are missing
- if the migration have failed, knex-migrator roll auto rollback
- you can automatically switch to 1.0 again
- added socket communication for the CLI
