Hi, I don't follow OG development but as host operator a few things are
coming up. The machine's load is gradually climbing over time and some
of that is OG.
Despite a relatively low hit rate on OG it is consuming quite a bit of
resource. If OG started taking off it would take the machine down.
First up: index.cgi requires 0.35s to perform a `perl -c` syntax check.
Any thoughts on putting OG on a mod_perl server? I have mod_perl running
here of course and we'd need to coordinate some apache.conf stuff.
Second: the supersearch.cgi gulps down CPU, often for seconds at a time.
It is a frequent resident of `top` output. This isn't really
acceptable. I'm going to request this feature be turned off unless an
effective optimisation plan or some other way to reduce its impact
here is constructed pretty soon. Sorry about this but it's encroaching
Third: I wonder if there's some way to instruct robots not to spider
parts of your wiki. This ought to speak for itself:
$ grep crawl /var/log/apache/london.openguides.org-access.log | grep 'action=edit' | wc -l
Finally: I posted about a DoS and was wondering what the status of a
solution was. http://openguides.org/mail/openguides-dev/2004-October/000542.html
Paul (any overbearing tone unintentional ;-)
Paul Makepeace .............................. http://paulm.com/inchoate/
"If my elbow was straight, then I'll show oyu mine!"
Hello. I noticed that the "Link to this page" link on the map-style
indexes doesn't keep track of all parameters; it doesn't remember the
map type (satellite, hybrid, or normal), and if you've zoomed or
scrolled the map at all then it forgets the category/locale that you
I attach a fix - there are patches to both OpenGuides.pm and
You'll end up with URLs looking something like:
Here are a few things that people might be interested in. They all
might require tweaking for your particular guide; don't run them
unless you understand them.
First of all, an importer thingy that reads data from a YAML file and
uses WWW::Mechanize to add it to a guide. (It won't overwrite
existing data; it checks first and warns you if you're attempting to
create a page that already exists.) Because it's YAML, you can't use
asterisks in the content or it gets confused. If you don't use
streetmap x/y links and OS x/y coords then you'll need to change that
part. You can include any fields in the YAML file that are present in
the edit form. This is mainly useful for creating stub pages so a
location search will find them. I've used it to add all London's Tube
stations and Good Beer Guide pubs.
rgl.pl is the importer and rgldata is an example datafile.
Secondly, a search thingy that finds all things in category A within N
metres of things in Category B. It's quite fast and efficient because
it uses raw SQL rather than the abstraction layers. It may be
Postgres-specific, and it's certainly OS X/Y specific, but it should
be obvious how to change that to suit your own guide. An example
(plan your own Circle Line pub crawl):
This is, unsurprisingly, find.cgi.
what lines they're on. Again, will need tweaking for non-London guides.
show_tube_stations.html goes somewhere in node.tt and show_tube_stations.js
goes in header.tt. nearest-tube.cgi lives in the same directory as wiki.cgi
Hope these are of interest.
Answering a question on Perlmonks: http://perlmonks.org/?node_id=601407
has set me thinking about our geodata fields, in particular our lat +
long. To be valid, these must be numeric; in fact the Google Maps code
will b0rk if there's garbage in there. This made me wonder if the check
could be done DB side, in the form of a constraint, or possibly as a
trigger to calculate the X and Y.
... Which made me think about the wider issue of data validation. I know
MySQL isn't brilliant in this area, but I'm no up to speed with Pg
enough to know what's on offer. I am aware of how commercial databases
like Oracle and Sybase do it; that's my bread and butter.
If we had more validation checks in, either server side or DB side, we
could probably block more spam, as the 'bots tend to put rubbish and
URLs into many of our fields.
Hello. If you look at the OGL page for the West Indian Quay Cineworld, it
has an embedded RSS feed of current showings, taken from the Time Out site:
The problem is that there's some kind of encoding mismatch that leads to
lots of "weird characters". Is there anything that can be done about this?
I've tested it elsewhere; it's not a problem limited to OGL.
I am impressed by the RDF backend of OpenGuides, and the goal of making
the information reusable on the Semantic Web.
I am giving a talk next month at AjaxWorld about Semantic Mashups using
RDF (which, for full disclosure, will feature my company's product,
Part of the story will be, "but where will you find all that data in RDF?"
OpenGuides is a very good answer to that question.
I want to use some RDF data from OpenGuides in my demo (with
attribution, of course). But I am having trouble coaxing RDF data from
the OpenGuide website in a useful way.
Here's what I would like to do. I see that in the OpenGuide Boston,
there is geocode information for all the MBTA train stations. For
instance, a page like
me the geocode location for the Northeastern University stop.
I would like to find a page that has, say, all the Green Line stations,
with their geocodes, all in one file (URL). Similarly for Redline,
etc. I can make a pretty interesting mashup page from such
information. I can do the same with all the single-station pages, but
that will seem awfully tedious when I show it as part of a demo.
Is there a way to get the RDF exported in this way? Is this something
that the OpenGuides folks would be interested in allowing me to do?
Chief Technology Consultant
I just had the occasion to install Ikonboard
(http://www.ikonboard.com/) a piece of message board software written
in Perl. It was an enlightening experience, and one I'd like to share.
There's been some discussion previously about the problem with
installing OpenGuides being that the build process installs both the
modules and the site. I think the Ikonboard guys have hit the nail on
the head with their install process, so here's a breakdown of how it
* You untar the install package and move the contents of the cgi-bin
directory to wherever your CGIs live. There's a perl_test.cgi and an
installer.cgi which you chmod +x.
* Running perl_test.cgi from your browser checks whether you have
prerequisite modules (CGI, DBI_File at least, or optimally various DBI
drivers) installed, and prints out both a bunch of $ENV and the
contents of your @INC for you to keep around for debugging purposes
should you need it.
* If you have everything, next you run installer.cgi from your
browser. You're presented with a screen that lists various files (such
as the ikonboard.conf file) and directories and whether they have
their permissions set correctly for the install to proceed. If they're
not, you set them appropriately and re-run the script. Presuming
everything is correct, it presents you with a button to proceed.
* Next you get a screen with various fields where you set paths to the
various directories - skins, static HTML, uploads, and so on.
* The next screen checks permissions on all these places as being writable.
* Next, the installer untars a bunch of tarballs that were included in
the installation directory, and moves their contents to the
directories you specified. One screen appears per untar; if
successful, it reloads the script with an incremented CGI argument to
move on to the next file. Very smooth to watch. Presumably if anything
fails it presents an error screen. (Note: this whole step is optional;
you can choose to skip it if you've already manually placed various
files in their destinations.)
* Next you get a screen to choose your admin user name and password,
set the name of the site and board to be displayed, and so on, and
asks you what kind of DB you want.
* The next step sets up the database and displays a confirmation of
the stuff that just happened.
* Finally, it redirects you to the board login screen - but the board
script refuses to run until you've gotten rid of installer.cgi, as
that would be a security hole. After you've ditched it, you can log
Overall, it's an excellent install experience. Hopefully you can see
how well it maps onto the site-related part of our own install
mechanism. I can see our existing Build.PL being hacked into two parts
- the first part, which remains Build.PL, installs the libraries. The
second part would become our installer.cgi. I see their reason for
keeping perl_test.cgi separate, as well: if a user is having problems,
they can run it to produce an instant system report to diagnose
issues. As a minor note, I think having the various templates and so
on as tar files within the tar file may be slight overkill - copying
from one dir to another works for me.
If people like the sound of this (perhaps even try downloading and
running the thing yourself; it only takes a moment and you can throw
away the result), would you be interested in me having a go at
producing something like it for us?
My only slight reservation about this is that I don't know how Dom's
packaging for Debian works, and if this would be completely
incompatible with it. Dom?
i've been visiting Berlin a lot and would like to start a Guide so i
can write about the funny and useful places that i find or am shown.
but i don't speak any German and i want to keep it that way - it's an
awful language. ( http://www.crossmyt.com/hc/linghebr/awfgrmlg.html )
i thought about asking for best practise / prior art on multilingual
Guides. the thing is i am not worried about having translations, and i
would sort of rather have any language that people feel like writing
in, squashed onto one page, than separate stuff out, in a way which
might make different language communities feel unwelcome or lapse into
i could do quite a lot with silly icons, and categories can have names in
any language, that's fine, and i'm not worried about knowing what
language category names are in - people will understand or not understand
- and one day we can do some magic with http://omegawiki.org if we like.
how is the OG collective hosting situation? it would rock my world if
i could park this somewhere i would not be subsequently responsible
for breaking and upgrading ;)