User tests: Successful: Unsuccessful:
Allow the $config
param to continue to work from the JFactory::getApplication() function or the legacy JApplication::getInstance() function.
JApplicationCms has a $config
param in the constructor but not in the getInstance()
function. This PR adds that support in and stops the config from being immediately overwritten when the app is initalised. Note that the config (from JFactory::getConfig()
still takes priority over anything initialised in the app's constructor however.
For testing instructions see the tracker item
Description | <p>Allow the $config param to continue to work from the JFactory::getApplication() function or the legacy JApplication::getInstance() function</p> | ⇒ | <p>Allow the $config param to continue to work from the JFactory::getApplication() function or the legacy JApplication::getInstance() function</p> <p><a href="https://github.com/mbabker" class="user-mention">@mbabker</a> you were the master mind behind the conversion from the old JApplication - I dunno if there was any reason this wasn't done before?</p> |
Labels |
Added:
?
?
|
I only create a new JRegistry instance if we get passed in an array (as was the standard for the legacy JApplication and JFactory()). As JRegistry is typehinted we can't just pass the array in
I understand the reason for creating a new JRegistry. It's not ideal but makes sense. One more tester?
Tested and works great. Can be merged.
Status | New | ⇒ | Closed |
Closed_Date | 0000-00-00 00:00:00 | ⇒ | 2014-06-23 15:56:56 |
Don't create a new JRegistry instance here. The application constructors handle creating it if it's null, just add the param.
As for why, I honestly don't remember.