no issue
- if we encounter an unexpected error whilst fetching embed details we return a generic validation error so we're not leaking any details about the URL that is being hit, however that meant the error logs were only showing validation errors making debugging difficult
- added explicit logging of the unexpected error before throwing the generic validation error
- These are simple functions that get data from config in a specific format
- They are also used by the topmost part of the application
- Config helpers seems like a reasonable fit to get them out of the web folder
- Functions have also been renamed to try to get them to make more sense
refs https://github.com/TryGhost/Team/issues/1211
Added ?format=json to the URL in an attempt to mitigate any issues with
weird caching and receiving HTML rather than JSON.
Used `type` in place of `card_type` to closer follow how the bookmark
card/embed works.
Removed the html & width/heihgt properties which are not needed at all.
refs https://github.com/TryGhost/Team/issues/1217
- moved top-level `tenorApiKey` to `tenor:apiKey` and added `tenor:contentFilter`
- added base config to `defaults.json`
- updated `public-config.js` and API output serializer to use the new top-level `tenor` key
https://github.com/TryGhost/Toolbox/issues/130
The transaction no longer commits in the promise chain, which wasn't
valid logic for a transaction, since it is commited automatically when
the promise chain resolves, and rollsback automatically when the
promise chain rejects.
This makes code which fails during the transaction error in the right
place, instead of getting stuck here. (Especially good for writing
tests).
The tests for this code can now live in the integration folder.
- This is a minor bugbare, but it will affect some configuration I'm about to do for c8
- I've been wanting to do it for ages, middleware is plural all on it's own so it's an odd affectation in our codebase
- This also only exists in 2 places, everywhere else we use "middleware"
- Sadly it did result in a lot of churn as I did a full find and replace, but consistency is king!
- this keeps production and test fixtures separate, so that changing the prod fixtures doesn't change the shape of our tests.
- we may still want to test that the production fixtures do what we expect, but that can be handled in a separate integration test, by specifically setting the fixture path
refs: https://github.com/TryGhost/Toolbox/issues/133
- instead of just a collection of utils, we now have a class that manages fixtures
- this should allow us to change the path to fixtures, e.g. between prod/dev and test, so that different fixtures can be loaded by default
- also makes it easier to test the fixture manager code itself
refs https://github.com/TryGhost/Toolbox/issues/127
- New instances or Urls and Resources during init were messing up test suites without an obvious solution. Moved them to only be triggered when the cache is present.
- Note the e2e-frontend tests are failing if thie initialization happens every time when init is called. There seems to be some reliance on Resources being the same intsance between "softReset" which seems wrong, but wasn't able to track it down definitevely
refs https://github.com/TryGhost/Toolbox/issues/127
- The resource cache is needed to have quick and reproducible state of the resouces tied to the urls instead of waiting for the db queries to finish.
- Allows to use UrlService without any database connection at all - useful for unit testing
- At the moment there's no way to see in the logs when the URL Service finally finishes
- This is the moment when Ghost stops serving 503s
- Adding this log line so it's clear to see, which migh be useful whilst were refactorising
refs https://github.com/TryGhost/Toolbox/issues/127
- The "withUrlOptions" is used internally in the constructor by the frontend's routers. To avoid passing around a whole function from the frontend routers duplicated the functionality from there.
refs 5a62253466
- The UrlService was relying on a "hidden" identifier field that was passed along with a router object. Now it's passed as an explicit parameter from the "frontend" to the backend's UrlService
refs https://github.com/TryGhost/Toolbox/issues/127
- Passing around whole instance of a frontend router was an overkill when there are only 3 static pieces of information that needed to be loaded. Extracting the router out makes the UrlGenerator way more readable, tests slimer, and the memory footpring of the process should be slightly lighter
- The toString overloading didn't make sense at the time of this refactor, maybe if there's a concrete usecase we could resurect it in a form of passing in a router's name or something.
refs https://github.com/TryGhost/Toolbox/issues/127
- This is an effor t to define a precise set of data needed for the UrlGenerator to function, which should help with decoupling it from the frontend routes
- This is almost the last piece to free us up from the massive "router" object that has been passed around
refs https://github.com/TryGhost/Toolbox/issues/127
- This is an effor t to define a precise set of data needed for the UrlGenerator to function, which should help with decoupling it from the frontend routes
refs https://github.com/TryGhost/Toolbox/issues/127
- This is an effor t to define a precise set of data needed for the UrlGenerator to function, which should help with decoupling it from the frontend routes
refs https://github.com/TryGhost/Team/issues/1211
Instead of rendering the HTML as an embed - we will send back the
necessary data. This will allow us to keep all the knowledge of HTML
structure in the Koenig repository.
refs https://github.com/TryGhost/Toolbox/issues/125
- The url loader is not fully working and is in very experimental mode. The aim is to ship this version to allow other team members to play with the feature in limited use-cases like testing evnironment
refs https://github.com/TryGhost/Toolbox/issues/116
- This should allow testing in a bit easier manner and would place the file into a more suitable directory
- ideally we'd put an alfa flag bahind this new "cached routes" feature to have less consequences to deal with if we have to back out
refs https://github.com/TryGhost/Toolbox/issues/116
- This is a PoC to check out how viable this approach is and if it's worth merging into main as a very quick win
- The `urls.json` is in a bad place right now should probably live in a data folder
refs https://github.com/TryGhost/Toolbox/issues/125
- Config initialization for the URL Resouces is a separate stage which doesn't have to be bundled along with resouce fetching method
- It gives even more flexibility when composing different ways to get the "resources" loaded into memory: right now it's from the DB but could come from a cache
refs https://github.com/TryGhost/Toolbox/issues/125
- The "init" method pattern is not used across the codebase and it's pretty standard to start the service in this way. Previous description was outdated and misguiding
refs https://github.com/TryGhost/Toolbox/issues/125
- The "fetchResources" method did way to many things extracted event listener setup logic to a separate method
- This allows to call out these stages as needed if we retreive resources separately from a cache of some sort and don't need to wait for the database response
refs https://github.com/TryGhost/Toolbox/issues/125
- The "fetchResources" is only used from one place and does way to many things at once:
- Fetches resources from the DB-
- Hooks up event listeners
- Starts the queue
- These are three different things, and should be three different methods ideally
refs https://github.com/TryGhost/Team/issues/1217
- add `tenorApiKey` to `publicConfig.config()
- update canary config endpoint output serializer to include `tenorApiKey` when the `gifsCard` labs flag is enabled
refs https://github.com/TryGhost/Team/issues/1211
This registers the NFT custom OEmbed provider to the OEmbed service for
the canary API. This should probably be done in a centralised place -
but we do not have a single instance of the OEmbed service.
When we have more information about why the OEmbed service is
instantiated like this, we can think about moving it into a singleton
service with an `init` method - which is where we can register custom
providers.
refs https://github.com/TryGhost/Team/issues/1211
This adds the initial custom OEmbed provider for OpenSea NFT's - we're
using the new custom provider functionality so that we can easily change
the logic here without affecting the core functionality.
refs https://github.com/TryGhost/Team/issues/1211
In order to override the default OEmbeds for OpenSea NFT's we need a way
to provide out own OEmbed data. We will want this in future too for
custom Twitter embeds, so this has been built in a way which allows
extension.
refs https://github.com/TryGhost/Team/issues/1212
This now emits the event when the service is reconfigured, rather than
when we issue the reconfigure command, which causes the event and the
action to be run in the wrong order. This would then cause knock on effects
of having the database in an undefined state - with stripe data in not linked
to the current Stripe account.
refs https://github.com/TryGhost/Toolbox/issues/120
- Changed endpoint name as it suits way better to the `/upload` postfix convention we use along with all other endpoints that support file uploads
closes https://github.com/TryGhost/Toolbox/issues/120
- Allows to update and upload brand new thumbnail images for previusly uploaded media resources
- The endpoint is available udner alpa flag as part of Admin API at `PUT /media/thumbnail/`
- As an input accepts following parameters:
- *required* `file` field containing an image file
- *required* `url` field containing parent media file URL
- *optional* `ref` as a field to put in an ID to reference the resource on the client side
- The response has following format:
```
{
media: [{
url: 'http://127.0.0.1:2369/content/images/1991/11/nicevideo_thumb.png'
ref: 'unique-id-420'
}]
}
```
refs https://github.com/TryGhost/Toolbox/issues/120
- When editing an uploaded media thumbnail file there'a need to remove existing thumbnail to keep media files:thumbnails 1:1. - Because the API client only has a public URL under which the resource is served it can only provide that as an API input, the `urlToPath` was also added to the base class of LocalStorageAdapter (it might be moved up to the BaseAdapter in the future if we see a need)
refs https://github.com/TryGhost/Toolbox/issues/114
- Files API is meant to be used for non-executable file uploads of all sorts
- The files are stored and retrieved for download as-is
