no issue
- The timeout has been triggered due to lot's (25) of posts being inserted into the databse , which took over 20 000ms on Travis.
- We don't need to insert this many posts in the first place to test the case
- The reason why it is taking longer to do the insertion operation then before should be investigated separately
no issue
- `og_image` and `twitter_image` fields are now located in a separate model so the transform functionality for those fields needed to move accordingly
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
no issue
- Added test cases to check edit permission on settings endpoints
- Added test to demonstrate owner-only being able to toggle members flag
- Permission check when editing settings `lab.members`
- Passed additional function to permissions to allow custom selection of unsafe attributes due to settings object structure.
- Fully implementing this check on controller level would be wrong architecturally and not that straight forward because we lack role data in "frame"
- Cleaned up test after moving default_content_visibility to it's own property
refs https://github.com/TryGhost/Ghost/issues/10477
The unsaved changes modal is displaying even when the post has been saved if images have been uploaded because the server is transforming absolute image urls to relative during input of the `mobiledoc` field but not transforming them back to absolute during output. The editor then thinks it's out of sync and shows the warning when trying to leave.
- `@tryghost/url-utils` has been updated with new methods for transforming URLs in mobiledoc content
- moves absolute->relative transformation from the API input serializers into the Post model
- transforms URLs in more fields for a more comprehensive transformation and fewer issues when re-configuring a site's domain
- previously there could be problems with internal links between posts not being transformed so you could change the url config to newdomain.com but links in post content would still be pointing to olddomain.com
- updates the API post output serializers to transform all modified fields
- drops the `?absolute_urls=true` param switch from the `canary` API post output serializer so that all URLs are output as absolute
- we're transforming more urls to relative when saving so this is necessary to ensure the unsaved changes modal is not triggered
- the query param isn't documented and will disappear in v3
no issue
- Improved error handling for member creation. We should be returning 422s instead of 500 when possible
- Wrapped `members.add` method with Bluebird promise. Wrapping is needed to be able to use `.reflect()` in CSV export method
- Added proper members CSV fixture
no issue
- Added Regression full test coverage for members Admin API
- Added `POST /members` endpoint
- Added members schema definition + validation
- Added ability to pass through send_email/emal_type options to members API
no issue
- Added 'labs' flag settings test
- Added test for default_content_visibility flag
- Default post's visibility takes into account values set in default_content_visibility setting
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
- the begin/end comments are only really useful when wrapping free-form content cards such as html and markdown, the rest all have specific elements and classes that can be used in parsers
- made the comment wrappers optional in the `render()` function created by the `createCard()` factory
- opted into comment wrappers for the html and markdown cards
no issue
- Updated test utilities to clearly identify both fields are not used in API responses
- Updated comment to remember clearning authors/author_id before releasing Ghost 4.0
refs #5151
refs #10737
- Removed all uses/references to post's "staticPages" filter
- It was only a feature specific to API v0.1 which doesn't have to take space in the codebase anymore
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
- 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
- adds `config:redirects` config option that defaults to `true`
- when set to `false`
- `/ghost/` will 404 on the front-end when a separate admin url is configured
- all `{resource}/edit/` URLs on the front-end will 404
no issue
- Removed v0.1 controllers
- Removed 0.1 API unit tests
- Removed 0.1 API app and mount point
- Removed leftover use of v0.1 in entry-lookup test suite
- Removed frontend client API enpoints and related code (middleware)
- Fixed prev/next test suites to use v2 API
- Set default API version to explicit v2 in UrlUtils
- Removed v0.1 API regex from public files middleware
no issue
- we used to redirect paths such as `/logout/` and `/signin/` to the admin but they are no longer desired
- with the introduction of members these URLs can be confused with front-end member related actions
- we want to be able to optionally "turn off" redirects to the admin to help mask the admin url when it's configured to be separate to the front-end
no issue
- 'static pages' (post of a page type) were not supported in v0.1 API
- this is where the 404 is comming from - df7e64fafa/core/frontend/apps/amp/lib/router.js (L66). and it was handled in rather late stage before - df7e64fafa/core/frontend/apps/amp/lib/router.js (L24)
- after moveing to v2 API the later stage doesn't happen so the entry lookup helper doesn't have anough infomration to tell if it's a 'Post' or 'Page' is being requested
no issue
- As v0.1 API is dropped there is no need to keep an API client around
- Removed references to ghost-sdk in regression test suite
- Removed routes to /public/ghost-sdk.js
- Removed reference to ghost-sdk in grunt build process
no issue
- Removed v1 'author' leftover in include statement for preview controller
- Removed v1 'author' leftover in include statement for preview controller
- Removed v1 'author' leftover in include statement in entry lookup routing helper
- Migrated related test to use v2 API controller
- Removed v0.1 routing confif
- Removed v0.1 url config
- Fixed tests that had to do with url's in resources after removing v0.1 resources from URL cache
- Removed v1 'author' leftover in include statement in static routing helper
- Modified the test to use v2 API
- Removed v1 specific condition with 'page' in context helper
- Fixed dynamic routing spec after theme switch to v2. All tested users have to have at least one published post to be shown as an author
- Fixed URL Service spec to use theme engine v2
no issue
- @tryghost/url-utils was bumped to 0.3.1 which fixed admin redirects returning relative rather than absolute URLs
- updates tests that were expecting relative URLs rather than absolute URLs
fixes#10990
- Changed the static router to throw a 400 error for a missing template file, rather than falling back to using the default.hbs file
- Falling back is weird and hard to understand, but throwing an error makes it clear that the user has to provide the matching template
- The new error reads 'Missing template [filename].hbs for route "[route]".'
Assume you have a route.yaml file something like:
```
routes:
/: home
```
- In Ghost v2, if you don't have a home.hbs template, Ghost falls back to using the default.hbs file if it's available
- Most themes have a default.hbs, however this file is a layout file, depended on by other templates, not a template file itself
- In production mode, using the default.hbs as a template causes weird, intermittent layout issues depending on which order pages are loaded
- This is due to this issue: https://github.com/barc/express-hbs/issues/161
- In Ghost v3, we will throw a 400 error for missing template files instead of having a fallback
- In the example above, navigating to '/' would throw the error 'Missing template home.hbs for route "/".'
