The MODX Development Process

MODX CMS is an Open Source PHP CMS first released in March 2005. Powering millions of websites globally, MODX has a reputation for speed, security and for being the most flexible, customizable CMS in existence (we call this creative freedom).

We’ve tried a variety of ways and tools to manage and run the project, including CVS, Subversion, Jira, Redmine, Forums, Community Advisors, and more. The following are the tactical ways and tools we use to create and release software.

Security Reports & Bounties

MODX is committed to providing a secure and reliable platform for its users. We welcome anyone to share any impactful issues and the techniques used to exploit them with us. We’re happy to work with you to resolve the issue promptly. We strongly recommend not sharing any known vulnerabilities with the general public and instead, responsibly disclose them by filing an issue via our security reporting form:

https://modx.com/community/report-a-security-issue

While we have no formal reward program, for impactful issues and at our election we may be able to offer a token rewarded for your discovery.

After you submit your issue there, the MODX Security Team will be notified of the issue, begin an investigation, and will contact you once they have resolved the issue for confirmation.

Types of exploits that are explicitly excluded from consideration include social engineering, SPF/DKIM/DMARC records, SSL ciphers, issues exploitable only through Self-XSS, clickjacking and issues only exploitable through clickjacking, HTTP 404 codes/pages or other HTTP non-200 codes/pages, disclosure of known public files or directories (e.g. robots.txt), CSRF on forms that are available to anonymous users (e.g. the contact form), logout CRSF, browser autocomplete/save password issues, descriptive error messages (e.g., stack traces), and brute force/DoS/DDoS attacks.

Semantic Versioning

Our releases follow semantic versioning conventions, or “semver”. In general, patch releases (2.6.1, 2.6.2, etc.) are for bug fixes between minor releases (2.7, 2.8, 2.9) which receive new features and APIs. Patch versions and minor releases should work and are generally considered straightforward change without breaking things. Major releases (2.0, 3.0, 4.0) are where breaking changes happen and typically requires effort to migrate data or upgrade between major releases.

Release Cadence

We strive for 1-2 minor releases a year, patch releases when needed, and major releases every 2-3 years. This provides periods of stability that correpsond to many typical website re-development or overhaul cycles, without too much frequency to be disruptive. We focus on solving customer problems and providing pragmatic solutions, not chasing the latest fads that may not be sustainable in the long run. (See our Software Philosophy)

Supported Software Versions

Once a major release occurs (e.g., 3.0), the previous major release will be frozen at its then-current minor release. We will continue releasing security patches and critical bug fixes that can result in data loss until the subsequent major release occurs (e.g., 4.0), but there will not be any new features backported.

Source Code Repository

All our source code is located at https://github.com/modxcms

This helps us keep things running smoothly with tracking issues, planning releases, doing builds, automating tests, managing releases, and more.

All it takes to participate in code reviews and reporting issues is a free Github account. If you’re reading this doc, you likely already have one.

Bug Reports & Feature Requests

Bugs and Feature Requests should be reported to the respective repository at MODX’s Github Account. There are dozens of Open Source projects hosted there, including Extras, MODX Revolution (our main project), and xPDO (our data abstraction that extends PDO).

MODX uses a report template for issues. It’s critical that this is filled out completely to ensure the issues can be reproduced and fixed in as timely a manner as possible.

Issues are typically closed by someone creating a Pull Request which resolves the issue or implements requested features. This can be a Community member, someone on the integration team, or anyone with a Github account that wishes to participate.

Occasionally an integrator or collaborator will close issues/feature requests for a few reasons: they cannot be reproduced, they are not in scope (like an Extra bug reported at the Revo repository), they are not something that will be done (see our Software Philosophy), or they’re really old reports that may or may not be applicable, or discussions have stalled out. Closed issues can always be re-opened, so we hope you don’t take closures for these reasons personally.