From Miraheze Meta, Miraheze's central coordination wiki
So, you want to add infoboxes in your wiki? Then this guide is for you!
Please, read it carefully.

Infobox is a template which looks like a card or table presenting short article summary at its very beginning. One might say that infoboxes are one of the most recognizable parts of wiki sites – even if the only wiki you've hanged on was Wikipedia, you'll see infoboxes on the vast majority of its articles.

On Miraheze, once your wiki creation request is fulfilled, you'll get a clean MediaWiki (the software that powers the majority of wiki sites nowadays) instance, with several additional extensions enabled by default, and a default Main Page. The rest stuff, such as templates and other extensions, has to be created or enabled manually. Thus, you'll have to add infoboxes to your wiki by yourself. In this essay I'll try to cover most important parts of infobox creations and other details.

Template basics[edit | edit source]

Infoboxes are templates. If you never edited on wikis or worked only in Visual Editor, I strongly recommend you to check this MediaWiki guide first. From my experience, such users don't really know how templates work and might get confused. If you know all this stuff already, you are free to proceed to the next section. Otherwise – it's important to understand what you're doing (or will have to do sooner or later).

So, infobox being a template means that you have the "card" itself stored separately, on special kind of page, which you then use on actual articles, normal pages by just filling up "card's" input fields.

The thing you should understand: an infobox won't work if you are not giving it the values you need on the actual article page. You should fill up the "fields" of the "card". Don't pay too much attention to how the infobox looks on its own template page because it's essentially empty and is useless until you give it values.

Infobox types[edit | edit source]

The first thing we should understand about infoboxes is that they're tables, usually consisting of rows with 1-2 cells, more in fancier variations. Then, we should consider what kind of infobox we're going to use. The case here is not only how easily the infobox template is going to be created, but how to easily maintain it in the long run, without much trouble.

So, the types are:

  • just tables, aka classic infoboxes
  • portable infoboxes – method of coding developed by Wikia/FANDOM, and adopted by other wikis via extension
  • infoboxes powered by Lua modules, mostly used on Wikimedia projects

If we'll arrange these types from easiest to hardest to create and maintain, it's gonna be: Portable > Classic > Lua.

If you want to have an infobox one to one how Wikipedia does, you, most likely, wouldn't actually need that. As an experienced wiki admin myself, I urge you to check the methods and nuances described below first.

Creating infobox by yourself[edit | edit source]

Portable[edit | edit source]

Starting with the easiest method – Portable Infobox. It's an extension developed by FANDOM (previously Wikia), which lets users create these specific tables in easier way, with specially designed and rendered XML-like tags. For example, the main, container tags are <infobox>...</infobox>. This portable infobox doesn't rely on traditional template coding (the figure brackets and simple parser functions) to provide the basic stuff that makes an infobox what it is.

To use PI, the extension has to be enabled first: check you admin sidebar, aka ManageWiki, and click on "Manage this wiki's extensions" link. Then go to "Parser hooks" tab or use search function to find "PortableInfobox"; tick the box and save changes.

Now, the infobox can be either:

  • Coded manually – FANDOM offers detailed guides with examples, here and here. The PI code itself is easy to learn, and additional experience with usual template wiki coding and parser functions will let you make fancier stuff in it.
  • Made with visual builder – this variant is for those who never had any coding experience and might find it confusing at first. However, the builder's functions are very limited and in the end you will get a very basic, simple infobox (which, of course, can be enhanced later by editing the template). To use it go to Special:InfoboxBuilder page on your wiki.[1]
How to use visual builder
Infobox Builder interface

The builder consists of four areas: infobox preview (1), buttons to add elements (2), parameter settings (3) and part with clear and finish buttons (4).

Upon opening the builder you have a default infobox with a title header, one image block and two simple data rows with labels. These are basic elements you're able to add via buttons in the right upper corner of the builder; the new element will appear at the bottom of previewed infobox. Already added elements can be moved around by holding and dragging them with mouse click.

The parameters have default names and properties, which can be changed: click on the element in infobox preview, and its properties will appear on the right.

Title header, with title parameter and default value – {{PAGENAME}}, which puts the name of the page where the infobox will be used, can be left like this, it's commonly coded like that. Clicking the upper right "Title" button will identical, big header at the bottom of infobox; if you want to add a smaller header (with fixed title or as parameter), you'll have to add <header> tag after template creation, see FANDOM coding guide linked above.

