OpenGuides-Dev June 2007

openguides-dev@lists.openguides.org

10 participants
19 discussions

Start a nNew thread

Google Sitemaps
by Markus Linke 03 Oct '07

03 Oct '07

Hi, is anyone using google sitemaps with openguides? Thanks, Markus

6 15

Preparing for a release
by Dominic Hargreaves 03 Jul '07

03 Jul '07

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)

1 1

Upgrading issue with changeset 1086
by Kake L Pugh 01 Jul '07

01 Jul '07

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

3 3

[OpenGuides-Dev] OG performance
by Paul Makepeace 20 Jun '07

20 Jun '07

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/

10 22

Next hackfest (pre-YAPC)
by Kake L Pugh 20 Jun '07

20 Jun '07

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

1 1

Review date field
by Dominic Hargreaves 19 Jun '07

19 Jun '07

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)

1 0

http://dev.openguides.org/ticket/113
by Dominic Hargreaves 19 Jun '07

19 Jun '07

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)

2 2

Public domain node images
by Kake L Pugh 19 Jun '07

19 Jun '07

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.

3 3

Adverts on the list archives
by Kake L Pugh 19 Jun '07

19 Jun '07

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

3 3

Summary field in atom/rss index
by Kake L Pugh 18 Jun '07

18 Jun '07

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

4 8

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

OpenGuides-Dev June 2007