Evil Empire Website

Evil Empire Website

] Created by AndrewTetlaw and AdrianLynch. EvEm is a gaming community website based on Twiki with a rather non-standard twiki look and feel.

Some Interesting Twiki Hacks on EvEm

Though I'd put down a few of the non-standard things we've done on EvEm.

Login Link

A link that prompts the user to login but not realatedto any TWiki action. On EvEm edit is restricted by .htaccess but view is not.

created an edit.login.tmpl file: a black screen with a line of javascript that redirects the browser back to the home page
created a login topic (SiteLogin)
created a link: /bin/edit/Home/SiteLogin?skin=login
simple! It prompts the user to login, briefly displays a black screen and then opens the home page

Login Status Box

A box on top of the left hand column that tells you when you are logged in, in the form of "You are logged in as XXXXX". As we do not limit access to view with .htaccess so I've had to use a cookie. When you use edit anywhere a cookie is set and read when using view . Briefly the JavaScript looks like this:

// global vars
var SCRIPTURLPATH = "%SCRIPTURLPATH%";
var SCRIPTSUFFIX = "%SCRIPTSUFFIX%";
var MAINWEB = "%MAINWEB%";
var WEB = "%WEB%";
var TOPIC = "%TOPIC%";

var CGIUSERNAME = "%REMOTE_USER%";
var USERNAME = "";

function setUsernameCookie()
{
   if ( CGIUSERNAME )
   {
      setCookie("USERNAME", "%USERNAME%"); // function to write a cookie
   }
   USERNAME = getCookie("USERNAME"); // function to read a cookie
}

function writeLoginInfo()
{
   if (USERNAME)
   {
      document.write('<table width="100%" cellpadding="3" cellspacing="0" border="1"_
       bordercolor="#000000" bgcolor="#4e575c"><tr><td valign="top">You are_
        currently logged in as <br /><a href="' + SCRIPTURLPATH + '/view' + SCRIPTSUFFIX_
         + '/' + MAINWEB + '/' + USERNAME + '">' + USERNAME + '</a></td></tr></table>_
         <br />');

   }
}

Then where ever I want the login info box to appear I put:

<script language="javascript">
<!--
  writeLoginInfo();
 // -->
 </script>

Edit-Preview-Save changes

Changed the cycle to a simple edit-save cycle with a remote preview window available from the edit form. This allows users to edit make changes, launch preview, close preview, continue typing into text area, launch preview again and see how their changes will look (without having to save).

changed form action on edit form to get rid of preview. Changed action="%SCRIPTURLPATH%/preview%SCRIPTSUFFIX%/%WEB%/%TOPIC%" to action="%SCRIPTURLPATH%/save%SCRIPTSUFFIX%/%WEB%/%TOPIC%"
created a preview button on the standard edit template to launch the following url in a remote window: SCRIPTURLPATH%/edit%SCRIPTSUFFIX%/%WEB%/%TOPIC%?skin=static"
created a new template edit.static.tmpl on this it has a form with an action of action="%SCRIPTURLPATH%/preview%SCRIPTSUFFIX%/%WEB%/%TOPIC%" but:
- a hidden field named 'text' instead of a text area with a value of ""
- a hidden field called 'skin' with a value of 'static'
- javascript to suck the contents of the 'text' field of the parent window into the 'text' field of the preview window then submit the form.
create a preview.static.tmpl file which has minimal HTML: just the topic body and alink to close or reload the preview.

Double Click To Edit

Stolen shamelessly from http://openwiki.org. You double click a page and it opens in edit mode. <body bgcolor="#000000" ondblclick="location.href='%SCRIPTURL%/edit%SCRIPTSUFFIX%/%WEB%/%TOPIC%'">

Data

General Pages on EvEm use a form called the article form which has fields for title, category, summary, keywords and thumbnail file name. These fields are used in the formatted searches and other functions in the EvEm plugin.

For example we use the category field to do this:

On this page: http://evem.org.au/bin/browse/Home/FreeGames you'll see this these links up top: Games > Links and Info which link to the following:

The first link displays a page with a formatted search for the value 'games' in the field and the second for 'games, links and info' in the field. The links are created using a function in the EvEm plugin.

At the bottom of each page is a similar system with keywords also generated by the EvEm plugin:

Related Topics by Keyword:
Games
Free
GPL
Open Source
Games + Free
Games + Free + GPL
Games + Free + GPL + Open Source

The category field has a limited number of choices to maintain a little consistency in the article pages, but the keywords field is open so that authors can group articles in any way they like. Clicking on a keyword link opens a page with a formated search by keyword field value.

We've used TWiki Forms in other places too. The game server page uses the form to store server values and the Home LAN Central page for member details. We've used this in conjuction with our Form Plugin to make a dynamic page of information with a form at the bottom to add an entry to the list.

Server list: http://evem.org.au/bin/view/Home/GameServerIndex?skin=home
HLC list: http://evem.org.au/bin/browse/Home/HomeLanCentralMembers

Formatted Searches

EvEm uses formatted searches a LOT to make dynamic pages. For example, the home page is a formatted search to get a 'latest topics'display in a format we wanted, it also takes a query string param to make keyword indexes. E.g. click on the keyword 'Quake 3' and you'll be directed to the home page for an index of the latest topics which contain 'Quake 3' in their keywords field.

The querys are passed via query string. An example formatted search looks like this:

%SEARCH{ "\"Article Status.*value=\".*Online.*\";\"Article Section.*value=\"%URLPARAM{"index"}%.*\"" web="Home" order="modified" reverse="on" regex="on" nosearch="on" limit="%URLPARAM{"count"}%" nototal="on" format="<table width=\"100%\" cellpadding=\"3\" cellspacing=\"0\" border=\"0\" class=\"articlesummary\"><tr><td><b><a href=\"/bin/view/$web/$topic\" class=\"h2\">$formfield(Title)$formfield(Article Title)</a></b></td></tr></table><table width=\"100%\" cellpadding=\"15\" cellspacing=\"0\" border=\"0\" class=\"articlesummary\"><tr><td><i>$username(\"$topic\") - $date - v$rev<br />$searchlinks(keywords=\"$formfield(Article Section)\" separator=\" > \" base=\"SectionIndex\")</i><p>$image(image=\"/pub/$web/$topic/$formfield(Article Thumbnail)\" align=\"right\")$formfield(Article Summary)</p><p><a href=\"/bin/view/$web/$topic\">Read on and comment...($commentcount( topic=\"$topic\" ) comments)</a></p></td></tr></table><br />" }%

A lot of the bits in the format value are for the EvEm plugin.

EvEm Plugin

For all the odd requirements we needed, we've placed a bunch of code in a plugin. For example in a formatted search we can have:

$username(\"$topic\")	Pulls out the last user to edit that topic (without the web value)
$searchlinks(keywords=\"$formfield(Article Section)\" separator=\" > \" base=\"SectionIndex\")	Makes the section links: Games > Links and Info
$image(image=\"/pub/$web/$topic/$formfield(Article Thumbnail)	Writes the image tage for the article thumbnail
$commentcount( topic=\"$topic\" )	In development, this is supposed to pull out the number of responses posted to each article.

And a couple of other odd bits. Here's everything if you're interested:

    $_[0] =~ s/%METAFIELD{(.*?)}%/&renderMetaField($1)/geo;
    $_[0] =~ s/%SEARCHLINKS%/&handleKeywords()/geo;
    $_[0] =~ s/%SEARCHLINKS{(.*?)}%/&handleKeywords($1)/geo;
    $_[0] =~ s/\$searchlinks\((.*?)\)/&handleKeywords($1)/geo;
    $_[0] =~ s/%TITLE%/&renderTitle()/geo;
    $_[0] =~ s/%SECTION%/&renderKeywordSection()/geo;
    $_[0] =~ s/%SECTION{(.*?)}%/&renderKeywordSection($1)/geo;
    $_[0] =~ s/%KEYWORDLINKS%/&renderSimilarKeywordLinks()/geo;
    $_[0] =~ s/%KEYWORDLINKS{(.*?)}%/&renderSimilarKeywordLinks($1)/geo;
    $_[0] =~ s/\$depth\((.*?)\)/&renderThread($1)/geo;
    $_[0] =~ s/%FORM{(.*?)}%/&renderForm($1)/geo;
    $_[0] =~ s/%FORMDATA{(.*?)}%/&renderFormData($1)/geo;
    $_[0] =~ s/\$image\((.*?)\)/&renderImage($1)/geo;
    $_[0] =~ s/%IMAGE{(.*?)}%/&renderImage($1)/geo;
    $_[0] =~ s/\$username\((.*?)\)/&renderAuthorUserName($1)/geo;
    $_[0] =~ s/%DOCID%/&renderDocumentID()/geo;
    $_[0] =~ s/%RESPONSEPARENTLINK{(.*?)}%/&renderResponseParentLink($1)/geo;
    $_[0] =~ s/\$commentcount\((.*?)\)/&renderCommentCount($1)/geo;
    $_[0] =~ s/%ENV{(.*?)}%/&handleEnvVariable($1)/geo;

%FORM% Plugin

Allows you to embed a variable and read a form template for display on the page. The form is editable while the page is still in view mode.

Syntax:

%FORM{ web="%WEB%" formtemplate="HomeLANCentralMemberForm" parent="%TOPIC%" newtopicname="%TOPIC%-Member-%GMTIME{$year$mo$day$hour$min$sec}%" }%

Used to submit new game servers and Home LAN Central member details. When you click 'Submit' it jumps straight to save .

When viewing a topic submitted via the form plugin we've made another for displaying the data, only because we didn't like the default way that TWiki did it and we wanted to be able to change it for each type of form.

%FORMDATA{ displayon="GameServersForm" fields="HostName,GameName,GameMod,ServerAddress" header="<table cellpadding=\"3\" border=\"0\" cellspacing=\"0\"><tr><td colspan=\"2\"><b>Game Server Details</b>:</td></tr>" footer="</table><br />" }%

Threaded Topic Responses

Using the form plugin and <code>%SEARCH%</code> threading.

Form plugin source:

%FORM{ web="%WEB%" formtemplate="BoardResponseForm" action="save" displayon="ArticleForm" parent="%TOPIC%" thread="%METAFIELD{"Thread"}%,%TOPIC%" threadid="%METAFIELD{"Threadid"}%%GMTIME{$year$mo$day$hour$min$sec}%" newtopicname="Response-%GMTIME{$year$mo$day$hour$min$sec}%-%DOCID%" header="<h3>Respond:</h3>" footer="" }%

Formatted Search source:

%SEARCH{ "FIELD.*name=\"Thread\".*value=\".*%TOPIC%.*\";FORM.*name=\"BoardResponseForm\"" order="field:Threadid" web="Home" casesensitive="off" regex="on" nosearch="on" nototal="on" bookview="" noheader="on" format="<table cellpadding=\"5\" cellspacing=\"0\" border=\"0\"><tr>$depth(thread=\"$formfield(Thread)\" padding=\"<td> </td>\" delimiter=\",\")<td><table class=\"boardresponse\" cellpadding=\"0\" cellspacing=\"0\" border=\"0\"><tr><td class=\"boardresponsesubject\">$formfield(Subject)</td></tr><tr><td class=\"boardresponsesummary\">$summary<p>Read More...</p></td></tr><tr><td class=\"boardresponseauthor\">by $username(\"$topic\") :: $date</td></tr></table></td></tr></table><br />"}%

Thus we search for topics using the form BoardResponseForm and containing the current topics name in the Thread field. We also use the ThreadID field to order the responses (See SortSearchByMetaField)

Using TWiki to Make TWiki Mode

We've tried to make as much of the site template pull content from topics as possible.E.g. the site css file, globalJavaScript, but also things like the side columns.

However some elements have to go on the templates. For example the =%FORMDATA% tags (one for each type of form we want to display) has to be on the template as does the form and formatted search for the topic response display.

Final Thoughts

Things still to do:

finish comment count for topics in search results
Upload of multiple files in zip file
Auto generation of thumbnails
1,000,000 other things

User comments:

Attachments too fiddly
Can't see original topic author easily enough

Comments

Interesting stuff! I was wondering if the pop-up preview window caused any problems with BackFromPreviewLosesText - I suspect that the new window will cause IE5/IE6 to flush their cached edit state, but since you still have the Edit window open that's not a problem. Worth knowing in case someone goes Back from the saved page, and there is a simple fix by setting some HTTP headers.

-- RichardDonkin - 04 Feb 2002

I like the threaded discussion plugin, this qualifies TWiki as a WebLog, or a MeatBall:WikiLog (a la Pikie:FrontPage). Nice feature! When compared with SlashWiki, maybe it's easier for Wikis to add weblog features than the other way round?

-- RichardDonkin - 12 Feb 2002

EvEm is now live, using TWiki. http://evem.org.au

-- AdrianLynch - 01 Mar 2002

Any chache of this getting bundled up into a skin and released to the general public? It's very very cool and I'd like to use it as well. smile

-- AdamShand - 26 Mar 2002

Seconded :> -- MartinCleaver - 27 Mar 2002

On my installation 2xclick-edit only opens the first version of the page edited during that browser session. E.g. 2xc-edit a page, save it, then 2xc-edit it again and you don't see your changes (in the edit screen, the browse screen is okay). Twiki 2001-Dec-01, Apache2, (perhaps Apache1.3 as well? don't remember)

-- MattWilkie - 31 May 2002

Moved MattWilkie's comments to the end - save diff for all you folks reading after me wink

-- PeterMasiar - 31 May 2002

Well we have just removed Twiki and replaced it with MovableType. Both Andrew and myself found Twiki exceptionally fragmented and bloated, with an exceptionally high learning curve for non technical people. As a comparison it took about a month to setup and modify twiki to provide the features we required, compared to about 3 hours with moveable type.

Granted that twiki is not a 'blog' style system, but even so Twiki manages to 'make the simple impossible and the possible difficult'.

The bottom line is I would only recommend this for people who enjoy tinkering, but there are far, far more elegant solutions available.

-- AdrianLynch - 02 Nov 2002

Seems like you really wanted a blog anyway, so TWiki didn't fit your application - not surprising that it was hard to do what you wanted... This has little to do with most TWiki sites, which are intended to be editable collaboration websites rather than blogs. TWiki is not aimed at non-technical people really - see AdminSkillsAssumptions for a bit more on this.

-- RichardDonkin - 02 Nov 2002

Yes EvEm wanted a blog more than a collaboration environment, and the parting shot is cantankerous. Nonetheless TWiki is difficult to setup and modify, even for technical people, if their skills happen to lie outside the realms of 1) perl, 2) unix.

The AdminSkillsAssumptions are what is needed to install and do simple modifications, and most experienced web masters should be able to figure it out. However what is much harder, and what EvEm managed to do quite well in my opinion, is to customizing TWiki's look and feel beyond installing a skin and a plugin or two.

I don't think it is in TWiki's best interests to dismiss complaints such as Adrian's out of hand. Most of the technical people I know appreciate ease of use just as much as non-techs, if not more so because they understand how much work is being saved.

-- MattWilkie - 04 Nov 2002

Yes. TWiki is complicated, as soon as you need to change the layout. And face it: the base look is really in-elegant -- TooUglyForNonTechnicalUsers. So you do need to change it. But any non-trivial change involves:

preferences per site, web, user
templates
plugin code
core code [sic]

This is architecturally ugly. How did that come about?

The WikiWay is good for collaborating on straight text. And sure it sounds like a cool idea, to extend that idea to variables, layout, some are even dreaming of code in wiki. Still, I think, low level layout is better served with a dedicated templating system. So, we are stuck with a wild mixture of places to fiddle... The incomplete effort to "outsource" so much into wiki pages had been better invested into templating and CSSing all code. In fact, attachment or form layout used to be in the TWiki2000 template system but moved back into core code. In hindsight, not a wise decision.

Another big issue: performance. All these online-search macros are nice; but as soon as your web has real content in it, the cost is just too high for everyday use. I worked my way around with a CacheAddOn, but I wonder why I needed it in the first place.

-- PeterKlausner - 07 Nov 2002

Peter, is the CachePlugin anything you care to share?

-- ThomasWeigert - 08 Nov 2002

Constructive criticism is always welcome, but calling TWiki 'exceptionally fragmented and bloated' doesn't tend to lead to a useful discussion. It's certainly true that TWiki could/should be easier to extend and customise, but it would require quite a lot of re-writing to make it easy to do this. The EvEm site really looked like a blog using TWiki, so it's not too surprising that WebLog software is a better fit.

Right now, I think the biggest issue for TWiki is BetterSkins (using CSS by default with a newer look, more like TigerSkin or similar). Using a third party templating system would also be helpful - by solving the CPAN module installation issue (perhaps bundling key modules with TWiki), it would not make installation any harder.

-- RichardDonkin - 08 Nov 2002

I agree that TWiki is architecturally ugly and bloated, but think that it is worth a discussion.

If it were beautiful I would not have argued for CommonFrontEndCgiScript, if it wasn't bloated I wouldn't have argued for things like WebStatisticsShouldBeAPlugin, if WikiML wasn't user unfriendly I wouldn't have pushed for HtmlAreaEditor.

For all this, it is currently more functional than most of its competitors. I do think, as I have said many times, that I think TWiki needs a rewrite. Whilst I am here for the interim and I continue to recommend TWiki over other products I do so only as measure until TikiWiki and PmWiki get better than TWiki. Unless the rate of change alters I see TWiki being beaten as an inevitability.

CoreTeam: The best way out of this is to empower your contributors to facilitate the rewrite, (PleaseCreateNewWeb) and get other people to help (CoreTeamNominationDiscussions).

-- MartinCleaver - 06 Jul 2003

... and watch out also for newest, fast-growing perl-based competitor - KwikiWiki. It's designed as flexible OO framework to build customized wikis.

-- PeterMasiar - 07 Jul 2003

As implied in my original comment, using emotive words is not likely to get a positive response. Another word for bloated is 'feature rich', for example.

Perhaps I wasn't clear what I meant by bloated. If so, I apologise. I don't wish for less features, on the contrary. But I do think that rationalisation is necessary to provide sustainable growth. [ MartinCleaver - 09 Jul 2003 ]

The real problem is getting more people coding for TWiki - ideally there would be a steady in-flow of high quality patches, using the PatchGuidelines, making it easy for the CoreTeam to say 'so and so has done some great patches recently, shall we add them to the team?' This is how most OpenSource projects work, e.g. Linux has a huge quantity of patches and a very small CoreTeam (if there is really such a thing) - more bazaar than cathedral.

I totally agree that we need to get more people to help code TWiki. I think we need to direct our attention to enabling them to do so. I believe that the best way to do this is to make sure that they know what we want coded. Hence my creating PleaseCreateNewCategories. [ MartinCleaver - 09 Jul 2003 ]

Writing code is the best way to improve TWiki - complaining about ugliness and bloatedness is much less likely to get us anywhere except into a flame-war. TWiki does have lots of areas that need improvement, but there seem to be far more people willing to discuss changes than are willing to actually write code (or do detailed design leading to code refactoring).

I agree that code needs to be written, I also think there is a tremendously large number of people who would help us if they could 1) see what needs to be done and 2) be encouraged by a vision of what could be acheived. I believe that admitting the deficiencies is the first step in understanding and communicating how we get from where we are today to where we want to be. It should not be emotive (again, I apologise for use of that wording) but it does need to be honest. [ MartinCleaver - 09 Jul 2003 ]

