A list of currently used 3rdparty plugins and a policy for future selections
You can access the list of Plugins of your P4 instance from your Admin Dashboard > Plugins.
Installation and updates of plugins is happening via the composer scripts. All the plugins that are present in all installations are defined in the common composer file. Additionally, plugins that are installed only on a specific P4 site is defined in the composer file for that site. For example, Loco Translate is only installed on the handbook site, and is defined in the handbook composer file.
Open source plugins are being pulled from wpackagist.org. To add a plugin, you have to find the correct wpackagist record, copy the line and insert it in the composer file as the loco translate example above.
The philosophy of adding plugins to a Planet 4 website can be summarized in the following:
- WordPress is not inherently unsafe. The vast majority of security or incompatibility issues on WordPress sites come from badly written or not maintained plugins.
We have described a process that should be followed every time a plugin is considered to be included in Planet 4:
- 1.Decide on the features you want
- 2.Investigate if these can be done by WordPress core
- 3.If not, investigate what 3rd party plugins exist, and a do a functional fit analysis
- 5.Install them locally or on a test/dev site and do a thorough testing (using both automatic testing and manual testing) to see if they create problems in other areas of Planet 4.
- 6.Get them installed on the relevant site, by having them being added to the relevant composer file.
This is a collection of best practices we gathered through the years of developing Planet 4 themes and plugins. Reach out to the Planet 4 team if you need more help with any of these topics.
Planet 4 is an Open Source project and all the themes and plugins being developed by us should also be. Publishing the code on Github is not enough. All repositories should include a
LICENSEfile, indicating which Open Source license is being used for that particular repository.
When initially creating the repository, Github also prompts you to pick one and if you do it will add this LICENSE file in the repository.
Open Source is not just about the license. If you think your plugin can potentially be useful for other NROs or even other organizations, you can also try to code it in a way that doesn't include hardcoded references to your website.
"description": "Provides Planet 4 content blocks",
All Planet 4 specific repositories should be prefixed with
planet4-, the NRO abbreviation (eg.
gpca-) and its Wordpress function (eg.
Then you just add the name that best describes what it does (eg.
If you are developing a plugin that can be used by the wider Wordpress community, you can instead prefix it with
Most of our repositories use the Github Flow git branch workflow. In practice that means that we start from one
mainbranch that reflects the current state of development which can be deployed in a dev environment.
Any new feature is being developer in a new branch that is being merged to
mainwhen is completed. A new tag is being create when the code is considered stable enough to be deployed in production.
Easy cloning posts and pages, including the ability to rewrite & republish.
Planet 4 has no SEO plugin installed or recommended. SEO plugins do a lot of things, some of which are not even things that should be done (eg. trying to "trick" Google into thinking that a page is something different than it is).
Our choice of operation is not "There is a plugin, let’s install it and see what it does", but “We need feature A, let’s find the best way to deliver its functionality”.