- Can I install visavi/rotor with composer require in an existing Laravel app?
- No. Rotor is not a Composer library you can pull into an existing application; it ships as a Laravel 13 and PHP 8.3+ application skeleton, a modular monolith with a modules/ plugin convention and a built-in admin surface. Integration means adopting the platform or federating with it over HTTP, not running composer require. Plan for a fork you own and track upstream.
- What Laravel and PHP versions does Rotor require?
- Rotor runs on PHP 8.3 or newer and targets Laravel 13. Because it is an application skeleton rather than a package, the framework version is tied to whatever the skeleton ships in a given release. Check the repository for the exact constraints of the version you plan to deploy before scheduling upgrades.
- How do I create a custom module in Rotor?
- Use the built-in generator: php artisan make:module Name --model=Item --admin --api. Copying a neighbouring module directory is documented as a bad shortcut because you lose translations, changelog entries, and model registration. Each module owns its own tables, routes, views, translations, and settings screen.
- How do module migrations work in Rotor?
- Module migrations are artisan-visible: php artisan module:migrate applies pending migrations for enabled modules and resets the settings cache. The bundled deploy.php runs it immediately after artisan:migrate, so it can be part of your normal deploy pipeline. Rollback for module migrations is still missing, so take backups before schema changes.
- Why did my contact form and outbound email stop working after upgrading Rotor?
- Feedback and MailNotify were extracted from core into catalog modules. If you upgrade without installing them, outbound mail silently stops and the contact form disappears. This is feature loss by omission rather than an error, so add those modules to every upgrade checklist.
- Can I reuse Rotor's forum, blog, or gallery modules in an existing Laravel application?
- Generally no. Modules assume ownership of their tables, routes, views, translations, and settings screen, and they do not compose into another application's aggregate. Rotor fits a community or content site built on the platform itself. Grafting forum, blog, or gallery capability into an existing domain model remains the expensive option.
- Are Rotor's hooks and theme partials stable between releases?
- Neither is a stable contract. The homepageView hook was removed in favour of Registry::homepage() only one minor release after hooks were recommended over core edits, and theme partials were renamed with a data-dialog attribute for native dialog support. Any theme work you commission inherits a rename obligation per release.
- Does Rotor expose an API I can rely on for external clients?
- Yes, but the API is per-module and unversioned, with no contract stability guarantee for federated clients. Recent releases added endpoints such as GET /api/comments and structured vote error codes, while tightening ?user= to require a token and return 403 for guests. Build clients defensively and expect breaking changes in minor releases.
- What hosting environment does Rotor target in production?
- It targets shared hosting rather than container orchestrators. The presence of cron.php for path-only cron hosts and hideable admin warnings points to that deployment model, which is useful for capacity planning even if you do not use it. The frontend builds with Vite and Bootstrap utilities.
- How much upgrade churn should I expect when maintaining a Rotor site?
- Expect frequent minor releases that push features out of core into modules, rename hooks and theme partials, and move the API surface in both directions. Some risks do retire, such as the strict_types TypeError fix, theme-less error pages, and the removal of spatie/laravel-ignition. Budget ongoing upgrade work as part of owning your fork.