-- RichardDonkin - 08 Jul 2003

There's an important point that people need to understand as well. Being a coreteam member or not boils down to one thing and one thing only from a developer's perspective: CVS write access to sourceforge. (there's a few other things, but I'd consider them minor to that) This isn't necessary to...

Develop for twiki. (Get the changes you want now )
Produce patches. (People will like you for it)
Contribute design. (People will love you for it)
Use custom webforms. (You'll be happy)
To have custom links across the top. (This is really nice)
Find Bugs. (!)
Refactor discussion.

CVS write access responsibility could even be said to interfere with the above...

-- MichaelSparks - 08 Jul 2003

Michael - there's a lot of truth in what you say. I had it easier when Peter applied all my (rather long) patches. I was harder when I had to correct more of my mistakes myself! smile

-- JohnTalintyre - 13 Aug 2003

Although Evil Empire is no longer using twiki, the twiki portion of their site is still live. Today anyway. Whenever they upgrade or move servers they are not likely to drag old baggage with them, so I saved some snapshots of EvEm-TWiki in action (EvEm-html-snapshots.zip 286kb).

It's quite a good looking site. The developers obviously poured a lot of energy into it. It's a shame they were going in a different direction than twiki could take them; or vice versa depending on your viewpoint.

-- MattWilkie - 17 Apr 2004

WebForm
TopicClassification	TWikiDeployment
TopicSummary
InterestedParties
AssignedTo
AssignedToCore
ScheduledFor
RelatedTopics
SpecProgress
ImplProgress
DocProgress

Attachments

Topic attachments
I	Attachment	History	Action	Size	Date	Who	Comment
zip	EvEm-html-snapshots.zip	r1	manage	286.2 K	2004-04-17 - 05:34	UnknownUser	some snapshots of EvEm-TWiki in action
gif	evemlogo.gif	r1	manage	3.4 K	2002-02-03 - 12:51	UnknownUser
zip	evemtwiki.zip	r1	manage	56.9 K	2004-04-18 - 06:15	UnknownUser	the EvEm plugin and templates; not in ready-to-run format

Topic revision: r30 - 2004-04-18 - MattWilkie

Account
- Log In
- Register User

Edit
Attach

Ideas, requests, problems regarding TWiki? Send feedback. Ask community in the support forum.
Copyright © 1999-2026 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.