New Wiki
Open, ConfirmedPublic


NOTE: The new Wiki is in it's transitional phase atm.

It’s goal is much more limited than previous one, basically this is a
developer/module team members tool to share technical docs. It should
also have general help info like setting up a new build of blender, some
code architecture docs, etc.

Moving a subset of old wiki pages is on-going process.

Old wiki shall be locked (made read-only) in a few weeks, proposed date
is June 15th. That means that developpers (also including GSoC students)
should request accounts on new wiki if they do not have one already, and
move their pages there.

Note that once in read-only state, it will still be possible to access
and copy wiki-markup content of the pages!

Recently Dan set up a fresh install of Media Wiki and migrated the old pages to it. This can be found at

To set up an account (developers only) just informally poke a wiki administrator for now
[these are @Campbell Barton (campbellbarton), @Brecht Van Lommel (brecht), @Sybren A. Stüvel (sybren), @Dan McGrath (dmcgrath) atm]

There are still several todos


  • We should keep the theme as close to the original to make maintenance easy.

Clean Structure

  • Remove the wiki versions (2.4, 2.5, 2.6) and instead only have one that is alway the latest.
  • Make all pages independent. Pages like are really confusing to edit.
  • Remove namespaces, so [[Building_Blender/Windows]] instead of [[Dev:Doc/Building_Blender/Windows]] (can be done after creation by "moving" the page)

Excluded from Wiki Migration

There are a couple of sections that mostly contain historic content and it is preferred to not port these over
(but this has to be checked carefully -- if in doubt, ask around... help in these decissions is welcome!)

What still needs to be done

  • Building
  • Tools
  • Developer Introduction
  • port Architecture docs (this is higher priority but needs special care to make sure we dont port "out-of-date" information)
    • Bmesh
    • RNA / DNA
    • ...
  • port Addon catalogue / docs (these will be moved to the blender manual [] though -- some of the docs already made their way into the new wiki but have to be moved again [to manual]), also see T54097
  • move Todo section ( to phabricator (parent) tasks. This way intern-linking (existing) phabricator TODO tasks is just more useful, too. As a first step, this has now been brought over in its current stats, see T55361 (and subtasks). These will now have to be cleaned up to remove "out-of-date" content.
    • Tools
    • Render
    • User Interface
    • Animation System
    • Game Engine (exclude this)
    • Editors
    • Breaking Backward Compatibility
    • Scripting
    • Import Export
    • Building Software
    • Installation, Environment
    • Regression Tests
    • User Based Todo (exclude this)
  • port Release Logs over (this is lower priority but does not require checking if content is out of date). For older releases up until 2.78 it was decided to just link to the old/archived wiki for now (lots of broken links / missing content / not subject to further editing anyways...).
    • Blender 2.80 (under development) note: hasnt been ported (yet?)
    • [real port] Blender 2.79 (latest stable release)
    • Blender 2.78
    • Blender 2.77
    • Blender 2.76
    • Blender 2.75
    • Blender 2.74
    • Blender 2.73
    • Blender 2.72
    • Blender 2.71
    • Blender 2.70
    • Blender 2.69
    • Blender 2.68
    • Blender 2.67
    • Blender 2.66
    • Blender 2.65
    • Blender 2.64
    • Blender 2.63
    • Blender 2.62
    • Blender 2.61
    • Blender 2.60
    • Blender 2.59
    • Blender 2.58
    • Blender 2.57
    • Blender 2.56
    • Blender 2.55
    • Blender 2.54
    • Blender 2.53
    • Blender 2.52
    • Blender 2.51
    • Blender 2.50
    • Blender 2.49
    • Blender 2.48
    • Blender 2.47
    • Blender 2.46
    • Blender 2.45
    • Blender 2.44
    • Blender 2.43
    • Blender 2.42
    • Blender 2.41
    • Blender 2.40



I don't know that I would go so far as to remove the old 2.4/2.5 manuals that exist in the wiki as they are the only manual that exists for them, unless people feel we could just assume it to be deprecated and removed from existence.

I wonder if it would be better to maybe try doing a one time conversion of the old 2.4 wiki manual back over to sphinx, once we do versioning over there with the manual. At least then we could provide redirects to the manual that would be indexed by Google and searchable/findable by people with old versions of Blender, or people who are merely curious.

As for how to structure and layout the updated wiki, I don't really have any opinion here as I am not the person that edits stuff. If you like using transclusion to create pages, that's up to the editors.

On the topic of a theme, Naiad is currently broken for the navigation tree on the left of the page. Personally I say scrap it; it looked nice but was too coupled (IMHO) to the extensions and templates/transcluded pages etc. I also believe it has problems with mobile? Anyway, I think it to be a terrible design when half the site breaks just be changing to a stock skin, like vector.

I also am curious what others think about the idea of moving to a Wiki family and using interwiki links for languages (eg:,,, etc.) for translation of everything else on the wiki, very much like how wikipedia does things.

Aaron Carlisle (Blendify) raised the priority of this task from Normal to Confirmed.

Ok, I think I have a clearer idea about the whole old wiki version things. We should keep the old manuals but not have wiki version for the rest of the wiki. Here is my idea on how this should be structured.

  • Home Page
    • Manual
      • Current (redirect)
      • 2.5
      • 2.4
    • Other wiki pages

I don't have a strong opinion on whether the old manuals get moved to sphinx.

Hello everyone !

Manual theme redesign
Current vogue is in the material and flat designs.
I think the wiki could benefit of efficient space usage just as shown in this image.

A little bit of CSS magic can help change the current wiki remake to be on the same level as:

Manual versions
As far as the old wiki goes; I think we should keep the latest major versions just for retrospective [2.40, 2.50, 2.60, 2.xx ].
There should also be a latest version, updated on the fly.

Thanks a bunch Dan for setting up new wiki! :)


