I am using the "heading links" feature as described here: https://www.esri.com/arcgis-blog/products/arcgis-storymaps/constituent-engagement/storymaps-heading-... to create a sort of within-story map table of contents for a specific piece.
I tested it with one link - it works. I go back in and add the rest of the links. After publishing, the test link now redirects to a new tab with "about:blank#blocked" in the address bar, but the subsequently added links work properly. I went back in and fixed the first link - after publishing it works but the others now redirect.
It appears that something is breaking when publishing the story. I can go in and change all the links simultaneously, but this is a frequently updated storymap, and I would prefer not to have to redo all the links every time we publish an updated version.
Hi @MalloryCarpenter1 -- I'm sorry you're seeing an issue with setting up heading links. The behavior you've described is not expected, and I'm not able to reproduce it based on the information you've provided so far.
Here's a test story I just created. There are four heading links are at the bottom of the story and they all appear to behave as expected: https://arcg.is/1vumWq0
Could you please share a bit more about the exact steps you followed to configure the links so we can try to determine what's going on?
Hi Owen,
Thanks for the reply - as described in the article I linked above, I "hovered" over the heading until the link icon appeared, then clicked it and would receive the prompt "success! link copied." I would then copy that link into the "create hyperlink" style option available when text is selected in the story map when editing.
I have not had time to re-edit the links out of the storymap yet so you can see it here:
If you scroll down to the "interactive map" section and click "St. Lukes" it will work properly, but if you click any of the others the error will occur. If I were to go in and edit the story again, the St. Lukes link would also break.
@MalloryCarpenter1 -- Thanks for sharing those steps and the link. I've tried several different ways to reproduce the behavior, but I'm not able to do so. The links always work as expected, even after going back and editing the story. Either this is a glitch in your particular story or there's a specific sequence of steps that are required to cause the problem.
At this point it'd be best if you could please contact Esri Technical Support. They will be able to better assist you in troubleshooting this issue with your story.
I’m encountering the same problem with old links breaking when new links are added. In trying to come up with a simple case that reproduces the problem, I have found a very odd issue with the way a link is created. If I type in the text for a link without following that text with the Enter key, and then establish the link, the link comes up broken and goes to “aboutblank#blocked” as mentioned above. If I type in the text for the link and follow it with the Enter key, then the link works properly. As I said, very odd.
Here are the steps to reproduce this problem:
These steps consistently produce a broken link in the tests I have run. I’m not sure yet if this is directly related to the issue in this case. I’m going to run some more tests. If needed, I could probably produce a video of the above sequence.
@BenParker -- I think you're on to something!! By design, pressing ENTER after typing/pasting the URL is required to properly configure the link. @MalloryCarpenter1, can you try this and see if that fixes things for you?
It does look like there may be a bug that sometimes allows a link to be partially/incorrectly added if ENTER is not pressed. We'll look into that to see if we can address it in an upcoming release.
Just to be clear, the Enter key seems to be needed when entering the text that will be associated with the link. As you indicated, the URL won't be applied unless Enter is pressed when entering it.
I have found a way to reproduce the scenario of a new link breaking an old one:
I know bulleted lists weren't mentioned thus far but maybe a similar mechanism is at work.
Here's what this most recent test looks like:
https://storymaps.arcgis.com/stories/aa89fb9b749b4c09ba9c5eaecf6ff785
Thanks for all the additional information. We can reproduce the issue now and are looking into the cause so we can try to get a fix out in the next few weeks.
We'll update this thread when we have more information.