- Having these as destructured from the same package is hindering refactoring now
- Events should really only ever be used server-side
- i18n should be a shared module for now so it can be used everywhere until we figure out something better
- Having them seperate also allows us to lint them properly
refs: bf0823c9a2
refs: ae86254972
- continuing the work of splitting up the theme service into logical components
Themes Service
- The serverside theme service now serves just the API and boot
- It loads the theme and passes it to the theme-engine via the bridge
This achieves the bare minimum goal of removing all the cross requires between server and frontend around themes
There is still a lot more to do to achieve an ideal architecture here as laid out in ae86254972
refs: bf0823c9a2
- continuing the work of splitting up the theme service into logical components
- am about to move the theme service to core/server so it should require i18n directly
refs: bf0823c9a2
- continuing the work of splitting up the theme service into logical components
- this file is not part of the theme engine so it should use the bridge not the engine
- am about to move the theme service to core/server so this will make even more sense then
refs: bf0823c9a2
- continuing the work of splitting up the theme service into logical components
Theme activations are a trickier piece of the theme split puzzle because they are called from the API and theme service on boot in different ways.
Activations require a theme to have been validated at different levels. Validations are also tricky - do they belong to the theme engine, or the theme service?
There are then several different flows for activations:
- On Boot
- API "activate" call
- API override on upload or install via setFromZip, which is a method in the storage layer
These calls all have quite different logical flows at the moment, and need to be unified
For now, I've moved the existing "activate" function onto the bridge. This allows the theme service to be split from the frontend, and refactoring can start from there.
I hope to move this so there is less code in the actual bridge very soon, but my goal is not to require any server packages in the frontend part of this
I think ideally:
- all activation code, including validation, should probably be part of the theme engine
- the theme engine should offer 3 methods: getActive() canActivate() and activate()
- the theme service is then only responsible for loading themes in and out of storage, JSON responses for the API, and handing themes to the frontend via the bridge at the appropriate moment
- Modules in /shared are supposed to be standalone modules that can be required by the server or frontend
- As the server shouldn't require the frontend, and vice versa, shared modules should require neither
- Otherwise it just becomes a crutch for allowing cross-depenencies, and will create circular dependencies
The Bridge
- The bridge file is not meant to be a crutch sat allowing cross-dependencies, but rather a new component that manages the flow of data
- That data flows from the server/boot process TO the frontend, and should not flow in the other direction
- The management of that flow of data is necessarily hacky at the moment, but over time the architecture here should get clearer and better
- Still, for the time being it will need to handle requiring across components until that architecture matures
- Therefore, it should live in core root, not in core/shared
refs: bf0823c9a2
- continuing the work of splitting up the theme service into logical components
- This one is a little more involved, as the i18n initialisation was unnecessarily spread over several locations.
- I moved it into being part of the ActiveTheme class and called in the constructor, meaning we don't need the services.theme.activated event anymore as the constructor is called in the same cases.
- Also moved the event listener for locales into the bridge, as I don't want that inside of theme-engine, and we don't want circular dependencies. We'll figure out a wayto refactor this soon too.
refs: bf0823c9a2
- Added a new bridge class that lives in shared. This should eventually be responsible for all cross-communication between the frontend and the server
- Having all the gnarly shared bits in one place should help us refactor more easily
- For now it also reduces requires between the core/server and core/frontend folders that are meant to be separate
- All calls to getApiVersion have also been renamed to getFrontendApiVersion, as this is different to the "default" API version
- Slowly getting to the point where frontend/services/themes can be moved to server/services/themes :)
refs: bf0823c9a2
- continuing the work of splitting up the theme service into logical components
- this is where it starts to get fiddly as the getActive function in themeService index is required across the frontend/backend mostly due to its use in the getApiVersion method
- for now left one usage of the getActive method in place in ghost-locals middleware ready for the next phase of the refactor, which will move some of the themeService index into a shared location
refs: 9f50e941eb
refs: bf0823c9a2
- Still working towards splitting the theme service into logical components
- The engine defaults were required in the index file, in a way that creates tight coupling across what would otherwise
be distinct components
- Also meant there was another hardcoded 'v4' in the codebase
- This fixes both issues by depending on the value from config
- Currently this adds Yet Another Config Require, but it should be fine for now until we have a new pattern for the frontend
- Note: We only care about the ghost-api engine, we used to care about both ghost and ghost-api. Now that there is only one there was no need for the more complex code structures
refs https://github.com/TryGhost/Team/issues/579
- when members signup is enabled returns `#/portal` otherwise returns feedly subscription URL
- allows for themes to have subscription buttons without condititionals, eg `<a href="{{@site.signup_url}}">Subscribe</a>`
- This is the beginning of splitting up the theme service into:
- Storage components used by the API (should be a server service)
- Theme engine & rendering components used by the frontend (this new engine service)
- The code to activate a theme which is shared code where the API & frontend need to communicate
- This is needed because currently the frontend theme service is required and used by the API, creating tight coupling.
- In my quest to truly separate the API and frontend, this is one of many battles that needs winning
closes https://github.com/TryGhost/Team/issues/552
Refactors URL transforms so they take place at the model layer rather than the API serializer layer. Continuation of the pattern created for the settings model in https://github.com/TryGhost/Ghost/pull/12738
- Added checks to all front-end tests to ensure output does not contain the magic replacement string
- includes failing acceptance test for `__GHOST_URL__` appearing in sitemaps
- Removed all transform-ready URL transforms from API serializers
- input serializers transform image urls relative->absolute to keep absolute-urls as the consistent "outside of the database" format
- output serializers should not need to perform any URL transforms as that will be done at the model layer
- Added url transforms to models layer
- removes knowledge from the API serializers which shouldn't need to know how data is stored internally in the database
- makes absolute urls the consistent "outside of the database" URL format
- adds transform step to the sitemap generator because the data used for that is fetched directly via knex which will not run through the bookshelf `parse()` methods
closes https://github.com/TryGhost/Team/issues/545
The price helper requires an object with amount & currency properties to
work correctly. This updates the @price data object to expose these.
In order to maintain backward compatibility with using the @price data
as primitive number values, we add a valueOf method which returns the
legacy dollar amount value.
This means you can use {{price @price.monthly}} OR
{{@price.monthly}} - the second of which will output the dollar
amount.
A new theme fixture was added to test both usages of the @price data
no-issue
The handlebars template module is required by the proxy service, as part
of the definition of the proxy service's module.exports. By
destructuring the i18n property from the proxy service at the time the
template module is loaded, the i18n property was always undefined, as the
module.exports of the proxy service had not been set.
Bypassing the proxy, and requiring the i18n module directly eliminates the
circular dependency.
* Refactored handlebars template tests to use proxy
Since this module is intended to be used via the proxy, we should test
it in the same way. We have uncovered a circular dependency issue, which
would not be possible to catch in tests unless the tests were to go via
the proxy.
* Added breaking test for handlebars template function
This test highlights the issue caused by a circular dependency, we are
unable to throw an IncorrectUsageError because i18n is undefined.
closes https://github.com/TryGhost/Team/issues/467
- switches to storing "transform-ready" URLs in the database
- transform-ready URLs contain a `__GHOST_URL__` placeholder that corresponds to the configured url that gives a few benefits
- much faster and less memory intensive output transformations through not needing to parse html or markdown - the transform can be achieved using a straightforward regex find+replace
- ability to change to/from or rename subdirectory without any manual updates to the database
- modified existing 4.0 url-transformation migration rather than adding another one and repeating the transformation on posts rows
- Theme preview was not showing the same behaviour as a real theme because nulls were being encoded and decoded incorrectly causing nulls/empty strings to be treasted as truthy values
- Swap from using split to using proper query param parsing so that the code is more robust
- this still creates empty strings and the string 'null' so added a small function to decode these back to real nulls
- moved to its own file ready to be split out - there needs to be a bigger picture plan for this
- added unit tests to cover the known issues + some potential breakages from converting the header string to a query param object
refs https://github.com/TryGhost/Ghost/issues/12602
As part of the member events, we added a third status of 'comped'.
Members with a status of 'comped' should still be considered paid, so
this fixes the definition of the paid flag to take that into account.
closes https://github.com/TryGhost/Team/issues/464
Currently, if the last4 value for a customer is empty, we end up showing `null` in theme where the card details are shown. The fix updates the last4 to return a masked value of **** instead of null if it's empty, ensuring themes using the last4 values don't have a `null` value shown to the user.
refs dd715b33dc
- this is the last event that is used to trigger part of the standard boot process
- events make the code harder to read/reason about
- the urlservice is one of the most core and critical components in Ghost, possibly the biggest consumer of time and memory
- we want to have the work it is doing front and center so that we can improve it
closes https://github.com/TryGhost/Ghost/issues/12506
- adds an error handler that will rename the backup folder to the original name if the newly uploaded theme wasn't saved successfully
refs b1a98b0b67
- note: I already replaced server.start with themes.ready in the above commit
- events make the code harder to read/reason about
- long term it would be nice to have a concept of hooks for services, but for now explicit is clearer
- use theme.ready for loading themes instead of server.start and properly clean this up
- remove server.start and server.stop as they are no longer used (only server.start was used, and only for themes)
- we're moving away from the pattern of using global events like this as they are hard to reason about
- This commit removes the old boot process and any files that are no longer needed as a result
- Remove the duplicate event for triggering inactive themes to load
- Tidied up a few other bits
- Allow the frontend to accept post messages to generate previews of the frontend
- Created a new endpoint in admin we can use to render these previews, which is possibly not necessary
- Supports a limited group of settings, which can easily be expanded, but care should be taken if expanding to use user-provided strings
- Currently the new boot process breaks the loading of inactive themes because the theme loader event isn't wired until after the server.start event is fired
- This is a WIP fix, there needs to be some bigger refactoring of the boot process once the old process is gone
no-issue
This removes all references to the members labs setting, any code that was run conditionally behind this flag now runs unconditionally.
* Removed usage of Members labs flag
* Removed tests for Members disabled
* Added dynamic keypair generation for when setting is missing
no refs
- Updates member model serializer to directly set subscriptions on member object instead of `stripe.subscriptions`
- Updates all references to members subscriptions from nested `stripe.subscriptions` to `subscriptions`
- Updates v3 API serializer to still use `stripe.subscriptions`
- Updates tests
no-issue
* Removed support for paid param from v3 & canary API
* Updated active subscription checks to use status flag
* Updated MEGA to use status filter over paid flag
* Removed support for paid option at model level
* Installed @tryghost/members-api@1.0.0-rc.0
* Updated members fixtures
closes#12271
- When previous active theme did not have locale data for certain language, loading a theme which has such data did not result in correct locale being loaded
- Underlying issue was in settings cache being outdated during theme change related i18n initialization
- Fix focuses on removing settings cache dependency and and rely on most up to date data about currently active theme
- The benefit of this approach is reduced coupling with settings cache
- we export i18n from `core/frontend/services/proxy` and this is used in
the most of the places in the frontend code
- this commit aligns the rest of the code in core/frontend to use the
proxy too
- unfortunately core/frontend/services/themes/i18n.js loops back to the
proxy so we have a circular dependency
refs https://github.com/TryGhost/Ghost/issues/12256
We no longer want to filter out cancelled subscriptions, so we are able
to remove the whereIn clause of the relation.
* Fixed paid flag on member
* Fixed content gating for members
Now that the subscriptions for a member include all of them, we must
explicitly check that the member has an active subscription in order to
consider them "paid"
- this helps bring all the code together so we can extract it in the
future
- turning it into a class also lets us easily inject the i18n instance
and store it locally
