The P4 development team always expected that several of the features of Planet 4 could not be served by existing 3rd party plugins, and custom development would be needed. 

This page contains all you need to develop the tool. Please read it after the Technology intro (hosting, coding and releasing)

 

 

Nro Developers starting point: Start here

WordPress core, 3rd party plugins and custom development

If your NRO is thinking of developing custom features or using 3rd party plugins, please first make sure that you verify the following aspects (in this specific order):

    1. Make sure the functionality you want does not exist in Core WP (for example user creation, page creation, etc.)
    2. If not, then consider a 3rd party plugin (only if they pass our functional and code standards testing)
    3. If none of the options above offer the functionality you require, then opt for custom development and keep reading 

If your investigation (see  Planet 4 – WordPress initial modules review and selection process ) leads you to choose with our own custom development, it will be either because the existing products do not offer the same functionality, or because their coding standards (or maintainability) is not good.

In these cases, we either offer different functionality (so we do not compete), or we offer a better maintained plugin, that adheres to WP coding standards.

It is never recommended to modify the WordPress core. Please read why you should not do it here.

 


Build and maintain a 3rd party plugin

The effort to build and maintain 3rd party plugins depends on multiple things. Some of the basic factors are:

    1. We are going to try to fulfil other users’ (except GPs) wishes for its future development (aka, if we are going to try to serve the community) or if we are going to make it exactly the way we want it, and just leave it for others to clone and modify if it serves their needs.
    2. If the 3rd part plugin has parts appearing in the front end, then such parts need to be checked for compatibility with the rest of the parts that interact with the front end. They need to interact with templates and may break easily if they are not compatible with the 3rd party plugin

Coming to time and how much it would take to build a new plugin, the minimum requirement would be : “As much time is needed in order for it to fulfil only GP’s needs”. 

Please keep in mind that any plugin you create will live in github and therefore will be open source. That means that whoever else wants to do things similar to what we do (or even build a whole website identical to ours) will be able to clone our code.

 


Skills required

Good PHP and Front-end developer skills are required to do custom development for P4. The idea is to build a team with exactly these deliverables in mind: a team that can build good 3rd party plugins (these skills are not easily available in the open market). 

 

 


Consistency between coding standards

Our plan is to do custom development that would adhere to the same standards that we are expecting from any 3rd party plugins that we choose. Below is an excerpt from how we check other’s code (and by extension, how we are going to do a code review of our own code):

Code quality, standards and best practices

 

We should check here that the PHP code follows WordPress’ code standards and best practices.

Additionally, for our own developed custom plugins, we would also expect that the code checks out against PSRs (1,2,4) http://www.php-fig.org/psr/  .

(one of the tools to do that: PHP_CodeSniffer https://github.com/squizlabs/PHP_CodeSniffer )

 

 


Code security

These steps must be followed to ensure code security:

  1. During our recruitment, we presented our developers with a piece of code and asked them to identify errors or problems or bad practices. Those problems included security issues. We do not hire people who cannot identify the security issues.
  2. We will be doing peer code review on a daily basis. No code will be shipped without a second set of eyes looking at it. 
  3. We have contracted and set up the usage of a service for static php code analysis: (company: https://www.ripstech.com/, our own implementation: https://saas.gc.ripstech.com/main/dashboard )
  4. All our developers will have allocated time to study methodologies regarding secure coding. For example the OWASP developers’ guide: https://www.owasp.org/index.php/OWASP_Secure_Coding_Practices_-_Quick_Reference_Guide  and WP plugins security with regard to WordPress plugin security methodologies.

 

 


Branching workflow

The branching workflow used for P4 development is the Gitflow.

This was a decision made by the whole dev team for the initial period, and to be reviewed if needed later.

 

 


Creation of themes methodology

In order to create a new theme, the following methodology must be followed:

  1. Bootstrap 4 as a UI framework
  2. Twig/Timber as the template engine
  3. Bower for managing front-end dependencies
  4. SCSS as the preprocessor

 


Theming tools

For theming tools, the team investigated Gantry, in line with our requirements. We also communicated with Gantry developers and presented them with our requirements. We decided that even though it provides good advantages, it is not appropriate for our project right now. It would add an extra layer of complication to the features we need to deliver for the prototype and that delay cannot be justified.

 


Timber autoescaping

The strategy used for escaping fields on the front end is done by Timber autoescaping :

Implementation:

 

  • Timber::$autoescape = true; should be added to the top of functions.php near where the otherTimber class properties are set. This enables automatic escaping of all fields that are output using {{ double braces }} and provides significant security hardening.
  • Fields which need to output raw HTML should be piped through raw. Example for the post body content:
  • {{ {{post.post_conten|raw}}
  • Fields which need to output potentially untrusted HTML should be piped through a filtering function as well as raw. Example for a post meta field value:
  • {{ post.custom_field_key|e(‘wp_kses_post’)|raw }}
  • Fields which need all HTML stripped should be piped through one of Twig’s built-in filters. Example for a post meta field value:
  • {{ post.custom_field_key|striptags }}

 


Links & Resources

#Development

DEV: Git best practices

Learn more
#Development #Setup

DEV: prepare for a new release (version) of Planet 4

How to do a release, given that we have websites on two different environments (VM and K8s).

Learn more
#Development

DEV: NRO developers starting point

So, you are a developer tasked to do customization to a specific P4 site. Welcome. Start from here 🙂

Learn more
#Development #Setup

DEV: Planet4 & ElasticSearch

Learn the ElasticSearch technology, and how Planet4 uses it.

Learn more
#Development #Engagement

DEV: Contribute to P4

A quick guide to devs and open sourcers for contributing to Planet 4!

Learn more
#Development #Visuals

DEV: Automated Visual Regression testing with BackstopJS

Quickly identify changes that alter a website’s appearance after each release performing visual regression testing with BackstopJS.

Learn more
#Data-Analytics #Development #Engagement #Setup

Create and track donation pages

Set up P4-alike donation pages and connect them to your payment gateway!

Learn more
#Administer #Content #Development

DEV: Sync your Production environment into your staging and develop environments

Sync P4 Production->Staging and Production->Develop websites!

Learn more
#Development #Setup

DEV: Add a new plugin in only one NRO site

3 steps to add a plugin for only ONE NRO website

Learn more
#Content #Development #Engagement #Setup

Create Engaging Networks Petitions with P4 Style

Set up P4-alike petitions with your advocacy tool (Engaging Networks..)

Learn more
#Development

DEV: See your code in the develop site

Want to see and demo your changes to the develop site before pushing them to release or production? Here’s how

Learn more
#Development #Setup

DEV: Setting up multilingual plugin

Once installed, the WPML plugin needs the right setup for your P4 language to be shown. Here’s how.

Learn more
#Development #Visuals

DEV: perform Visual Regression Testing on local dev environment

To catch css regression bugs we use use BackstopJS. learn how to compare visual changes, test regressions and verify changes.

Learn more
#Development

DEV: Trigger an update of your develop site via CircleCI

Commits to the develop branch of your P4 child theme will trigger an update of your develop site. Here’s how…

Learn more
#Development

DEV: Publish a theme/plugin with packagist.org

For Composer to pick up the plugins and themes we create, we want them to be published in a composer…

Learn more
#Administer #Development #Engagement #Setup

Integrate P4 with other Engagement Systems

Put P4 at the centre of your engagement systems suite (or satellites?!?).

Learn more
#Case Study #Development #Setup

DEV: Customize the P4 Child Theme

Change P4 styling or functionality at child theme level, customizing css or markup template.

Learn more