phpList Development

For the complete list of phpList development links, including repositories, documentation, and more, see the development infrastructure page. See also the development environment setup guide.

You can use Docker if you wish, to create a working phpList on your local system from source, for development purposes.

phpList uses coding standards to keep code uniform and consistent with best practice. Your contributions should adhere to these also.

phpList 3 includes many custom functions to make adding new features easier. These include functions for getting and setting message data, for example. A comprehensive list with documentation of these functions exists in the Function index.

Please sign the Contributor License Agreement (CLA) via GitHub to make managing the legal aspects of the phpList codebase simpler. It is only required once and takes just a few seconds.

Currently it seems to fail on Firefox. If you get an error, please use Chrome instead. We will try to find the cause.

Alternatively sign and send the CLA to us by email or post.

phpList uses both Behat and phpUnit for automated testing.

Guidelines for running and writing user acceptance tests with Behat can be found in testing documentation of the phpList 3 repository.

These tests are automatically executed by Travis.

phpUnit tests for phpList 4 use a custom configuration documented in the phpList 4 documentation folder.

phpList includes a powerful plugin framework for extending application functionality. Most aspects of phpList's behaviour can be changed via a broad range of plugin hooks. See the comprehensive guide to writing a plugin. A directory of existing plugins exists on the Plugins page.

Unlike contributions to the phpList core applications, plugins can use a variety of different copyright licenses, so long as they are compatible with the license of phpList.

To facilitate development of phpList, core code, themes and plugins, you can now set up phpList in docker and work with your local code.

Upcoming releases are tracked on the GitHub. Issues are assigned to 'target versions', which can be a fixed version number (e.g. 4.0.1) or a meta version (e.g. 'Next patch'). Hard numbers represent that the issue needs to be included in a specific release, whereas meta versions represent issues that would be 'nice to have' in the next release of a given type (e.g. patch, minor, or major).