BUG: Deep Linking

  • Hi,

    My site is structured like:

    • /photos/tour1/tour1pano1/
    • /photos/tour1/tour1pano2/
    • /photos/tour2/tour2pano1/
    • /photos/tour2/tour2pano2/

    Where each pano has it's own html page for search indexing and metadata (proper social media previews when linked, etc) about that place at `/photos/tour1/tour1pano1/` and where that page redirects you to it's scene in the krpano tour containing all the images for that tour at `/photos/tour1/?startscene=tour1pano1`.

    So, I've enabled `deeplinking` in the skin_settings and overriden the `skin_deeplinking_update_url_process` action to generate paths like `/photos/tour1/tour1pano1/` instead of `/photos/tour1/?startscene=tour1pano1`, in order to match the layout of my site.

    The problem is, as soon as history.replaceState is called, tile loading breaks.

    The tour at `/photos/tour1/` uses a relative path to the tiles like `tour1pano1/tiles/x`, but as soon as the deep linking updates the path to `/photos/tour1/tour1pano1/` it then also starts trying to resolve the relative tile references from that point as `/photos/tour1/tour1pano1/tour1pano1/tiles/x`.

    Can krpano be fixed to reuse the original location of the tour for resolving tiles, so that "cosmetic" changes to the address (for in case the user refreshes the page) won't break tile loading?

    Much Thanks!

    Edited once, last by hubick (May 14, 2020 at 7:25 PM).

  • it is NOT a bug, if you tamper with the vtourskin and break things *wink*

    note that ?startscene=... also sets the startscene global variable,
    which might be needed in some places, so you'd have to change that, too.
    secondly this might be connected to the paths given in the scene descriptions,
    did you adapt these to your scheme?

    you can change this to your liking, but there are interconnections and you have to find all places affected.
    then you probably cant use the droplets anymore or have to adapt them, too
    i'm not sure this is worth all the hassle.

    why dont you simply use an index php inserting the proper metas

  • 1) the startscene variable is set by the url, this is missing with your scheme
    <action name="startup" autorun="onstart"> in tour.xml will not work anymore
    but maybe thats not important because of 3)

    2) the path scheme is all over in the scene description in tour.xml
    (if the tour was created with a droplet)

    Code
    <scene name="scene_mypano" title="mypano" onstart="" thumburl="panos/mypano.tiles/thumb.jpg" lat="" lng="" heading="">
    	<view hlookat="0.0" vlookat="0.0" fovtype="MFOV" fov="120" maxpixelzoom="2.0" fovmin="70" fovmax="140" limitview="auto" />
    	<preview url="panos/mypano.tiles/preview.jpg" />
    	<image>
    		<cube url="panos/mypano.tiles/pano_%s.jpg" />
    	</image>
    </scene>


    3) i'm not sure i got it right what you're doing,
    but creating a full html page for each single panorama is not a good way to go
    it breaks about everything in krpano *rolleyes*
    (scene transitions, global variables, etc etc)

  • The individual pano location html pages are not part of the tour, and krpano is not expected to understand their URL format.

    What I'm asking of krpano is, to let me use the deep linking facility to forge the browser address outside the tour. I want users to be on the tour html page, but it to appear as though they aren't, so if they hit refresh, they'll be taken back to the canonical location for the content they were viewing, which is, again, a location outside the tour.

    If those pano location html pages redirect users to that scene in the tour, using the unmodified and intact startscene capability as provided by krpano, I want krpano to let it appear to that user as though they're still back where they were.

    Unfortunately, updating the address to change the folder path breaks the tile loading of krpano itself.

    I want krpano to learn it's location at initial startup, and remember it, so that "cosmetic" changes to forge the URL don't break it's own resolving of resources. I want it to help me lie to the user about where they are, and not believe that lie itself.

    I'm gonna go mess with %placeholders% to see if one of the standard ones or a custom one in the tile path might be able to achieve this (either way, I still think it's a bug, and that krpano shouldn't be impacted by post-start changes to the address).

    Edited 2 times, last by hubick (May 14, 2020 at 8:28 PM).

  • I was able to successfully work around this issue by changing all urls in my scene xml to be relative to the BASEDIR placeholder, and supplying absolute paths in xml and basepath arguments to embedpano().

    I very much dislike using absolute paths, as now my photos directory is no longer portable and needs to know it's path on the server *sad*

    I had tried to make the urls in my included xml's relative to the CURRENTXML placeholder, but "current" in that context doesn't refer to the include system, it seems to mean current in the sense of what "xml" embedpano() is currently using or something. It was actually the description I found in the old docs ("path of the current loaded main xml file (not the included one)") which made that more clear than the current docs.

    Anyhow, here's the code for my deep link forging, in case it ever helps anyone else:


    Edit: Now I'm double confused, as the browser.location variable wasn't being updated, yet the tile resolving still broke on replaceState() - so I'm guessing the resolving isn't using browser.location? Anyhow, given the basedir placeholders work, I've updated the code to set browser.location so I can track and attempt to call pushState() on scene changes instead, which also requires some fiddling to make the back button actually update the page content...

    Code
    jscall('window.onpopstate = function(event) { window.location.href = window.location.href; };');

    Edited 2 times, last by hubick (May 13, 2020 at 7:56 PM).

Participate now!

Don’t have an account yet? Register yourself now and be a part of our community!