[4.0] Set the cli as global app#16540
Conversation
|
WIll reopen when ready. |
…onvert # Conflicts: # libraries/src/CMS/Service/Provider/Session.php
| * | ||
| * @since 11.1 | ||
| * @since 11.1 | ||
| * @deprecated 5.0 Load the app trough the container |
includes/app.php
Outdated
|
|
||
| // Instantiate the application. | ||
| $app = JFactory::getApplication('site'); | ||
| $app = JFactory::getContainer()->get('SiteApplication'); |
There was a problem hiding this comment.
I think this and AdministratorApplication still need to run through JFactory::getApplication otherwise we're going to end up with the JApplicationCms::$instance being empty right?
There was a problem hiding this comment.
This has to be reverted back otherwise none of the singletons will be populated. JFactory::$application and the JApplicationCms instances container.
There was a problem hiding this comment.
Can we not set them manually like I did with the cli scripts?
There was a problem hiding this comment.
You can set JFactory::$application manually, but without Reflection, you can't set JApplicationCms::$instances.
There was a problem hiding this comment.
I will revert that change and do it then in a new pr.
build/helpTOC.php
Outdated
|
|
||
| // JSON encode the file and write it to JPATH_ADMINISTRATOR/help/en-GB/toc.json | ||
| file_put_contents(JPATH_ADMINISTRATOR . '/help/en-GB/toc.json', json_encode($toc)); | ||
| file_put_contents(JPATH_ADMINISTRATOR . '/help/toc.json', json_encode($toc)); |
There was a problem hiding this comment.
Why are we removing en-GB here?
There was a problem hiding this comment.
As this folder doesn't exist, either we remove it or create it. But like it is now it crashes.
There was a problem hiding this comment.
It's supposed to exist - https://github.com/joomla/joomla-cms/tree/staging/administrator/help/en-GB - probably something that needs to be worked on from the Mediawiki PR.
There was a problem hiding this comment.
Looks like i accidently deleted it :/ oops. 98cef84#diff-41ac6b5cb48181a44ad59de73a6fc4dd
| $dispatcher = $container->get('Joomla\Event\DispatcherInterface'); | ||
| $dispatcher->addListener('onAfterSessionStart', array(JFactory::getApplication(), 'afterSessionStart')); | ||
|
|
||
| if (JFactory::getApplication() instanceof CMSApplication) |
There was a problem hiding this comment.
Why? If anything this should be a method_exists() check. This needlessly restricts the session service provider.
| { | ||
| $this->app = $app ?: CMSApplication::getInstance('site'); | ||
| $this->menu = $menu ?: $this->app->getMenu(); | ||
| $this->app = $app ?: \JFactory::getApplication(); |
There was a problem hiding this comment.
I know the typehinting here is for the base CMSApplication, but are we certain that there isn't anything buried in the internals of the site router and menu that could cause a problem if the admin application were used in place of the site application?
| if (\JFactory::$document) | ||
| if ($isCli) | ||
| { | ||
| // We're probably in an CLI environment |
There was a problem hiding this comment.
The comment here is actually very misleading, I don't think it even applies anymore. The comment above the if statement is more accurate, so I think the change you made should be reverted.
The intent was to use the document format type if there is already a JDocument instance in JFactory, and if that isn't set to fall back on the format in the request (obviously this part is web specific).
| echo $app->toString(); | ||
|
|
||
| $app->close(0); | ||
| $app->close(0); |
There was a problem hiding this comment.
$app->close() should be called regardless of being a CLI or web app. Or it can be removed completely as we'll hit the return line below and whatever PHP does after calling the uncaught exceptions handler would be performed.
There was a problem hiding this comment.
Then we need to add that function to the CMSApplicationInterface?
There was a problem hiding this comment.
I'm starting to think we can get away with just removing $app->close() completely and just using the return statement a few lines down, regardless of context.
| $this->app = $app ?: CMSApplication::getInstance('site'); | ||
| $this->menu = $menu ?: $this->app->getMenu(); | ||
| $this->app = $app ?: \JFactory::getApplication(); | ||
| $this->menu = $menu ?: $this->app->getContainer()->get(MenuFactoryInterface::class)->createMenu('site', ['app' => $this->app]); |
There was a problem hiding this comment.
Why this change? This just seems like adding complexity for the sake of it, unless you plan on removing getMenu() from the CMSApplication class that was just fine.
There was a problem hiding this comment.
I'm working actually on the cli scripts. Running the indexer from the command line needs the router which needs the site menu.
There was a problem hiding this comment.
The typehinting here is still for the web application class chain, not the interface yet. So it's still wouldn't support a CLI app here anyway.
The next issue is the app interface isn't container aware, so you can't rely on getContainer() being available either.
|
I'v changed all the input from Michael. Can you guys please have a second look? |
| } | ||
|
|
||
| $app->setBody($data); | ||
| if ($isCli) |
There was a problem hiding this comment.
This makes me wonder if setBody and getBody should be in the interface. Thoughts @mbabker
There was a problem hiding this comment.
I wouldn't try finangling it to fit. CLI and web apps handle output differently (CLI with output objects, web with response objects, both different APIs). So this is the best option.
|
This looks largely good. I want Michael's thoughts on the setBody/getBody thing but once we have that and we've solved conflicts I think this is probably good to merge |
…onvert # Conflicts: # libraries/src/CMS/Factory.php # libraries/src/CMS/Router/SiteRouter.php
As we introduced the
CMSApplicationInterfacethe cli apps should act as global applications. This is a followup of #16499 and #16516.Additionally the apps from the controllers are loaded from the container.
DON'T Merge, please!