PHPackages                             monolyth/mural - PHPackages - PHPackages  [Skip to content](#main-content)[PHPackages](/)[Directory](/)[Categories](/categories)[Trending](/trending)[Leaderboard](/leaderboard)[Changelog](/changelog)[Analyze](/analyze)[Collections](/collections)[Log in](/login)[Sign up](/register)

1. [Directory](/)
2. /
3. [Utility & Helpers](/categories/utility)
4. /
5. monolyth/mural

AbandonedLibrary[Utility & Helpers](/categories/utility)

monolyth/mural
==============

MUltiple "Resource" AutoLoader

0.3.0(9y ago)01.3kMITPHPPHP >=5.3

Since Jun 20Pushed 9y ago1 watchersCompare

[ Source](https://github.com/monolyth-php/mural)[ Packagist](https://packagist.org/packages/monolyth/mural)[ RSS](/packages/monolyth-mural/feed)WikiDiscussions master Synced 1mo ago

READMEChangelogDependencies (1)Versions (8)Used By (0)

Mural
=====

[](#mural)

MUltiple "Resource" AutoLoader

Mural is a small package containing a custom autoloader to sanely serve *and*test multiple "apps" (websites, normally) from the same repo, while keeping your shared code base clean.

Installation
------------

[](#installation)

### Composer (recommended)

[](#composer-recommended)

`composer require monolyth/mural`

### Manual

[](#manual)

Clone or download the repo, and make sure the `Monolyth\\Mural` namespace maps to the `src` directory of Mural in your autoloader. Since it's only one file, you could also `require` it manually.

The problem
-----------

[](#the-problem)

Your average small site will have code somewhere (say, `src`) and a public directory with your `index.php` front controller (say, `httpdocs`). Since normally `httpdocs` will only contain static files, you can set your autoloader (e.g. in `composer.json`) to look at `src` and be done with it. The same goes for any external packages.

However, more complicated projects will have multiple public facing paths, with a few project-specific overrides but mostly a bunch of shared code.

One could tailor PHP's `include_path` to automatically include the right code, but this is problematic during testing: you would need a test suite per project (site), since class names would be identical and would trigger a fatal error.

The solution
------------

[](#the-solution)

The Mural autoloader allows you to specifically namespace these overrides, whilst still exposing the "original" names to consuming classes. During testing, simply don't include it and test to your heart's content with the original, fully namespaced (and thus unique) classes. In your application use the "normalised" classnames instead.

WHY $DEITY??? An example
------------------------

[](#why-deity-an-example)

Okay, a bit more clarification. This is actually a real-world example.

Say you have a group of dating sites. Lots of functionality (messaging, profile editing etc.) is shared, but there are some specifics. `straight.com` is aimed at straight people, but `gay.com` is aimed at gay people (duh). Apart from the logo and some other CSS they're identical, except in one important respect: when searching, `straight.com` should only match male <> female results, whereas `gay.com` should only match male <> male or female <> female results. A fictional directory layout might be:

```
/path/to/sites
    /vendor