[4.2] Deprecate getting the router by the app and introduce a service

[laoneo]

Pull Request for pr's #36562, #36629, #36631.

Summary of Changes

As discussed in #36631. It would be better to get the router from a service. Additionally the getRouter function in applications do become deprecated.

A second step would be to turn the language plugin into a service provider plugin and inject the router there. The same goes for the finder extension and the applications.

ping @nibra and @wilsonge

Testing Instructions

• Create an article
• Create a blog menu item
• Enable the language filter plugin
• Open the front end

Actual result BEFORE applying this Pull Request

All is working.

Expected result AFTER applying this Pull Request

All is working.

[Fedik]

I would not deprecate it, Web APP still should have it, like it have a Document.
Just add ServiceProvider, and if someone need a specific Router he will pick it from there (like in Route::link()).

Another thing, introducing SiteRouterInterface looks a bit not-intuitive to me, what purpose of it?
I would expect then AdministratorRouterInterface, ApiRouterInterface, CliRouterInterface etc

[joeforjoomla]

I would not deprecate it, Web APP still should have it, like it have a Document. Just add ServiceProvider, and if someone need a specific Router he will pick it from there (like in Route::link()).

I agree. Just like Document, Session, etc for consistency it should not be deprecated. Otherwise everything should be deprecated. App still should have everything as a shortcut to the container.

[BPBlueprint]

I have tested this item ✅ successfully on 51cfca4

---

_{This comment was created with the J!Tracker Application at issues.joomla.org/tracker/joomla-cms/36688.}

[dgrammatiko]

I have tested this item ✅ successfully on f6908c0

---

_{This comment was created with the J!Tracker Application at issues.joomla.org/tracker/joomla-cms/36688.}

[laoneo]

rtc

---

_{This comment was created with the J!Tracker Application at issues.joomla.org/tracker/joomla-cms/36688.}

[roland-d]

@laoneo This requires another test after the new commit.

@BPBlueprint Could you redo your test again?

[laoneo]

@roland-d all I did was adding a try/catch block around, nothing more f6908c0

[roland-d]

Thanks everybody.

[joeforjoomla]

Pinging @laoneo

Actually this PR is not fully b/c and reliable, given than:

Factory::getContainer()->get('SiteRouter'):

is not the same than:

$this->app::getRouter('Site');

I've noticed that they are 2 separate and different instances of the SiteRouter class.

So given for example that the Joomla core uses the container: Factory::getContainer()->get('SiteRouter'):
but a system plugin still uses $this->app::getRouter('Site'); to attach some build/parse rules:

$router->attachParseRule ( array (
		$this,
		'preProcessParseRule'
), \Joomla\CMS\Router\Router::PROCESS_BEFORE );

The result will be that the preProcessParseRule function of this plugin will never be called.

This implication has potential drawbacks, not sure how it can be solved other than update the code of all extensions to the new container to work on the same instance of the router class.

[laoneo]

There is an alias missing for the old class names. Can you give #37381 test?