Skinning a ZWiki

This weekend I wasn't content with relaxing and enjoying going out with friends for coffee and with the HelMUG guys for... eh... coffee too. I worked on a little coding project with ZWiki. Hacking in my spare time today was fun. Even though I did nearly the same stuff I do at work, I feel relaxed. It seems that because I did something new, was on a "discovery" tour, there was something playful to it, like playing a game. Now, what was it all about, this ZWiki and Skins thing?...

You know, I have had this idea that a ZWiki (or any Wiki for that matter) is really a simple little Content Management System, in fact I wrote once about the easiest CMS on Zope. But to make good use of a CMS, the result has to look good and people don't want to spend weeks to restyle the basic ZWiki look. That's what templates are for. At http://www.openwebdesign.org, lot's of free and good looking web templates are available. My little project was to pick one of those and make it "dynamic" with a ZWiki.

I'm not going into the details here, that will have to wait for a How-To somewhere on zwiki.org. But basically the work consisted of dropping the HTML files, images, and CSS files into the ZWiki folder. Then adapting some of the ZWiki templates to produce HTML that "fits" with the openwebdesign template. Even allowing for some time where I had to orientate myself in the ZWiki code base and template system, it took just a couple of hours. There are still some rough corners and some things not yet done. But the intermediary result at http://nautica.demo.zwiki.org is pretty nice (if I may say so myself, and I didn't do the design anyway :-). Motivation enough to write out the procedure in more detail soon.

More ZWiki Skins and Skin Know-How

Friday evening I finally took the (seemingly) big step and slapped some new paint on my own little wiki site papakiteliatziar.gr. Just like with the nautica project, I took a template from openwebdesign.org and created a zwiki skin out of it. The template needed only a few changes, the biggest of which was the replacement of the main deco image with one of my sketches. I like the result so far, even though the content of the site may look greek to you. It's been the fourth ZWiki skin I'm building, and I'm getting faster with each one. I'm down to a couple of hours for a site with a reduced set of wiki functionality.

Since I've learned a lot in the experience, I was able to update the HowTo describing the process. At first zwiki.org had some problems with a full disk, so I stored the howto right there on my own zwiki. Now that the database of zwiki.org has been packed, the HowTo found its home at CreateZWikiSkinsFromOpenWebTemplates. The other places (nautica and papaki) still have it, but they point to zwiki.org, where I plan to keep the howto updated. (Reminder for those coming in late: The ideas behind this are explained in The Easiest CMS on Zope... Zwiki and Skinning a ZWiki.)

Given the latest trolling on the zope mailing list I think it's interesting to note that Simon provides one of the biggest documentation projects for the Zope community, yet works on a shoestring hosting. Maybe some people could contribute something for that instead of spending hours for a useless and irresponsible trolling project.

The Garage Site using ZWiki

For a while now I've been talking about skinning a ZWiki and using it as the easiest CMS on Zope. I've done a demo site with Simon (of ZWiki fame), done my own wiki site in this way, and we've done a couple of client demos at my workplace. Now we did what we recommend others for our own site and it rocks: Looking at the new Graphics Garage website (went online yesterday evening) you wouldn't guess this to be a ZWiki, it's a pure design site. But there is some nice tech behind it which results in a very simple user interface...

The first step was to shut out all the world from editing, sorry folks but a company site isn't a "free for all" :-). For logged in users the wiki interface stays almost the same. Once logged in a small "control form" (pic) is displayed on the page, some other Zwiki functionality has been removed since we don't need it. We added a very simple custom image container product. This does simplified uploading, editing, searching of images. Most important: It displays the markup needed to put the image into reStructuredText, ready for copy and paste. It also associates those images with an "Accelerated HTTP Cache Manager" so they get some caching love from proxies and browsers.

Looking at the site you will notice that the pages aren't uniform at all. Almost every page looks different. My target was that there would have to be no special treatment through the ZMI for pages to be different. It would be "easy" in the first place to set properties on pages and then change stuff around in the ZPT. But that is not transparent to users, in my opinion it's a recipe for later disasters when editors want to change things around. What we needed was something that gives designers the freedom to style pages while retaining technical boundaries.

So instead we standardized on reStructuredText, using some "compound" statements to build blocks of content and marking things with :class:. That stuff is then picked up from the CSS where all the styling happens. Editors don't need to be too proficient with reSTX, most of the times looking up how it was done before or on some other page is enough. Of course the ZWiki "Preview" function helps. What we don't have though is some kind of "Workflow"... mess up the page and it really is messed up. For playing around editors can use the wiki "Sandbox", which is open only to logged in user.

For the "Nuts and Bolts" section I used a python script and ZPT to build an automatic sub menu. This gets included into the pages using the reSTX "raw directive" and some DTML. It's not the best solution for me, because it binds us to reStructuredText and we have to enable DTML (not that much of a security problem in a closed site, but still). Also it inserts an extra "span" into the code, which breaks validation. Yes, apart from those pages, all the site validates as XHTML 1.0 strict. It wasn't even difficult.

