Editing Wiki Pages

Now that you have our wiki locally, you can edit the files right on your device. If you don't know how to work with VSCode, there are some very good videos from Microsoft itself here.

To make our pages look prettier, we have a lot of great tools, that you can use to highlight sections, insert components, insert images, and much more!

Our wiki uses Markdown to provide a way of modifying the way text looks. With special Vue-Components, we can add things like buttons, spoilers or code blocks. Its also possible to use some HTML, but we only recommend this for advanced users and won't cover this in our guide.

Page Setup #

Each page consists of two parts: The Head (Front Matter) and the Body.

Inside the Head you write the most important information about your article.

---
title: How to contribute to our wiki
mentions:
-   TheItsNameless
---

The title is required, as it is the name shown in the bar on the left side. Mentions isn't needed, but it would be great if everyone knows who made the great article they are reading!

After the Head, you write the Body. The body is just your whole content. A common mistake everyone does the first time is to put the page title as a level 1 header on their page. You don't have to do this, because the title given in the Header will already be placed on top of your page.

List of categories:

• Guide
• Extra
• General
• Tutorials
• Vanilla Re-Creations
• Documentation
• Commands
• On Event Systems
• Scoreboard Systems
• NBT in Depth
• Legacy Scripting
• Ideas

New categories can be defined a section's index.md file.

List of tags:

• beginner
• beta
• easy
• experimental
• expert
• guide
• help
• info
• intermediate
• outdated
• recipe
• scripting
• system

