What's all this? You're currently viewing the articles that make up the Knowledge Base. It's all built on Jekyll, a static website generator we use.
Want to help contribute to the Knowledge base? Write or update an article!
- The guides must be clear and well explained for the user to understand.
- Fact check and make sure the information you're providing is accurate.
- Proofread for any grammatical and spelling mistakes.
- Validate markdown and html syntax.
- Provide proper frontmatter.
- Use valid links and images.
- Make sure guides are up-to-date.
All articles are stored within the content/_posts/ sub-directory. When creating an article, create a .md file under the correct section, category and sub-category folders. As an example, if you were to create an article that explains how to install and use a plugin in Minecraft Java, the file would be created as such: content/_posts/minecraft/modification/plugins/yyyy-mm-dd-plugin-name.md. You're required to add the date at the beginning of the file name in the YYYY-MM-DD format. These dates are used to show when the article was last updated, so that users are aware if an article is up-to-date.
Articles are written in Markdown. Writing in Markdown is very easy to do. If you need help understanding how to do certain tasks, like creating a link, inserting an image or creating a list, look here.
If you wish to add an alternate version of a guide for a different Minecraft edition (Java or Bedrock). Use a replica of the other title and permalink with the corresponding category (Java or Bedrock) switched.
The frontmatter is the block at the top of every article surrounded by a pair of triple dashes ---. As the frontmatter is based on YAML, ensure that the correct syntax is followed:
---
layout: post
title: "Title of Article"
category: Java
tags: General
description: "Here is the description of your guide"
keywords:
- keyword: "dynmap"
- keyword: "world"
matches: ["live", "browser", "map"]
permalink: /minecraft/java/general/name-of-article
image: "link"
author: Name
icon: book-bookmark
---| Metadata | Description |
|---|---|
layout: |
Must always remain as post |
title: |
The title of your guide, make sure it contains the necessary keywords to make it stand out |
category: |
Any of the categories in the content/_categories/ folder (Case sensitive) |
tags: |
Any sub-category; they are each listed in their corresponding category file in the content/_categories/ folder. (Case sensitive) |
description: |
A description for your guide, keep it concise, informative and interesting |
keywords: |
All keywords relevant to the topic. Keywords without a "matches" key will be used as a standalone search query while those with the key will be combined to form a more accurate query. |
permalink: |
/section/category/sub-category/short-title (Lowercase) |
image: |
A direct link to an image to be used as a thumbnail (Optional) |
author: |
Name of the current author and maintainer. For multiple authors (maximum of 3), use the the array format. |
icon: |
Direct link to an icon. (Optional) |
toc: |
Whether to enable table of contents or not. (Optional, default value is true) |
Encompass your values in quotation marks if it contains symbols other than slashes
/or hyphens-. New authors must request for their github account to be manually added to display correct profile pictures.
The below frontmatter options are extra options for Minecraft modifications and addons (plugins, mods and data-packs) in addition to the default options:
---
icon: "link"
mod-name: "Name of mod"
mod-type: "Plugin, Mod, Standalone"
mod-url: "link"
---| Metadata | Description |
|---|---|
icon: |
Direct link to the mod's icon |
mod-name: |
Official mod name |
mod-type: |
The software type, such as plugin, mod, standalone, etc |
mod-url: |
A link to the mod's official page or website |
If you wish to include a post from an existing category in the Getting started category, use these extra frontmatter options:
---
getting-started-tag: General
post_order: 1
---| Metadata | Description |
|---|---|
getting-started-tag |
Functionally the same as tags: but specific to the getting started category only |
post_order |
Order of the post within the Getting-started category |
Using "# Title of Article" isn't needed; the layout will automatically add the title of the article to the top of the guide. That being said, always use "## Subtitle" instead.
It is recommended to a related Github flavored emoji at the beginning of main subtitles (## or h2) to improve user friendliness (such as: ## :earth_asia: Dynmap). Emojis/icons will be explained further in the next section.
Github emojis and a few server software icons are supported to improve user friendliness and add vibrance to your articles:
To use a Github emoji, copy its name including the colons (e.g: :smile:) and paste it in the article, we only recommend using them in main subtitles (## or h2) and tabs to avoid over-saturation, a list of all Github emojis can be found in this cheatsheet.
We have a built in recommended icon and a few server software icons you can use anywhere in your article, with the latter especially so in tabs. We currently support recommended for recommended icons and spigot,paper, purpur, forge, neoforge, fabric, quilt, velocity and bungeecord for server software icons. To add the icon to your article follow the format below, make sure to replace icon with one of the options listed beforehand.
<i class="icon"></i>If you're adding an image to the files, follow the structure below:
Replace Alt text with an alternate text incase the image is not loaded properly or for accessability purposes. ... must also be replaced with the actual path of your image including the file name and extension.
When typing out steps using lists, make sure to separate each step with a blank line. Otherwise, a <p> tag will not be generated.
When navigating around the Dashboard, four colors (Orange, Green, Red, Blue) can often be seen on different buttons such as Restart, Save File, Delete, Connect, etc. It is a good idea to color these words with the same color as can be seen in the Dashboard to make the guides more user friendly and vibrant. Fortunately this can be done by making the word bold (** **) and immediately following it with an inline attribute with the color as a style name like so:
**Connect**{: .blue } **Delete**{: .red } **Restart**{: .orange } **Save File**{: .green }
In certain articles, you may want to use tabs to group separate alternate procedures in one place, such as procedures on configuring a software with a plugin and mod version:
{% tabs software %}
{% tab software plugin %}
Steps for the plugin go here
{% endtab %}
{% tab software mod %}
Steps for the mod go here
{% endtab %}
{% endtabs %}
The first word after the tab keyword is used to group the tabs together, while the words after will be displayed as the tab label. If the content of tabs have a similar structure, place the tabs under each heading rather than placing headings in tabs.
There are 4 custom blockquote, which are each used in different context:
Note:
Used to add additional information that does not fit in its own paragraph.
> hi this is blockquoteSuccess:
Used to signify success messages or completion.
{: .success}
> hi this is blockquoteWarning:
Used as a warning to avoid something.
{: .warning}
> hi this is blockquoteError:
Used as a way to display common errors or issues.
{: .error}
> hi this is blockquoteLearn how to embed a YouTube video
<video controls preload="auto"><source src="https://example.com/video.webm" type="video/webm" src="https://example.com/video.mp4" type="video/mp4" /></video>If you're adding a video to the files, use a path like
content/assets/videos/posts/....
Make sure to provide both webm and mp4. Webm are much smaller and load faster, although an MP4 file is required as not all browsers support webm format. So the MP4 is more of a fallback option if the user's browser doesn't like the webm format.
Create a pull request in this repo and title it using the following format: "New: Name of Article" or if you're editing an article, title it like "Edit: Name of Existing Article".
Your edit will be reviewed by our support team along with your code to check for any syntax errors.
All PRs are closed if inactive for a long period of time, usually about 3 weeks to a month.