GetWiki has benefited from a series of changes in its software, taking advantage of the changing landscape of publishing in general. What is a Wiki but a published series of pages, not unlike any other website or magazine?

Late in 2003, I began GetWiki by forking the underlying Pseudopedia software, MediaWiki, to include remote XML content. The class and function I'd added to the codebase were called getwiki:

<?php
class getwiki
	{
	// vars
	function getwiki()
		{
		// curl the remote page in XML
		}
	}
?>

...and along with HTML/XHTML/XML output standardization and some other features, GetWiki 1.0 was introduced in 2004 as an alternative to MediaWiki. The reaction from the Pseudopedia community was harsh and defensive, and at once demonstrated all of the evils of that community, as noted elsewhere. It also clarified to me that one should not want to provide a codebase for such users. During 2004-05, the 1.0 implementation had become a 1.x series of further changes, and I moved the 1.0 release itself offline.

During 2007-2009, my world had long moved on from all this WikiDrama, life on the internet had also changed again, and GetWiki 2.0 had emerged as my new custom codebase, all from scratch and in concert with “Plug”, another codebase I'd developed for rimric.com. Gone was any tie to MediaWiki, which, as I'd described one time, had become a series of ever more bloated and complex pineapple extensions, when they should have been perfecting an orange. For example, the increasingly large number of PHP files in MediaWiki were continually consolidated and reorganized in GetWiki, while also moving to a functional and object-oriented design, away from “PHTML”. Also, the new GetWiki parser class was never intended to support every little feature in use by Pseudopedia, but to remain as light and fast as possible, because parsing a traditional wiki shouldn't require a datacenter.

GetWiki 2.0 was about simplifying, reducing, and making a better presentation of a hopefully better-written article. You can't do that with a mob in control. That said, some features I'd introduced during that time didn't really pan out. For example, discussion forum functionality, an alternative to “talk” pages, eventually gave way to no discussion being a part of the GetWiki website, other than the old blockquote tricks. The “friends” feature, much like Facebook and other sites, also went away in later revisions. Sometime during all this the actual hosting of getwiki.net was moved from ibiblio to a commercial provider, which again, provided me far more freedom, as well as server capacity.

By 2012 I'd also incorporated mobile/responsive display and had worked different designs into the codebase, and during the following years into 2016, GetWiki 2.0 had essentially become a mature 2.x leaning toward a 3.0, along with another whole new web design, as in use today. This new graphic design not only combined rimric.com, mrmparrott.com, and getwik.net into a single codebase, but the codebase had been consolitated into only five PHP files, using four classes, and a fully integrated functional codebase. Everything seen on the websites was now produced by a function.

(index.php)
<?php
	// vars
	// includes
	include_once("page.php");
	include_once("database.php");
	include_once("parser.php");
	include_once("user.php");
	// initiate classes
	$user = new user();
	$data = new database();
	$parse = new parser();
	$page = new page();
	//  output page
	$page->output();
?>

As I lived my life and did other things, the 2.x era of GetWiki then ran for years without changes until recently, when I again decided to work on the code in my spare time. PHP itself had gone from 4.x-8.x, and with an exception or two, I found the code had held up nicely given my focus elsewhere. The basic design hasn't changed, but there are a number of structural changes, yielding what we can now call GetWiki 3.0.

---

GetWiki 3.0/3.x

Spring Cleaning (in Autumn)

After the 20th Anniversary and a few other big projects it was finally time for some pruning of the GetWiki database as well as some of the code.

With the code, many updates have been made to the PHP classes and functions which output this site as you see it, from improved parsing, to an updated custom difference engine, a table of contents for articles which have headings, a utility showing the non-article “green” links, and more. However, while I can boast about how functionally simple GetWiki has become, it still comprises over 13,000 lines of PHP in dozens upon dozens of functions, plus 1,500 lines of CSS. Parsing a wikipage is done in a series of loops, but changing one thing in a loop often leads to “whack a mole” in others, resulting in a “rope-a-dope” Still, the custom parser now supports all of the reasonably-expected WikiCode along with other goodies, but some of the more esoteric features of the 'Pedia are still ignored, because they won't be used here. Making {{cite type|key=val|text}} codes work well enough was a victory, especially given all their variations.

As for the MariaDB database, after consideration I decided to delete 126 (then another 37 or so) articles, meta pages, redirects, and includes, which amounted to well over half of the wiki! When I say “delete”, though, that's just from the active DB in use - the content still lives in backup form, and a small amount has been pasted into the remaining articles. This pruning has left a much leaner and tighter collection of relevant content, and after a good deal of cleanup page by page, I can finally say the wiki is clean, with minimal “green” links. I've also merged the old GetMeta namespace into the GetWiki namespace, re-organizing and simplifying the namespaces as shown below, which allows better delineation over what gets displayed in various sections of the site. For example, we don't need to see redirects and includes in the index or in recent edits on the right side flyout, and it's faster to check a field we already pulled than to search the text separately for them.

