docs: explanation about sitemaps in headless WordPress #116
Conversation
There was a problem hiding this comment.
I like the overview and the introduction of the problem. I like how each solution has clear pros and cons. The three solutions need a little work. 1 is new to me, I haven't heard of it before, have you seen others do this method? I'm open to it but seems a little strange. The three methods documented in the RFC #17 that we need to comer here are:
- Proxying the sitemap from the front end to the back end. - https://github.com/wpdecoupled/site/tree/main/src/routes/%5Bfile%3Dsitemap%5D
- Generating a sitemap from GraphQL content (you cover this with 2/3...but static VS SSR is not a "separate" method...just a different rendering strategy. - https://github.com/wpengine/faustjs.org/blob/main/src/pages/wp-sitemap.xml/index.jsx
- Fetching existing sitemaps and and parsing them into a new sitemap with any added framework routes (the current faust method)
|
@theodesp @moonmeister, the problem with the 2. approach (WPGraphQL) is that WPGraphQL returns maximum 100 node per page. If you set You can increase that limit but it may cause problems for the WP instances low on resources: https://www.wpgraphql.com/filters/graphql_connection_max_query_amount |
docs/explanation/sitemaps.md
Outdated
| const transformedContent = sitemapContent.replace( | ||
| new RegExp(process.env.WORDPRESS_URL, 'g'), | ||
| process.env.FRONTEND_URL | ||
| ); | ||
|
|
||
| return new Response(transformedContent, { | ||
| headers: { | ||
| 'Content-Type': 'application/xml', | ||
| }, | ||
| }); |
There was a problem hiding this comment.
If the front-end url is correctly set in WP this isn't necessary and causes performance issues. I'd recommend we make a note that the correct URL needs to be set in WP for this method and do a direct proxy as shown in https://github.com/wpdecoupled/site/blob/main/src/routes/%5Bfile%3Dsitemap%5D/%2Bserver.ts
There was a problem hiding this comment.
@moonmeister I'm resposting this question regarding the nature of the proxy:
Regarding proxying the sitemap.xml from WordPress to the Headless site:
- If the
sitemap.xmlis served from WordPress, the links inside it will use the WordPress site URL, which can cause CORS issues when accessed from the headless frontend. - If we ensure the sitemap links use the correct headless frontend hostname, the next issue is how Next.js maps
<sitemapindex>links to file system routes.
For example, these sitemap links:
http://localhost:3000/wp-sitemap-posts-post-1.xml
http://localhost:3000/wp-sitemap-posts-page-1.xml
http://localhost:3000/wp-sitemap-taxonomies-category-1.xml
http://localhost:3000/wp-sitemap-users-1.xml
Each of these would need a corresponding file or API route in Next.js.
I saw that Faust.js solves this by transforming sitemap links into a query format:
sitemap.xml?sitemap=<url.pathname>
I tried to do some Next.js Regex Path Matching to match in the config but its very unreliable they don't seem to work
I’m interested in hearing your thoughts on what we mean by proxying.
There was a problem hiding this comment.
So a proxy fetches content from another endpoint based on a request. So a VPN is a proxy of sorts. https://en.wikipedia.org/wiki/Proxy_server
docs/explanation/sitemaps.md
Outdated
| // pages/[...sitemap].js | ||
| export async function GET(request, { params }) { | ||
| const { sitemap } = params; | ||
| const sitemapFile = Array.isArray(sitemap) ? sitemap.join('/') : sitemap; | ||
|
|
||
| const wpSitemapUrl = `${process.env.WORDPRESS_URL}/wp-sitemap${sitemapFile ? `-${sitemapFile}` : ''}.xml`; |
There was a problem hiding this comment.
I don't really understand this code. A catch-all route wouldn't work with most other routing situations. Aditionally, any unknown URL that should 404 would just render a sitemap.
There was a problem hiding this comment.
See comment above regarding some questions about the logic.
theodesp
dismissed stale reviews from ahuseyn, whoami-pwd, and colinmurphy
via
19073cd
closes #50