It also displays fine on lynx. Some pictures don't have alt-attributes. It would be great if images inserted into reSTX out of Zope would automatically use the "title" attribute of Zope's "Image" object for "alt". That would make it much easier for editors (in reSTX you can use :alt: with the image directive, but it's not as obvious as uploading the image with a description right away).

Images are my only other grief (so far, knock on wood), in the "Portfolio" page. That page contains a lot of images. They also have to be in reasonable good quality, being a showcase of our company's work. Since our line here isn't too big the download takes quite long and I'm still thinking about good solutions.

ZWiki Code Contributions

Yesterday I started to look more into contributing patches and bugfixes to ZWiki. As I start to feel more confident in Zope hacking, I feel I can maybe contribute something for the first time. So yesterday I went through the steps on the zwiki.org/DarcsRepos page, installed darcs and set it up. Easy. Sent in my first patches too.

Instant gratification: My patches appear on the "zwiki repo summary page". Browsing through that commit list made me want to contribute even more. ZWiki is such a great product and so far it's all been Simon's work, blood and sweat! He really could use more contributions!

zwiki.org offline, awaiting backup

The host of zwiki.org (and with it all the wikis on wiki.zope.org) are currently offline due to technical problems. To me it looks like filesystem corruption (about the only thing that can bring a ZODB to its knees). Simon requested restoration from a backup from his provider after trying all kind of things. We'll have to wait for that now...

In the meantime we can meditate on how much of a community service zwiki.org and wiki.zope.org really are providing. Simon currently has a very small hosting plan, so I'm thinking about finding ways to get together the means to upgrade zwiki.org to a bigger plan (see his provider's VPS plans), Simon currently has VPS-1, which is really tight for such a big and busy Zope site. Getting him to put zwiki.org on VPS-2 would be the fastest and simplest solution. Ideas?

zwiki.org is back!

