You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In WP, it is possible to set the site address as the headless frontend url! This updates all of the site links to use the actual Next.js frontend url instead of the cms links.
This would be super nice being able to click "View post" and it would open the frontend instead of the backend page.
But this also changes the post links in the WP REST API.
So far in our sitemap generation, we have just been using an ENV NEXT_SITE_URL and just swapping out the NEXT_PUBLIC_WP_URL with this NEXT_SITE_URL one. If the correct frontend url is added in WP we could just use the real site url.
To implement this, we would need to explore all of the possible side effects, like what happens when linking directly to a media asset like an mp4 video, etc.
We would also need to make sure getPageData is resolving these url paths correctly. Right now when we are resolving the page routes as relative paths we are just stripping out the NEXT_PUBLIC_WP_URL from the page link.
The text was updated successfully, but these errors were encountered:
In WP, it is possible to set the site address as the headless frontend url! This updates all of the site links to use the actual Next.js frontend url instead of the cms links.
This would be super nice being able to click "View post" and it would open the frontend instead of the backend page.
But this also changes the post links in the WP REST API.
So far in our sitemap generation, we have just been using an ENV
NEXT_SITE_URL
and just swapping out theNEXT_PUBLIC_WP_URL
with thisNEXT_SITE_URL
one. If the correct frontend url is added in WP we could just use the real site url.To implement this, we would need to explore all of the possible side effects, like what happens when linking directly to a media asset like an mp4 video, etc.
We would also need to make sure
getPageData
is resolving these url paths correctly. Right now when we are resolving the page routes as relative paths we are just stripping out theNEXT_PUBLIC_WP_URL
from the page link.The text was updated successfully, but these errors were encountered: