1
0
mirror of https://github.com/cotes2020/jekyll-theme-chirpy.git synced 2025-12-18 05:41:31 +00:00

Update the tutorials.

This commit is contained in:
Cotes Chung
2020-04-13 00:38:56 +08:00
parent 99aadd61c1
commit 1209879bed
4 changed files with 88 additions and 71 deletions

View File

@@ -25,33 +25,36 @@ tags: [TAG] # TAG names should always be lowercase
> **Note**: The posts' ***layout*** has been set to `post` by default, so there is no need to add the variable ***layout*** in Front Matter block.
- **Timezone of date**
### Timezone of date
In order to accurately record the release date of a post, you should not only setup the `timezone` of `_config.yml` but also provide the the post's timezone in field `date` of its Front Matter block. Format: `+/-TTTT`, e.g. `+0800`.
In order to accurately record the release date of a post, you should not only setup the `timezone` of `_config.yml` but also provide the the post's timezone in field `date` of its Front Matter block. Format: `+/-TTTT`, e.g. `+0800`.
- **Categories and Tags**
### Categories and Tags
The `categories` of each post is designed to contain up to two elements, and the number of elements in `tags` can be zero to infinity.
The `categories` of each post is designed to contain up to two elements, and the number of elements in `tags` can be zero to infinity.
The list of posts belonging to the same category/tag is recorded on a separate page. The number of such *category*/*tag* type pages is equal to the number of `categories`/`tags` for all posts, they must match perfectly.
The list of posts belonging to the same category/tag is recorded on a separate page. The number of such *category*/*tag* type pages is equal to the number of `categories`/`tags` for all posts, they must match perfectly.
let's say there is a post with front matter:
let's say there is a post with front matter:
```yaml
categories: [Animal, Insect]
tags: bee
```
then we should have two *category* type pages placed in folder `categories` of root and one *tag* type page placed in folder `tags` of root:
then we should have two *category* type pages placed in folder `categories` of root and one *tag* type page placed in folder `tags` of root:
```terminal
jekyll-theme-chirpy
├── categories
│   ├── animal.html
│   └── tutorial.html
── tags
  └── bee.html
│   └── insect.html
── tags
  └── bee.html
...
```
and the content of a *category* type page is
and the content of a *category* type page is
```yaml
---
layout: category
@@ -60,7 +63,8 @@ category: CATEGORY_NAME # e.g. Insect
---
```
the content of a *tag* type page is
the content of a *tag* type page is
```yaml
---
layout: tag
@@ -69,20 +73,23 @@ tag: TAG_NAME # e.g. bee
---
```
With the increasing number of posts, the number of categories and tags will increase several times! If we still manually create these *category*/*tag* type files, it will obviously be a super time-consuming job, and it is very likely to miss some of them(i.e. when you click on the missing `category` or `tag` link from a post or somewhere, it will complain to you '404'). The good news is that we got a lovely script tool `_scripts/py/pages_generator.py` to finish the boring task. Basically we will use it via `tools/init.sh` instead of running it separately. Check out its use case [here]({{ "/posts/getting-started/#option-1-built-by-github-pages" | relative_url }}).
With the increasing number of posts, the number of categories and tags will increase several times! If we still manually create these *category*/*tag* type files, it will obviously be a super time-consuming job, and it is very likely to miss some of them(i.e. when you click on the missing `category` or `tag` link from a post or somewhere, it will complain to you '404'). The good news is that we got a lovely script tool `_scripts/sh/create_pages.sh` to finish the boring task. Basically we will use it via `tools/init.sh` instead of running it separately. Check out its use case [here]({{ "/posts/getting-started/#option-1-built-by-github-pages" | relative_url }}).
- **Last modified date**
## Last modified date
The last modified date of the posts is recorded as `seo.date_modified`, for example:
The last modified date of a post is obtained according to its latest git commit date, and all the modified date of the posts should be stored in `_data/updates.yml`. For example:
```yaml
---
seo:
date_modified: 2020-01-04 17:05:41 +0800
---
-
filename: getting-started # the post filename without date and extension
lastmod: 2020-04-13 00:38:56 +0800 # the post last modified date
-
...
```
This date is equal to the lastest git-commit date of the post file and can be automatically generated by the tool script `_scripts/py/update_posts_lastmod.py`. Similar to the other script `pages_generator.py` mentioned above, it is also be called from `tools/init.sh`, so it doesn't have to be used separately.
You can choose to create this file manually, but as you may notice, the better approach is to let it be automatically generated by a tool script. And `_scripts/sh/dump_lastmod.py` was born for this! Similar to the another script `_scripts/sh/create_pages.sh` mentioned above, it is also be called from `tools/init.sh`, so it doesn't have to be used separately.
When some posts have been modified since their published date and also the file `_data/updates.yml` was created correctly, a list with the label **Recent Updates** will be displayed in the right panel of the desktop view, which records the five most recently modified articles.
## Table of Contents