Caritas Schweiz Multi-Site Relaunch
Multi-site relaunch on Drupal 9. The state-of-the-art setup was decoupled with ReactJS and Gatsby for the front ends of the three Caritas Schweiz websites: caritas.ch, bergeinsatz.ch and caritascare.ch
Case descriptionCaritas Schweiz 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.
Case goals and resultsGOAL 1: Enable content and media sharing, improve workflow, and achieve content consistency across all three instances (www.caritas.ch, www.caritascare.ch, www.bergeinsatz.ch )
SOLUTION: Achieved an optimised content editing workflow by installing and configuring the Drupal Domain module which provides a checkbox field on content and media items that associates the entity with the appropriate websites. 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.
GOAL 2: Manage multiple translations
SOLUTION: 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”. 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.
GOAL 3: Improvement of editor experience
SOLUTION: 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.
GOAL 4: Creation of a form solution
SOLUTION: 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.
The new www.caritas.ch website went live on schedule on January 17, 2023. A robust fundraising module served as the foundation for digital fundraising, offering easy handling. It resulted in over 3500 completed transactions in the first month after the launch. The first disaster relief campaign for immediate assistance to the victims of earthquakes in Turkey and Syria was activated quickly and ran smoothly.
A CMS (Content Management System) was implemented for three websites under the same CI/CD (Continuous Integration/Continuous Deployment), with standardized and centrally managed frontend components.
Simplified editorial workflows and intuitive content and media management allow for a broader team of editors to work independently (self-service).
There was an increase in regular donations due to tailored fundraising widgets based on donation purpose and needs.
The average interaction duration increased by 16.4%.
Challenges1. User login / registration for a (mostly) static site.
Although most parts of the website are static, there needed to be a section (on the bergeinsatz.ch website) where users could create accounts and bookings. To achieve that we made use of iframes in which we loaded the CMS. The users would see the login/registration forms inside an iframe (styled to look like the frontend website), and because the CMS and the frontend websites share the same base domain, the cookies were available on both, so that we could show user information data (fetched using GraphQL) like the Login or My Profile links in the header of the frontend website.
2. Booking missions for users.
On the bergeinsatz.ch domains, the users are allowed to book missions. The Mission and Booking data types were built using the Drupal core entity system, which allowed us to easily customise these entities with fields and enabled us to create various reports and listings. Besides these entity types, we also used a node type for storing the data of the farms (which have their full view page in the frontend). In the CMS, editors are allowed to create Mission items and attach them to Farms, and in the frontend the users are allowed to create Bookings that are attached to specific Mission entities.
3. Volunteer notification system testing.
The volunteers which are able to book missions should also get various notifications at different periods in time. This is usually tricky to test in the real world, since you'd have to wait for days / weeks in order to get those notifications. To overcome that, the system provides a test mode for the booking system where a CMS user with administrative rights can set a specific date and time, which will be used as the current date and time. And this date and time applies to all the operations related to bookings (sending notifications, displaying of active / past bookings in the user profile or generating a volunteer certificate).
- No major contributions, just usual collaboration (review and test patches)
Extensive open-source code was used in https://github.com/AmazeeLabs/silverback-mono
In addition, a case study was submitted to Drupal.org detailing the projects and learnings, https://www.drupal.org/case-study/caritas-schweiz-multi-site-relaunch
The backend (CMS) site is hosted on Lagoon, while the frontend (the actual website which is accessible to the end users) is hosted on Netlify. On every deployment (which gets triggered either by pushing code to the prod branch, or manually triggered from the Lagoon UI), the frontend site (which is a Gatsby app) gets fully rebuilt by a Lagoon process and afterwards it gets automatically deployed to Netlify. This is done by an Amazee Labs NPM package called "Publisher": https://github.com/AmazeeLabs/silverback-mono/tree/development/packages…. The same package would