To make a tag display in the navigation, simply add it to the displayedTags array in `.vitepress/theme/Components/Navigation/NavLinkTag.vue``

Wiki Add-On #

Sometimes we need to give a template/example pack after a guide. For this purpose we use separate GitHub repository: wiki-addon. Please, add your packs there. It helps us to maintain all add-ons and keep them up-to-date.

Viewing the Wiki locally #

Its really hard to know how your article will look when its finished and published. To help with that, you can use a tool called npm!

In VSCode, in the top bar, click on "Terminal", then on "New Terminal".

The first time you view it locally, you have to type npm install and wait until its finished. This is just done the first time (or when you have some .vue errors)!

To view the wiki locally, type npm run dev and press enter and wait until its finished loading. It will show you this:

Hover over the part where it says "http://localhost:3000/" and press ctrl and left-click. Your browser will open with the wiki.

Done! Every time you change and save a file in VSCode it will automatically be updated in your browser.

Viewing the Built Page #

The above tool shows you how the Wiki will look when it is built. But sometimes there are some errors arriving which you only get if you build the page.

Building the pages means compiling every markdown-page to a .html-page, which will be hosted on our servers. If you just use npm run dev, the pages are not compiled that way and there may be some errors which are not showing in the developer view.

To build a page, follow the above process, except for the step where you need to type npm run dev. Instead, type npm run build which will build the page.

[
	'entities/vanilla-usage-components.md',
	'entities/vanilla-usage-spawn-rules.md',
	'entities/vuc-full.md',
	'entities/vusr-full.md',
]

This might take a while. If the process finishes without any errors, you can view the built Wiki by running npm run serve. You need to open the link given in the Terminal and you are done!

Working with Markdown #

The wiki uses Markdown, a powerful text-formatting syntax. To learn more about Markdown, visit the official Markdown Guide!

We wont teach you the whole Markdown-Language, but there are some things that you need to pay attention to!

Linking #

If you want to refer to another website, like the Microsoft Docs, you can use links.

To link something in Markdown, you can either just write out the whole link:

https://wiki.bedrock.dev

Or show some other text instead of the link:

Click here!

Linking to sources outside the wiki #

To link to another source, just copy the whole link url (including the https-part in front of it) and paste it in the field:

[Click here for the official Microsoft Docs](https://docs.microsoft.com/de-de/minecraft/creator/)

Click here for the official Microsoft Docs

Linking to other pages in the wiki #

You can create links, that redirect you to other pages in the wiki. These are called relative links.

[Redirect to the contribute page](/contribute)

Redirect to the contribute page

[JSON Arrays](/guide/understanding-json#arrays)

JSON Arrays

[Go to Working with Markdown header](#working-with-markdown)

Go to Working with Markdown header

To redirect to another page, just look in the file explorer. The main folder is the "docs" folder. To link to a page thats directly inside this folder, you can just write /pagename, like /contribute to link to the contribute page. Every page that is inside a folder has to be accessed by writing the name of the folder, a slash, and then the page name: /blocks/block-materials.

Working with Components #

Our wiki uses special Vue-Components, which you can use to add things like Buttons, Spoilers, CodeBlocks, etc.

Panel #

Panels are used to inform or warn the user about some really important stuff. There are three types of Panels: tip, warning and danger.

:::tip
some tips here
:::

:::warning
a warning here
:::

:::danger
danger zone
:::

Panels are created by typing three colons and the type of the Panel. Then you can write your content and at the end you close the Panel by typing just three colons.

You also can add headers for panels:

:::danger STOP!
danger zone
:::

CodeHeader #

CodeHeaders are used to nicely wrap codeblocks, so a user can easily copy the code inside them. You can also add some text, like a file path, so the users know exactly where to put this code. Remember to format json. You can use this tool.

<CodeHeader>BP/blocks/example.json</CodeHeader>

```json
{
    "some": "json"
}
```

{
	"some": "json"
}

The filepath goes between the two HTML-Tags. Make sure to follow our Style-Guide when describing filepaths:

• If you link inside a Behavior-Pack, place BP in front of all other files:

✔️ BP/blocks/example.json

❌ YourBehaviorPack/blocks/example.json

• Same for the Resource-Pack, use RP in front of all other files:

✔️ RP/manifest.json

❌ YourResourcePack/manifest.json

On the next line after the closing tag, you have to start a code block to use this Component, as shown in the example above.

Button #

A Button works like a link, but is more noticeable for the user.

<BButton
    link="https://youtube.com"
    color=red
>your button text</BButton>

<BButton
    link="/favicon.ico" download
    color=red
>Download Wiki Logo</BButton>

The text between the two HTML-Tags is the text that will appear on the button.

The link can either be an external website, or a page in our wiki. For the last case, use relative links, as described in our linking-section.

Checklist #

The Checklist can be used to tell the reader about certain things that need to be done or to show what has already been done.

<Checklist>

-   [x] This will be checked!
-   [ ] This won't be checked!

</Checklist>

This will be checked!

To add new entries to the Checklist, you need to create a Markdown List, and start each entry with [x] or [ ].

If you start the entry with [x], this entry will be checked.

If you start the entry with [ ], this entry won't be checked.

Pay attention to the empty lines between the content and the tags! If you forget these, this component will not work!

Spoiler #

A spoiler is a Component that can be used to hide some content, so it doesn't block the whole site.

<Spoiler title="title">

text here

and here

</Spoiler>

The content between the two tags is the content that will be hidden.

Pay attention to the empty lines between the content and the tags! If you forget these, this component will not work!

Label #

A Label is a small icon with uppercase letters that can be used to give your articles more flair.

<Label
    name="name"
    color="green"
>label</Label>

name

Don't overuse them! They look cool, but someone could really give them too much attention and forget to focus on other important parts of your article.

FolderView #

FolderViews are Components which can be used to show a setup of files, like in our Project-Setup guide.

<FolderView
	:paths="[
    'com.mojang/development_resource_packs/guide_RP/manifest.json',
    'com.mojang/development_resource_packs/guide_RP/pack_icon.png',
    'com.mojang/development_resource_packs/guide_RP/texts/en_US.lang',
    'com.mojang/development_behavior_packs/guide_BP/manifest.json',
    'com.mojang/development_behavior_packs/guide_RP/pack_icon.png',
    'com.mojang/development_behavior_packs/guide_RP/texts/en_US.lang',
    ]"
></FolderView>

The :paths Attribute is a String, that contains a List of all separate file paths. This String must be written with double quotes! Each file path must be written entirely and has to be wrapped inside single quotes.

YouTubeEmbed #

A YouTubeEmbed can be used to embed a YouTube Video in your article.

<YouTubeEmbed
    id="dQw4w9WgXcQ"
/>

WikiImage #

A WikiImage is an alternative way to add an image in your article.

<WikiImage
	src="/assets/images/homepage/wikilogo.png"
	alt="alternative text"
	pixelated="true"
	width=420
/>

Unlike a markdown image, the image can be pixelated here.

To make a download link for image, use <a href="wiki_image_path" download>My Text</a>:

My Text

CardLink #

With CardLinks you can make fancy boxes with an image and a text, which contains a link!

<CardLink
  imgsrcLight="assets/images/homepage/wikilogo.png"
	title="title"
	link="https://google.com"
/>

title

Don't overuse them! They look cool, but someone could really give them too much attention and forget to focus on other important parts of your article.

New Lines #

Always remember to add new lines before and after components!

Wrong:

-   one
-   two
<CodeHeader>BP/blocks/example.json</CodeHeader>
```json
{
    "some": "json"
}
```

Correct:

-   one
-   two

<CodeHeader>BP/blocks/example.json</CodeHeader>

```json
{
    "some": "json"
}
```

Formatting Guide #

Everyone likes to read wikis that are perfectly and consistently formatted.

Well, its hard to realise that. And we don't want perfectly and consistently formatted wikis. But if everyone tries to follow these simple rules, all users will have a better time reading our wikis!

General Rules #

1. For naming packages, folders, etc. consult our Style-Guide.

Headings #

1. Don't use level-1 headings. Your page starts with a level-1 heading which has the same title as written in the Front Matter.
2. Try to avoid heading levels higher 4. They wont show in the right sidebar (only level-2 headings appear there) and won't have proper styling.
3. Use the Title Case style. For example,
   • Welcome to the Wiki!
   • How It Works
4. Don't use : in your headings!

Some examples:

✔️ ## A Page

❌ # A Page

✔️ ### Some Other Layer

❌ ###### Some Other Layer

✔️ ## My Own Article

❌ ## my own: article

✔️ ## Next Steps

❌ ## Next Steps:

JSON Code #

1. Use CodeHeaders, unless it is illogical or not possible.
2. Fully extend JSON Code if it improves readability aka. as "Prettified Code".
   • Do not extend .geo.json files as it would be too long.
3. If the code is too long or not necessary, wrap it in a spoiler component.
4. Use RP and BP as root folders.
5. Make comments but not many.

Describe the most important things in comments inside the JSON, you can tell about other components after the code. Also follow our comments style. Example:

{
	"format_version": "1.16.100",
	"minecraft:item": {
		"description": {
            // Describing an object with components.
			"identifier": "bs:copper_coin",
			"category": "items"
		},
		"components": {
			"minecraft:max_stack_size": 64, // Short description a value/component.
			"minecraft:creative_category": {
				"parent": "itemGroup.name.items"
			},

            "minecraft:use_duration": 3.5,
            "minecraft:icon": {
				"texture": "copper_coin"
			}
            // Make notes about a group of specific components (icon and use_duration in our case) used above this way.
		}
	}
}

• minecraft:max_stack_size

...

• minecraft:creative_category

...

Markdown Formatting #

This section is only for the readability of your Markdown files. It wont be visible in the wiki.

1. If you use lists or numbered lists, use tabulators or 4 spaces after the - or number.
2. Prettify Markdown tables. Use spaces and - to extend all rows to the same lengths. Use one space before and after each cells content.
3. Don't use HTML-Tags, even if they are possible. You can use them, if you know what you are doing, but only if its absolutely unavoidable. If you have an Idea for a new Component, that could be useful for everyone, let us know and maybe we will add it!

✔️

-   list

❌

- list

✔️

| Some Data | Aaaaand More Data |
|-----------|-------------------|
| here      | and here          |

❌

| Some Data | Aaaaand More Data |
|-----------|-------------------|
| here      | and here          |

For tables you can download an extension. However always check how it formats it.

✔️ <WikiImage src="my/image.png"/>

or

✔️ ![](my/image.png)

❌ <img src="my/image.png" />

✔️

`code`

❌

    code

You can do space before text this way:

> text:

text

Sometimes you need to comment something in .md file.

<!-- Comment! 👀 --> ‹- It is here!