CiviCRM Community Forums (archive)

Classes are being loaded in 4.5.beta3 by packages/vendor/composer/ClassLoader.php but this doesn't respect Custom PHP as set by the 'customPHPPathDir' configuration parameter.

ClassLoader.php gets its directories from packages/vendor/composer/autoload_namespaces.php which contains ...

<?php

// autoload_namespaces.php @generated by Composer

$vendorDir = dirname(dirname(__FILE__));
$baseDir = dirname($vendorDir);

return array(
    'Symfony\\Component\\EventDispatcher\\' => array($vendorDir . '/symfony/event-dispatcher'),
    'Symfony\\Component\\DependencyInjection\\' => array($vendorDir . '/symfony/dependency-injection'),
    'Psr\\Log\\' => array($vendorDir . '/psr/log'),
    'Civi\\' => array($baseDir . '/..', $baseDir . '/tests/phpunit'),
    'CRM_' => array($baseDir . '/..'),
);

If I edit the last line to be ...

    'CRM_' => array('/my/custom/php/directory', $baseDir . '/..'),
);

... then my custom code is found.

We need to either revert to loading classes the old way, or changing this to respect 'customPHPPathDir'. I also wonder whether this breaks extensions etc that (for better or worse) override class names that are part of Core.

Created issue CRM-15081

PR: https://github.com/civicrm/civicrm-packages/pull/71

I suspect it's an intentional design decision that composer does not to facilitate runtime class-overrides. (Or, put another way, I don't think many folks in the broader PHP community would lift a finger to preserve that anti-pattern.) But we should maintain compatibility with existing overrides.

The PR tells composer to skip autoloading of CRM_* classes -- so the old autoloader (which supports overrides) will handle CRM_*, and the new autoloader (from composer, which doesn't support them) will handle new classes (e.g. Symfony\* and Civi\*).