Thanks to Simon and his provider (and thanks to regular backups - you're doing yours, right?) zwiki.org is back online. We've lost a few edits that happened in the hours from the last backup to the problems. That's bad, but not as bad as a full desaster would have been. Thank you Simon for all the work you are putting into this community thing!

Zwiki Bugday this Friday?

Got some "free to play" time at work (yay my boss!). This Friday (tomorrow) would be a nice chance to make a Zwiki bugday, like Simon used to organize a few times. Anybody in for it? I would be at it from 10 in the morning till 18:30 in the Afternoon (GMT+2).

The zwiki.org/IssueTracker is full of stuff that needs sorting out. Even if you don't know much Zope/Python programming you could help by going through the issues, try to reproduce them, add instructions how to reproduce them and feedback into the comments. If you *do* know python/zope hacking, patches, comments, hints are of course welcome!

So, what do you think? Join us at #zwiki on irc.freenode.net, comment on zwiki.org/GeneralDiscussion or zwiki.org/BugDay or leave a comment here!

Zwiki Bugday Fun

I'm done with my part of the BugDay and Frank went home too. We have so far closed 13 issues and opened 1 new one. A lot of "oldies" have been closed after failing to reproduce them, but we also got patches for some issues into the darcs repository.

I started the day with something a little bigger (#1299 getting Zwiki-in-Plone to do mailout again) and rounded it out with smaller stuff. Quite often all I had to do was to implement and test existing patches or the patches Frank gave me and put them into darcs. Zope hacking is fun.

Now I'm really tired but happy! Good bughunting to Simon and whoever lends a hand to continue the bugday!

Zwiki 0.59 RC2 is out... test, test!

Over the weekend Simon has released Zwiki 0.59 RC2 over at zwiki.org. It's been a while since there was a Zwiki release, so this one contains a lot of bugfixes. Some of the bugfixes are relevant to making your fight against the spammers and vandals who haunt any "open" wiki a better fight. We also have a few select new features, like "If-modified-since" handling (aka "conditional HTTP GET", or "304") to reduce traffic and server load, and sortable views of the issue tracker.

This is a Release Candidate, so please download and test it. Don't be afraid of testing though: The code is already running on zwiki.org, my own wikis and a few other places, so it's stable enough. We also need all translators to look through RC2. The final 0.59 release is due April 2.

Zwiki 0.59 is released!

Simon released Zwiki 0.59. This release includes a lot of bugfixes (some relevant to the neverending fight against spammers and vandals), and a few features. It's been well tested, so I'd suggest people upgrade to this. Of course if there are any problems or even feedback, let us know on freenode/#zwiki, on zwiki.org/IssueTracker or zwiki.org/GeneralDiscussion.

This Friday Zwiki BugDay

Just a small reminder: This Friday is a Zwiki bugday. As usual, you can read a bit more over at zwiki.org/BugDay, we'll be online at #zwiki on freenode too. Our main target is to try to reproduce and maybe close as many as possible of the old issues that are clogging the issue tracker.

DateTime changed, duh!

Yesterday evening, even before Zwiki bugday officially started, we had the first results. I had pestered Wu to get involved, even though he's pretty much busy with work. In the evening he tried out a little test script I needed for our problem with "last edit date". We noticed that on his server DateTime('2007-05-02 10:11:04') doesn't give the same result as on my machines. At first I had thought this to be OS dependant (all of my boxen live happily without "locale" support). But then I noticed that he was using Zope 2.10 and a little testing on my side and a bit of search revealed that Zope's DateTime() has indeed changed for 2.10.

Zwiki is falling exactly in the case that got fixed: We have date strings without time zone information. We use DateTime() to get the strings into DateTime() objects (so we can do time calculations) - but we so far expected the date and time to be interpreted as GMT or "Universal" time zone (aka UTC).

To fix this for all Zope versions we have two approaches: We can change the format for last_edit_time to include timezone information, providing upgrade methods. Or we can glue ' GMT+0' at the end of last_edit_time whereever we convert to a DateTime(). The first choice appears cleaner to me, but we've already changed that format a couple of times in the past, so I wonder what others have to say.

Zwiki Bugday Wrapup

Yesterday's Zwiki bugday was fun and successful. It started slow. In the morning I was busy at work, but in the afternoon got permission to work on the bugday on company time (yay Graphics Garage!). Had a slow start, mainly getting details on some of the issues, like the stuff Wu helped with, but did not get a break in on any particular bug. Later Simon showed up on #zwiki and things got really started...

After working hours I went home and continued till past midnight. This bugday showed me that exchange of information and opinions are an important point of a bugday. "What do others think about this fix?", "What's the best way to solve issue X?", "What was this line of code there for?", "Does Y work for anyone?" - that kind of stuff. You can't always discuss things right away when project devs are so far apart and in totally different timezones.

I got my DateTime change question answered, and went on and fixed it right away. We decided to change the format for last_edit_time after all - the change turned out to be clean and fast. There is now only one point -- in the upgrade() method -- where we detect an old style ISO() DateTime format without time zone information. We mimick the old behaviour by slapping on a ' GMT+0' and convert to a proper ISO8601 timestamp. I don't think I closed any other issues myself (except for a dupe or so), but I'm content with the result of the day.

zwiki.org Domain Trouble

Currently zwiki.org is awaiting domain renewal. The domain name can't be resolved, so you can not reach zwiki.org by browser right now. Quote Simon on GeneralDiscussion: "zwiki.org is expiring and I'm having trouble getting my registrar to accept the payment." If you are in a hurry and need to access something from zwiki.org, you can add the following line to your /etc/hosts file:

66.179.181.88   zwiki.org

... don't forget to remove that line once regular DNS service picks up zwiki.org again.

Update: Problem solved! The domain is renewed, DNS is flowing again, we're open, visitors welcome!

Zwiki 0.60 Released!

Unobserved by the world, Simon released Zwiki 0.60 into the wild yesterday. We had a 0.60RC1 for a while, some bugs came up and got fixed and here you are, with the next proper release. I have to think hard about what's new in this release, mind you: not because there isn't anything, "au contraire", there is a lot. But I've been running on development versions for quite some time now and have enjoyed most of the changes for a while already. So, what's there?

• Lots of fixes to get Unicode working with Zope 2.10's new ZPTs, so we're ready for 2.10 now
• The plohn fanboyz will cheer: works with Plone 3 now too it seems
• Page editing history is uncoupled from Zope undo now. That means the edit history stays around when you pack the ZODB.
• Commenting works for plaintext and html pages too now
• Wiki templates are now imported recursively. I hear you sighing "what's that and why should I care?" In short it lets me build nice templates e.g. from http://www.owd.org into Zwiki templates and give them to you as a tgz, so you can make a prefab wiki like nautica.demo.zwiki.org with one click.
• The usual bunch of code cleanup, bug fixes, and small improvements.
• ... anything I've forgotten, drop me a comment!

Copy a Folder's Contents

Zwiki's new revision system uses a BTreeFolder2 to permanently store revisions. That's a wise decision, because those revisions can really pile up. Some wikis ran with an interim version of the code, where it created a normal folder to hold revisions. What I did there is to rename the folder to "revisions_orig", create a new "revisions" folder and copy the contents over. Here is a little python script that does the copying over, when the cookie used by ZMI copy & paste can't seem to hold them all. Nothing special, just one of those posts to remind myself...

Create a new "Script (Python)" object in the ZMI, fill it in with this code:

### Parameter List: from_folder, to_folder

from_folder = getattr(context.aq_explicit, from_folder)
to_folder = getattr(context.aq_explicit, to_folder)

from_folder_ids = from_folder.objectIds()

from_copied = from_folder.manage_copyObjects(from_folder_ids)
to_folder.manage_pasteObjects(from_copied)

print 'done'
return printed

Running it should be self-explaining.