P4 FAQs

What’s the overall plan for Planet 4?

Planet 4 will ultimately replace more than 40 Planet 3 websites, 9 WordPress websites and 1 Drupal 7 portal. Such commitment to digital upgrade represents a great chance for Greenpeace to lead the way in the nonprofit sector, but also a great responsibility in the months to come. 

The Global Implementation Plan outlines the scope, methodology and roadmap for the product rollout.  

What’s the P4 Roadmap?

Planet 4 was live for the first time at the beginning of 2018 on version 1.0, the improvements made since then can be found in the updates page. Since then, the P4 team is constantly reviewing the roadmap of the features to be developed to achieve the P4 concept and keep improving the product.

You can learn more about the high level roadmap in the Past the Prototype Medium post, and for more details about specific user stories you can check the concept stories document (which represents the breakdown of the Roadmap into epics).

What will my NRO get in replacement of P3?

As described in the Memorandum of Understanding (MoU) – to be signed for every implementation – NROs will receive:

  1. a WordPress code base with themes (a Greenpeace theme and a child theme) and any related plugins and registry + baseline configurations, all upgrades of which will be provided by the P4 Development team;
  2. a list of supported packages and plugins;  
  3. tools to do Continuous Integration and testing (Jenkins);
  4. documentation how NROs can test local P4 instances and local customisations;
  5. hosting in the selected global hosting solution (Google Cloud Compute Engine);
  6. “Out of the box” integration with Engaging Networks as online advocacy and donation tool as a first globally shared system (and baseline for additional integrations in future versions).
  7. “Out of the box” integration with the media library / Orange Logic as Greenpeace global repository of visual assets (images, videos, etc..)

More info in the Technology intro. 

What’s the “co-development” process?

Basically how ideas for features and new functionalities make their way to the core product. More info and full idea list at >> Improving P4

The flowchart explaining how NROs can contribute to the p4 development!

WHAT can we customize / develop ourselves?

Each NRO will have its own P4 install of WordPress, therefore all child themes can be customized by NRO development teams (e.g adoption of plugins, custom designs like this awesome Handbook etc..).

  • KEY INFO >> By signing the Memorandum of Understanding (MoU) each NRO will accept boundaries for local development, which includes P4 policies for code quality and code security, Codebase Rules, Resources to create / develop custom code, methodology (composer + GP registry + github), unit tests, responsibility for fixing custom code and local (non-globally endorsed) engagement systems’ integrations.

Basically, NROs can (and should!) be free to experiment, but must also take responsibility for doing so, without impacting other offices.

In a nutshell: the P4 development team controls the master theme, and the NRO team responsible for their website will be responsible for their own child theme.

More info in the Technology intro. 

Does P4 support multiple themes?

There are going to be parts of P4 that NROs may want to look different, which some offices are currently achieving using different WP themes, like the case of a few digital reports.

Rather than using multiple themes (by adopting plugins like this one), for single pages that may need different layout than the P4 default template, the inclusion of these custom themes in P4 can be solved adopting pages with different presentation. Here’s how:  

  1. NROs develop a page template in individual P4 child themes
  2. Make it look as they want, using css
  3. Select that page template for the content you want to appear like that

The generic approach as described above – “What can we customize / develop ourselves?” – allows NROs to extend P4, by adding their own plugins, templates or themes, but as we have said, this comes with certain understandings (see above).

Need more info? Contact the P4 Project team

WHERE can we customize / develop?

Each NRO will have its own Development, Staging and Production websites. The dev site is used for developers to test and showcase new code before it is ready to be pushed to production.

This dev website is not meant to substitute the local development environment for developers. Developers still need to have a local development environment where they will be doing development.

Local devs will be able to develop on their own machines, downloading P4 from github https://github.com/greenpeace/planet4-base and https://github.com/greenpeace/planet4-master-theme.   

More info in the Technology intro. 

How much P4 costs?

The P4 software is free. NROs, however, will have to sustain costs for project teams and software-services related to P4, specifically:  

What resources my NRO needs to implement P4?

To implement P4, NROs must allocate at the very least the resources, described more in details in the P4 implementation – Work plan + ALL NROs RASCI:

IMPORTANT >> All estimates are expressed with these ratios:

Why should my NRO take P4 and not another CMS?

Planet 4 is Greenpeace International’s proposed tool to replace Planet 3, which will get decommissioned by mid-2019. Like all globally endorsed systems, offices adopting P4 will benefit of:

Some NROs already replaced P3 with new institutional websites, they just couldn’t cope with P3 anymore. Being part of a distributed, federated organization, each NRO is free to adopt any non globally endorsed software tool, but won’t be able to benefit from the above-mentioned advantages.

Why is GPI driving only 6 implementations and not all of them?

To maximise effectiveness and deploy 30+ website in one year. GPI will not impose slots to NROs for launching P4, but facilitate the transitions for offices who are more willing or able to go first.

The first 6 P4 implementations will be key to build implementation capacity and fine-tune the process, all the following ones will simply have to go through the ‘industrialized” deployment process. Smoothly, effectively and on time.

More details on the Full Implementation Plan.

What is the difference between “Early” and “Regular” adopters?

