I wanted to add a contents to my hub with links to sections within the article. I managed to do this using the mod_##### number but then noticed that the links don't work when browsing with Safari on Iphone or Ipad, they just take you to the top of the page. They do work with Chrome for mobile but I have since deleted the links as I think this would be too irritating for people browsing with Safari. Is there another way of linking that would work on all browsers?
We don't officially support anchor links, but as you witnessed they do work in some browsers.
I did a bit of research and it appears that there may be a known issue with Safari (it doesn't support named anchors).
I found this related discussion in Apple Support forums.
Matt, I read that Apple Support Forum thread. They say to use "ID=" instead of, or in addition to, using "name=" - but they didn't clarify that that refers to the destination (not the link), which is why the thread continues with people saying they don't understand. The link, itself, simply should have the URL of the hub followed by # and then the name of he capsule (i.e. #mod_nnnnnn ).
HubPages uses "ID=" in the HTML code on the capsule names, so that's the correct method to make it work with all browsers.
As I said in my prior comment, it works for me.
I'm working with our engineering team on this to see if we can make it work more consistently for iOS.
Can you share examples of Hubs and the anchor URLs you are using that are not working properly in iOS?
That way I have some additional examples to test.
I have a hub were I use anchor links to specific capsules and I never had a problem with Safari. I just checked it now using Safari 6.1.6 and it worked fine. I wonder if it's a bug in older versions of Safari.
I am aware that sometimes HP changes the address of capsules, which breaks those links. But that's another issue. I think that happens sometimes when hubs are edited, but I'm not sure.
In my observation the issues affecting iOS/Safari and not Safari in OS X.
I just tested my hub on my iPad, which has iOS/Safari. My anchor links worked there too.
It could be the issue isn't aan anchored link issue, but related toa redirect.
Are you using URLs in the format subdomain.hubpages.com/etc... or hubpages.com/etc ?
It looks like the non-subdomain URLs might actually be the issue.
My particular hub is an Editor's Choice, so it is not in the subdomain. I specify the link as
You're saying that it might be a problem with non-subdomain URLs. My hub disproves that. So it must be something else for those who experience the problem.
Please see Glen's clarification below
If you are still having trouble using the links int he manner he described, let me know on what platform (browser and version, OS version, device model number), which Hub, and what links are causing issues and I can look into it further.
I have removed the anchor links in my hubs for the time being. An example of anchor links that don't work using my iphone 5 running Safari are in Relache's Don't make the 10 most common hubber mistakes' hub. I'm not sure which version of Safari I have on my phone but it is as up to date as it can be. The internal links work fine on my phone when I use Chrome but Safari just reloads the page and leaves you at the top.
Glenn, do you have a hub example that I can look at with internal links to see if they work ok for me?
Dougalbunny, Yes, you can see an example of internal links with an anchor in my hub "How To Claim Your Authorship With Google" - There are three of them in the second paragraph.
Thanks for referencing Relache's hub. I took a look at it and I found the problem.
Relache - you can fix it. Your links go to hubpages.com but your hub is in your subdomain. I assume you once had this hub as Editor's Choice and now it's back in your subdomain. HP creates a 301 redirect in both directions - when moved to Editor's Choice and also when moved back.
I tested your hub in Firefox and Safari. Turns out I was right in my prior comment. Firefox follows the anchor when it is 301 redirected, but Safari just follows the 301 redirection to the top of the page because it no longer has the anchor after being redirected.
So if you add your subdomain to your anchored URL's, it will work under all browsers.
I just thought of something else that might be the reason for your problem. Are you using the correct URL before the anchor? If it's in your subdomain then you have to use your subdomain URL. But if it's an Editor's Choice hub then you have to specify the URL without your subdomain. And no WWW either, which is a mistake I see some people making. As long as you have the exact and correct URL it should work on all modern browsers. Mine does.
One other point. If your hub is Editor's Choice and you are using your subdomain URL, then it will follow the 301 redirect. It's possible that some browsers will lose the anchor on a URL when following a redirect. That would explain why it seems to work with some browsers and not with others. This is another reason why you need to be sure that you are using the correct URL.
UPDATE: Please see Glenn's very helpful post below.
There are other browsers where this same error occurs on the HubPages site on mobile devices.
That doesn't really bode well for those new HubPages Pro editors who are supposedly making tables of contents for people's Hubs and the entire sway towards being mobile-oriented now, does it?
@relache I did some follow up and was able to confirm that editors are not adding tables of contents to Hubs. Can I ask where you heard that information?
I thought I had read something to that effect in the HubPro discussion. Perhaps I misunderstood what someone was saying amidst my horrified reaction to many of the pilot test editing stories.
Thanks for the info and discussion link. I think for the time being I will leave the contents out of my hubs as I am a safari, mobile user and I know I would find it somewhat annoying clicking on links that don't do anything so I guess other people would too!
by Paul Edmondson 9 years ago
Today we are putting a few staff accounts on Subdomains. This is a pretty major change to the site that we've been working hard to get out as fast as possible. You can see an example at (In the next hour or two at) http://pauledmondson.hubpages.com Once we get data and work through bugs...
by Dorian Bodnariuc 6 years ago
I just checked a few of my former lenses, and it seems like 301 redirects from Squidoo don't work anymore.Does anyone know anything about this? I used to have some social media traffic, mostly from Pinterest and Google+. That traffic is lost now. Cheers,
by Seet 7 years ago
Hello all, I will be conducting an experiment of trying to get one of my hubs to the first page of a rather competitive keyword. All updates will be on here.The keyword is "Best Facebook Games"Now, I am giving myself 30 days to do this. Starting today June 24, 2013. Experiment ends July...
by Ben Guinter 8 years ago
I'm curious to hear if there are any hubbers, who saw a big drop in traffic after the most recent Google Panda and Penguin updates, have fixed their issues and are getting good traffic again yet?I think it would be good for us all to know what changes brought about your renewal of traffic, since...
by Glen Kowalski 6 years ago
I published my first hub tonight. All the material was already written (was going to use it on squidoo before the 'great purge' and I got fed up with them. So here are my questions...First, I plan on making a large collection of hubs about fishing, specifically saltwater fishing at...
by Brian Leekley 7 years ago
I have learned through forum discussions that including an outgoing anchor text link in a text capsule in a hub is good idea when a) the word or phrase used as the anchor text closely relates to what the hub is about, b) the webpage linked to closely relates to what the hub is about, and c) the...
Copyright © 2021 Maven Media Brands, LLC and respective content providers on this website. HubPages® is a registered trademark of Maven Coalition, Inc. Other product and company names shown may be trademarks of their respective owners. Maven Media Brands, LLC and respective content providers to this website may receive compensation for some links to products and services on this website.
|HubPages Device ID||This is used to identify particular browsers or devices when the access the service, and is used for security reasons.|
|Login||This is necessary to sign in to the HubPages Service.|
|HubPages Traffic Pixel||This is used to collect data on traffic to articles and other pages on our site. Unless you are signed in to a HubPages account, all personally identifiable information is anonymized.|
|Remarketing Pixels||We may use remarketing pixels from advertising networks such as Google AdWords, Bing Ads, and Facebook in order to advertise the HubPages Service to people that have visited our sites.|
|Conversion Tracking Pixels||We may use conversion tracking pixels from advertising networks such as Google AdWords, Bing Ads, and Facebook in order to identify when an advertisement has successfully resulted in the desired action, such as signing up for the HubPages Service or publishing an article on the HubPages Service.|