WikilyWIKILY
All games8 Wikis · pick your game
Menu

Documentation

What an extension is made of

Updated 2026-08-13

You have been through the case against and still need a new kind of block. This is what one is made of, so you can judge the size of the job before starting.

Three parts

Four things, and the schema is the one that matters: the editor panel is derived from it, so a well-named schema produces a good editor for free.
A manifestThe extension id, name, description, and the list of widgets it ships. One file.
A widget definitionPer block: its id, palette label, description, and its attributes schema, declared as a Zod object.
A render componentPer block: given those attributes, return the markup. Usually a small server component.

The schema is the editor

You do not write an editor panel. It is derived from your attributes schema, so the type you declare is the control an author gets.

And the name you give an attribute picks a better control than its type alone would:

...ColorA colour picker.
...UrlA URL field.
...Href ...LinkA page picker that names the page it points at.
A media-ish nameThe media library.
...FieldA picker listing the columns of the connected data with what each one holds.

Spend your care on the schema. A well-named one produces a good editor for free; a lazy one produces a wall of text boxes no author can use.

That is why naming an attribute titleField rather than title_col is worth doing. Two more things earn their keep in the panel:

group:Files an attribute under a heading. Keep a text field in the same group as the switch that shows it, or an author turns a heading on in one place and hunts for where to type it.
canvasPreviewA container that draws content of its own sets this to "live", so the canvas renders the real widget instead of an empty heading with a drop hint.

Reading the page’s data

Most blocks worth writing read the entry the page is bound to. A widget declares that it needs a bound row, and the platform hands that row over: already resolved, already merged with corrections, already translated where the column is translatable.

A widget does not query anything. It receives the row and renders it, which is why an extension block can never reach another wiki’s data: it is not given a way to ask.

For what that means to the person using your block, see Extensions and Tables and rows.

Getting one in

Extensions ship with the platform rather than being uploaded, so a new one arrives by contribution.

  1. Open Manage › Extensions and use the option to build one. The wizard scaffolds the files.
  2. Write the schema first, then the render component.
  3. Check it in the editor: add the block, and look at the panel your schema produced.
  4. Submit it. It is reviewed like any other code.

That review is a feature rather than a hurdle. An extension runs on every wiki that enables it, so a mistake in one is not confined to your pages.

Keep it small

A block that draws a skill tree from a table outlives one that draws your skill tree, and is usually no harder to write.

The difference is whether the specifics live in the code or in a column. And if the block turns out to be mostly arithmetic with a bit of markup around it, stop and reconsider Lua.