My Blog Automation Workflow in 2022

✍🏼 Written on Feb 23, 2022    💡 Updated on Mar 7, 2022
❗️ Note: it has been days since this article was written, please be aware of its timeliness
🖥  Note:Technology advances, and so do my tinkering endeavors.
📚  Also published on Craft: https://www.craft.do/s/zGU3Z3SIIVMahv

Preface

In 2021, I wrote an article about ](https://www.xheldon.com/tech/my-blog-ci.html) blog automation, but at that time, I didn’t properly handle the issue with Craft images, and the logic was scattered across multiple repositories, making it less replicable. After that, I tested the feasibility of directly uploading images from Craft (the answer was no), so I recently spent a weekend solving the problem of transferring images to Tencent Cloud. Combined with switching to Vercel instead of GitHub Pages, the speed has improved significantly. Here’s a record of the process.

Note: There may be follow-up articles like “My Blog Automation Workflow in 202x,” after all, technology evolves, times progress, and I’m still tinkering 🤣.

Main Content

Overall Workflow

Image

Detailed Explanation

⓵ Craft Document

Refers to blog documents written in a specific format. The format must meet the following conditions to be correctly synced to the repository:

  1. The first element of the document must be a table containing meta information.

  2. In the meta information, the title field doesn’t need to be written—I extract it directly from the document data. The headerImg and image copyright information (if uploaded from Unsplash) also don’t need to be included.

  3. Drawing elements are not supported (because they cannot generate files with valid image extensions). If they exist, they won’t be uploaded to COS and won’t display properly (since they are Craft’s proprietary file type).

⓶ Craft Plugin Repository (Public)

Refers to the plugin used in Craft to fetch document content, process it, and upload it to the repository. For more information about Craft plugins, see ](https://developer.craft.do/). The address for the private plugin I wrote is ](https://github.com/craft-extension/craft-github-extension).

The plugin’s function is to convert Craft document content into Markdown format and then use the GitHub REST API to send it to a fixed repository location—specifically, the content.md file in the craft_publish_ci repository. If the file exists, its content will be replaced. The repository is public and can be found ](https://github.com/Xheldon/craft_publish_ci).

⓷ craft_publish_ci Repository (Public)

This repository primarily uses GitHub Actions to process images. After receiving content from the plugin (i.e., when the content.md file is updated), it reads the file’s content, identifies the images in the Markdown file (block-level elements starting with ![ are judged as images, along with special header images marked with headerImg), fetches them, and stores them in Tencent Cloud COS. For consistency and convenience, I convert all images to the JPG format within the Action. This simplifies the logic for replacing image URLs in the document when no new images need to be uploaded (e.g., when only text is modified), as some images may not have common extensions like PNG or JPG, or may even lack an extension altogether. I once attempted to use the content-type from the image fetch response to append the correct extension, but found that some images (e.g., TIFF) returned application/octet-stream (if I spelled it correctly). Moreover, this approach required fetching all images in the document first, which risked being banned. Thus, I opted to convert all images to JPG before uploading. After obtaining the CDN URLs, the corresponding image addresses in the document are replaced with the CDN links. Finally, the updated file content is pushed to the actual blog repository, x_blog_src.

⓸ x_blog_src Repository (Private)

Upon receiving a push update, this repository triggers an Action to build HTML files and deploy them to the public blog repository x_blog. The rationale for this setup is detailed [here]](https://www.xheldon.com/tech/the-using-of-github-pages.html#:~:text=我的博客之前是直接在源码放在 repo 中,使用 Github Pages 提供的默认的 Jekyll,然后设置自定义域名。但是这样有以下几个问题:).

⓹ x_blog Repository (Public)

[This repository]](https://github.com/Xheldon/x_blog) grants Vercel permission to read its content for deployment. It is bound to a custom domain, allowing access via www.xheldon.com. The reason for not using GitHub Pages is that Vercel offers a more professional solution with dedicated global CDN acceleration, whereas GitHub Pages suffers from slower DNS resolution and lacks CDN optimization. While GitHub Pages may suffice for documentation sites, it feels inadequate for a blog without any optimizations.

Additional Details

Some pages in the blog asynchronously fetch data from Notion, such as the Subscription Management page. This process also utilizes Vercel’s serverless functionality to forward requests to Notion’s database on the server side. I’ve designed this interface to be universal—by sending the Notion database’s headers and databaseId via POST—making it convenient for future pages that may require asynchronous Notion data fetching.

- EOF -
Originally published at: My Blog Automation Workflow in 2022 - Xheldon Blog