Contributing code

    Here’s what the contribution process looks like in brief:

    1. Fork our GitHub repository,
    2. Work locally and push your changes to your repository.
    3. When you feel your code is good enough for inclusion, send us a pull request.

    See the How to contribute a patch how-to document for a walk-through of this process.

    If you’re interested in developing a new feature for the CMS, it is recommended that you first discuss it on the mailing list so as not to do any work that will not get merged in anyway.

    • Code will be reviewed and tested by at least one core developer, preferably by several. Other community members are welcome to give feedback.
    • Code must be tested. Your pull request should include unit-tests (that cover the piece of code you’re submitting, obviously)
    • Documentation should reflect your changes if relevant. There is nothing worse than invalid documentation.

    Since we’re hosted on GitHub, django CMS uses git as a version control system.

    The is very well written and will get you started on using git and GitHub in a jiffy. It is an invaluable resource for newbies and old timers alike.

    Python

    We try to conform to as much as possible. A few highlights:

    • Indentation should be exactly 4 spaces. Not 2, not 6, not 8. 4. Also, tabs are evil.
    • We try (loosely) to keep the line length at 79 characters. Generally the rule is “it should look good in a terminal-base editor” (eg vim), but we try not be too inflexible about it.

    HTML, CSS and JavaScript

    As of django CMS 3.2, we are using the same guidelines as described in

    Frontend code should be formatted for readability. If in doubt, follow existing examples, or ask.

    JS Linting

    Or you can also run the watcher by just running .

    This is how you fix a bug or add a feature:

    1. us on GitHub.
    2. Checkout your fork.
    3. Hack hack hack, test test test, commit commit commit, test again.
    4. Push to your fork.
    5. Open a pull request.

    And at any point in that process, you can add: discuss discuss discuss, because it’s always useful for everyone to pass ideas around and look at things together.

    Running and writing tests is really important: a pull request that lowers our testing coverage will only be accepted with a very good reason; bug-fixing patches must demonstrate the bug with a test to avoid regressions and to check that the fix works.

    We have an IRC channel, our email list, and of course the code reviews mechanism on GitHub - do use them.

    If you don’t have an IRC client, you can join our IRC channel using the KiwiIRC web client, which works pretty well.

    Important

    When we refer to the frontend here, we only mean the frontend of django CMS’s admin/editor interface.

    In order to be able to work with the frontend tooling contributing to the django CMS you need to have the following dependencies installed:

    We use for our styles. The files are located within cms/static/cms/sass and can be compiled using the libsass implementation of Sass compiler through .

    In order to compile the stylesheets you need to run this command from the repo root:

    While developing it is also possible to run a watcher that compiles Sass files on change:

    By default, source maps are not included in the compiled files. In order to turn them on while developing just add the --debug option:

    We are using gulp-iconfont to generate icon web fonts into . This also creates _iconography.scss within cms/static/cms/sass/components which adds all the icon classes and ultimately compiles to CSS.

    In order to compile the web font you need to run:

    This simply takes all SVGs within cms/static/cms/fonts/src and embeds them into the web font. All classes will be automatically added to as previously mentioned.

    JavaScript files are split up for easier development, but in the end they are bundled together and minified to decrease amount of requests made and improve performance. In order to do that we use the gulp task runner, where bundle command is available. We use for bundling JavaScript files. Configuration for each bundle are stored inside the and their respective entry points. CMS exposes only one global variable, named CMS. If you want to use JavaScript code provided by CMS in external applications, you can only use bundles distributed by CMS, not the source modules.