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)  .

(one of the tools to do that: 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:, our own implementation: )
  4. All our developers will have allocated time to study methodologies regarding secure coding. For example the OWASP developers’ 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 :



  • 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