With Planet 4, each Greenpeace office will have its own Wordpress instance
As you may have figured by now, Planet 4 will be built on Wordpress. This platform choice led us to explore technical options to figure out how to push Wordpress to its full potential and empower people to act.
One of the most pressing questions was about choosing between a series of individual Wordpress instances or a single one with multiple sites attached to it. In other words, should we opt for a common Wordpress baseline that each Greenpeace office could customize as per their needs or implement a system that would centralize the multiple sites of the organization?
Finally, the steering committee and the project team agreed on a direction of travel: each national or regional office (NRO) will have its own instance of Wordpress. Planet4 will provide a common base theme and a list of pre-selected modules Greenpeace offices can choose from. However, each office will have their own instance of Wordpress, on a shared hosting platform. NROs will then enable and/or customize themes and plugins of that specific instance. To create cohesion and consistency, there will also be shared best practices and common quality assurance processes (keep reading for further details).
Here are the main reasons we’re leaning towards this choice.
Learning from the past
The ancestor of Planet 4, Planet 3, is the CMS that currently propels most of Greenpeace websites. Planet 3’s architecture is monolithic, in the sense that there is a single content management system installation powering multiple websites. This is also called a multi-domain architecture, where each site is recognized and has its content served based on its domain name. Since we have used this architecture for quite some time now, we also know a bit about its disadvantages:
- It reduces flexibility for local customisation: Having multiple domains managed by one installation entails a lot of custom logic to manage different behaviors and answer to special needs of each one of them. As requirements constantly change or evolve for each domain, there’s a constantly increasing amount of custom code being written to handle them. This means more conditional statements and therefore a potential loss of performance due to more code being executed at each load for every domain.
- It generates technical debt in the long run: More custom logic implies more code complexity, inherently creating technical debt and increasing maintenance costs. As the code base grows, so does the probability for these special cases to overlap. It becomes more difficult to maintain the overall stability. This has a direct impact on development cycles: when more edge cases needs to be considered and tested, fewer features are being shipped.
- It is harder for newcomers to collaborate: if you want to add new features you will still need to make sure you do not break someone else’s custom domain configuration. You will therefore need to understand other domain configurations and customization to build your own. This tends to lead to having a strong centralized team rather than a highly distributed one.
- It sets the basis for single points of failure: Series of custom code written for the needs of specific domains could be introducing vulnerabilities (or performance issues) which, if escalated, would directly impact all the other domains. In case of a major breach, basically, all domains hosted on the CMS could be harmed at the same time.
Into the future
With Planet 4, the objective is to rethink entirely the way Greenpeace works with Content Management Systems to build flexible, secure and engaging platforms. Starting from the known issues mentioned above, the discussions we had and the inputs we received from the community gave us valuable insights about what the ideal architecture may look like, and how we should get there:
Flexibility over control
National and regional offices should be able to independently choose the components of their websites, extend them or even develop new ones if they want to. Instances from around the world should not be limited to pre-provided features. Colleagues should be able to develop new ideas without restrictions — other than the respect of code standards and security boundaries.
Offices should be able to take risks if they decide to do so, and this should not impact other offices. Flexibility does not mean no rules, though. To compensate for these risks, we will define quality criteria to be met when customizing, to define boundaries and scope of Global IT support.
Distribution over centralization
The Planet 4 architecture should reflect our organizational model: fulfilling a common goal through a distributed execution. Hence, at a technical level too, our offices should be able to move autonomously. Greenpeace websites should be technically independent from each other, and yet share common components to create economy of scale. Everyone will have, however, to follow the same processes when it comes to quality control and user acceptance testing, in order for the global support body to function properly and effectively.
Bottom-up over top-down
No matter how out of the box ideas might be, offices should be able to move fast with their implementation without depending on a single vendor. We already said that Planet 4 will be built using an agile methodology and developed iteratively through a trial and error approach. The ideal scenario is to have this methodology implemented at office level, to get local teams to be able to address technical challenges fast and autonomously. These pools of experts will be at the center of the Planet 4 community of practitioners.
Communities over individuals
Whereas offices with more technological know-how are fine to “walk with their feet”, there are other NROs which may struggle with resources and capacity to build, deploy or even maintain their websites on their own. Such offices will be able to use a vanilla installation of Planet4, with a set of templates and modules they can choose from to create their site(s). If they stick to such defaults, they will not technically be building, deploying, customizing their own site, as such baseline will be part of the globally supported solution.
As emerged from internal Focus Groups, most offices still want to maintain a strong common visual identity baseline. The above-mentioned P4 vanilla site theme, from which each instance will be created, will ensure visual cohesion between the sites.
The offices with more capacity are willing to share back common components, so that the whole Planet 4 community can benefit from them. This approach will shape how we will work together across Greenpeace, empowering the P4 practitioners’ community to promote the sharing of best practices, knowledge, ideas and, ultimately, stimulate innovation.
Open Source over secretive
Greenpeace is shifting from being secretive to open and share even more with the broader movement. We want to do that at a technical level too. We want to try new approaches, innovate and even fail a few times. Whatever the results will be, we will share what we’ve done with the broader Wordpress community: contributions, features, new modules, automated tests, security vulnerability reports, lessons learned and ideas.
The choice: a series of Planet 4 individual instances
Given all these considerations, the project team believes that the monolithic, multi-domain approach is not what Planet 4 needs. In that purpose the proposal to start prototyping for a new greenpeace.org built around individual Wordpress instances has been submitted to (and approved by) the project Steering Committee.
While this approach may change depending on the design concept outcomes (that are due next month), it is more efficient to focus the technical exploration on the most likely and desirable scenario.
Some collaboration proposals have already been covered in a technical post of the Discovery phase. To maintain a high-quality codebase throughout Planet 4 instances, the documentation, communication and training processes will have to be standard, constant and smooth. All Wordpress modules will have to go through the P4 module selection and review process before being integrated into the Planet 4 module repository.
Obviously this approach still raises a lot of questions. We will publish more information in the following weeks about how this all works together. For example how will we keep all these sites up to date? How will content be shared across NROs working on the same campaigns together? How will offices be able to enable/disable plugins on individual sites? How can one build a child theme and still receive updates from the master theme? There are many other questions, known and unknown, that we will need to address.
We will maintain a series of FAQs on the Individual VS multi-site choice, so don’t hesitate to comment directly in the document, tweet your thoughts at #GPP4 or simply shout below.
