Skip to content
Textpattern plugin cache extender
Branch: master
Clone or download
Fetching latest commit…
Cannot retrieve the latest commit at this time.
Type Name Latest commit message Commit time
Failed to load latest commit information.



Packagist | Twitter | Donate

Loads Textpattern plugins from project and Composer’s vendor directories. Unlike the default plugin cache feature, rah_blobin supports all the features expected from a plugin that was normally installed from a compiled package; Plugin-lifecycle callbacks, installers, uninstallers, updaters, activators, option panels, load order configuration, translation files, load types, and require and include statements.

Rah_blobin works by creating stub loader plugins for each plugin in the project or the PSR-0 compliant vendor directory. These loaders then reference the source files, loading the assets from static source files as a normal plugin. What Textpattern sees is just a normal plugin, a plugin that is fully supported and can use any of the features plugins have in their arsenal. These plugins can also be managed and disabled from the native Plugins panel.


Using Composer:

$ composer.phar require rah/rah_blobin


Rah_blobin allows you to enjoy both the advantages of plugin cache directory and the power, easiness and compatibility of normally installed plugin package. It allows you to directly edit and modify source files, put the plugins under a version control system, like git or SVN, or handle installation through package and dependency managers, like Composer.


Rah_blobin uses and supports the manifest.json plugin source structure. The manifest.json is a structure used and compiled by MassPlugCompiler. The essential part of how rah_blobin works is the manifest file, manifest.json. This meta file describes what the plugin is and how it’s structured, the stub loader is then build upon that, reflecting all the attributes defined in the manifest files.


Finding plugins from the project directory

Rah_blobin picks up plugins from the project directory recursively. This means it supports nested and deep file structures, which also allows it to support Composer’s vendor directory and PSR-0 structures. It finds plugins by searching for manifest.json files. Any directory where it finds one is considered as a plugin.

Processing files and creating a loader

After it has found the manifest.json files, it processes and parses the contents. It constructs the plugin using the manifest file and collects the source and translation file references it needs. It then writes a loader plugin to the database based on that information. Each plugin will get its own loader, containing all the meta information the plugin would contain after it was installed normally from a package. The difference compared to a normal plugin, is that instead of it copying source code to the database, it references the source files. This means that you can edit the source files themselves and changes will reflect instantly.

Plugin-lifecycle, updaters and installers

Updaters and installers are run when the version number in the manifest.json file is changed. This may change in the future to every import run task.

Disabling and uninstalling plugins

Plugins can be disabled from Textpattern’s own Plugins panel. Uninstalling can be done by adding uninstall property to the manifest file, or by uninstalling the plugin normally from the Plugins panel and then deleting its source directory from your projects directory.


  • Textpattern 4.6.0-dev.
You can’t perform that action at this time.