The first 6 implementing offices (or “Early Adopters”) will get P4 before the others, but at the same time do extra efforts in supporting the GPI team to document the process, track efforts and report back, experiment bug fixes of the core tool and shape the P4 community of practice. The reasons behind the choice of these offices rather than others are detailed in the implementation plan.

All other offices (or “Regular Adopters”) will get the product later, but benefit from the experience of both Early Adopters and GPI team. Using this awesome Handbook, NROs will be able to start preparatory work independently and at their own pace, before the P4 Development team will actually come in and deploy the product in scheduled “setup queues”, organized in bi-weekly sprints. The Handbook is still under development, but (as anything in this project) it’s of course publicly accessible – https://planet4.greenpeace.org/

More details on the Full Implementation Plan.

Do I really need a staging site?

A staging site is an independent environment with the same characteristics of your production environment. This environment is mainly created to test plugins, themes, custom code and creation of content. The reason why is so important to test your content on staging before production is because our platform is an engagement platform where we deal with volunteers and donors who have graciously trust us by giving us some of their personal information.

Providing information online is a lot less personal, and we need to build trust with our users to make them feel comfortable and secure while using our site. We build trust by having a fully functional website so its very important for our visitors to see that things are working correctly. That is why we need a staging site, to ensure things will work correctly before going live in production without interfering with the end user experience.  

Can I use my staging site as a development environment?

It is not recommended to use your staging environment as your development environment for many reasons. One of them is that staging is where the final testing takes place before releasing to production and if you use it as your development environment and start committing code there, it will interfere with the testing of the version about to be released to production.

Also, it can confuse users creating content if they see different features or broken features on staging that are not available in production yet, remember content editor will have access to staging and might not be aware of the work the developers are doing. Additionally, the staging environment picks up its code from a specific git branch which is not supposed to be directly edited in the git workflow we are using.

The only way to override that would be to ssh directly to the server, and even then, your changes would be overwritten on any server update. The staging environment was not build with development in mind. Development should happen on your local environment.

Can I get my staging environment before deployment phase?

This is a common question NROs might ask when they get to a point in the preparatory phase where they want to have their staging site to start playing with it and creating content there. The creation of the staging site is a task that correspond to the deployment phase and we highly recommend to stick to the tasks corresponding to each implementation phase.

Each phase (preparatory, deployment and go live) has been planned in a way that allows GPI development team resources to have capacity to perform each task needed for the implementation of each NRO and fully focus on it. If we start requesting dev team resources when it is not planned to do so, we will be taking resources from other NROs’ implementations. Please read following question and if after reading you still decide you want to have a staging environment earlier there are a few things you should be aware of:

Can I draft my content directly on staging instead of doing it first in Google Docs?

The reason why is suggested to create content in a Google Document first before creating it on staging is to allows people to focus more on the essence of the content and prevent it from being distracted by other aspects of it like the layout or styling. Creating content in a Google Doc also opens room for discussion, reviewing, commenting and overall better drafting and editing for your new content.

Planet 4 is an innovative platform that follows different workflows for creating content and navigating through the site than Planet 3. This could cause confusion in the user who has not taken an editor or admin training of the site (this training takes place in the deployment phase) and might cause you more distraction and waste of time.

It is also worth mentioning that once starting the deployment phase and getting your staging environment you will have 4 more weeks to work on it and create content there.

Why are we not able to push content from Staging to Production?

It might seem easier to have a script to migrate content from staging to production instead of creating content manually again in production. The reason why we don’t suggest this is because staging is the site where we will explore, test, break, and create dummy content to learn more about the platform.

A migration script will also migrate by default all this dummy content created which is unuseful content we don’t want to have in production. A clean up of the staging content will then be required to migrate content from there to production. From experience, we’ve seen it takes the same amount of time to do a clean up of your staging site than copying and pasting manually your new content in production.

Also the migration script will not always create the content exactly the same as in staging, there are always edge cases where content migration goes wrong and you’ll have to fix these issues manually, which will also take you more time. Creating content manually in production will help you develop your web master skills and build the confidence needed for working on production.

What about multilingual websites?

WordPress allows multilingual portals, and the GPI team is investigating how P4 will support multilingual websites, both from an architecture and content point of view. Two of the “Early Adopters” are multilingual NROs (India and Canada), therefore a solid solution (or more than one?) will be proposed within the next few months.  

More info on set up a multi-lingual P4.

What about security?

P4 has (and will have) very few plugins, all of which must pass security review, so the plugin repository will be both slim and globally approved.

As part of the implementation, Akismet will be implemented as the anti-spam standard, HTTPS as the security protocol and a valid SSL (Secure Sockets Layer) certification will be activated once the production site will go live in Akamai.

On a more general approach, Global IT is always on top of the global standards, and for P4 will always follow them, adding a constant double code-review for every integration of code. Once the Login feature will be available, for example, the solution will have to follow IAM (Identity Access Management) global standards to ensure our supporters’ data are 100% safe, whether an office is under GDPR (General Data Protection Regulation) or not.    

More info on P4 Plugins and Tech intro.

Who is using P4?

By the end of 2019, Planet 4 will be deployed in more than 30 countries and across 20 Greenpeace National and Regional Offices (NROs).

Here’s a regularly updated snapshot of the product deployment. Is your NRO live with P4? Time to join the community!

P4 adoption map. Countries represent local Greenpeace websites (e.g. Brazil = greenpeace.org/brasil)

Links & Resources