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 "/".'
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
- Content API doesn't return primary_tag and primary_author fields by default if authors or tags were not requested
- These fields are still always included in Admin API as a result of having authors and tags loaded (like a sideeffect)
refs #11040
In case of falsy `sendWelcomeEmail` config, the blog setup crashed as the setup method implicitly returned undefined instead of promise. This handles the fasly config correctly.
- Adds regression test for pro config blog setup
no issue
- bump eslint-plugin-ghost to v0.5.0
- update core/test eslint config to use "ghost:test" in place of custom ruleset
- apply automated eslint fixes
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.
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.
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#10927
- Previous fix 2823c0b342
- It didn't work because the validation layer in "frame" doesn't take into account the value under `required` property of the controller, so to prevent validation on the field whole `required` key/value have to be removed
- Removed unused variables
- Extended regression suite to prevent similar problems in the future
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
* Swapped v1 with v4 UUID as requestId when logging
no issue
v1 UUID are based on current time and the hardware MAC address of the
machine where they are being generated. As such they have much more
complex semantics than v4 UUIDs which are simply randomly generated.
Unless there's a specific requirement for the special semantics of v1
UUIDs it is simpler and less error prone to simply go for v4 UUIDs
whenever just a unique identifier is needed.
* Swapped v1 with v4 UUID when creating a temporary contentFolder
no issue
v1 UUID are based on current time and the hardware MAC address of the
machine where they are being generated. As such they have much more
complex semantics than v4 UUIDs which are simply randomly generated.
Unless there's a specific requirement for the special semantics of v1
UUIDs it is simpler and less error prone to simply go for v4 UUIDs
whenever just a unique identifier is needed.
* Swapped v1 with v4 UUID when creating a temporary exportFolder
no issue
v1 UUID are based on current time and the hardware MAC address of the
machine where they are being generated. As such they have much more
complex semantics than v4 UUIDs which are simply randomly generated.
Unless there's a specific requirement for the special semantics of v1
UUIDs it is simpler and less error prone to simply go for v4 UUIDs
whenever just a unique identifier is needed.
fixes 10883
- fixed an issue where /amp/ pages would cause an infinite redirect loop
- this only occurred when amp was disabled, and query params were passed to the /amp/ url
- this fix resolves the issue by not assuming /amp/ is the end of the URL
- it also checks for `/amp/` (both slashes) and replaces one
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
no issue
- The reason for the test failure was:
- Bump in express version: 5a316c3c80)
- Which included bump of it's internal dependency `send` to version send@0.17.1: https://github.com/expressjs/express/releases/tag/4.17.0)
- Which had a change in how 'xml' type was interpreted: https://github.com/pillarjs/send/pull/154/files
- Because in Ghost documentation for dynamic routing, we clearly state to use `contetn_type: text/xml` instead of just `content_type:xml` the test was considered to be not up to date (ref. https://docs.ghost.org/api/handlebars-themes/routing/routes/)
- Returning `content-type: text/xml; charset=UTF-8` stays in line with the rest of Ghost codebase
- WARNING: when using `res.type('xml')` for whatever reason in the codebase be awere that express will send `application/xml` header which is not the convention used throughout the codebase
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 #10656
- To make sure more users see important updates or announcements
notification dismissal now works per user instead of globally
- Expanded acceptance test for notification deletion
- Expanded regression test covering multiuser dismissal of notification
- Added clarifying comment about destroyAll method use in API
refs #9178
- Migrated settings model regression to unit tests
- Removed redundant/unuseful post tests
- Extracted post model regression tests to API tests
- Renamed test suites for consistency
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
no issue
- Descreased ammount of posts inserted by 'posts:mu' fixture so that Travis doesn't timeout.
- The fix is just a patch, needs investigation into what change caused the timeout in the first place
no issue
- Reported here: https://forum.ghost.org/t/in-version-2-16-3-found-bug/6065/3
---
Admin Client sends false or true booleans for `is_private` key.
The settings table has two columns "key" and "value". And "value" is always type TEXT.
If you pass value=false, the db will transform this value into "0".
`settingsCache.get('is_private')` is then always true, even though the value is meant to be false.
We should add a migration in v3 and normalize all setting values to ensure consistent database values. Furthermore, we should improve the handling around settings values in general.
For now, we protect parsing values from DB, which we anyway need to transform the values into the correct data type, because we always save strings. This will protect values being stored as "false" or "1" or whatever.
closes#10512
- Removed field filtering in blog owner fetching because it didn't work before (fields weren't reduced) and now broke generated sql queries (ambiguous id field)
refs #10512
- Fixed ability to fetch specific fields when fetching tag resource by id
- Also only returning `url` field when specified in `fields` parameter
closes#10518
- we had a very generic logic to remove "unwanted" null values
- copied from v0.1
- originally added in 7d4107fec4
- this logic transformed: settings = [{key: 'key', value: null}] to [{key: 'key'}], which is wrong
- i've removed this generic logic completely, because i don't know which purpose it serves
- if there a specific case where we want to remove null values, we should either use the JSON schema or use a specific serializer for the target resource
- added tests to proof that settings API behaves as it should
- one test failed because we removed the isNull logic -> if you send published_at = null on a published post
- the model layer has a piece of logic to force a date if you set published_at to null if the status is published
- protected
* Required kid be a header claim as according to spec
https://tools.ietf.org/html/rfc7515#section-4.1.4 (JWT is an extension of JWS)
* Updated error message for missing kid
* Fixed admin-api key unit tests
* Fixed regression and acceptance tests
refs #10438
- "null" means the resource does not exist (it was sett to "null"), which is not true
- we won't serve primary_tag and primary_author by default
- TODO: add the same change to the Content API v2 (raise issue)
no issue
- make use of filter instead of status=all or data.page
- nql was designed to filter data on database layer
- do not break v0.1
- we just got rid of the "status" query param, you should use the filter instead
- get rid of the ugly condition to remove page field if "fields" param was used
- allow filtering on model layer for "findOne"
- do not allow filtering for "findOne" on API layer for now
- the API controller defines what is allowed
- the model layer can allow more by default
- we can re-use the powerful filter logic without adding hacks
refs #10438, refs #10106
* Renamed existing pages ctrl
* Splitted posts & pages for Admin API v2
* Added pages JSON input schema for Admin API v2
* Removed single author for Content & Admin API v2
- single author is not documented
- single author usage is deprecated in v0.1
- single author usage is removed in API v2
* Splitted posts & postsPublic controller for v2
* Removed requirement to send `status=all` from Admin API v2
* Removed `status` option from pages Content API v2
* Removed `status` options from Users Admin API v2
refs #10438
- the `updated_at` functions as version control value
- it is required for collision detection
- we might redesign this feature at some point
refs #10438
- these fields are not used
- no need to expose them in v2
- we will either remove them in the next major or use them for new features (will see)
refs #10461
- do not break the existing webhooks by keeping both payload formats for subscribers events
- refactored webhooks service to run models through target API version
- added new events described in the target issue reference
- this refactoring & enhancement is undocumented, further breaking changes will happen because we are actively working on: https://github.com/TryGhost/Ghost/issues/10438
no issue
- the model & api layer suffered from missing fields when creating resources
- usually there is only a handful of fields which are required to insert a resource
- the other fields are nullable and/or get defaults assigned
- the API only returned the configured default fields and the fields you have sent to the API
- this resulted in a response with missing fields
- if you have listend on "created" event, the same happend
- you received a model with missing fields
- we now set the undefined fields to null on purpose to ensure a full model for both cases
@NOTE:
There is no endpoint to serve webhooks (not for v0.1, not for v2).
Exposing the secret is required if an integration fetches it's api keys and it's webhooks.
The secret is currently un-used and not implemented.
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 #9178
- Removed tests that had duplicated or already covered cases in acceptance or unit tests
- Optimized some slow tests
- Some test suite naming changes
- Imports cleanup
refs #9178
- the cronjob for mysql fails currently
- the target test throws some errors, which would take a while to figure out why
- we have moved the model tests to a different location/folder and since then they have failed for mysql
- we are re-working/re-considering a lot of regression tests anyway so i thought it's easier to simply skip this test for now
- the target test passes if you run it as a single test file (!!!!)
refs #9178
`yarn test` only runs acceptance and unit tests.
We will setup a cronjob in Travis and run the regression tests once per day.
You can manually run them with `yarn test:regression`
This separation is just a first step into the right direction.
Travis will no longer run for 10-13minutes.
The goal is to run common API use cases and unit tests in Travis and locally by default.
## After this separation we still need to:
- re-work our test utility
- remove some tests
- define which tests are our common API use cases
- rewrite some tests
- make testing easier (starting/stopping Ghost, fixtures and resetting services or event listeners, it's a pain and takes sometimes ages to fix tests)
---
**Acceptance:**
- common/basic API use cases against the current **stable** API
**Unit:**
- all unit tests (no database access)
- proper mocking
**Regression:**
- packages we don't want to run for each PR or commit
- tests which protect Ghost from breaking components and behaviour
- it is wishful that regression tests are using Ghost's API's (frontend, apps, core)
---
**This PR requires an update to our docs.**
