Sector(s)
Team Members
Project Team
Amazee Labs:
Project Manager: Zsófia Gugán
Developer: Mattia Simonato
Developer: Joëlle Symons
Caritas Schweiz
Caritas Schweiz is a charitable organisation committed to preventing and fighting poverty in Switzerland and worldwide in around 20 countries. As well as providing emergency relief in disasters, their work encompasses a vast range of socially essential areas such as support for those on a low income or seeking asylum.
Caritas-Bergeinsatz is dedicated to supporting the Swiss mountain farming community. The goal of the organisation is to connect farmers with volunteers who can ease the workload of farmers during busy periods or emergencies. The scheme is very often vital for the farming community to ensure the farm remains operational, even during times of extreme pressure.
Caritas Care specifically focuses on support for the elderly to provide them with the care they need in their later years, while at the same time retaining their independence. Additionally, Caritas Care provides wages for relatives who act as caregivers and dedicate their time to care.
About the project
Caritas Schweiz's website needed a comprehensive relaunch to better meet marketing, communication and fundraising needs. A contemporary user experience was to be created that conveys competent and concise factual content in a visual and descriptive manner and guides users along their needs with a clear structure. Furthermore, donation features were to be enhanced, editorial processes in content management simplified and technical performance, security, and scalability increased.
At the same time, the relaunch was intended to create a technical platform on which other Caritas Schweiz projects such as www.bergeinsatz.ch and www.caritascare.ch can be built.
Key Features
Multi-site setup with the Domain module
As part of the solution, the proposal was for all three websites (Caritas Schweiz, Caritas-Bergeinsatz and Caritas Care) to share a Drupal instance to enable content and media sharing, to improve the editor workflow and content consistency across the different sites.
This was achieved by installing and configuring the Domain module, which provides a checkbox field on content and media items that associates the entity with the appropriate websites. Editors have websites associated with their user accounts to display the content that is relevant to them and website-specific publishing permissions. On the front end, three individual sites were built which use different users with the appropriate permissions to fetch the content.
This multi-site setup has reduced the time editors spend uploading media items and creating content for the three sites, improved maintainability (with technically only one website to worry about), allows administrative/high-level editors to oversee the implementation of the communication strategy easily and unifies editorial onboarding and training.
Decoupled Drupal with GraphQL
ReactJS and Gatsby were used to build performant, maintainable and interactive websites, with some great tooling like Storybook, Prettier, and ESLint to help us along the way. Having a separate static front end has security benefits due to only having the HTML, JavaScript, CSS and media files from the Gatsby build on the main domain, which reduces the risk of vulnerabilities being targeted in Drupal. If the back end was ever to go down for some reason, the front end is much more robust as it is separately hosted and there’s little that can go wrong, as it is simply hosting static HTML and associated files.
A decoupled architecture also allows the back end to be replaced with another CMS, which offers clients some portability if their back end requirements change but they want to retain the front end. It’s for these reasons that a decoupled architecture was chosen for the Caritas Schweiz websites.
When using Drupal as a decoupled CMS, you need to decide how your content is going to be exposed via an API, so that the front-end website can fetch everything it needs. Amazee Labs loves GraphQL, so it was a natural choice to use the GraphQL Drupal module, co-maintained by our very own Philipp Melab. Custom GraphQL schema was created to match the requirements and the back-end team worked closely with front-end developers to ensure the data retrieved would work well in the React components.
The headless Drupal setup is working well for the system and the separation internally really helps with the developer workflow.
Decoupled interface translations
Drupal has a good system for translating interface text in the traditional Drupal architecture, by using the t function. However, in a decoupled setup there are many interface translations in the front-end components that Drupal has no knowledge of. With a lot of strings, and four languages to translate them to, the Caritas Schweiz editorial team needed a solution to be able to manage these translations, and it made sense to have them where the rest of the translating was taking place: in Drupal.
A custom module was implemented to create a custom endpoint for translations in Drupal with the context “gatsby” - this allows differentiating between the front-end translations from translatable strings within Drupal. To retrieve these translations, a field was added to the GraphQL schema that returned all translations with the context “gatsby”. A contributed module was not used, or created, for this feature (due to the mix of using an endpoint for the creation and GraphQL resolver for retrieval), there is a similar module in development called Decoupled Interface Translations, co-maintained by Amazee Labs' Nick O'Sullivan.
The Caritas Schweiz editors can now manage both the translations for content and the front-end website in Drupal with ease. The creation and retrieval all work automatically so that there’s no overhead for developers when adding a translation, as long as the translatable string is defined correctly in the front end.
Improvement of the editor experience
With the increase in better editor user interfaces in website builders and WordPress, the aim was to match these expectations in Drupal, by using Gutenberg as a WYSIWYG editor. The workflow and UI are preferable compared to other options such as Layout Builder, Panels or Paragraphs to build rich content.
Using the Gutenberg Drupal module, numerous custom blocks were created based on a component library. The front-end visual style was matched, as closely as possible, to provide a WYSIWYG solution. Each of these custom blocks was then created as its own GraphQL type with the expected fields for the component and added to the schema.
The editorial team at Caritas Schweiz have enjoyed using the Gutenberg editor and found it intuitive. Internally, the UI has moved closer to what will be output on the front end and Gutenberg Drupal module has been cemented as part of Amazee Labs’ Drupal stack now.
Front-end preview
A challenge with decoupled websites is matching the ability in Drupal to edit a page, save and go to the view tab to see the final result. For something so essential and a basic requirement, there are a couple of things to overcome: when a user creates or updates content, ensure the front-end rebuilds with the new content; and provide an easy way to view the front end, as simply as in a traditional Drupal setup.
To ensure the front-end website is kept up-to-date, a custom module notifies our Gatsby site when an entity is created or updated, and this triggers an incremental build to just update what has changed. The View tab on entity pages shows a version of the front end, so it matches the usual Drupal edit-and-view workflow.
Webform usage
As part of the requirements, a forms solution was requested that could be managed by Caritas Schweiz editors. The Webform module is a go-to solution in Drupal as it is super flexible and extensible. However, with a decoupled architecture webform configuration data cannot be consumed and create forms on the front end, without a large development overhead. So to play to the strengths of the Webform module, Drupal webforms were embedded as iframes with a custom theme, to seamlessly integrate it with the front end, without the huge overhead of implementing a form builder in the front end.
This solution gives the Caritas Schweiz team the ability to embed any Webform now via the Gutenberg editor, and thanks to the features in this contributed module, provides them with a lot of flexibility in the forms they are creating.
Why Drupal was chosen
All three Caritas websites previously used TYPO3 CMS as their platform, however after conducting a CMS-research study, Drupal came out on top! The main factors that influenced the decision included editorial workflows, Gutenberg editing experience, API support, and flexibility in content-modeling. The state-of-the-art setup was decoupled with ReactJS and Gatsby for the front ends.
The extensive module library was vital to the success of the project and to achieving the specific business objectives.
Drupal 9 also provides a straightforward upgrade path, which ties in with Caritas Schweiz’s goal to have a clear long-term maintenance strategy in place.
Technical Specifications
Drupal version:
Key modules/theme/distribution used:
