GetWiki:Overview

GetWiki was first developed early in 2004 to "get wiki" content from site to site. At the time, MediaWiki appeared to be a more intuitive and user-friendly application than other Wiki-engines, full of features, actively tested and improved by dedicated developers from around the world. However, this does not mean improvements could not have been made to MediaWiki, or still made - no application is perfect - and having a "team" of developers does not guarantee the quality of software will be high. Since using it as a codebase for GetWiki in 2004, MediaWiki has become overly complicated "bloatware", while GetWiki has remained very simple, in keeping with the spirit of "Wiki Wiki".

During its latest releases, MediaWiki remains a Wiki engine created primarily for Wikipedia, and when used elsewhere its lackings and bugs are laid bare. Time spent working with MediaWiki from an outsider's perspective made bugfixing mandatory, but potential improvements to the interface, security and standards were obvious as well. Thus, GetWiki first emerged as a series of bugfixes simply to get MediaWiki to actually work as advertised, then development continued, diverging as a "fork". GetWiki is now an optimized wiki engine bearing less and less resemblance to its predecessor which works on a variety of servers and hosting environments - the 2.0 release strongly continues this trend of independence.

That independence was a real problem for the Pseudopedians. Overreaction to the legal XML importing and licensing changes was relentless, and even Jimbo Wales himself threatened to sue (Jul/Aug, 2005), emailing, "I will take legal action if necessary, do you understand that? I don't know why you choose to be so difficult". Being "difficult" meant that GetWiki 1.0 licensing was going to stay as originally released, regardless of their unfounded complaints to the FSF and other threats. The reaction GetWiki set off for the Pseudopedia-faithful was quite the firestorm at the time.

Features in GetWiki 1.0

Like most software, the development of GetWiki came about as much by accident and inspiration, along with a little desperation, than by any plan. After seeing the massive job it was to manually copy and save selected articles from Wikipedia into another Wiki, the initial impetus was clear enough: create a simple method by which we could save only the desired articles from the remote Wiki, instead of loading an entire database "snapshot" or continue copying manually.

XML Importing

This has been perhaps the most important feature of GetWiki, one which is incredibly simple, and controversial. The basic idea to use XML came about as a result of ongoing research on the technology after working it into projects for rimric interactive, but it was only then a recent addition that XML export was added in MediaWiki. After this, it was easy enough to develop an extension to MediaWiki, "GetWiki", in order to import the XML content from another MediaWiki-based Wiki.

It was truly amazing how much knee-jerk criticism this feature received from Wikipedians, when the entire content of the Pseudopedia has always been freely available under the GFDL as well as provided in form of regular database "dumps" for anyone to download, use, mirror, edit or fork. Importing article-by-article is no different from this in principle, and has the added benefits of:

• selecting articles with merits important to a particular Wiki
• distributing server load, both electively and selectively
• dividing single data snapshots into dynamic individual article histories
• accentuating user interaction in creating a Wiki

XHTML/CSS Standards

After work on the XML import utility, it was clear the HTML output of MediaWiki used more than one standard (convention). The output, written by many developers, used several now deprecated standards to output HTML code to the browser, and given the long prefered focus on XML standards and XHTML/CSS design, this would not do. Somewhere, in this process of labouriously going through each PHP file to update all of the various HTMLs to clean XHTML (W3), the MediaWiki 1.1.0 being used as a code base was forked, because at this point, the changes could not easily be turned back into a later MediaWiki release. These changes seem to have caused a flurry of activity by the MediaWiki developers in trying to update all those mixed "td"s and "TD"s, unquoted attributes, unclosed elements, and other remnants. The latest versions of MediaWiki have, as a result, come a long way toward XHTML standards.

Yet, realistically, given the nature of how a Wiki works, it is not likely a WikiWeb will be 100% valid XHTML for long. Users are free to enter valid XHTML, invalid HTML, or any combination of code, some of which cannot be corrected at output time, because the authors' intentions cannot be anticipated in all cases - especially on a large Wiki. Also, as seen more recently in building code to translate TeX formulas, sometimes elements will be nested improperly, either breaking validation or affecting the display of the article. This by no means implies the goal was not a good one, though.

GUI Enhancements

In the course of using MediaWiki and GetWiki, moving between, user interface issues began to emerge. Right off, the colours used in MediaWiki began to strain the eyes, and so, why not make a small change here and there? Eventually, enough changes were made so that whole pages, such as the user preferences page and others, were completely reorganized and prettied up. This was not done merely out of creative angst, but from a desire to make the interfaces of GetWiki as easy to understand and intuitive to use as possible, especially for new users.

All Wikis strive, or should strive, for simplicity, but few seem clear for new users. The visual design of important pages, such as a "Main Page", is usually not given enough care in order to effectively introduce just what a wiki is to a newcomer or prospective contributor. Changes in GetWiki toward this have been at most subtle, because the basic MediaWiki design is a good one, but outlining check boxes, carefully selecting font colours, and other improvements can at least make the functions clearer. This is an area which will see continued improvements in 2.0.

