@heelc29 - I have done this 3 times too be sure I wasn't reporting incorrectly... but I can't replicate the BEFORE condition..

I have debug mode on, cleared cache every time to be sure etc etc after having deleted lines 100-113 in [joomla-cms/libraries/src/MVC/Model/BaseDatabaseModel.php and the backend loads fine...

On 5.3.0 ßeta 2, PHP 8.3.19, MariaDB 10.6.15 if that matters.

So, what am I doing wrong?

@heelc29 - I have done this 3 times too be sure I wasn't reporting incorrectly... but I can't replicate the BEFORE condition..

I have debug mode on, cleared cache every time to be sure etc etc after having deleted lines 100-113 in [joomla-cms/libraries/src/MVC/Model/BaseDatabaseModel.php and the backend loads fine...

On 5.3.0 ßeta 2, PHP 8.3.19, MariaDB 10.6.15 if that matters.

So, what am I doing wrong?

@exlemor I don't now. I just tried again

Result is still the same

@heelc29 - it appears that the code has evolved and is no longer as the same so I can't test this PR ;(

joomla-cms/libraries/src/MVC/Factory/MVCFactory.php
Lines 170 to 177

 if ($model instanceof DatabaseAwareInterface) { 
     try { 
         $model->setDatabase($this->getDatabase()); 
     } catch (DatabaseNotFoundException $e) { 
         @trigger_error(\sprintf('Database must be set, this will not be caught anymore in 5.0.'), E_USER_DEPRECATED); 
         $model->setDatabase(Factory::getContainer()->get(DatabaseInterface::class)); 
     } 
 }

is not what I have in my file :/

if ($model instanceof DatabaseAwareInterface) {
            try {
                $model->setDatabase($this->getDatabase());
            } catch (DatabaseNotFoundException) {
                @trigger_error('Database must be set, this will not be caught anymore in 5.0.', E_USER_DEPRECATED);
                $model->setDatabase(Factory::getContainer()->get(DatabaseInterface::class));
            }
        }

(I'm on Joomla_5.3.4-dev - built on 23 August 2025 00:29:58 UTC)

it appears that the code has evolved and is no longer as the same so I can't test this PR ;(

@exlemor Sorry, I don't follow. The code from MVCFactory is for informational purposes only and is not part of the test. The differences you describe are also very minor (missing variable in catch, unnecessary sprintf removed). The relevant code for this pull request is in BaseDatabaseModel.

This pull request has been automatically rebased to 5.4-dev.

This pull request has been automatically rebased to 6.1-dev.

Conflicts resolved

This pull request has been automatically rebased to 6.2-dev.

This needs also be documented here.

This pull request has conflicts, please resolve those before we can evaluate the pull request.

I succesfully tested that removing lines 101-114 are deleted from the constructor of BaseDatabaseModel results in the described 500 error, which disappears after DatabaseAwareInterface is added to the implements-list of BaseDatabaseModel. As described above, I think this PR should stick to that, not trying to repair things that would break as a reult of the removal of those lines that was temporarily needed to test this PR.

I have no idea why earlier tests by @exlemor couldn't replicate the situation before this PR. I'm curious what went wrong there.

I succesfully tested that removing lines 101-114 are deleted from the constructor of BaseDatabaseModel results in the described 500 error, which disappears after DatabaseAwareInterface is added to the implements-list of BaseDatabaseModel. As described above, I think this PR should stick to that, not trying to repair things that would break as a reult of the removal of those lines that were temporarily needed to test this PR.

I have no idea why earlier tests by @exlemor couldn't replicate the situation before this PR. I'm curious what went wrong there.

I succesfully tested that removing lines 101-114 from the constructor of BaseDatabaseModel results in the described 500 error, which disappears after DatabaseAwareInterface is added to the implements-list of BaseDatabaseModel. As described above, I think this PR should stick to that, not trying to repair things that would break as a reult of the removal of those lines that were temporarily needed to test this PR.

I have no idea why earlier tests by @exlemor couldn't replicate the situation before this PR. I'm curious what went wrong there.

I succesfully tested that removing lines 101-114 from the constructor of BaseDatabaseModel results in the described 500 error, which disappears after DatabaseAwareInterface is added to the implements-list of BaseDatabaseModel. As described above, I think this PR should stick to that, not trying to repair things that would break as a reult of the removal of those lines that were temporarily needed to test this PR.

I have no idea why earlier tests by @exlemor couldn't replicate the situation before this PR. I'm curious what went wrong there.

This PR is no new feature, but resolving a bug: at the moment the MVCFactory never uses its database to inject it in a model, but the model gets its own database from Factory::getDbo().

I succesfully tested that removing lines 101-114 from the constructor of BaseDatabaseModel results in the described 500 error, which disappears after DatabaseAwareInterface is added to the implements-list of BaseDatabaseModel. As described above, I think this PR should stick to that, not trying to repair things that would break as a reult of the removal of those lines that were temporarily needed to test this PR.

I have no idea why earlier tests by @exlemor couldn't replicate the situation before this PR. I'm curious what went wrong there.

This PR is not a new feature, but resolving a bug: at the moment the MVCFactory never uses its database to inject it in a model, but the model gets its own database from Factory::getDbo().

\Joomla\CMS\Extension\Service\Provider\MVCFactory is not able to get an individual Database from a Component-Container because of:

if ($factory instanceof DatabaseAwareInterface) {
	$factory->setDatabase($container->get(DatabaseInterface::class));
}

in Version 6.2.0. Only the CMS-Database (from parent container) is used.

Adding \Joomla\Database\DatabaseAwareInterface to \Joomla\CMS\MVC\Factory\MVCFactory-Implements resolves the problem in Version 6.2.0. As a workaround in my Components using its own database I use the following code to set the database in provider.php:

		$container->extend(
			MVCFactoryInterface::class,
			function (MVCFactoryInterface $factory, Container $c) {
				$factory->setDatabase($c->get(\Joomla\Database\DatabaseInterface::class));
				return $factory;
			}
		);
```<hr /><sub>This comment was created with the <a href="https://github.com/joomla/jissues">J!Tracker Application</a> at <a href="https://issues.joomla.org/tracker/joomla-cms/45060">issues.joomla.org/tracker/joomla-cms/45060</a>.</sub>

\Joomla\CMS\Extension\Service\Provider\MVCFactory is not able to get an individual Database from a Component-Container because of:

if ($factory instanceof DatabaseAwareInterface) {
	$factory->setDatabase($container->get(DatabaseInterface::class));
}

in Version 6.2.0. Only the CMS-Database (from parent container) is used.

Adding \Joomla\Database\DatabaseAwareInterface to \Joomla\CMS\MVC\Factory\MVCFactory-Implements resolves the problem in Version 6.2.0. As a workaround in my Components using its own database I use the following code to set the database in provider.php:

		$container->extend(
			MVCFactoryInterface::class,
			function (MVCFactoryInterface $factory, Container $c) {
				$factory->setDatabase($c->get(\Joomla\Database\DatabaseInterface::class));
				return $factory;
			}
		);
```<hr /><sub>This comment was created with the <a href="https://github.com/joomla/jissues">J!Tracker Application</a> at <a href="https://issues.joomla.org/tracker/joomla-cms/45060">issues.joomla.org/tracker/joomla-cms/45060</a>.</sub>

For me, there is no need to remove lines 101–114 from the code in \Joomla\CMS\MVC\Model\BaseDatabaseModel before Version 7.x. Because I'm not using 'dbo' in $config.

For me, there is no need to remove lines 101–114 from the code in \Joomla\CMS\MVC\Model\BaseDatabaseModel before Version 7.x. Because I'm not using 'dbo' in $config.

If the database should initialised via \Joomla\CMS\MVC\FactoryMVCFactory->createModel(), then the BaseDatabaseModel class must implement the DatabaseAwareInterface. Currently, the database is initialised in the BaseDatabaseModel constructor. The constructor-code could be restricted to initialisation via $config[“dbo”]:

        $db = \array_key_exists('dbo', $config) ? $config['dbo'] : null;
        if ($db) {
            @trigger_error('Database is not available in constructor in 7.0.', E_USER_DEPRECATED);
            $this->setDatabase($db);

            // Is needed, when models use the deprecated MVC DatabaseAwareTrait, as the trait is overriding the local functions
            $this->setDbo($db);
        }

Actually, you could also read the database directly from the container [MVCFactory->createModel()]:

        if ($model instanceof DatabaseAwareInterface) {
                $model->setDatabase(Factory::getContainer()->get(DatabaseInterface::class));
        }

If you wish to avoid using Factory::getContainer(), the component’s container would need to be available in MVCFactory. However, I’m not quite sure at the moment whether resources (such as the database or the router) should always be read from the container, or whether the container is only passed to the component during initialisation?

If the database should initialised via \Joomla\CMS\MVC\FactoryMVCFactory->createModel(), then the BaseDatabaseModel class must implement the DatabaseAwareInterface. Currently, the database is initialised in the BaseDatabaseModel constructor. The constructor-code could be restricted to initialisation via $config[“dbo”]:

        $db = \array_key_exists('dbo', $config) ? $config['dbo'] : null;
        if ($db) {
            @trigger_error('Database is not available in constructor in 7.0.', E_USER_DEPRECATED);
            $this->setDatabase($db);

            // Is needed, when models use the deprecated MVC DatabaseAwareTrait, as the trait is overriding the local functions
            $this->setDbo($db);
        }

Actually, you could also read the database directly from the container [MVCFactory->createModel()]:

        if ($model instanceof DatabaseAwareInterface) {
                $model->setDatabase(Factory::getContainer()->get(DatabaseInterface::class));
        }

If you wish to avoid using Factory::getContainer(), the component’s container would need to be available in MVCFactory. However, I’m not quite sure at the moment whether resources (such as the database or the router) should always be read from the container, or whether the container is only passed to the component during initialisation?

This pull request has been automatically rebased to 6.3-dev. Joomla! 6.2 is now in feature freeze.