A modern CMS based on WordPress
Clone or download
Pull request Compare This branch is 1127 commits ahead, 1369 commits behind WordPress:master.
Fetching latest commit…
Cannot retrieve the latest commit at this time.
Type Name Latest commit message Commit time
Failed to load latest commit information.
src We do not use same db_versioning structure which make this remove cal… Jan 19, 2019
tests Adjust rest api category tests to the fact there is no default category Jan 19, 2019
tools ungutenberg for #149. Leave some APIs which are likely to be used in … Dec 11, 2018
.editorconfig Build: Switch package.json to using tabs for indents. Oct 22, 2018
.gitignore branding in .gtiignore Jan 8, 2019
.jshintrc General: Remove `.jshintrc` and `*.json` from the 2-space-indent `.ed… Oct 12, 2017
.nvmrc Build/Test: Update dependencies for 5.0 Oct 9, 2018
.travis.yml remove unsupported php versions from travis and slack notifications Jan 16, 2019
Gruntfile.js Resolve leftover merge issues Dec 9, 2018
README.md Typos, punctuation, grammer fix Nov 1, 2018
composer.json Build/Tools: Add PHPCS to the 5.0 branch. Oct 22, 2018
composer.lock Build/Tools: Add PHPCS to the 5.0 branch. Oct 22, 2018
jsdoc.conf.json Docs: Add jsdoc.conf.json JSDOC configuration file. Sep 11, 2017
package-lock.json Post WordPress 5.0.3 version bump. Jan 9, 2019
package.json Post WordPress 5.0.3 version bump. Jan 9, 2019
phpcs.xml.dist Build/Tools: Add PHPCS to the 5.0 branch. Oct 22, 2018
phpunit.xml.dist REST API: Introduce Autosaves controller and endpoint. Oct 19, 2018
webpack.config.js Build Tools: Add non-minified `@WordPress` scripts to the build output. Nov 12, 2018
wp-cli.yml Remove debug mode from WP-CLI by default, as it now outputs too much … Nov 28, 2015
wp-config-sample.php Lightly clean up and improve inline documentation in wp-config-sample… May 10, 2015
wp-tests-config-sample.php Database: Restore numbered placeholders in `wpdb::prepare()`. Oct 31, 2017



A modern CMS based on WordPress (a.k.a WordPress fork)

You can read more about the "why" on the project's site at https://calmpress.org and follow news on the blog https://blog.calmpress.org

Getting a "ready to use" code

It might come as a surprise to some, but GitHub has bandwidth limits and in order to avoid running into such a corner, all of the distributions will be done from our site. Right now you can get them from the downloads page at https://calmpress.org/downloads/

Installation instructions

Same as the WordPress "5 minutes" installations.

Converting from WordPress

calmPress strives to be as DB and API compatible to WordPress as possible, therefore a conversion from WordPress to calmPress should not involve more than pointing to the same DB, probably by copying the wp-config.php, and copying the wp-content directory.

Themes and plugins written for WordPress should work "as is", where "work" in this context is that they will not suffer any kind of PHP level error, although if they are targeting some niche functionality that is being deprecated like trackbacks, they might not be able to do anything meaningful.


In general this kind of project always has a need for non technical contribution. For example, the project needs a nicer logo, and some proofreading.

Reporting issues, whether they are "bugs" or feature requests, is a great way to contribute. A few things to keep in mind

  • We use the term "bug" to describe a situation in which a feature being developed is not working correctly. Once the feature is shipped in a release, any further modifications are "feature requests"
  • Suggestions on improving current implementation in terms of text, UX, or code structure are very welcome (as long as they will not cause regressions ;) )
  • For "new" user facing features you should have a convincing argument as to why more than 30% of the users will be interested to use it
  • If you are interested in making a case for deprecating a feature, you should prove it has an inherent security, privacy or performance problem that can not be fixed, or that the feature is not used.
  • Code contributions are welcome in the form of PR. Still better to open an issue first to be sure that the suggested development fits with the "values" and technical direction the project would like to have.
  • If you are contributing code, it should use the WordPress coding standards as much as possible.


You will need to install NPM's grunt to run a build.

All source code is located under the /src directory, and the grunt/build process builds a "distribution" into the /build directory.

Branches and tags

Since we inherit WordPress's GIT structure with all its branches and tags, we use a cp/ pefix to identify tags and branches which are unique to the calmPress code.