2.4 and 2.5 manuals: those would simply remain readonly, kind of 'archived'. I don’t see much point on wasting time on them to port to sphinx or whatever, but there is no reason to remove them either, they can be 'forgotten' in their own corner imho. :P

In fact, maybe we could have an 'archived' section in the wiki, where we explicitly dump any page which is no more in sync with current blender - would include said manuals, but also all old design and tech docs that are no more really relevant. This way, no need for 'version' name spaces.


Agree it would be nice to make it coherent with other blender sites, but imho most important thing is to have something easy to maintain and update along with wikimedia. So rather use a well known and maintained skin (even default one?), with a few as possible customization (css-only ;) ).

Naiad was a great result, but trying to make wiki not look like a wiki requires tremendous work - to create it and to keep it working at each update! Let's not forget that wiki, now that manual uses its own stuff, will mostly be tech doc place. We want to keep it simple and easy to use and maintain, more than everything else.

The problems with Naiad is (currently) the Nav tree is missing. The problem with Any of the stock skins is that we have a bunch of Naiad related cruft in the templates that make a stock nav area break, so things need clean up if we want to go that route. It doesn't matter to me either way; I am just letting you know that if we go with a stock setup, there is a lot of work needed to clean things up and bring it back to a stock setup.

+1 for @Bastien Montagne (mont29)'s reply.
Best we have wiki that can be maintained and not focus too much on customization unless if gives real practical benefits and doesn't prevent us from upgrading in the future.


I have no idea how much work is to setup the new skin, vs stripping down our current version to be compatible with the default skin.
That being said, I am all in favor for css tweaks so that it looks like the other blender websites, as long as it is not too much work.
I am not so worried about styling, but about the functionality of the navigation.

+1 for read-only versioning. I understand that this means to keep the content as it currently is, with new material going to sphinx.

I think the default skin is better than going back to the old Naiad.

I started to do some cleanup of the current wiki today, mostly in the release notes area, but ran into a problem when trying to delete pages.
Currently, there is no way to batch delete files. I did a simple Google search and found some solutions that might help:

However, there may be a chance that these will not work due to the old media wiki version that we use.
In this case, I think that we should layout a day where shut down the wiki and move to the new wiki.
From here we can use those scripts to delete many pages that we don't need. A big example
here would be the old manual translations (2.4, and 2.5, 2.6).

