You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Is your feature request related to a problem? Please describe.
Recently we've found frustration when our team are trying to expand the content on Janeway's CMS when running the hourglass theme.
Usually, one of our team members will request a change to be made, communicate the details of such change to developers and then someone from the technical team will need to produce a changeset via Github which then has to be reviewed and deployed. Use of django-components requires users to be able to access and run the django rendering backend, which is an open door for security vulnerabilites, as it allows for arbitrary code execution server side. Tailwind CSS would have not been a wise choice without a component library, so the trade-off that we made to run these technologies is now hindering usability of the platform long term.
This friction is a big departure from the WYSIWYG editor that made it possible for anyone in the team to edit content pages prior to running the theme
Describe the solution you'd like
To bring back the power to make edits to CMS pages to members of the team, we could write a custom template backend to limit the use of the backend engine only to delegate work to django-components. This mechanism would enable all users to alter the content that is provided to each component, however there wouldn't be a WYSIWYG interface for it, meaning users would be required to understand the inner workings of django-components or continue to delegate work to the tech team
Describe alternatives you've considered
An alternative would be to drop our CMS in favour of one provided from a vendor. Ideally, it would also support WYSIWYG and would probably require dropping django-components in favour of a solution that works natively with the CMS system itself.
Additional context
We've had a brief chat in Discord about this and agreed it makes sense to use an internal design meeting session to discuss this.
The text was updated successfully, but these errors were encountered:
Is your feature request related to a problem? Please describe.
Recently we've found frustration when our team are trying to expand the content on Janeway's CMS when running the hourglass theme.
Usually, one of our team members will request a change to be made, communicate the details of such change to developers and then someone from the technical team will need to produce a changeset via Github which then has to be reviewed and deployed. Use of
django-components
requires users to be able to access and run the django rendering backend, which is an open door for security vulnerabilites, as it allows for arbitrary code execution server side. Tailwind CSS would have not been a wise choice without a component library, so the trade-off that we made to run these technologies is now hindering usability of the platform long term.This friction is a big departure from the WYSIWYG editor that made it possible for anyone in the team to edit content pages prior to running the theme
Describe the solution you'd like
To bring back the power to make edits to CMS pages to members of the team, we could write a custom template backend to limit the use of the backend engine only to delegate work to
django-components
. This mechanism would enable all users to alter the content that is provided to each component, however there wouldn't be a WYSIWYG interface for it, meaning users would be required to understand the inner workings ofdjango-components
or continue to delegate work to the tech teamDescribe alternatives you've considered
An alternative would be to drop our CMS in favour of one provided from a vendor. Ideally, it would also support WYSIWYG and would probably require dropping
django-components
in favour of a solution that works natively with the CMS system itself.Additional context
We've had a brief chat in Discord about this and agreed it makes sense to use an internal design meeting session to discuss this.
The text was updated successfully, but these errors were encountered: