It's been quite a while since the last update, but this time I'll be discussing a recurring issue with headless CMSs: the preview environment

Staging site SSR settings

When integrating SSG sites like Astro with headless CMSs, content previewing often becomes a challenge. In the past, we sometimes rebuilt all pages for previewing, but we were dissatisfied with the build waiting time, so this time we decided to set up SSR only in the staging environment, which does not require rebuilding. SSR is slightly slower in display speed than SSG, and costs are incurred for each request, but this is not a problem in a staging environment with only a small number of requests

Regarding SSR configuration, Astro provides environment-specific adapters and comprehensive manuals. In the case of Netlify, which is used on this site, installation was easy; we simply followed the manual and added the adapter settings to the Config file. Setting environment variables and enabling SSR only in the staging environment completed the process

Authentication of private articles

Setting up SSR was easy, but as it is, the content that can be viewed on the staging site is limited to published WordPress articles. You can temporarily publish articles on WP to check them (although they won't be reflected on the live site until a production build is done), but this method is not appropriate for the operational workflow

Therefore, we added authentication information to API requests from the staging server to enable retrieval of private WordPress posts. The implementation steps are as follows:

  • Create an application password for a user with administrator privileges in the WordPress admin panel and save it as an environment variable along with the username
  • To retrieve private articles, you must include authentication information in the API request header. For GraphQL, which is used on this site, the method for setting this authentication information is as follows. Note that the authentication token requires Base64 encoding, but window.btoa cannot be used in a Node environment, you will need to implement your own encoding function.
export const encodeBase64 = (data: string) => { return Buffer.from(data).toString("base64"); }; export const gqlClient = new GraphQLClient(URL_API, { headers: { Authorization: `Basic ${encodeBase64(WP_USER + ":" + WP_PASS)}`, }, });
  • All that's left is to specify additional statuses for each request. Incidentally, in WPGraphQL, specifying multiple statuses is done in a special way: where : { stati: [PRIVATE, PUBLISH] } . This stati seems to be a term unique to WPGraphQL, and it took me a while to find it. Also, private posts are simply not retrieved if they are not authenticated, so if you don't perform authentication in the build for the public site, you can reuse the same query without any problems.

Change preview URL

The article URL displayed in the WordPress admin panel is based on the WordPress server where it's installed, and therefore differs from the published URL or staging URL. As it is, clicking the preview button won't display the intended page, so we'll use WordPress hooks to rewrite it

  • Rewriting the preview button in the classic editor using `preview_post_link` . It's simple because it only involves changing a string
  • `get_sample_permalink_html`
    rewrites the permalink field in the classic editor. Since this requires rewriting the HTML String, care must be taken not to alter the HTML structure.
  • Rewrites the REST API accessed from the rest_prepare_post block editor. For links, $response->data["link"] is the link for preview, and $response->data["permalink_template"] is the link label for Slug settings.


summary

WordPress as a headless CMS has many differences from its original design philosophy, making it difficult to use as is. However, after this much work, it has finally become much easier to use. There are still many other areas that need improvement, so I will write about those on another occasion