As promised, I plan to release OpenGuides, with all the many
improvements made during and after the hackfest, shortly.
Can those with open tickets assigned to them (you can see open defects
at http://dev.openguides.org/report/13 - Kake, klur, andrewb, ilmari,
ivorw, earle) drop me a line to let me know whether they have any code
changes ready to go in in the next few days - this will allow me to
time the release effectively. If you have no plans to work on the ticket
in the foreseeable future, and don't already have work ready, please
reassign the ticket to 'Nobody'.
The release will in any case not happen until after this weekend.
Cheers,
Dominic.
--
Dominic Hargreaves | http://www.larted.org.uk/~dom/
PGP key 5178E2A5 from the.earth.li (keyserver,web,email)
There's an issue with changeset 1086 that needs to be noted in UPGRADING,
and pointed out here.
This change alters the way that the common categories and locales in the
navbar work. These templates - navbar_categories.tt and navbar_locales.tt
- are ones which guide admins are almost certain to have modified, since
the categories and locales in the distributed templates won't be relevant
to most guides.
First of all, your template needs to check for
[% config.enable_common_categories %]
rather than
[% common_categories %]
in order to know whether to add this <div> to the navbar or not.
Secondly, you need to replace
<a href="[% catloc_link %]Category_[% cat %]">
with
<a href="[% config.script_url _ config.script_name %]?id=Category_[% cat %]">
So this is just a heads-up to people to be aware of the changes. I haven't
added this to UPGRADING because I'm tired and in the middle of tracking down
other upgrading issues. Could someone do that, please?
Kake
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
on others.
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
8242
$
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
Cheers,
Paul (any overbearing tone unintentional ;-)
--
Paul Makepeace .............................. http://paulm.com/inchoate/
"If my elbow was straight, then I'll show oyu mine!"
-- http://paulm.com/toys/surrealism/
OK, the next hackfest is looking like one of these two:
Sat 21 + Sun 22 July
or
Sat 18 + Sun 19 August
Probably at my house again. Let me know if you have a preference!
Note that the latter date is quite close to YAPC, so I'm thinking the
July one is probably better, unless loads of people can't make it.
Kake
OpenGuides has had a long-standing feature request from me which I'm now
thinking about implementing:
http://dev.openguides.org/ticket/1
The idea would be to prevent entries from getting too stale by storing
some meaningful data about when the node was last checked over for
accuracy (as opposed to other minor changes).
This could be done a couple of ways:
- as per http://london.randomness.org.uk/wiki.cgi?Trinity%2C_SW4_0JG
in free-text in the node content
With a ticky-box:
"If you have verified the content of this article as correct, please
ticky ticky [ ]"
Suggested rendering of this data - at the bottom of pages:
"This page was last checked for accuracy on yyyy-mm-dd"
This itself could be done two ways:
- as Wiki::Toolkit metadata - automatically populate it with a standard
string representation of the date if appropriate
The way I'm starting to favour, though, is a new sort of Wiki::Toolkit
data. This has the advantage that it can be typed correctly (as a date
object). It's a bit more work to implement, but not too much.
The question is, whether this is an appropriate addition to
Wiki::Toolkit. Since it is in many ways similar to the modified stamp,
I think it is.
The question also arises of whether we could also use a "should be
reviewed on the following date" - ie an explicitly staleness factor,
rather than just inferring such (6 months after last reviewed date, for
example). Would it be overkill to be able to specify both?
Kake is in favour of retaining free text descriptions (useful of only
some parts of the content have been verified) but this doesn't allow
systematic searches on this data (so we can proactively go out and
regularly review nodes, for example. There's no reason, of course, that
we can't keep both functions - people can carry on doing this even if
there is more structured data available too. Or we could add a separate
free text field, as a normal metadata field.
Any opinions welcomed.
Cheers,
Dominic.
--
Dominic Hargreaves | http://www.larted.org.uk/~dom/
PGP key 5178E2A5 from the.earth.li (keyserver,web,email)
Hi,
I believe you've already implemented this - do you have any patches to
share?
Cheers,
Dominic.
--
Dominic Hargreaves | http://www.larted.org.uk/~dom/
PGP key 5178E2A5 from the.earth.li (keyserver,web,email)
I'd like to use some public domain photos as node images on RGL. I'm
not entirely sure how to do this within the "node image" system - the
OpenGuides templates automatically put the little "(c)" copyright
symbol in front of the name of the person who took the photo. I found
a public domain licence on the Creative Commons site:
http://creativecommons.org/licenses/publicdomain/
but I don't really understand this sort of thing so I thought I'd ask
for help here. What should I put in the little boxes on the
OpenGuides edit form in this situation?
Kake
P.S. Yes, they are definitely public domain; a friend of mine took them.
Hello. I think Dom might have asked about this before, but it seems to
still be going on.
Many of the older openguides-dev list postings are sitting on the interweb
with attached adverts. For example:
http://lists.openguides.org/mail/openguides-dev/2004-August/000485.html
I understand that this is unintentional - could it be fixed, please?
(If it's _not_ unintentional, and the ads are necessary to pay for the
list archive bandwidth, then I'm sure we can come up with alternative
hosting between us all.)
Kake
Hello. At the moment, when you ask for an atom feed of the entire
site, it looks something like this:
<entry>
<title>Adam And Eve, SW1H 9EX</title>
[...]
<summary>Add Category Real Ale to GBG pubs. [AutoKake]</summary>
<updated>2007-05-04T17:46:28+01:00</updated>
<author><name>AutoKake</name></author>
[...]
</entry>
Since we now have a proper summary field, should we putting its value in
here instead of the latest change comment?
Kake