Utility: Official release of the unofficial Dominions 3 Wiki

[JonBrave]

Originally Posted by lch

You know, that would be exactly what I'd have asked if I was in your situation. There should be a "live" version and a "testing" or "development" version of a website, and changes should only be pushed from the "dev" to the "live" version when they're finished. When I was working on web design things, I always kept things that way. With the Wiki, I haven't done such a setup, mostly because it was overkill and because I am usually not working on the live code, but just install and upgrade code from the official SVN codebase now. When I started on the Wiki, I didn't need such a setup because nobody knew about it and I was free to do whatever I wanted to do without the need to have a working "live" version while I'm developing. Now that there is some customer/user base who needs to access the Wiki even when I'd need to work on it, I would favor and use such a setup, yes. In case I ever intend (and have time) to work more on it, I think I'll work on a cloned version like you have considered, yes.

Dear Mr Ich,

I think some people didn't like how I asked! I'm glad to see you take it the way it was intended

Here's what I don't get/is sad. Your Wiki is, or should be, 99.9% static text. No offence intended, but as I recall it's just clicking on links to other pages (little if any interaction) --- which is fine, and as it should be. A few years ago, as I recall, the site would have been some pages & links, and that could be plonked anywhere. Nowadays, it seems, you all need "engines" & "scripts" to deliver your sites. Hence all the issues about your site being "down". That's the bit I don't get? Let (suitable) pages be just static content, or if necessary generate it at some point and save/offer that?

[lch]

Originally Posted by JonBrave

Here's what I don't get/is sad. Your Wiki is, or should be, 99.9% static text. No offence intended, but as I recall it's just clicking on links to other pages (little if any interaction)

Like others already wrote, far from it. It's probably pretty close to the other way around. Almost everything, including in most parts the graphics, is dynamically generated. There are caching mechanism in place, especially for the graphics, so that it doesn't have to be generated completely if there is a hit, of course. But what is stored in the MySQL database is something called Wikitext, which is being rendered into what you see on your screen. The Wikitext is just some very sleek text with Wiki-specific markup which aims to be very readable even when you edit the source code in the editor, instead of HTML for example, where your actual text can get lost in all the tags and markup it carries. And unlike HTML, that Wikitext has to be parsed by the server, not only on your side by your browser. That whole Wikitext runs through the MediaWiki parser before you see it, and MediaWiki, the Wiki software, has some very wicked Templating mechanism built-in, too. It's a very complex Turing-complete language, if you want, which differentiates it from a WYSIWYG Content Management System where you use a finite set of tools. Oh, and the MediaWiki software itself with the included parser is programmed in PHP, which is an interpreted language that has to run through a PHP parser at runtime before it is being executed, too. So there are a couple of parsers simultaneously at work at the server on different levels whenever the Wiki has to spit something out on your screen.

Of course, the aim is to keep the actual rendering low as much as possible. Which is why I am using something called APC, Advanced Parser Cache, to always keep the things which are used the most in memory. And theoretically, all the rendering should only be necessary if somebody makes a change to one of the pages. But there's just not enough memory to keep all the thousands of pages in memory at once, which is why you do have those load times (and sometimes it seems to get stuck at some point, I don't know why). When I wrote that the Wiki is probably slow either because of my net connection (I doubt it) or the server hardware (quite possible), I forgot one other thing: It might very much be slowed down by the design, too. I am using extensions, like SMW, Semantic MediaWiki, which could probably be used better. I'm using Templates that could probably be optimized. A couple of pages could probably be formatted in a better way, and most of all: The unit pages, which I'm guessing are being accessed the most, are using a design which is maybe not very cache-friendly. It accesses an internal MySQL database of stats and values quite similar to Edi's Dom3DB which I separated from the MediaWiki articles so that I'd have it easy to update those stats and values when a new update to Dom3 changes them. Back when the Wiki was developed, there were more or less regular updates every half year, and quite a lot of little data changes could happen in a patch. Populating that data into the Wikitext from the unit articles would be painful manual labor, or I'd have to write my own parser/robot to find and change that information, so I wrote a MediaWiki extension which grabs that data from another internal database instead. Nowadays Dom3 is pretty much final and there haven't been any major patches to the content lately, so such a setup is not as necessary as it seemed to be at first, and I could probably lose that design. I didn't knew about the power of Semantic MediaWiki when I started this design, too, and I probably could have dismissed this strange design from the start. Like I wrote in my opening post, I think there's probably a lot more powerful stuff to be harnessed from SMW, but I lack the knowledge and the time to learn it outside of a paid work experience myself now.

I'm still hoping that a SMW wizard might come by at some point, weave his magic wand and suddenly everything will just be beautiful and lightning fast... In the meantime, you'll have to live with things the way they are now. Not ideal, but you'll have to cope.