ModuleTools: the shared toolbox every XOOPS 2.8.0 module now gets for freeIf you have ever built a XOOPS module, you know the ritual. Copy a
class/Common/ folder from the last module. Paste in the install helpers, the version checks, the admin table code, the confirmation dialog, the breadcrumb builder. Fix the namespace. Hope nothing drifted since the last copy.
With XOOPS 2.8, that ritual is over.
ModuleTools ships inside XOOPS 2.8.0 Core as
Xoops\ModuleTools\*, autoloaded on every request. There is nothing to install, nothing to activate, and no helper module to keep in sync. Your module just calls it.
What is in the boxModuleTools is the successor to the mTools helper module, rebuilt as a proper library. It gathers the services modules used to carry as copied files:
*
Install and update hooks. Directory checks, file checks, dependency and version guards, sample-data buttons, and an update checker that reads your GitHub releases.
*
Admin pages in minutes. Object tables, tree tables, single-record views, CSV export, and a controller that handles create, edit, delete and uploads from one form definition.
*
Objects and forms. A dynamic object base with SEO fields and a form builder that turns your handler's metadata into a ready XoopsThemeForm.
*
Front-end helpers. Breadcrumbs, letter navigation, pagination, text truncation with intact HTML, social bookmarks, syntax highlighting, image resizing.
*
Permissions. Per-item group permissions with a clean gateway, so your module never writes to the permission table by hand.
*
Module lifecycle. A ModuleContext value object for paths, URLs and constants, a namespace autoloader that also understands legacy filenames, and a cloner that turns one module into the starting point for the next.
Why it mattersLess code to own. A typical converted module drops dozens of copied files. Fewer files means fewer places for a bug to hide and fewer places to patch when one is found.
Security fixes land once. When the confirmation dialog or the CSV export is hardened, every module on the site gets the fix on the next Core update. No module release required.
Modern PHP, tested. The library targets PHP 8.4, passes PHPStan at level 6, and ships a growing PHPUnit suite that includes consumer tests run against real modules inside a XOOPS tree.
No migration cliff. Existing modules keep working. ModuleTools registers lazy aliases for the stable
XoopsModules\Mtools\* names, so a module written for the mTools module runs on 2.8 unchanged. When you are ready, the migration guide walks through swapping copied classes for library calls, and a Rector rule set does most of the typing.
Still there for 2.7. Sites on XOOPS 2.7.x keep the separately distributed mTools module with the same class names. Write against the API once and it runs on both.
Getting startedOn XOOPS 2.8 the library is already loaded. In a module, grab your XMF helper and go:
use XmfModuleHelper;
use XoopsModuleToolsModuleModuleContext;
$helper = Helper::getHelper('mymodule');
$ctx = ModuleContext::fromHelper($helper);
$ctx->uploadPath('images');
For standalone development,
composer require xoops/moduletools brings in the same package with its stubs and test suite.
The full walkthrough lives in
docs/getting-started.md, and
docs/migrating-a-module.md covers converting an existing module. Try it on your next module, or on the one you have been meaning to clean up, and let us know what you build.
PACKAGIST: https://packagist.org/packages/xoops/moduletools INSTALLATION: composer require xoops/moduletools
