Uploaded image for project: 'phpBB3'
  1. phpBB3
  2. PHPBB3-12004

Support empty routes to app.php/ in path_helper

    Details

    • Type: Bug
    • Status: Unverified Fix
    • Priority: Major
    • Resolution: Fixed
    • Affects Version/s: 3.1.0-dev, 3.1.0-a1
    • Fix Version/s: 3.1.0-b3
    • Component/s: Styles
    • Labels:
      None

      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

        Hide
        imkingdavid David King added a comment -

        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.

        Show
        imkingdavid David King added a comment - 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.
        Hide
        nickvergessen Joas Schilling added a comment -

        /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.

        Show
        nickvergessen Joas Schilling added a comment - /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.
        Hide
        Marc Marc added a comment -

        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.

        Show
        Marc Marc added a comment - 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.
        Hide
        imkingdavid David King added a comment -

        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.

        Show
        imkingdavid David King added a comment - 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.
        Hide
        Marc Marc added a comment -

        Then again, what if e.g. a portal wants to overtake requests to example.com? Do we really want to break that behavior?

        Show
        Marc Marc added a comment - Then again, what if e.g. a portal wants to overtake requests to example.com? Do we really want to break that behavior?
        Hide
        imkingdavid David King added a comment -

        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.

        Show
        imkingdavid David King added a comment - 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.

          People

          • Assignee:
            Marc Marc
            Reporter:
            Marc Marc
          • Votes:
            0 Vote for this issue
            Watchers:
            3 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development