Joomla Cms Laravel Package

Getting Started

• Install the CMS, not a library. joomla/joomla-cms is the full CMS monorepo. Fastest path is usually a release package or:

  composer create-project joomla/joomla-cms my-site
  # then run the CLI installer (Joomla 4/5+)
  php installation/joomla.php install
  

  From a git clone, run composer install first and point the document root at the repo root; the installer lives under /installation.
• First places to read: administrator/components/ (back-end extensions), components/ (front-end extensions), modules/, plugins/, templates/, libraries/src/ (the Joomla\CMS framework), and api/components/ for Web Services endpoints.
• First useful exercise: build a template override, then a tiny module. An override (templates/<your-template>/html/com_content/article/default.php) teaches you the output layer without touching core. A module (mod_hello/mod_hello.php + tmpl/default.php + mod_hello.xml) teaches the manifest, install, and rendering lifecycle in under an hour.
• First real use case: a custom system plugin to hook application events, or a small component with a list/edit view using Joomla's MVC bases. Both are representative of daily extension work and force you through manifest, language files, ACL, and routing.
• Tooling: enable Global Configuration → System → Debug and the Debug plugin; logs land in administrator/logs/. Use the in-built Web Services (/api/index.php/v1/...) if you need to integrate external systems rather than writing new controllers.

Implementation Patterns

• Extension anatomy is the unit of work. A component is components/com_foo/ plus administrator/components/com_foo/, an entry point, a services/provider.php DI registration, MVC classes, and tmpl/ views. Modules are entry script + tmpl/; plugins are event subscribers; templates are layout/override packages.
• Modern namespaced extensions (Joomla 4+). Put classes under your own namespace and PSR-4 autoload them via the manifest:

  <namespace path="src">Vendor\Component\Foo</namespace>
  

  Register services in services/provider.php using Joomla\CMS\Extension\Service\Provider\... and the component's BootableExtensionInterface. Avoid loading files manually.
• Use the DI container, not globals.

  $app = \Joomla\CMS\Factory::getApplication();
  $db  = \Joomla\CMS\Factory::getContainer()->get(\Joomla\Database\DatabaseInterface::class);
  

  Inject dependencies into controllers/models/views through the container and constructor arguments where possible.
• MVC pattern. Extend BaseController, BaseModel, HtmlView (or JsonView for APIs). Keep business logic in models, formatting in views, request validation in controllers. Use FormModel + XML forms in models/forms/ for consistent filtering, validation, and ACL-aware field rendering.
• Events over hard coupling. Implement Joomla\Event\SubscriberInterface and register in the plugin entry point:

  $dispatcher->addSubscriber(new MyPlugin($app));
  

  Common hooks: onAfterInitialise, onAfterRoute, onAfterDispatch, onContentPrepare, onContentBeforeSave, onUserAfterLogin. Dispatch custom events for your own extensibility.
• Database access with the query builder. Always use $db->getQuery(true) and #__ prefixes; never concatenate table names. Use prepared statements / quoteName to keep queries portable and safe:

  $query = $db->getQuery(true)
      ->select($db->quoteName(['id', 'title']))
      ->from($db->quoteName('#__content'))
      ->where($db->quoteName('state') . ' = 1');
  

