Sticky Links
WPML’s Sticky Links are links that automatically trace the destination page and can never break.
A Sticky Link automatically (and immediately) changes then the page it’s linking to changes. This doesn’t require any scanning or manual operation – it just happens by itself.
If you’re using the default permlinks, you’re seeing links like:
/?p=2 /?page_id=4
These links indicate the IDs of pages and posts. They’re never going to change. Once a page, post or category is created it’s assigned a unique identifier (ID). This ID will never change. The title, slug and permlinks can change, but this ID will remain the same.
So, a default link will always work. Even if you later change the permlinks to include the title, publish date and any other scheme, that default link will work.
What happens when you link to a fancy URL?
Most WordPress users prefer to use a fancy URL scheme (like title and publish month) over the default links. This way, the URLs become much more meaningful.
The problem is, fancy URLs can change at any given time. It can happen due to many reasons. You can argue and say that by being careful enough it’s possible to avoid changing pages’ permlinks, but this is like saying you can drive blindfold and avoid accidents. It’s just not possible.
The result is broken internal and external links.
Sticky Links fix the problem by design
This is how WPML creates Sticky Links:
- When saving a post or page, it will scan all internal links and replace them with the ‘default’ links.
- When rendering, it would replace all ‘default’ links with their current permlinks.
The result is that all the links you insert to other pages or posts will be stored as default links to the resource ID. They can never break under any circumstance. No matter how the title, slug or hierarchy changes, or ever if you’ve chosen a completely different permlinks arrangement. All links would always be intact.
When the page is displayed, the links would point to the current URL selected for each page. The default link works too, but requires a browser redirect.
Performance issues?
Having to scan every page for links and changing them on-the-fly may seem like a lot of work. In reality it’s not that bad. Calculating the permlinks according to IDs is an extremely fast operation (the other way around is more resource heavy).
And, if you’re using any caching plugin, this operation will only be done once in a long while. Much like the rest of the computing intensive rendering tasks that WordPress needs to do anyway.
Updating existing contents
The Sticky Links administration page offers to scan all posts and pages and fix all existing links. It will check for any internal links and would change them to the default link style.
It also reports broken links and offer to fix them (manually, by the user).
Subscribe via RSS
English
Follow
I just installed this plug in and got this error and do not know how to fix from my server. Cannot even access WP. Please HELP!!!
Fatal error: Cannot redeclare class AbsoluteLinksPlugin in /home/connie1/public_html/wp-content/plugins/sitepress-multilingual-cms/modules/absolute-links/absolute-links-plugin.php on line 28
Hi Constance,
Don’t panic, WordPress makes it extra easy to fix this situation.
Go to the plugins directory and delete the absolute-links folder. Then, when WP sees that the directory is gone it will automatically deactivate the plugin.
Instead of using this plugin, which is now obsolete, just install SitePress. It includes the absolute links functionality and works perfectly.
Go in to plugin in host (hostgator)? Then when there delete the plugin from public_html? Because I cannot get into WP at all. Thank you in advance. I can breathe again…
Yes, go to public_html/wp-content/plugins/
Under it, you’ll find a directory called ‘absolute-links’. Delete just it. Nothing else.
If you’re not sure, don’t delete. Explain this to hostgator and ask them to do it for you. Try not to delete the entire WordPress folder…
Thank you that worked. So this won’t happen with new pluginin – SitePress Multilingual CMS? Many thanks.
The problem happened because BOTH SitePress and the older Absolute-links plugins were active together.
We’ll fix that in the next minor SitePress release, so that it checks that the older plugins are not active – preventing errors like this from repeating.
Do you offer just the Sticky Links plugin w/o the rest of the CMS functions? I see the Absolute-links, but since it’s Obsolete now I’d prefer to avoid it. Thanks
We’re not maintaining this any more as an independent plugin. New features and bug fixes now go to the WPML plugin.
The link text of internal links is critical to create a pages ranking reputation. More important than even external linking text.
A nice idea for internal links (though of course it has no intrinsic connection with multilingual functionality and would be much more useful as a separate plugin).
I’m just wondering why you mention broken external links when the plugin doesn’t address this? I don’t think this can be addressed by a plugin – or am I missing something? It’s just that at a glance, following the text “The result is broken internal and external links.” with the heading “Sticky Links fix the problem by design” seems to imply that the external links are dealt with too – which I’m not sure is the case.
If you link to the default link, and not to the permlink, you’ll get unbreakable incoming links as well.
For example, the permlink for this particular page (right now) is:
http://wpml.org/wordpress-cms-plugins/absolute-links-plugin/
Whereas, the default link is:
http://wpml.org/?page_id=13
If you ask others to link to the default links, you’re set. No matter what structural changes you make in your website, these links remain intact. Since WP does a 301 redirect from the default to the permlink, the incoming links are counted for the permlink URL.
So the seo ramifications of this would be what? If the source code shows wp page id instead of the permalink page won’t that hurt w/the serps?
This is the beauty of WPML’s sticky links. The page ID shows in the page code, but not in the final HTML sent to visitors and search engines. They always see the correct permalinks, exactly as they should.
There are no SEO compromises with WPML’s sticky links.
amir, thanks for answering my question, but I must ask because I saw in my google webmaster tools that they had identified in my internal links the absolute link not the url, if you are certain I won’t be penalized because I would normally accept your conclusion as well due to the fact that it makes sense. But because the url shows up in the page code as absolute google will seemingly penalize you for duplicate content, and I don’t want to risk my rankings to find out for sure. But I am anxious to use this plugin due to my duplicate content issues with the slash and backslash. Google identified me as having duplicate meta tags for this very reason. This plugin solves that problem at least as long as it doesn’t create its own issue.
thanks again
The default URLs should not be displayed on your HTML. They are replaced by the current permalinks. Even if they do, it’s not a big deal, but they shouldn’t.
Can you post the URL to a page that includes sticky links? It should be immediate to see how the links appear on that page.
Can sticky links detect, for example, when a link in a Spanish-language page points to an English-language page on the same site, and correct it to point to the proper language?
This happens alot for us, because to translate pages we’ll first copy the contents of the English page over to the Spanish one, and then translate sentence-by-sentence, and it’s very easy to forget to update internal links to point to the Spanish page when doing this.
If it doesn’t have this capability, would it be something you’d consider adding in the future, either as part of sticky links or maybe another section of WPML?
Our professional translation system does that. It allows translators to work only on the texts and adjusts all links between pages.
If you’re interested, you can use that system with your own translators as well (for a fee)
Amir, ill be in touch. Very interested.
Hi, I’ve found an error with Sticky-links: the link is always referring to the “original” page. What I mean: I’ve a translated page, their urls are:
page1: mysite.com/thepage
page2: mysite.com/it/lapagina (tranlsation of page1)
If in another page (in IT language) I link the page2 (using “mysite.com/it/lapagina”), the link is replaced with the “page1″ URL after saving!
I have to manually replace all the /?page_id=XXX with the right number referring to the right page!
Has anyone found a solution to this, i have the same problem.
It’s better to report problems in our forum. We don’t provide technical support via comments.
So I have other plugins that have shortcodes in my post… the shortcode outputs some links but they remain unchanged, still /?p=1
What do I have to modify so that sticky links works in OTHER plugins shortcodes?
We don’t a solution for this, but if the authors of these other plugins work with us, we can help them make it all integrated.