Occasional Zwiki-related posts by SimonMichael and co. To contribute a post, create a subtopic of this page.

December 17, 2009 6:48 pm

Fundraising for plone support

Fabien reported a problem with his Plone-integrated zwiki after upgrading, on the zope mail list, and we worked on it in #zwiki over a couple of days. Progress was made but as far as I know he's still in trouble (I am off irc for the moment - perhaps he'll reply to this if things changed.) The details are hazy now but there was a problem with the compatibility matrix and with (re)installing zwiki into his Plone 3 site. Vejeta reports no problems doing this with Zwiki 2, but.. what's needed is some thorough testing with latest plone versions, and appropriate updates to code and docs. I can't spend more free time on it, but I've created a pledgie funding goal:

Click here to lend your support to: Make Zwiki easily installable in Plone again and make a donation at www.pledgie.com ! Make Zwiki easily installable in Plone again

If you care about Zwiki and Plone, please take a look, or forward to others who might be interested. If people need it, they'll fund it and I'll gladly make it happen.

November 13, 2009 10:43 am

Zwiki/Zope version dependencies

On #zwiki this morning, fredden was trying to revive an old Data.fs and the wiki therein.

I, still sluggish for lack of strong breakfast tea and bracing sea air, mumbled "KeyError macros... could mean old zwiki skin templates..". This is the most common breakage when you make a big jump in Zwiki version; the usual solution is to remove or rename any zwiki skin templates from the wiki folder.

This was good advice as far as it went but we then spent some time trans-globally working through various compatibility issues with older zope, python and zwiki. It may have been better to go immediately into the wiki folder with the ZMI, delete skin templates and try viewing the wiki page again. Or again, I may have misinterpreted the original error traceback, which was incomplete (always paste the full traceback, kids! Copying it from /error_log -> raw text in your browser is often easiest.)

We didn't pinpoint the issue but fredden got back up and running by installing his previous zwiki version (0.38) along with compatible zope and python. Tomorrow hopefully he'll upgrade to at least 0.61 (which I believe yes, I will release as 1.0 just to make it easier to talk about).

Anyway; in the process I did find some errors in the Zwiki/Zope dependencies at http://wiki.zope.org/zope2/VersionsMatrix , which is useful; and generally cleaned up that page. Use it to know what runs with what when you have to deal with older zope/python/zwiki/plone versions.

November 5, 2009 3:44 pm

Spam countermeasures

The current state of zwiki spam is this: publicly-editable zwikis should set a true edits_need_username property, and in most cases this stops the spam; however there is at least one persistent zwiki spammer who works around this. I fairly regularly see a small burst of spam edits from zwiki.org and the wiki.zope.org wikis (and I know at least one other zwiki operator that gets hit.) The spam currently tries to be discreet, embedding a single link in existing content, and even trying to cover tracks with some regular-looking edits.

Next, I or some other all-edits subscriber will click to the affected pages, look at history (access key "y") and revert to the last good version. Aside: this leaves the spammed revisions in the history; I would rather expunge them completely, but that needs fixing.

Finally I will harvest the new spam domains and add them to the banned_links lines property which I keep on the root folder of the zwiki servers I manage (zwiki.org's, and wiki.zope.org). If I were to neglect this, the small bursts would probably become large ones. Sometimes I'll mention the new patterns on #zwiki as something other zwiki operators should add.

This is now too tedious, and I need a new plan. I had some fruitful discussion with betabug on #zwiki this morning, looking at his HoneyPotBL product and various other blacklist-type solutions out there. I have a new, two-pronged strategy targetting general and zwiki-specific spam respectively:

  1. I found Repel, a nice apache add-on for rejecting known-spammer ip addresses that just worked. This is now running on zwiki.org. It's a little hard to test, but presumably providing some protection; the log shows occasional comment spammer and other suspicious/malicious ips being blocked. If you're getting zwiki spam and running behind apache, it's probably a good idea to set this up. You'll need to sign up with Project Honeypot to get a key, but that turns out to be easy.

  2. I made Zwiki check a global blacklist at edit time, out of the box. This is crude but requires no configuration, seems to be working and hopefully won't cause trouble. Here's the release note:

    The banned_links, max_anonymous_links and max_identified_links
    properties are no longer supported. Instead, at edit time Zwiki
    attempts to read a global blacklist of zwiki-specific spam patterns
    from zwiki.org. This feature aims to stop the most common zwiki spam
    for all Zwiki users with minimum maintenance effort. For added
    protection, you can block known spammer ip addresses with
    http://repel.in-progress.com (see also http://betabug.ch/wiki/HoneyPotBL.)
    This is a prototype. For now, a http get attempt to
    http://zwiki.org/spampatterns.txt with 1-second timeout is made at
    each edit. The feature is on by default. Todo: follow suggested
    caching interval.
    To disable use of the global blacklist, add a local "spampatterns"
    lines property on or above your wiki folder. You can leave it empty
    or paste in the contents of your old banned_links property.

Right away, this means less work for me, since updating one spampatterns.txt file is quicker than updating multiple banned_links properties. It protects all zwikis running the new code, mine and yours, and hopefully soon the zope wikis. And as a side benefit, it might for the first time give me way to estimate the number of active zwiki sites (by counting spampatterns.txt requests). Some folks may turn this off, but I'm hoping most will not. Comments welcome!

October 25, 2009 3:08 pm

Problem wiki folder ids, what to do

We sometimes need to know whether we are in a wiki's revisions/archive subfolder, or in the main wiki folder. Eg when viewing or doing other things with a page revision object. Here are some alternatives I've considered:

  1. use known folder ids like 'revisions' or 'archive - this means your wiki will break if you happen to choose that id for the wiki folder. This is what we've done up to now, and I just noticed the bug.
  2. use ids, but more obscure ones like 'zwiki_revisions' or 'revisions_' - old wikis will break and need (quick) upgrading; urls are not as nice
  3. use a custom folder type - old wikis will break and need upgrading; custom types in the zodb are a pain with their ingrained module paths
  4. use folders with a marker attribute added - old wikis will break and need (quick) upgrading; folders that look normal but aren't seems like fertile ground for gotchas (but, when would you ever manually create an archive/revisions folder; and copy/pasting a wiki should still work)

For now we stick with 1. We could detect and warn in the failure mode, but we don't yet.

October 25, 2009 2:36 pm

A Zwiki blog

I'm starting a new (zwiki-based) blog. I plan to blog on Zwiki-related topics here (and, refine the zwiki-blog-building process.) Any other Zwiki user can post guest blogs, and I encourage that. I will be adding a proper feed and other standard blog comforts so that this will hopefully become something worth bookmarking.

Right now the only other zwiki-blog I know about is http://webseitz.fluxent.com/wiki , which has been running continuously since.. it looks like 2003 at least. It's a little hard for me to tell because the site is running a really well-matured Zwiki vintage (0.17). Way to go BillSeitz!


See BloggingDiscussion for some history of building blogs with Zwiki. I took ZwikiBlog from there and have been tweaking it. Instead of listing all recent pages, this version lists only its latest N direct child pages. So to make a blog post, create a new page below The Zwiki Blog. The plan is to have stable, blog-worthy content below this page, while (for now) existing within the larger wiki (which makes linking easy and keeps the zwiki.org url).

The index page is html+dtml, with comments and some edit features disabled. Here's the code which includes the rendered main text of its children.