Artifact 05b438f2398694592d578cf862fd85f9f9f4dca3:

Wiki page [AUTOLOADER_UPDATE] by mario 2014-02-13 17:35:16.

---

D 2014-02-13T17:35:16.244
L AUTOLOADER_UPDATE
N text/x-markdown
P 86c05822ddf105dc46095febae138b16012f8c9a
U mario
W 1648
<h3>automatic classmap updating</h3>

The disadvantage of map-based autoloaders is the rebuilding step, at least for development.

While the [update](wiki/update) is undeniably easy, it's also redundant with the built-in automatic updating on missed identifier lookups.

You can declare a locally-installed shared.phar autoloader to update itself on undefined and unlocalizable classes (= newly added code).


### .htaccess

With

    SetEnv AUTOLOADER_UPDATE 1

in your .htaccess you can trigger the auto update run.


### In code

Or just override it prior inclusion of the autoloader: 

    $_SERVER["AUTOLOADER_UPDATE"] = TRUE;
    include_once("./vendor/shared.phar");


### Adapt the stub

Some installations may wish to update the `shared.phar`s stub itself.

It contains a setting:

        // Try to rebuild map on missing identifiers.
        public $auto_update = 0;

Which could be predeclared to `1` obviously.

This requires unpacking and repacking the phar or its stub just once.


### Global vs. local install

The global `/usr/share/php/shared.phar` will not typically auto-update (non-writable). While an alongside activated local `./vendor/shared.phar` may.

You may then wish to instantiate the local loader last however; else the rebuilding attempt will trigger on each invocation where globally-installed classes are requested first.


### Deployment

If you upload `shared.phar` together with the class repository beneath it, the contained map with its relative paths will continue to work. Unless the phar is writable (e.g. suexec setups) the automatic updates won't run.


Z 0f5e18ca6dd4f1fc064ae59bfb2d54aa