• ACL is data, not code. Define asset rules in access.xml, create them on install via script.php (#__assets), and gate controllers/views with $user->authorise('core.edit', 'com_foo'). Use $app->checkToken() / Session::checkToken('post') on every state-changing request.
• com_ajax for lightweight endpoints. For small JSON/AJAX handlers, a module or plugin registered as com_ajax is often faster than a new component:

  index.php?option=com_ajax&module=foo&format=json
  

  You still get framework bootstrapping, ACL, and output formatting for free.
• Overrides first, forks never. Template overrides and plugin events are the extension surface. If you must change core behavior, prefer a plugin reacting to an event, or a template override, over patching libraries/.
• Custom fields and form XML. Extend content types with plugins/fields/*; reuse the Form API (Joomla\CMS\Form\Form) for consistent validation, filtering, and layout. This keeps admin UX native.
• CLI and scheduler. Register console commands via services/provider.php with ConsoleApplication and Joomla\Console\Command\AbstractCommand. Joomla 4.1+ also has plg_system_scheduler for cron-like job definitions — good for recurring imports/syncs.
• Package and deploy. Ship extensions as signed zips with an update.xml and a <server> entry so the native updater can handle upgrades. Use Joomla's build/ tooling for release packages; keep install scripts (script.php) idempotent for migrations.
• Tests. Unit tests live under tests/Unit (PHPUnit); system/acceptance tests use Codeception + Selenium. For your own extension, mirror this structure and mock Factory::getApplication() and the database.

Gotchas and Tips

• Do not edit core. Updates overwrite it, and the GPL-2.0 monorepo assumes extensions are separately licensed packages. Overrides and plugins are the supported extension points; treat libraries/ and administrator/components/com_* as read-only.
• Cache bites constantly. Joomla caches pages, modules, and the internal cache groups. After config or code changes, clear System → Clear Cache, purge the template cache, and re-test with caching disabled. Debugging "my change isn't showing" is almost always cache or an opcode cache.
• CSRF tokens. Missing checkToken() or a stale token produces a 403 with little detail. Include HTMLHelper::_('form.token') in forms and check it server-side. Same for AJAX: pass the token and verify in the handler.
• Manifest XML is silently strict. A malformed or incomplete manifest.xml can install "successfully" while registering nothing. Validate against the Joomla schema, confirm <namespace> and <autoload> entries, and check #__extensions after install.
• Asset/ACL setup happens at install time. If script.php didn't run or rules weren't inserted into #__assets, permissions behave oddly. Re-check the asset tree on update, not just install.
• Language files are mandatory, not cosmetic. Use Text::_('COM_FOO_...') and ship language/en-GB/en-GB.com_foo.ini plus .sys.ini. Missing strings show the raw key and look broken in admin.
• Version and deprecation churn. Joomla 4 removed many J* legacy classes; 5.x continues namespacing and drops deprecated APIs. Pin your target Joomla version in composer.json/manifest <targetplatform>, and test against the next major before release. The project ships frequent minor releases, so follow the release notes rather than assuming LTS stability.
• SEF/routing surprises. Component routers (router.php) and menu-item aliases interact; test with SEF enabled and disabled. Missing router logic yields ?option=com_foo&view=... URLs that break menus and canonical links.
• Database portability. Use the query builder and #__ prefix; MySQL-specific SQL will fail on PostgreSQL. Check date/time handling against the configured timezone (Factory::getConfig()->get('offset')).
• Output escaping and input filtering. Use htmlspecialchars / HTMLHelper::_('string.truncate') and InputFilter rather than trusting request data. Joomla's filter defaults differ by context, so be explicit with $app->getInput()->get('x', '', 'cmd').
• Debugging aids. JDEBUG, the Debug plugin's query/deprecation panels, $app->enqueueMessage(), and Monolog under administrator/logs/ are your first stops. var_dump in an HTML view is noisy — use the JSON view or log channel.
• File permissions and paths. tmp/ and administrator/logs/ must be writable; configuration.php should be read-only in production. Bad permissions cause confusing upload, cache, and install failures.
• com_ajax requires a published module/plugin and the correct module/plugin parameter; unpublished means a flat 404. It's a frequent "endpoint disappeared" cause.
• Testing environment is non-trivial. System tests need a live site, Selenium, and a database. Budget time for CI infrastructure if you plan automated acceptance tests; PHPUnit-only tests are much cheaper.
• Composer in Joomla is nuanced. The CMS ships its own vendor/; adding third-party PHP dependencies means managing autoload paths and version conflicts with Joomla's libraries/vendor. Keep extension dependencies isolated, and check composer.json constraints before adding large libraries.