Array(
	0	=> 'Redirect',
	1	=> 'Include',
	2	=> 'Article',	
	3	=> 'GetWiki',
	4	=> 'Profile'
	);

Wiki Publishing Platform

During these many years the wiki functions were pared down to display-only, with no logins or registrations allowed other than my own. I worked on other software projects during that time. Eventually, it was clear that GetWiki would be best as a continued small editing platform for select articles, so I started turning things back on, realizing the merge with “Plug” and “SOHOdb”, and during two front-end design changes, left a lot of code to refactor. At the same time, GetWiki code was merged in with the regular website hosting for rimric.com and mrmparrott.com.

This meant GetWiki functions are mixed in with rimric press functions for my book titles and projects. Hosting-wise, this is fine, but it's left a lot of legacy code in various places, and even I had lost track of what's what at times as I've been going along with minor updates. This led to major editing/refactoring. Still, the newest web designs using the masonry and responsive CSS are working well, and the PHP has survived updates into the 8.x PHP server locally on Fedora Linux, 7.x online. As of June 2024 I've been cleaning up the refactoring and reducing the codebase to what's really necessary, while adding new wiki features, such as better but limited support for some of the Pseudopedia wikicode, like citations, etc. There can be some limited usefulness of having references and footnotes separated, but not much beyond that.

---

GetWiki 2.0/2.x

“Plug” Simplicity

Does anybody really need all those links and functions?

