Modern Dev Workflow

SuiteCRM 7 was built before modern PHP tooling matured, but it is fully compatible with Composer, Git-based workflows, and PSR-4 autoloading for custom code. This page describes the recommended approach.

Composer

SuiteCRM ships with its own composer.json and a vendored vendor/ directory. You can use Composer to manage dependencies for your custom modules without affecting the core.

Adding a dependency to a custom extension

Do not modify the root composer.json — it is owned by SuiteCRM core and will be overwritten on upgrade. Instead, place a separate composer.json inside your custom module and require it from your extension’s entry point:

# Inside your custom module directory
cd custom/modules/MyModule/
composer init
composer require vendor/some-library

Then require your module’s own autoloader at the top of your main file:

<?php
if (!defined('sugarEntry') || !sugarEntry) die('Not A Valid Entry Point');
require_once __DIR__ . '/vendor/autoload.php';

Running Composer on the core

When you need to update core dependencies (e.g. after pulling a new release):

composer install --no-dev --optimize-autoloader

Always run composer install (not update) when deploying, to ensure the composer.lock is honoured.

Git Workflow

What to version control

In a SuiteCRM project, commit only the files you own. A typical .gitignore for a SuiteCRM development repository should exclude:

# SuiteCRM generated/cached files
cache/
config.php
suitecrm.log

# Installed vendor code
vendor/

# Uploaded files
upload/

Track your customisations under custom/, your module packages, and any deployment scripts.

Branching strategy

A simple feature-branch workflow works well:

  1. Create a feature branch from main (or master).

  2. Develop and test on a dedicated development instance.

  3. Open a Pull Request / Merge Request for review.

  4. On merge, deploy to staging, run a Quick Repair and Rebuild, and verify.

  5. Deploy to production using the same steps.

Never develop directly on a production SuiteCRM instance. Always test on a separate instance first, as metadata changes require a Repair cycle that can briefly take the instance offline.

PSR-4 Autoloading for Custom Code

SuiteCRM’s core loader does not use PSR-4, but you can add PSR-4 autoloading for your own custom classes via Composer.

Setting up autoloading

In your custom module’s composer.json:

{
    "autoload": {
        "psr-4": {
            "MyCompany\\MyModule\\": "src/"
        }
    }
}

Run composer dump-autoload after updating the autoload configuration. Your classes in custom/modules/MyModule/src/ will then be available as \MyCompany\MyModule\ClassName.

Invoking from a Logic Hook

<?php
if (!defined('sugarEntry') || !sugarEntry) die('Not A Valid Entry Point');

require_once 'custom/modules/MyModule/vendor/autoload.php';

use MyCompany\MyModule\SomeService;

class MyModule_LogicHook
{
    public function afterSave($bean, $event, $arguments)
    {
        $service = new SomeService();
        $service->process($bean);
    }
}

Automated Build Tasks with Robo

For automating repetitive tasks (building Sass, running tests, triggering a repair), SuiteCRM ships with Robo. See the Automated Tasks section for full details on using and extending Robo within SuiteCRM.

Content is available under GNU Free Documentation License 1.3 or later unless otherwise noted.