OPENING POST
Description
Right now an internal link found in content.rendered triggers a new SSR. It should be captured in Frontity and switched to a client route.
User Stories
As a Frontity developer
I want to use Frontity’s router for all the internal links found in content.rendered
so that when readers click, the route change is done in the client
Possible solution
We have to add a processor for this.
SUMMARY
Please, bear in mind that this section wasn’t part of the opening post. It has been added afterwards and its purpose is to keep a quick summary with the most relevant information about this FD at the top of the thread.
Relevant links
Also, as noted by @mmczaplinski, we should check for absolute links and change them to relative links.
For example, in a site www.mydomain.com with a WordPress URL wp.mydomain.com we need to do this change:
<a href="https://wp.mydomain.com/some-post">
<a href="/some-post">
@luisherranz now that we have a <Link /> we could simply add a processor to replace all anchor tags with our <Link /> component. It already checks for external links. We would only need to add a check for internal absolute links and convert to relative links.
Absolutely. Great idea.
The only thing missing here is that the WordPress bakend URL is only on state.source.api now, and it may (or may not) contain a prefix, usually /wp-json.
We have seen lately that many packages need to know the “WordPress URL”, not only for the wp-source package.
I’m not 100% sure yet how that should be handled. One idea is to move it to state.frontity, similar to url:
export default {
state: {
frontity: {
url: "https://mars.frontity.org",
title: "Test Frontity Blog",
description: "Useful content for Frontity development",
backend: "https://test.frontity.org",
},
},
packages: [
{
name: "@frontity/wp-source",
state: {
source: {
prefix: "/wp-json", // This will be the default.
prefix: false, // This could be use to use `?rest_route=`.
isWpCom: true, // To support the WP.com API.
},
},
},
],
};
For example the @frontity/head-tags plugin is extracting the backend URL from state.source.api using this function: https://github.com/frontity/frontity/blob/dev/packages/head-tags/src/utils/index.ts#L29-L38
I’ll open a new FD to discuss this.
This is the new FD: Make the backend URL a global setting
Let’s move the conversation there 
I’ve started working on this here: https://github.com/frontity/frontity/pull/520
@luisherranz Do you think it’s worth relying on state.source.api for now and change it later?
I’m not sure we’re at a point where Make the backend URL a global setting can be implemented.
Hey, sorry for the delay in my answer @nicholasio.oliveira (I’m on holiday although I try to stay up to date).
To be honest, I’d prefer to try to do it now, because… well, the sooner the better for this type of change. If we keep delaying it it’s going to be more difficult.
And I think we can make it 100% backward compatible using derived state: Make the backend URL a global setting
I just finished my PR for this: https://github.com/frontity/frontity/pull/520 the new source url made things much easier!
2 Likes
Released in @frontity/components@1.6.0 and @frontity/html2react@1.5.0:
Thanks @nicholasio.oliveira!! 
1 Like
We have encountered an issue in our web, frontity.org with the link processor (I think). We have two different sites in the same project. In the frontity.settings.js file, we defined that, for all the urls that starts with /blog we are using the twentytwenty-theme, and for the others we are using our custom theme frontity-org-theme.
The problem is that both of them use the same frontity.url. In some blog posts, we are linking to pages in the frontity-org-theme, like the About Us page for example. I assume that, as it matches frontity.url, it does CSR. And it renders the About Us page in CSR with the twentytwenty-theme, which isn’t correct. It should SSR the page with frontity-org-theme, as it is a url not covered by the match property of the blog.
We have found a workaround, and adding target="_blank" to the link it’s okay, as it is loading a new tab. But I feel it should work without that property.
Is there something we should change in the frontity.settings.js file or is this a bug? Would it be possible to check if the link matches the match and, if not, do SSR?
This feels like a bug to me and agree the easiest way is checking if the link matches the match property. I wonder though if it’s possible to do CSR between different sites/themes.
This should fix it: https://github.com/frontity/frontity/pull/625
Didn’t test with multiple sites but added tests that covers the edge case here. @SantosGuillamot Can you check if this fixes the issue for you?
Great Thanks for the quick PR!
I have tried to test it in the frontity.org repo but I wasn’t able to make it work. Not sure if there’s something I am missing. I have left my feedback in the Pull Request. We can keep the conversation there.
I see, I was assuming the match property was being exposed through the useConnect
I’ll take a look at getSettings and see if there’s a way to access the match property from a component.
There is an issue using the match property. In most cases, there will be a default site where you don’t have to use the match, so we couldn’t rely on the match property in all the cases. @mmczaplinski, any ideas about which could be the best approach here?
I think that the approach outlined by @nicholasio.oliveira is in the PR is correct. We can expose the match property in the state.frontity. I don’t really see another way to solve this at the moment.
I think that it the in case when there is no match property (e.g. on a “default” site with no match attribute in the settings) we can check the link against state.source.url. That is:
if (link.startsWith(state.source.url)) {
// The link could also start with http:// or https:// so should account for that.
return link;
}
(this is not tested) 
From an SEO perspective, I believe using absolute is the easiest to maintain.
There are arguments for both, and John Mueller (Google Search Guru at Google) says both works “if done correctly.”
However, if you don’t have the time or resources to focus on SEO, it’s easier to just make it all absolute for a set-it-and-leave-it point of view. That way you don’t need to worry about SEO and duplicate content etc.
Would it make sense to write a processor to look for your current URL (localhost or real domain etc.) and string replace the href but also truncate it become a relative link so it can be handled internally?
Possibly having two settings to choose between absolute or relative will be interesting.
Sources:
1 Like
Sure. It should be easy to do a processor for that. Something like this:
const relativeToAbsoluteLinks = {
test: ({ node }) =>
node.component === "a" &&
node.props?.href.startsWith("/")
processor: ({ state, node }) => {
// Add `state.frontity.url` in front of all relative links.
node.props.href = state.frontity.url + node.props.href
return node;
},
};
1 Like