Write Blog With Hexo

Abstract

Before hexo, I use jekyll to build my blog on github. But after I migrate to mac ox, I found hexo would be faster and more convenient.

In this post, I mainly focus on record my practice to write blog with hexo.

Content

install hexo

To install hexo, please refer to install. One thing to be careful about is to install node.js as precondition.

write with hexo

There are mainly two ways to write a post and deploy it to blog server(github).

draft firstly, then complete post(recommended)

It’s suggested to record idea quickly in draft, and complete them later. draft is a special layout, it’s not just layout format as others. the special point is such draft file would be located under source/_drafts. so when you review your post locally or deploy it remotely, draft are ignored.

Following are the steps to write in this draft -> post way on my mac OS.

1. Go into the hexo folder

   cd Workspace/Hexo

2. Create draft file, where you can record idea quickly. Draft would be ingored when generating static files and deploying. And you can configure _config.yml render_drafts: false to hide them in local server review.

   hexo new draft "draft name"

   Since I configured default layout as draft, and hexo support short represent of command, such as new can be simplified as n. You can input command

   hexo n "draft name"

3. Publish your draft, which is migrate from source/_drafts to source/_posts with same file name but with data prefix. and format it based on scaffolds/post.md. You should only do it when the draft is ready to bee seen as post to format looking. Following p is short for publish

   hexo p post "draft name"

4. Start local server to review your post locally. you don’t need to generate static files if you review locally. Following s stands for server.

   hexo s

5. Opitonal step but useful if you are writing English. When you review your post and updated format, we do suggest you to check your source post with command line spell check tool.

   aspell -c your_post_file

6. Generate static files in need(would skip the file have no change if public exist). All changed posts would be generated with static files. Follwing g is short for generate.

   hexo g

7. Deploy static fields on github to share outside, it would deploy all static files from last step. So if you don’t want to deploy some contents, keep them in as draft. Following d is short for deploy.

   hexo d

write post directly

if you plan to start draft and complete this post in short time and deploy it, you don’t need to draft firstly. you can go this way. the server, generate and deploy steps are the same as above.

1. Go into the hexo folder

   cd Workspace/Hexo

2. Create post file directly and you complete your post.

   hexo n post "post name"

3. Start local server to review your post locally.

   hexo s

4. Optional but useful when writing in English, check your spell in post file.

   aspell -c your_post_file

5. Generate static files in need.

   hexo g

6. Deploy it on github to share outside, it would deploy all posts.

   hexo d

Questions

:❓ do I need to care space and title case in “post name” or “draft name”?

For space, as we know, file name don’t support space(linux). the hexo would smartly transfer the space to ‘-‘ symbol.

For title case, hexo do support show title-case on browser for words in “post name” or “draft name”. I’ve already configured it in _config.yml titlecase: true. So when you see it on browser, it would fit the tile case smartly.

For file case, hexo also support to transfer lower cases or upper cases from “post name” or “draft name” to file name. I’ve configured it in _config.yml filename_case: 1.

In conclusion, we would write our post or draft name as “post name”. you really don’t need to care lower or upper case issue, choose whatever you like. hexo would take care of showing and filename transfer. But you must keep the space surrounded by quote “”.

:❓ why the updated field don’t work?

This field udpated is used to show edit time and defined in front-matter of a post. It work with field date, which is used to show create time. the edit time would only be shown in browser when udpated time is later then date

So if you edit it manually, it would only work when it’s later than created time.

Another option is configuring updated_option: date in _config.yml, it would use the current date time(the day you edit) as edit time.

:❓ any suggestions to apply address symbol for text?

In markdown, there are are several types of ways to addressing text. my practice is like below.

*specific terms, like defination, parmas, options*
**words you want to address, like conclusion**
***file/folder names***
~~obsolete text but you want to remove~~
`executable commands`

:❓ what’s the markdown in front-matter of post used for?

I know it’s kind of wired, but since hexo markdown don’t support convergence of lines without empty line by default. we need to configure it to merge the lines without breaking by empty line as a paragraph.