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.
Also, think that the crucial bit that should be documented is which settings the user will need depending on what kind of hosting they are on. I think that the final table should look like:
Iāve linked here from the PR to add docs for state.source.url because it was not 100% clear to the DevRel team from the Discussion above which information should be documented and which one was implementation detail.
Yikes, youāre correct @luisherranz, sorry for the confusion! Iāve missed that weāre checking if itās a free Wordpress dot com site in here as you pointed out.
However, I think that I wrongly thought that because the state.source.api in the first case should also be public-api.wordpress.com/wp/v2/sites/sub.wordpress.com.
This table is also the correct one then. @juanma Could you take a look and see if we need to update the docs according to this? The table that I have made is superseded by the one that Luis made.
