Development is open and available to any member of the Mautic community. All fixes and improvements are done through pull requests to the code. This code is open source and publicly available.
If you think that you have found a security vulnerability, please email email@example.com with as much detail as possible. The core team will review the vulnerability and if found applicable, will create the patch in a private repository. The vulnerability will be disclosed once the patch has been included into a release.
Developer documentation is available at https://developer.mautic.org. To add additions or corrects to the documentation, submit Issues or Pull Requests against https://github.com/mautic/developer-documentation.
Pull Requests with additional features should be created with the Mautic Product Roadmap goals in consideration. Any features that are created for core that don’t follow the overall goals of the project may not be included.
In addition to following the general direction of the development goals, the pull request code must be well-formed following coding standards and guidelines. If you wish to target a specific release version number for the feature, its best to make the pull request early so any feedback from the core team can be implemented and adequate testing can be performed.
Features that are determined not to fit within the direction of the Mautic Core goals are more than welcome to be created as plugins instead.
You will need to sign the Mautic Contributors Agreement in order to contribute code to Mautic (which can be done online)
All code styling is handled automatically by the aforementioned git hook. If you setup git hook correctly (which is true if you ever run
composer update before creating a pull request), you can format your code as you like - it will be converted to Mautic code style automatically.
All code contributions should include adequate and appropriate unit tests using PHPUnit and/or Symfony functional tests. Pull Requests without these tests will not be merged. See below for more extensive information on Automated Tests.
When creating a new Pull Request, the description template should be filled appropriately in detail. Any Pull Request that does not have an appropriate description will not be considered for merge.
Each new feature should include a reference to a pull request in our End User Documentation repository or Developer Documentation repository if applicable. Any enhancements or bugfixes affecting the end-user or developer experience should also be accompanied by a PR updating the relevant resources in the Documentation.
SET GLOBAL innodb_default_row_format=DYNAMIC; SET GLOBAL sql_mode=(SELECT REPLACE(@@sql_mode,'ONLY_FULL_GROUP_BY',''));
cd /var/wwwif your local server root is at /var/www).
git clone https://github.com/mautic/mautic.git)
Each time you update Mautic's source after the initial setup/installation via a new checkout, download, git pull, etc; you will need to clear the cache. To do so, run the following command:
$ cd /your/mautic/directory $ php app/console cache:clear
(Note that if you are accessing Mautic through the dev environment (via index_dev.php), you would need to add
--env=dev to the command).
composer install to ensure new vendors are installed and/or existing upgraded.
Before running these commands, please make a backup of your database.
If updating from a tagged release to a tagged release, schema changes will be included in a migrations file. To apply the changes, run
$ php app/console doctrine:migrations:migrate
If you are updating to the latest source (remember this is alpha), first run
$ php app/console doctrine:schema:update --dump-sql
This will list out the queries Doctrine wants to execute in order to get the schema up-to-date (no queries are actually executed). Review the queries to ensure there is nothing detrimental to your data. If you have doubts about a query, submit an issue here and we'll verify it.
If you're satisfied with the queries, execute them with
$ php app/console doctrine:schema:update --force
Your schema should now be up-to-date with the source.
Mautic downloaded from GitHub has the development environment. You can access it by adding
index_dev.php after the Mautic URL. Eg.
http://localhost/mautic/index_dev.php/s/. Or in case of CLI commands, add
--env=dev attribute to it.
This development environment will display the PHP errors, warnings and notices directly as the output so you don't have to open the log to see them. It will also load for example translations without cache, so every change you make will be visible without clearing it. The only changes which require clearing the cache are in the
In case of assets like JS, CSS, the source files are loaded instead of concatenated, minified files. This way the changes in those files will be directly visible on refresh. If you'd wanted to see the change in the production environment, you'd have to have run the
app/console mautic:assets:generate command.
In many cases, the CSS files are built from LESS files. To compile the changes in the LESS files, run
grunt compile-less command.
Everyone can test submitted features and bug fixes. No programming skills are required. All you have to do is to follow the steps below.
Every change to Mautic core happens via PRs. Every PR must have 2 successful tests to be merged to the core and released in the next version. Testing a PR is a great way to move Mautic forward and personally improve its quality and stability.
rm -rf app/cache/*or
app/console cache:clear -e dev).
Before executing unit tests, copy the
.env.dist file to
.env then update to reflect your local environment configuration.
Running functional tests without setting the .env file with a different database will result in the configured database being overwritten.
To run the entire test suite:
bin/phpunit --bootstrap vendor/autoload.php --configuration app/phpunit.xml.dist
To run tests for a specific bundle:
bin/phpunit --bootstrap vendor/autoload.php --configuration app/phpunit.xml.dist --filter EmailBundle
To run a specific test:
bin/phpunit --bootstrap vendor/autoload.php --configuration app/phpunit.xml.dist --filter "/::testVariantEmailWeightsAreAppropriateForMultipleContacts( .*)?$/" Mautic\EmailBundle\Tests\EmailModelTest app/bundles/EmailBundle/Tests/Model/EmailModelTest.php
If you plan on running the acceptance test suite, you'll need to have the Selenium Server Standalone installed and the Chrome WebDriver available locally.
If you're on a Mac and you use Homebrew, you can install Selenium by running
brew install selenium-server-standalone.
You'll also need to download the latest Chrome WebDriver.
Unzip and move the
chromedriver file to
Once you have Selenium installed and the WebDriver available at the specified location, open and modify the plist file found at
<dict><array> block under
ProgramArguments, add the following after the line containing
... <string>-Dwebdriver.chrome.driver=/usr/local/Cellar/selenium-server-standalone/drivers/chromedriver</string> ...
With that completed, you may now start the Selenium server using
brew services start selenium-server-standalone.
Follow the standard installation procedure for Selenium server standalone. Ensure that you have the chrome driver available, and startup the server with the following command:
java -jar -Dwebdriver.chrome.driver=/path/to/chromedriver /full/path/to/selenium-server-standalone.3.x.x.jar
All test suites can be executed by running
bin/codecept run from the project root. Optionally, you can specify running just the
unit test suites by adding one of those words after the
Mautic uses PHPSTAN for some of its parts during continuous integration tests. If you want to test your specific contribution locally, install PHPSTAN globally with
composer global require phpstan/phpstan-shim.
Mautic cannot have PHPSTAN as its dev dependency, because it requires PHP7+. To run analysis on a specific bundle, run
~/.composer/vendor/phpstan/phpstan-shim/phpstan.phar analyse app/bundles/*Bundle
Found errors? Think you can improve this documentation? edit this page