Details
Bug
Major
Description
The symfony routing component allows us to use the path "/" for routes. Therefore, we should be able to use example.com/app.php/ for controllers. However, this currently does not properly work. The method get_web_root_path incorrectly returns phpbb_root_path. Therefore, paths to images or files are broken.
Activity
/index.php still leads to index. But exactly this is the aim of this patch/ticket.
F.e. portals do not make sense if they are not the landing page.
So we patched it to allow portals to use / only as a route, so the landing page is the portal and links to index.php still work as intended.
in 3.0 .htaccess was modified for this. But as we have routes now, it should be possible via routes.
Also, example.com/app.php doesn't seem to be the same as example.com/ with URL rewriting enabled. example.com/foobar translates to example.com/app.php/foobar but as example.com/ is a valid directory it will not rewrite it with the current rewrite rules.
The idea, however, is for example.com/ to eventually route through app.php, and index.php will be moved into a controller. app.php should eventually become the single point of entry and all paths given (even existing files and directories) should be routed through the routing sytem. I know that that is not the current behavior, but that is what I understand is planned.
Then again, what if e.g. a portal wants to overtake requests to example.com? Do we really want to break that behavior?
Any route defined in an extension is loaded after routes in the core; therefore, any extension route that is the same as a core route should overwrite the core route. So extensions should be able to provide a portal page, but we should require that they also provide an alternate route for accessing the board index. When the index code is moved into a controller, any route can just call that controller method, so that is easy. Ultimately, we should support a path like example.com/ in extensions, but the behavior of showing the board index when app.php/ is omitted should remain until the index has been put into its own controller and given its own route.
Note that example.com/app.php/ will be the same as example.com/ with URL rewriting enabled, and should be reserved for the index page when that is changed to be a controller. This should be fixed, of course, but extensions should probably not hijack this, unless they provide an alternate route for the index page.