Sometimes, I'm not so sure, and some wiki software is far more bare-bones, much prettier to look at. GetWiki is certainly simple to use, but in developing “Plug”, the application now running rimric.com for free book reviews and news/discussion of small press titles, I'm now looking at how to simplify GetWiki even more, and get away from the bloat (and let's face it, the baggage) associated with “wiki”.

ie:

• having “talk” pages, especially when they have to be wikied, is quite useless and confusing - why not just have comments at the bottom of an article, like a blog or news site?
• maze-like lists of pages, images, their sizes and cross-links, and other features are also far less useful when the application is simpler (and...when the “culture” is not about policing people unnecessarily).
• at a technical level, the MediaWiki guts GetWiki inherited are very convoluted, with lots of very slow, high server load processing, and un-normalized database tables (articles are stored in three separate tables, recent changes in two, and lots of info is stored in more than one way).

The only real difference now between a blog and a wiki is that the article can be edited by others, right? Why is “blog” considered “fun” and “cool”, while “wiki” is considered “pedantic”, “dorky”, “cumbersome”, and “authoritarian”? Aside from adding features from GetWiki to Plug, like the Index, and the Atom Feed, I'll also look to possibly gut GetWiki of some of the last remaining bloat (handed down from The Pseudopedia). It would simplify the interface and remove the last of their slow, GPL code. Any thoughts?? -User:Proteus 09:59, 11 Mar 2008 (EDT)

Metadata Classification (Categories/Facets)

I've long been researching this “categories” thing, and once again, the way it's done on Pseudopedia is close, but not very sophisticated. They now have so many categories, and category pages, that they've resorted to manual indexing of those categories (defeating the purpose), not to mention that the database and “recent changes” is polluted with all those “category namespace pages”, which are not really pages, but which have to be managed as such. Metadata about articles on a GetWiki Wiki is important, and I've long wanted a solution to this, but I did not want to simply follow a WP-style category scheme. While WP's is both a “Forward Index” and a “Reverse Index”, it is a method which gets in the way and creates another mess which has to be further classified itself. That's why GetWiki has not had “categories” before now.

Two very clever approaches are out there (linked below), and doing them both (doing them both without creating endless extra pages about pages, etc), seems very, very interesting:

• Hierarchical Classification (see Wikka): Assign a single category to every page via a separate interface (similar to “what links here”), and the default category is “uncategorized”. Every category can have a parent and secondary parent, but top-level categories are primary “trees in the forest”, like Philosophy, Science, or Art. This would work just as WP's “2-Dimensional” categories, such as “all topics in Philosophy”, except there would be no pesky category namespace pages to keep up with, manage, or misuse (as is now the problem on WP), and single-parent categorization will be far simpler, or “1-Dimensional”. [[Category:Foo]] markup in the articles would, as now, be ignored.
• Faceted Classification (Iawiki [dead link]): Assign Author, Subject, Type and Origin “facets” to every page. The Author part is already in the database, viewable on the history of each page. The Subject part is similar to a top-level category, and other Type and Origin data can be easily added to describe pages. This method allows searching in a “2-Dimensional” way, such as “all Philosophy pages edited by Proteus”.

Every page would have “Breadcrumb” Navigation as well as “Facet” Navigation displayed (breadcrumbs along the top, with facets just below), all making for a “3-Dimensional” classification scheme on the full set of real classifiable pages (not talk, user or system pages). A reader can follow the links of her choice and browse the various collections.

So, we would, as a result, have a quite simple method. Have a “classify this page” link on classifiable pages. Possibly, this page would only be changeable by Sysops, but regular Editors could “add” categories?? The page would show the Metadata in dropdowns/checkboxes that can be changed. These bits of Metadata count as categories and facets at the same time, for example with Dynamism:

1. Category (“Philosophy”)
2. Subject (“Systems Theories”)
3. Type (“Wiki”)
4. Origin (“Imported”)
5. Author(s) are in the page history (perhaps pruned of blocked spammers), or limited to the most recent Author?

I'm working on this now-ish (got other things going on) and it's coming right along on a test wiki, and it's pretty complex. Adding Metadata to a page is easy, probably with added fields to each page in the database, or adding a Metadata table, but getting it all together in a simple, intuitive way takes time. I'm on the fence about whether changing categories/topics and changing a page's Metadata should be sysop-only. It would be all-too-easy to mess up the system by a malicious user, but maybe regular Editors should be allowed to add (where it is missing or incomplete), but not change, categories/topics?? Or, if regular Editors can change Metadata, perhaps it can be added to the “revert” mechanism, if abused??

This “3D” method would not be part of recent changes as so many minor changes to each page, unless it is logged separately. The whole idea of categories is that they are Metadata, and should not also be “reverse linked” namespace pages to manage, watch or overuse. The thing about Faceted Classification is that many areas, such as the Humanities, benefit from a Hiearchical approach - why not have both and still keep it simple?? -User:Proteus 13:59, 18 Apr 2007 (EDT) (updated: -User:Proteus 16:44, 24 Apr 2007 (EDT))

---

GetWiki 1.0/1.x

Re-Importing

On [the former] Wikinfo, we've found it necessary to occasionally “re-sync” articles imported, but could really use a quick way to do something like a “diff” with the current version, especially those with an edit history on Wikinfo. This could also be tied into the suggestions above, for multiple imports. -User:Proteus 18:49, 22 Mar 2005 (EST)

Multiple Wikitext Support

Not all wikis use MediaWiki, and currently, few use GetWiki. Why not provide an upgrade path for those wikis using PhpWiki, UseMod, and so on, some of which use a slightly different wikisyntax than we do? Could they not benefit from the features GetWiki offers?? -User:Proteus 23:43, 20 Jan 2005 (EST)

Atom/RSS Import/Export

Perhaps GetWiki could (a) export its recent changes or new articles, or both, via Atom/RSS, and (b) also provide a MSG-like import functionality to aggregate several other GetWiki feeds onto a single page? Is this something useful, or is “RSS” overhyped?? -User:Proteus 12:14, 19 Mar 2004 (EST)

Custom User Rights

Instead of hard-coded user's rights, as “developer”, “sysop” and “admin” in GetWiki 1.0, “developer”, “sysop”, “bureaucrat” in MediaWiki 1.2.0+, why not allow that different wikis will be better served with different names for these rights, that “bureaucrat” or “sysop” may not suit all wikis? [The former] Wikinfo could use editing titles (ie. editor-in-chief, managing editor, etc), while a filmmaking wiki could use filmmaking titles (ie. Producer, Director, etc), and so on. GetWiki 2.0 could offer these user rights as simple categories and allow their names to be changed in LocalSettings.php.

There could be one “benevolent dictator” type of user as a default (currently “GetWiki Sysop”), who alone can grant users (a) “bureaucrat” rights, who likewise can grant “sysop” rights, and (b) “developer” rights. Everything would be logged in “GetWiki:Grant_Log” using the titles selected in LocalSettings.php. Also, it may be useful to have user rights displayed on each user page, next to, or under, the User:X at the top. For a site like WP, there are too many users to scroll through the list, so clicking on a user page would reveal their rights. -User:Proteus 14:31, 5 Apr 2004 (EDT)

Multiple Wiki Imports

The basic possibilities of multiple importing can be explored through several configurable options, which may be included in a possible new version of GetWiki. Multiple imports could be used as comparisons and selections for wikis importing articles. -User:Proteus 12:14, 19 Mar 2004 (EST)