As introduced in Create > Develop and documented in #Development, NROs are welcome to do development on the P4 platform.

The Product team preference would be that offices develop tools relevant and useful to more than one NRO, part of the P4 roadmap / voted by the community and with the CONTRIBUTE Jira label.

We do understand, however, that your office will also do development only for your P4 site, for any number of reasons (your NRO is using a service that no other office uses,  a consultant stuck in 2004 told you to implement a feature that no one else wants, any number of reasons).

You do understand that these changes will modify your site.

In the MoU signed between the Planet 4 product team and your NRO, it reads:

"[..] For every core update, the P4 Development team will perform 
automated testing on every P4 instance, eventual blockings due 
to core plugins will be fixed by the Dev. team, but blockings 
due to local customisation will fall under NRO's responsibility[..]"

and

"[..]Greenpeace XXXX will be responsible for fixing any custom 
code eventually breaking during core product updates or upgrades; [..] "

Things that could break your site:

  • A security issue introduced by your code
  • An aesthetics issue

For example, an NRO changes the header of the site by modifying the child theme. The changes are based on the existing core master-theme. Some time later the p4 project decides to change the header. Quite possibly that change will break the customisation that the NRO did.

At the moment, there is only 1 customization done by an NRO, Greenpeace Netherlands. I have that in my mind, and if I see that we are about to change the core code that they are based on, I will notify them. This though will not be possible when we start having more and more customization.

We are discussing in the team about how we can best help you on maintaining the balance and making sure that your site does not break.

Our current thinking is that each plugin, each theme has its own tests, AND we also have site wide tests. And that those tests are included in the pipeline and are running automatically on all new deployments.

We are designing a number of different testings for a “base” p4 website and including at least 4 different kinds of tests:

The current plan is that once we have done that successfully (We are still investigating about how to put them in the pipeline, where etc for each kind), we will document it as “instructions about how to include tests for your own theme/plugin”.

The idea is that you will have a number of tests on your plugin/theme that will be running each time we are deploying to your site, and will be notifying us (and you), if any changes (from the core or from your plugin/theme) breaks your site. You will have to write those tests together with your customisations and include them in your plugin/theme.

We are not there yet (we are still trying to figure it out), but this is the plan.

We are welcoming your comments (and your expertise!).