SUPPORT THE WORK

GetWiki:InterWiki

ARTICLE SUBJECTS
aesthetics  →
being  →
complexity  →
database  →
enterprise  →
ethics  →
fiction  →
history  →
internet  →
knowledge  →
language  →
licensing  →
linux  →
logic  →
method  →
news  →
perception  →
philosophy  →
policy  →
purpose  →
religion  →
science  →
sociology  →
software  →
truth  →
unix  →
wiki  →
ARTICLE TYPES
essay  →
feed  →
help  →
system  →
wiki  →
ARTICLE ORIGINS
critical  →
discussion  →
forked  →
imported  →
original  →
edit classify history index GetWiki:InterWiki
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, GeWiki 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

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 have 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.

-Proteus (5:50pm EDT - Mon, Jun 10 2024)


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 (Wiki:Index|Index), and the Atom (Wiki:Feed|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)

As I’ve worked on other big projects recently (production design on my new book releases, for example), I’ve reflected on this. rimric.com, running “Plug”, has none of the problems associated with “wiki”, and now has two features GetWiki doesn’t have: Internal private messages (not just forwarded email) and also friends (and “foaf”) connections (with no privacy problems). Along with the true BB-style threaded discussion forums, that makes three major features - four, if you count the true classification feature already present in GetWiki 2.0, which would update the way GetWiki works... -User:Proteus 13:23, 6 Jul 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”. markup in the articles would, as now, be ignored.
  • Faceted Classification (see IAwiki): 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 the (Blah:Main_Page|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 at GetWiki:Classify Log. 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))

This is mostly finished, and at the same time, there were many changes to the subtle parts of the “skin” (see the Water Cooler for more). There are now breadcrumb links and facet links at the top of the pages (in place of redundant links before). The classifcation of articles (except talk, user, and special pages) is done completely separately from the editing of articles (for many reasons). The new “classify this page” link on allowed pages leads directly to the Classification of that page, and can be immediately changed (all changes are logged at GetWiki:Classify Log). Everything is geared toward keeping Categories simple, broad, and few in number, while allowing a wide range of Facet “tags” per article. Sysops see a couple of extra layers on the classify page, allowing the moving and editing of categories in a simple manner. There are no Category or Facet “pages”, as they are done, correctly, within the relational database. I’ve still got to get the “browse” function together...feedback on any/all is appreciated. -User:Proteus 16:56, 25 Apr 2007 (EDT)


GetWiki 1.0/1.x

Re-Importing

On Wikinfo, we’ve found it necessary to occassionally “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)

I’m working on an Atom feed of editor’s picks. I think feeding recent changes or new pages is highly boring to the people we would want to attract to a wiki. -User:Proteus 12:43, 4 Apr 2007 (EDT)
This is done now, and the hopefully useful feed is visible on all GetWiki pages. Rather than hitting newcomers with more recent changes, it shows featured articles. Rather than pushing recent changes into a noisy feed which few would care about, it bridges blog-styles and wiki-styles. The feed could be anything, in fact. Most of the settings will be editable in the “local settings”. -User:Proteus 13:15, 10 Apr 2007 (EDT)

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? 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)

Editors’ extra rights have been added in 1.0 to their user/user_talk pages, in the upper right corner. The “admin” right has been added recently, too. Admins can promote/demote any user and view other user information not available to sysops. The powers of the 3 administrative categories, therefore, do not overlap. In 2.0, the 3 will be changed to numbers, so that the text names of the categories can be changed, as desired. -User:Proteus 21:00, 30 Jan 2005 (EST)

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)

This may very well be a default feature of enacting multiple wiki importing. If GetWiki:2.0 can do multiple imports, that would include any wiki running GetWiki 1.0+/MediaWiki 1.1.0+, as long as the XML schemas are consistent. This would mean a wiki running GetWiki 2.0 could auto-import from the language Pseudopedias, Wiktionary, Wikinfo, GetMeta, or whatever. I’ll have to research the sister projects to ensure their output XML is available and consistent. -User:Proteus 23:53, 10 Sep 2004 (EDT)

edit classify history index
[ last updated: 5:52pm EDT - Mon, Jun 10 2024 ]
[ getwiki edits: 22 , site views: 2,467 ]
LATEST EDITS [ see all ]
GETWIKI 17 JUN 2024
GETWIKI 11 JUN 2024
GETWIKI 10 JUN 2024
GETWIKI 02 JUN 2024
GETWIKI 01 JUN 2024
CONNECT