site()->visit($page) Does Not Work with Content Representations

[neildaniels]

Describe the bug This is sort of the 2nd part of #1362. I believe this is a regression from Kirby 2, but because of the removal of the filter route parameter, I've never actually needed to hit this case before.

If you visit a page such as /sitemap.xml and that path hits matches a route, at some point you would probably like to invoke site()->visit($page). However, by the time you have a Page model object, that Page doesn't have any intrinsic knowledge of the content representation you requested. That should still be part of the route/current URL though.

I would expect that the visit() method would be able to correctly infer that an XML representation (in this case) is still the intent. Currently, it does not infer that the XML representation should be provided.

To Reproduce Steps to reproduce the behavior:

1. Have a route that matches something with a content representation
2. Fetch the page object for the source (see #1362 for separate issue regarding that).
3. Invoke site()->visit($page)

Expected behavior I would expect the content representation template to be used, not the "normal" one.

Kirby Version 3.0.0

Additional context Here's a basic route with a hacky workaround for #1362.

    [
        'pattern' => '(:all)',
        'action' => function($uri) {
            $pathParts = pathinfo( '/' . $uri);
            $uri = str_replace ('//', '/', $pathParts['dirname'] . '/' . $pathParts['filename']);
            $page = page($uri);
            if (!$page) {
                $page = site()->errorPage();
            }
            return site()->visit($page);
        }
    ],

[LeBenLeBen]

I would love to see that restored too! In the meantime I had to replicate a bit of the default behavior by manually rendering the page with the right representation from the router:

site()->visit($page, $locale);

if ($extension) {
  return kirby()
    ->response()
    ->body($page->render([], $extension))
    ->type($extension);
}

return $page;

[bastianallgeier]

@LeBenLeBen that's a good workaround for now. I will try to fix this in a more elegant way though.

[bastianallgeier]

After thinking about it some more, the correct approach in v3 is to use $kirby->resolve($path, $languageCode) in such cases.