Security Hardening

One problem, which has grown out of proportion with Wikipedia's actual importance, has been the security of its content. Any casual glance at the recent changes and mailing list discussions reveals an extraordinary effort spent on correcting vandalized content, discovering/claiming dummy user accounts, called "sock puppets", and in general, over-monitoring and micro-managing the users of the Wikipedias. As GetWiki developed, and due to more sensible policy on GetWiki, better measures needed to be put in place, rather than rely on a bunch of sysops to revert edits and discuss procedure. Many Wikis do not have the benefit of so many adminstrative users, and so cannot rely on the "eyeball" method of content security.

So, blocking non-account edits by default does wonders for preventing casual vandalism, by far the largest category. Linking a previously blocked IP address or address range to block the generation of new accounts is another big step, as well as blocking any edits or uploads from blocked IP/ranges even after login from a non-blocked account is another. Allowing the "admin" user, who can promote/demote other users, to view the last used IP address-host-range and email information for each account is a big help. The result? There is now virtually no vandalism on a GetWiki site, at least compared to what happens daily on Wikipedia, and no need for teams of overzealous and biased sysops to patrol the site and try to "out" the "sock puppets".

Removing Biases

Looking through the MediaWiki code also reveals a high number of Pseudopedian biases which are inappropriate for other types of sites. From the use of certain server dependencies, to the names of variables, to the assumption of namespace mechanics, to the aforementioned security drawbacks based on groupthink culture, MediaWiki is heavily biased toward the way Wikipedians want to work. GetWiki has slowly removed many, and eventually all, of these biases, favouring settings which are easily customizable for the wiki in question.

One example: MediaWiki requires both a MediaWiki, for messages, and Wikipedia, for many default settings, namespace on your wiki, where GetWiki removes Wikipedia and makes MediaWiki optional (There is an additional namespace placeholder corresponding to your export wiki setting, be it Wikipedia, Wikinfo, or any GetWiki 1.0+ or MediaWiki 1.1.0+ wiki). More and more small bits of code have been translated, removed, added or otherwise modified to make GetWiki a generalized wiki engine, rather than a Wikipedian's wiki engine. Of course, there is nothing wrong with running a Pseudopedian's engine, but for the growing number of wikis which strive to distance themselves from Wikipedia, or in general maintain independence, using Wikipedia's software may seem limiting.

Features in GetWiki 2.0

The fun in developing software independently is that sensible choices can (theoretically) be made more easily, and in due time, than when trying to please a group. Watching how the WikiSphere has evolved over the years, both toward a juggernaut of misinformation in one Wikipedia, to a proliferation of small, free-thinking websites, it is clear that the concept of "wiki" isn't as cool as it once was (circa 2003-2005). These more independent sites, which at one time might have been wikis, are far more likely to be forum-based discussion sites or blogs. GetWiki is free to stray outside the lines proscribed by WikiMinders, MeatBall and Wikipedia, to become a different form of website interaction.

Categorical Facets

In GetWiki 1.0, there was no way to formally classify articles, as the feature was not part of the original codebase used, and more importantly, the feature is misused and overused on Wikipedia and the other Pseudopedias. "Categories" were avoided in GetWiki as the problems associated with them became apparent: The proliferation of categories and schemes, to the point of having one category for every page (which seemed the goal of Pseudopedians); the reliance on putting the category code into the article itself, which could cause problems and confusions in editing and page histories; and the need to create categories of categories, and so on, in order to offer some manner of navigation.

In GetWiki 2.0, categories are handled in the proper manner. First, they are separate designations from the actual source text of the page, so we can change one without affecting the other, either on purpose or accident. This also allows the possible restriction of changing categories to site administrators, or "sysops", but otherwise solves several technical problems. The categories are also displayed on each article, as a form of "breadcrumb" navigation (up to three levels), all linking to a central index function which works as a database should. This encourages categories to be broad and easily understood, instead of becoming so numerous they would need their own classification.

Furthermore, in GetWiki, Faceted Classification is also used, which is superior in some ways to Categorical, or Hierarchical Classification. "Facets" are added fields to the data surrounding the pages, but not the actual text source of the page. They create "facets" of index information about the subject, type, origin and author of an article. These facets are used, along with the categories, to create a multi-dimensional index, which can be used intuitively to narrow the numbers of articles matching index criteria. For example, one can find out the number of Philosophy articles last edited by Proteus. One could find all the articles forked in Philosophy, or all the original articles on Systems Theory, for examples.

So, for a particular page, we have this 3-dimensional schema:

• Title (Dynamism)
• Category ("philosophical studies")

1. Subject ("complexity")
2. Type ("wiki")
3. Origin ("forked")
4. Author ("proteus", or the last editor)