Image block by default uses image parameter, but doesn't have a default value. It can be either left empty – the block won't be rendered at all (the preview uses MediaWiki logo just as example), or given file name of image to be used as placeholder. File name must include file extension (.jpg, .png, etc), but doesn't need File: prefix; same goes for when you normally use infobox. Another, separate image block can be added with upper right "Image" button, but needs to be given different parameter. But several images can be used within single image block as well, either as tabs (explained further below) or with advanced template coding after template creation.

Data rows here are given generic dataX parameters and just a "Label". Click on the element and change parameter and label names to proper ones. Bear in mind that parameter names are case sensitive, and it's better to make them lower case. If label property is left blank, the data row will become a single cell just for value of the parameter. But if you type a space break in it, the label cell will remain, just seemingly empty; this is handy when you want to make several parameters data rows to have one label, for example "Born" with birthdate and birthplace parameters (see images below).

To delete element click on it and then use "Delete element" button at the bottom of element settings area. The red "Clear infobox" deletes the entire infobox in the builder.

After finishing your infobox, click the blue "Publish infobox" button, then add name of the template in pop up input field.

The only thing about PI, which might put someone off, is its visual design – since it was created by FANDOM for mobile version of their site, it inherits platform's general feel. But it can be fixed via CSS, even on FANDOM itself it's a normal practice for wikis to modify PI's look drastically. More about that in this section.

Another nice feature of PI is native support of tabs in the image block, so you can insert several images. It's done with MediaWiki's gallery tags:

|image = 

Also, there will be an additional special page which will list all PI templates of your wiki, Special:AllInfoboxes.

Classic[edit | edit source]

Since infoboxes are technically tables, this is how they initially were coded on various wikis – with HTML tags or wiki table markup. Thus they are also called "classic infoboxes".

The good thing about this method is that your infobox won't depend on additional extension of things like Lua modules, so chances it suddenly breaks are nearly zero. The not so good thing – this method is for those who already knows either HTML or wiki markup well enough to not get lost in the code. HTML tags are more preferable because the need of parser functions in a wiki markup table will require fake pipes ({{!}}), making the code harder to read. The use of parser functions makes the process even more challenging, because usually if some parameter in infobox is not provided and doesn't have default value, the entire part of it (like a row), corresponding to that parameter, should not appear (which is not a problem for PortableInfobox, described in previous section). Here's an example of what you'll have in this case:

{{#if: {{{X|}}}|<tr>
          <td>X label</td>

And the wiki markup version:

{{#if: {{{X|}}}|
{{!}} X label
{{!}} {{{X|}}}

Same goes for tabs functionality – you gotta code all by yourself.

If you want to see a full classic infobox example you can check them on my wiki. You are also allowed to import/copy (with credits) and modify them as you want.

Lua[edit | edit source]

Not much can be said in this essay about infoboxes powered by Lua modules. Lua is a programming language on its own, it provides a lot of flexibility to template functionality, but the downside is that unless you actually know Lua, you won't be able to create such infobox as quickly as with previous two methods. And even with copying code bits from existing templates or asking someone else to code it for you, you still will have a hard time maintaining or modifying such infobox. The reason why they're used on Wikipedia is because it's simply huge and very complex, covering a vast amount of subjects and themes, and thus require a lot of different infoboxes. Those infoboxes are coded with a main, base "infobox" template, which itself is build with Lua and uses many additional subtemplates. The majority of specific wikis, focused on a single subject or number of subjects sharing one trait, very rarely can achieve the same amount of content to require such complexity, so the previous methods – portable and classic, are usually enough. FANDOM is probably the clearest example of this, where portable infoboxes are implemented on nearly every wiki over there.

Taking infobox from another place[edit | edit source]

A rather tempting alternative to building infobox by yourself is taking/copying/importing an existing one from another wiki, preferably an established one. And, of course, different wikis can use different infobox types mentioned above.

Very often, when starting a wiki, newbies fell into a trap of importing stuff from Wikipedia. As explained earlier, WP templates are very complicated. Import in this case is rarely fully successful, which means that you'll waste a lot of time on fixing the many errors this process will bring, adding missing stuff manually and having a hard time comprehending how to change things for your needs, unless you know Lua already. See also: Don't import Wikipedia.

So, what about portable and classic infoboxes? Good news – you can transfer them with very little or no hassle at all. Fan wikis are especially lucky in this case: you can easily find something fitting on FANDOM, since portable type is the most widely used here.[2] Before importing you'll just need to enable extension first, and maybe force the template to work after import with an cache purge or empty edit.

Now, there's copying – literally copy/pasting template's code to a new page on your wiki, and then there's importing, one of MediaWiki's own features. Which one is more preferable? Import, because:

  • Licenses/copyrights are a big deal on wiki sites; most wikis work under CC BY-SA, so if you took stuff from such place it should be clear and credits are due, and importing ensures that (and of course, if there's more strict license, you better find another wiki).
  • There's always a chance template uses some other templates, specially created subtemplates or modules, and in export/import process you can get all this stuff included within single session.

Thus copy/pasting is advisable if you are sure the template is simple and won't throw dependencies errors at you later, and you will provide some credits to original author of template manually.

Depending on which wiki you've decided to take template from, there are two ways to perform import – the usual, which works with any MediaWiki instance, and more specified which works only with several Miraheze and Wikimedia wikis.

From any wiki via file[edit | edit source]

The first method involves download and upload of an XML file. The process starts on the source wiki – you should go to its Special:Export page. In the "Add pages manually" input field type name of the page you want to import, with namespace prefix, in our case Template:. Further below you'll see 3 checkboxes – all of them must be checked:

  • "Include only the current revision" – it's alright for templates to be exported without full page history, otherwise (for example, with articles) it's not advisable.
  • "Include templates" is the most important one, it will hook along all subtemplates as explained above (it's not checked by default).
  • "Save as file" – so you'll get an XML to upload in on your wiki, otherwise you'll just get a page with raw XML code, which has no use for us.

After downloading the file head to Special:Import page on your wiki. In the "Upload XML data" form select XML to upload. The only tricky setting here is "Interwiki prefix": if you are getting template from FANDOM, you should type fandom in this field, if it's Miraheze wiki – mh. In case of other wiki farms or independently hosted wiki projects you'll have to find the right prefix by yourself, or import won't get trough.

From Wikipedia and the likes directly[edit | edit source]

The second import method is limited to 6 wikis acting as the source: Miraheze projects – Miraheze Meta (this place), Developers Wiki, Login Wiki, and Wikimedia projects – MediaWiki, Wikipedia, Wikimedia Meta. In this case import can be done directly without files. Go to the same Special:Import page on your wiki and scroll down for "Import from another wiki" form. In the "Source wiki" dropdown choose the wiki, then in "Source page" field type name of the page you want to import (with namespace prefix). Like in export form, it's better to include all templates. But bear in mind what was said earlier about Wikipedia templates being overcomplicated.

If you want to go this direction, Mediawiki has an importing Wikipedia infoboxes tutorial with all of the complex steps. We do not support Extension:Wikibase, so those parts of templates would need to be removed.

Miscellaneous[edit | edit source]

Visual Editor[edit | edit source]

In Visual Editor – a type of page editor opposite to Source Code one, templates can be inserted, but if they have parameters chances are you won't be able to fill them up right away. To make a template fully accessible in visual editor you'll have to make additional coding in it with extension called TemplateData. It is available on Miraheze, but it's really a whole different beast, and I'm not going to explain it here, the manual on MediaWiki should cover it well.

An alternative here would be temporarily switching to source code, adding infobox with boilerplate (blank infobox code to copy/paste and fill up, usually appears in template's documentation) and then switching back to visual. For how to use templates in source code editor see the MediaWiki guide.

Inclusion and exclusion[edit | edit source]

In templates some parts of the code can be excluded from usage on actual articles, or oppositely, some parts can be limited to be used. This process is also called transclusion, and is done with special set of tags:

  • <noinclude>...</noinclude> – the content between these tags will appear only on real Template: page, but won't appear when template is used on any other page. It's usually the case with documentations – template fragment which explains how it works or should be used, or categories made especially for templates.
  • <includeonly>...</includeonly> – these tags will hide their content on Template: page, but will still allow it to appear on other pages. They are usually used to make template page appear cleaner, especially if there is documentation with usage example, or to prevent default categories – made for articles especially, from applying on template page (unless you are using documentation subpages, see next section).
  • <onlyinclude>...</onlyinclude> – these tags are rarely used, but still can be handy. Content inside them will appear in both template and normal pages, but it will exclude from the latter whatever is outside of them. They also will overrule the other two tags, <noinclude> and <includeonly>, if they are presented.

Documentation[edit | edit source]

Templates can have documentation, which explains how the template works, what it uses and how it should be used, and contain boilerplate code and examples of usage. Template documentation isn't obligatory, but it is, of course, better to have some kind of instruction for other editors, especially new ones, or in case you're leaving the project behind. The most important part however, is that documentation shouldn't break the template itself, either with errors in the code or just by appearing on a page when it shouldn't.

There are two ways of implementing documentation:

  • directly on Template: page, inside <noinclude> tags
  • separately on a subpage, which would be linked (transcluded) on Template: page (again, inside <noinclude>)

The second method is considered to be more clean, especially for template code, and is more preferable for TemplateData extension (see above).

Subpage is usually created by adding to template's full name /doc ending. For easier implementation a separate documentation template is used – it appears as header, which indicates that a documentation will follow below, and creates the subpage link. Also make sure subpages are allowed in "Template" namespace settings (see "Manage this wiki's namespaces" in admin sidebar).

Again, like with many other things, it is not advised to import Wikipedia documentation templates or use them as a gold standard, because of their sheer overcomplicated nature. It can be done in much simpler manner: here is an example from my wiki – you are free to copy and modify it as you want.

Once you've inserted {{documentation}} in the real template, click on red "/doc" link it has added, and create the subpage itself.

Default categories[edit | edit source]

You can make infobox, or any template, to add articles into categories by default, or with some parameters/values. For simpler, first case you have two methods: use <includeonly> tags (explained here) or by adding this code piece at the bottom of the template, outside of <noinclude> tags:

{{#ifeq:{{NAMESPACE}}|Template|<!-- do nothing -->|[[Category:...]]}}

The parser function here checks whether the page has Template: prefix, and if it doesn't, it will add article to further listed category. For example, your Template:Character will add article to Category:Characters automatically, and the editor won't have to type the category in [[...]] manually. But that way you also won't be able to exclude the page from said category, unless you'll remove this code from template itself. This method is also more preferable if you are using documentaion subpages with template usage examples.

The other case, inserting a category by tying it with some parameter, will require other parser functions. For example, in infobox about a character we have parameter group. At the bottom of template's code (inside previous function which excludes template namespace) I'll add this piece:

{{#if: {{{group|}}}|<!-- do nothing -->|[[Category:Independent characters]]}}

This function, #if, analyzes our parameter: if editor provided some value to it, i.e. they added some group's name here, nothing would be done. But if parameter was left blank, function will insert this page in "Independent characters" category.

For more info on parser functions check this MediaWiki help page.

Styling[edit | edit source]

Short answer – CSS.

Long answer – CSS defines design aspects of any web site nowadays, and wikis are no exception. It's coded on separate pages and applied to the entire site via classes or ID's, without the need to manually add inline styling for each element. Example of inline styling would be:

<div style="width: 30%; float: right; background: grey; border: 2px solid black;">...

But with CSS we will have just <div class="example">... and on CSS page:

.example {
width: 30%;
float: right;
background: grey;
border: 2px solid black;

And this class can be used in as many elements as you want.

If you make infobox from scratch, like classic one, you create and define classes by yourself. If you go with portable, which already has its own structure and styling, you should modify it. But first we need to determine what classes/ID's it has. PI CSS guide on FANDOM lists some them. But the usual process is using browser's element inspector tool (depending on browser of your choice it can be called with right mouse click on the element or via menu, as developer tool, etc). A panel with page's HTML code, styles of element and other properties will open. In the styling section you can change existing or add new CSS rules and see how element will look on the fly (these changes are temporary and will disappear on page refresh).

Once you settled on what changes has to be made, they can be added in actual CSS. There are several places to do that on wiki sites, but for templates the most common are:

  • MediaWiki:Common.css page – this is the main CSS page of the wiki, as the code listed here will apply on entire site not matter what skin (theme) your wiki uses. It's handy if design of your infoboxes is not complicated and don't have some sort of types with different appearances.
  • /styles.css subpages created with Extension:TemplateStyles – oppositely, this method is more preferable if you want to give different looks to different infoboxes. It also will free Common.css from much code to load on every page of the wiki every time, in other words – the styling subpage will load only if template is used on the page. For usage details see this help page.

As a testing ground you can use your personal CSS, which will be a subpage of your user page: User:<your username>/common.css. Portable Infobox also has an alternative CSS application with themes (see previously linked FANDOM guides).

Coming soon[edit | edit source]

Things I'll be working on later and will make available on Miraheze Dev Wiki for everyone to use:

  • Wikipedia restyling for PortableInfobox
  • PortableInfobox versions of some highly popular Wikipedia infoboxes

Still need help?[edit | edit source]

If you still need help with your infobox, please don't hesitate to join Discord and ask or alternatively use Community Noticeboard.

Notes[edit | edit source]

  1. There is currently a bug which prevents builder from loading on first try or at all in Firefox; if refreshing the page doesn't help, try using another browser.
  2. As for 2023, it seems like FANDOM has limited the set of pages available to view for logged out (anonymous) users, including the ones need for export/import, however the source code can be copied from template's page (but be aware of possible dependencies).