So this is mainly a question for @Dan McGrath (dmcgrath) on whether the scripts would work or not,
If not we need to get a time frame for when to shut down the wiki and make the new wiki default.

Hi @Aaron Carlisle (Blendify),

There is a problem with the current wiki in that we cannot add new extensions. Normally when you add an extension you need to run an upgrade script to extend the database schema, but this script is broken in the current database due to a problem with Latin/UTF problems, so we wouldn't be able to activate new extensions. The problem gets fixed when we upgrade Mediawiki though, so the new system would be able to run these extensions just fine, and I believe are even included in the new site.

It may be possible that I can I run some of the admin scripts in the shell to delete specific urls though. Looking at the shell, I do see a "deleteBatch.php" script. It appears to take a text file with a list of pages to delete:

  • <listfile> : File with titles to delete, separated by newlines

Maybe this would be enough? Or would you guys rather wait and switch to the new wiki instead?

It seems like you are talking about which was the second bullet point.

No, there are php scripts in the maintenance folder in Mediawiki installs that let you do stuff that may or may not be available through the web UI. The extensions I think are more meant for people without shell access.


From here we can use those scripts to delete many pages that we don't need. A big example here would be the old manual translations (2.4, and 2.5, 2.6).

Where was this ever agreed on? Translations should be handled the same as english manual imho, archived and made non-editable, but why deleted?

After trying to work on T48381 I found that the current wiki is too slow for me to do anything.
I think the best solution right now is to do a little theme clean up and make the merge to
After everyone is forced to use pages can be added/removed/moved has needed with a lot more ease.

I have just checked the manual, and there have been performance improvements, so it should be back to normal now.

Today i found in the official wiki that vimeo videos seem to be embedded by using the flash video player. I propose to customize or update the <vimeo> plugin so that it uses the html5 player instead. Here is an example page:

When i open this page with firefox, then i get the warning about usage of flash.

I also noticed that it looks like the new wiki does not (yet?) support the <vimeo> tag. I believe it is important to at least support embedding of videos from vimeo and youtube.

Aaron Carlisle (Blendify) changed Type from Bug to Design.Feb 8 2017, 6:30 PM


Is it planned to allow to log in to the (upcoming) new wiki with a account?
I hope it will be considered because it's not currently possible to log into with a account...


could be archived and a new set of pages created for addons.
as one of the original authors and designers of this page and
I would be happy to work with wiki devs to see the new pages created for blender 2.8 series.

I was about to update the new wiki, move/copy more stuff from the old wiki, I can log in using the credentials from the old wiki but I dont have editing permissions in the new wiki.
Could somebody set this up for me [or tell me how to do it myself]?
Thx in advance!

I was about to update the new wiki, move/copy more stuff from the old wiki, I can log in using the credentials from the old wiki but I dont have editing permissions in the new wiki.
Could somebody set this up for me [or tell me how to do it myself]?
Thx in advance!

The wiki was meant more for testing. There will be no porting over as the actual port work will involve disabling updates to the old site, and then doing a database dump into the new wiki, followed by shutting down the old one and renaming the new one.

I think after the 2.8 release should be a good time for this even if we use the default wiki skin.

port Addon catalogue / docs (these will be moved to the blender manual [] though -- some of the docs already made their way into the new wiki but have to be moved again [to manual])

I would like to handle this and I want to create a separate design/structure document before we go about that.

Help > Release Log link will have to be updated after the switch.

I just saw the big wiki changes happened today. Two questions:

  1. Is there more information available as to the reason for the migration to a new wiki? I looked over this thread, but I'm not seeing much in the way of specifics. This would be helpful in a FAQ point of view, in establishing some rough rules/guidelines, and for preventing any perceived negative aspects from the old wiki from creeping into the new one.
  1. Is there more information about what is being migrated over and what isn't? For instance, the old tutorials (e.g. Modeling Two dice)? Templates? User pages? Feature requests / design mockups? Docs on depreciated Blender features (e.g.: Blender Internal)? User add-on docs (for the add-ons not shipped with Blender)? Summer of Code pages for previous years? I'm guessing no for the tutorials and feature requests, but I was not as sure about the other items I listed. should be migrated, as it does serve some purpose for bug reports.