state.frontity.url: http://localhost:3000 or wherever your Frontity app is.
I guess you will have to define somewhere that state.source.url is a WP.com site, but I am not sure what is the best way to do this, I guess you would need to set state.source.isWpCom: true.
If state.source.url is set to https://artistintheshed.com then I get a 404 - I guess because that’s not a valid link to the API. Adding state.source.isWpCom: true doesn’t make a difference.
If state.source.url is set to https://artistintheshed.wordpress.com then it works as that points to the API at wordpress.com.
But then the link component problem that I describe in the loom video occurs - I guess because the internal links pointing to artistintheshed.com/whatever don’t match the hostname part of the URL which is artistintheshed.wordpress.com as far as Frontity is concerned.
By the way, this site is just an example because I know they have a custom URL. This problem will occur for any wordpress.com site with a custom URL.
As a matter of fact, the solution that Michael posted in the github issue is probably correct (or very close to what we it should be) so thanks Michael!
So, assuming that the bug I’ve mentioned is fixed, we should be able to do either of two things:
But I don’t think that is working right now, is it? Because state.source.api is not checking state.source.isWpCom to check if the site is a WordPress or not, it is doing its own logic:
{
api: ({ state }) => {
// Check if it's a free WordPress.com site.
if (/^https:\/\/(\w+\.)?wordpress\.com/.test(state.source.url))
return addFinalSlash(
`https://public-api.wordpress.com/wp/v2/sites/${state.source.url}`
);
return addFinalSlash(
addFinalSlash(state.source.url) + state.wpSource.prefix.replace(/^\//, "")
);
},
isWpCom: ({ state }) =>
state.source.api.startsWith(
"https://public-api.wordpress.com/wp/v2/sites/"
),
};
If I am right, I guess we need to use state.source.isWpCom inside state.source.api. Something like this:
{
api: ({ state }) => {
// Check if it's a WordPress.com site (free, personal or premium).
if (state.source.isWpCom)
return addFinalSlash(
`https://public-api.wordpress.com/wp/v2/sites/${state.source.url}`
);
return addFinalSlash(
addFinalSlash(state.source.url) + state.wpSource.prefix.replace(/^\//, "")
);
},
};
You’re right about checking the isWpCom@luisherranz . Ideally, we should check if that’s the case inside state.source.api but I’ve realized that the problem is that this would introduce mutual infinite recursion
The state.source.api is checking the state.source.isWpCom in it’s definition and vice versa. So if the user does not define the isWpCom themselves, you’ll get a “Maximum stack call exceeded” exception.
However, we can check if the state is a derived state using Object.getOwnPropertyDescriptor()
I think we will then need a slightly more complex check like this:
{
api: ({ state }) => {
// Check if it's a free WordPress.com site.
// We have to make sure the `.isWpCom` is NOT a derived state because otherwise
// we would end up in an infinite loop.
if (
typeof Object.getOwnPropertyDescriptor(state.source, "isWpCom").value ===
"boolean" &&
state.source.isWpCom
) {
return addFinalSlash(
`https://public-api.wordpress.com/wp/v2/sites/${state.source.url}`
);
}
return addFinalSlash(
addFinalSlash(state.source.url) + state.wpSource.prefix.replace(/^\//, "")
);
},
isWpCom: ({ state }) =>
// The user can define either the `state.source.url` or `state.souce.api`
// so we should try to detect either of those cases automatically.
/^https:\/\/(\w+\.)?wordpress\.com/.test(state.source.url) ||
state.source.api.startsWith(
"https://public-api.wordpress.com/wp/v2/sites/"
),
}
This will still fail if the user has a site on wordpress.comwith a custom domain but has NOT specified "isWpCom": true. I think that there is nothing that we can do about it though because if the user chooses to use their custom domain, Frontity cannot just know if it’s a wp.com or wp.org.
So, we will have to make it explicit in the documentation that when using a wp.com site with a custom domain, the user has to pass the isWpCom: true in their settings.
Regarding the code, I think you still have to check inside state.source.api if state.source.url is from a subdomain.wordpress.com site because you cannot rely on state.wpSource.isWpCom for that:
const api = ({ state }) => {
// Is it a WordPress.com site with a custom domain?
const isCustomWpCom =
!isDerived(state.wpSource, "isWpCom") && state.wpSource.isWpCom;
// Is it a free WordPress.com site using a subdomain.wordpress.com domain?
const isFreeWpCom = /^https:\/\/(\w+\.)?wordpress\.com/.test(
state.source.url
);
if (isCustomWpCom || isFreeWpCom) {
const { hostname } = new URL(state.source.url);
return addFinalSlash(
`https://public-api.wordpress.com/wp/v2/sites/${hostname}`
);
}
return addFinalSlash(
addFinalSlash(state.source.url) + state.wpSource.prefix.replace(/^\//, "")
);
};
I don’t understand some of the cases you mentioned on the table.
When you talk about these three specifically:
Free WP com - configured by state.source.api
Personal and Premium WP com - configured by state.source.api
WP org and Business WP com - configured by state.source.api
What do you mean exactly when you say that state.source.url is derived from state.frontity.url? Shouldn’t it be derived from state.source.api?
I thought state.source.url should point to the WordPress instance, not the Frontity one. Except for the embedded mode: in that case, I guess state.frontity.url and state.source.url would be the same.
I think we never thought that state.source.url could be derived from state.source.api if state.source.api is defined by the user (not derived) but I guess that with Michal’s isDerived function we can do that.
Actually, that would mean that state.source.url is backward compatible and safer to use than it is today.
Ok, we have carefully reviewed the logic and I think we got it right this time
Not only that, but thanks to @mmczaplinski’s isDerived function and @David who noticed that we can use that to derive state.source.url from state.source.api, now state.source.url is backward compatible and safe to use in any package!! .
Awesome work guys
Thanks also to @mburridge for bringing into our attention the problem with wordpress.com sites that have custom domains but can’t use /wp-json.
The 
