I've attached a setupdb script for OpenGuides created
for 2 reasons
1) it seems silly to have to remember the arguments
for cgi-wiki-setupdb when you've already input them
into a perfectly good wiki.conf file
2) it can input some standard nodes (like Text Formatting
Tips, sample licensing etc.) for an OpenGuides distribution.
Hopefully should be pretty clear from script and basic
POD. Any suggestions?
(Tested on Win32 with Mysql and SQLite)
I just got this trying to delete version 17 of "Wiki Etiquette":
DBD::Pg::st execute failed: ERROR: Bad timestamp external representation ''
at /home/earle/downlode.org/perl/lib/CGI/Wiki/Store/Database.pm line 572.
Might be a CGI::Wiki thing.
----- Original Message -----
From: "Alessio Bragadini" <alessio(a)sevenseas.org>
To: "IvorW" <ivorw-openguides(a)xemaps.com>
Sent: 27 June 2004 16:02
Subject: Re: [OpenGuides-Dev] openguides-setupdb script
> On Sun, 2004-06-27 at 12:32, IvorW wrote:
> > By the way, I have a Postgres problem with type conversion. How do I force it to use
> > a float (or rather a double)? This is a problem with the distance finder on Postgres.
> What's your problem exactly? Typecasting in PostgreSQL is usually done
> in the form of
> select a::float from...
> but please let me know if I can help.
Just uploaded 0.02 to CPAN which now passes the test on Postgres as well
Thanks for the info.
Quick reminder - Bio Mapping is now live at the RCA Degreeshow in
Please come along to the show and borrow one of the devices to join in
the Collaborative Emotion Mapping. You can also catch the project
on-line at www.biomapping.net. New maps will be uploaded as the
emotion map grows.
The event will go on till next Sunday - 4th of July. (closed July 2), 10am to
6pm daily. Late night opening on the 1 July until 10pm.
Royal College of Art, Kensington Gore London SW7.
This fixes the problems that Dom (& others) were having with diff.
----- Original Message -----
From: "PAUSE" <upload(a)pause.perl.org>
To: "Ivor Williams" <6bed-rgew(a)spamex.com>
Sent: 26 June 2004 13:02
Subject: CPAN Upload: I/IV/IVORW/CGI-Wiki-Plugin-Diff-0.07.tar.gz
> * Replies will be sent through Spamex to cpan-testers(a)perl.org
> * For additional info click -> http://www.spamex.com/i/?v=3625358
> The uploaded file
> has entered CPAN as
> file: $CPAN/authors/id/I/IV/IVORW/CGI-Wiki-Plugin-Diff-0.07.tar.gz
> size: 7458 bytes
> md5: 83ea44c82bfe9d07df9681330c76d88d
> No action is required on your part
> Request entered by: IVORW (Ivor Williams)
> Request entered on: Sat, 26 Jun 2004 12:02:10 GMT
> Request completed: Sat, 26 Jun 2004 12:02:36 GMT
> paused, v460
Kake has now released version 0.35 of OpenGuides, and I would recommend that
everyone upgrades to it as soon as possible. The change that this version
brings is the ability to delete specific history versions of any node; this
is an important tool to combat wiki spammers, who are becoming increasingly
common. Up until now, even if you reverted their change, their spam would
remain in your database forever and still be available in node history. This
is now no longer the case. So, I suggest upgrading as soon as possible
(requires the new CGI::Wiki 0.54).
My thanks to Kake for implementing this so quickly after it was suggested.
> -----Original Message-----
> From: openguides-dev-bounces(a)openguides.org
> [mailto:email@example.com]On Behalf Of
> Earle Martin
> Sent: 25 June 2004 09:09
> To: openguides-dev(a)openguides.org
> Subject: [OpenGuides-Dev] Spam, node history and recent changes
> I see london.og has had some spam put on it (thanks Kake and Ivor for
> undoing the damage). I just made myself look a muppet by
> forgetting how our
> front-page recent changes box works and trying to commit a
> page change with
> a different summary so the spam wouldn't appear on the front
> page - only, of
> course, that didn't work because the listing doesn't collapse multiple
> occurrences of the same node.
> This is a problem, because it means spammers can attack any
> page and be
> _guaranteed_ to be on the site's front page for a while,
> until they've been
> pushed off the bottom of the list.
> So, can I propose that on the _front_ page, we collapse
> multiple occurrences
> of any single node so that only the most recent change is
> listed? This would
> probably necessitate a slight phrasing change to "ten most
> recently changed
Agreed we should compress multiple changes to the same page. After all, people
only get to see ten of them.
While we are at it, I think we should also filter out "null edits" (and not
saving them). As it is, we do see plenty of null edits appearing in RecentChanges,
on the front page, and in change histories of individual pages.
Regarding suppressing pages appearing on the front page, I suggest that we
provide the facility to make the "change type" of a particular version
editable after the event. That way, we can change unwanted edits to "minor
> Also, it's been pointed out (on
> ) that once the spammer makes a modification, it stays in the page history
> forever, and thus stays accessible to search engines, justifying the attack
> in the first place. There are two ways to combat this, I think: (a) make
> history pages not available to search engines (which I think should be the
> case anyway, because they contain mistakes and other crud - so I'll make
> this happen), and (b) let site administrators delete particular _versions_
> of a page, perhaps just by replacing the content with "deleted", rather than
> actually removing it - that way it could show up on the page history as
> "(deleted)" or some such.
(a) I agree totally.
(b) We want perhaps to make this a soft delete, or archive the dead text somewhere
else in case we need it for legal reasons.
I see london.og has had some spam put on it (thanks Kake and Ivor for
undoing the damage). I just made myself look a muppet by forgetting how our
front-page recent changes box works and trying to commit a page change with
a different summary so the spam wouldn't appear on the front page - only, of
course, that didn't work because the listing doesn't collapse multiple
occurrences of the same node.
This is a problem, because it means spammers can attack any page and be
_guaranteed_ to be on the site's front page for a while, until they've been
pushed off the bottom of the list.
So, can I propose that on the _front_ page, we collapse multiple occurrences
of any single node so that only the most recent change is listed? This would
probably necessitate a slight phrasing change to "ten most recently changed
Also, it's been pointed out (on http://www.usemod.com/cgi-bin/mb.pl?WikiSpam
) that once the spammer makes a modification, it stays in the page history
forever, and thus stays accessible to search engines, justifying the attack
in the first place. There are two ways to combat this, I think: (a) make
history pages not available to search engines (which I think should be the
case anyway, because they contain mistakes and other crud - so I'll make
this happen), and (b) let site administrators delete particular _versions_
of a page, perhaps just by replacing the content with "deleted", rather than
actually removing it - that way it could show up on the page history as
"(deleted)" or some such.