refs #10582
- otherwise we will forward string booleans to model layer
- causes trouble if we trigger events
- causes trouble if we want to add conditions to the model e.g. setting.get('value') ?
no issue
- e.g. /feed.xml/ was showing a 422
- any other none slug site requests showed a 422
- should be a 404
- context: site is talking to Content API
- it can happen that the API returns a 422
- the routing layer needs to handle this and always show a 404
- catched error in routing error handling
- need to see if there are more cases
closes#10595
* Added breaking test for img-url helper
Input from the content API was absolute, adding this test to verify my fix
* Updated existing test to breaking test for img-url
Had made a dumb assumption when building images sizes, this updates the
test to fail so we can verify the fix
* Refactored img-url to return as early as possible
This makes it a little easier to parse what's going on, and it also
allows us to remove the check for existence of the image url in the
getImageSizes function
* Refactored img-url config parsing to clean up core logic
Superficial refactor to make future changes able to focus on what rather
than how.
* Refactored internal image detection into helper
We're gonna need to know if the image is internal or not, when we force
the path to relative, if we pull this out now, we have access in the top
level logic
* Removed duplicate checks for internal image
Cleaning up and moving "higher-level" logic into the main function of
the module
* Renamed attr -> requestedImageUrl
Superficial refactor, trying to be more explicit about identifiers
* 🐛 Fixed img-url to output relative url by default
Includes a check to isInternalImage as we never want to make external
images relative.
* Returned early if img-url recieves external url
After realising we never want to deal with external urls, we can
continue to return as early as possible, letting us remove checks and
simplify the more complex logic for internal images.
* Cleaned up the internal image logic
Defining the three functions in order helps to see what operations are
going to happen and in which order, we can then return the result of
each operation applied to the next operation.
refs #5162
- allow pagination and navigation partial helpers to have attributes passed through to them
- e.g. {{navigation header=true}} -> {{#if header}} will now work
- allows styling navigation to be done differently for different sections of the page
- properly create a data frame, and pass through "this" context
- means {{navigation header=true}} is the same as {{> navigation header=true navigation=@site.navigation}}
- our partial helpers, have the same behaviour exactly as if the partial was called directly
- this is additive, and improves behaviour
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
- 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#10570
Added a conditional to only run makePathsAbsolute when database:client
is sqlite3, which keeps expected behaviour (make the
"database:connection:filename" path absolute when running SQLite) while
not breaking MySQL behaviour.
no issue
- trying to use the v0.1 Public API when it was disabled led to a confusing error message, see https://forum.ghost.org/t/403-forbidden-error-on-postman-api-call/6017
- adds an explicit check for the Public API being enabled in the client authentication step and throws a useful error message if client auth is attempted when it's disabled
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
closes https://github.com/TryGhost/Ghost/issues/10558
- added conditional to explicitly set `excerpt` to `null` in the API output serializer when a post has no `plaintext` or `custom_excerpt` value
no issue
- Migrated default scheduling adapter to use Got via the request proxy
- SchedulingDefault is the only module that was using superagent so removed it as a dependency
no issue
- was unable to revert 9dd7aff9c6, because it contains members changes
- functional calls did not work correctly, because the content and admin ctrl differentiation happend in the web layer
- `isContentAPI` returned true for `api.v2.settings.edit(data, {context: {internal:true{})`
- content & admin API are using different controllers
- we can just tell which ctrl is content API and which is not
- the direction fits for the content & admin API split
no issue
- throwing an object from a catch handler is not a good idea
- unexpected and broke functional call to API (always returned a 500, because API returned {err: err, method: ...}
* 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
