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/Ghost/issues/13739
- This is a short term fix to prevent this new feature causing boot errors
- This will allow development to continue uninterrupted this week & also allow us to do a rollout
- The proper fix will be to move where these files live, which will be done before we go live
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.
no-issue
- The workflow runs in the pull_request_target context which has access to repo secrets even when triggered from a fork
- Pinned the GH Action to a specific version to guard against upstream changes to the Action which may abuse access to secrets
refs https://github.com/TryGhost/Toolbox/issues/125
- The in-memory url objects would be persisted in the contents folder allowing to take advantage of the cache during the next instance start
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/81
- the existing `label-actions` tooling was deprecated and shut down but
after reviewing, it wasn't expressive enough for our workflow use cases
- we wanted a tool we could drop into our repos and it works without
extra configuration
- I've developed the `tryghost/label-actions` GitHub Action which will
supports all our labeling flows for triaging
- this commit switches the repo over to using that
- configured the scheduled tasks to run at midnight daily
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.
