There are multiple ways in xautoload to register namespaces for 3rd party code.

A good idea is to look at xautoload.api.php, which is usually more up to date than this documentation page.

Direct registration (not recommended)

The most straightforward one direct registration:

function hook_{boot|init|..}() {
  // PSR-0
  xautoload()->finder->addPsr0($namespace, $dir);
}

The problem here is that you need to decide from where you do the registration.
You could do it from hook_boot() or hook_init(), but is that early enough?

Also, can you be sure that xautoload is installed and on the correct version? Otherwise you might see a WSOD..

Recommended: Using hook_xautoload()

Documentation moved here.

Support for Libraries API

Documentation moved here.

Class map discovery

Documentation moved here

Support for composer libraries?

If you are planning to pull in Composer libraries for your Drupal 7 modules, you should definitely have a look at Composer manager. This allows to automatically download the required Composer libraries, and it will generate an autoload.php. All of that completely without xautoload.

This being said, there are some ways that xautoload can help out with Composer libraries.

First, the XAutoload ClassFinder has registration methods very similar to those of Composer's ClassLoader.

Secondly, the ClassFinderAdapter classes in xautoload, that are passed into hook_xautoload() and friends have some convenience methods that are designed both for raw downloaded Composer libraries, and for Composer directories where Composer has already downloaded the dependencies and generated an autoload.php file.

// Parse the raw composer.json provided by a Composer package for autoload information. This will even trigger a scan for classmap generation, if the "classmap" setting is used.
$adapter->composerJson('path/to/composer.json');
// Scan a directory for Composer-generated autoload files.
$adapter->composerDir('[..]/vendor/composer');

What xautoload can't do is to download Composer packages. This is what other modules are for.

Also, the composerDir() and composerJson() currently have one limitation: If you have an "composer/include_paths.php" / or "composer/autoload_files.php" with composerDir(), or $json['include-path'] or $json['autoload']['files'] in composer.json, then these will have no effect on requests where xautoload is cached.

See #2299265: Composer include paths and include files have no effect if xautoload is cached., and chime in if you have a thought!

Comments

darth_revan43@yahoo.com’s picture

What exactly do I write in my custom module to call the hook_xautoload()? I don't understand.

donquixote’s picture

Do you know how Drupal hooks work?

donquixote’s picture

To clarify: You don't actively call your hook implementation, you wait for your hook implementation to be called.

cconrad’s picture

xautoload_InjectedAPI_hookXautoload->namespaceRoot is marked as deprecated, what's the new recommended method?

donquixote’s picture

Sorry, I was not subscribed to comments on this page.

I updated the documentation, you can use Composer-style add() (alias addPsr0()), addPsr4(), etc. For more methods, look into http://cgit.drupalcode.org/xautoload/tree/src/Adapter?h=7.x-5.x. "LocalDirectoryAdapter" is the one that is passed into hook_xautoload().

Ok, to be honest, it is still an xautoload_InjectedAPI_hookXautoload object for BC reasons, but this is now a subclass of LocalDirectoryAdapter.