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)
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):
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.
The effort to build and maintain 3rd party plugins depends on multiple things. Some of the basic factors are:
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.
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).
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 )
These steps must be followed to ensure code security:
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.
In order to create a new theme, the following methodology must be followed:
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.
The strategy used for escaping fields on the front end is done by Timber autoescaping :