OpenGuides-Dev December 2004

openguides-dev@lists.openguides.org

20 participants
36 discussions

Re: [OpenGuides-Dev] Local installs: where you don't have root
by Kake L Pugh 23 Dec '04

23 Dec '04

On Wed 22 Dec 2004, IvorW <ivorw-openguides(a)xemaps.com> wrote: > The HOWTO at http://openguides.org/dev/?node=OpenGuides%20HOWTO says > Local installs > If you're installing the OpenGuides modules into a > local directory rather than system-wide, you're going to need to let > the OpenGuides scripts (wiki.cgi, newpage.cgi, preferences.cgi and > supersearch.cgi) know where to find them. That's a documentation bug - this issue was fixed ages ago. I've replaced the paragraph on the wiki with a terse sentence that's at least not inaccurate. Someone else may have time to flesh it out a bit. > An alternative is to add the environment variable PERL5LIB in the > .profile or .bashrc for the user account who will be running the > script. Are there any issues with this? Well: (a) some installs have all CGI running as the web user, and (b) it doesn't work in any case, so yes there are issues. Kake

1 0

[OpenGuides-Dev] Bug? "This is the first version"
by Rev Simon Rumble 23 Dec '04

23 Dec '04

Just saw this pop up in my logs from Google exercising all the links. It looks like it followed the List All Versions link from: http://engineer.openguides.org/?id=Brogo_Dam;version=0;diffversion=1 Looks to me like some accidental barewords in the code. ==> /var/log/apache/error.log <== [Wed Dec 22 13:51:54 2004] wiki.cgi: This is the first version at /usr/lib/cgi-bin/openguides/wiki.cgi line 57 ==> /var/log/apache/access.log <== crawl-66-249-66-49.googlebot.com - - [22/Dec/2004:13:51:54 +0000] "GET /touristengineer/wiki.cgi?action=list_all_versions;id=Brogo_Dam HTTP/1.1" 200 461 "-" "Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)" I'm still running 0.45 here, but managed to get the same error on Oxford at: http://www.ox.compsoc.net/oxfordguide/?action=list_all_versions;id=Bar_Baby… -- Rev Simon Rumble <simon(a)rumble.net> www.rumble.net The Tourist Engineer Nerds need vacations too. http://engineer.openguides.org/ "A politician is like a nappy. He should be changed regularly, and for the same reason" - Column 8, Sydney Morning Herald

2 1

[OpenGuides-Dev] sf guide spam
by aaron brownlee 23 Dec '04

23 Dec '04

Hi - Noticed some wikispam on the SF guide. Wondering how active that guide is, if there is someone that admins there, and if there are plans to combat spam bots and remove spam pages from the revision history? Just curious. Your project seem like a great use of a wiki community, but if even the "wiki nature" page gets spam raped every day, I doubt the idea will be taken seriously and put to use. cheers ~ (a)

2 1

[OpenGuides-Dev] Local installs: where you don't have root
by IvorW 22 Dec '04

22 Dec '04

The HOWTO at http://openguides.org/dev/?node=OpenGuides%20HOWTO says Local installs If you're installing the OpenGuides modules into a local directory rather than system-wide, you're going to need to let the OpenGuides scripts (wiki.cgi, newpage.cgi, preferences.cgi and supersearch.cgi) know where to find them. To do this, you'll need to add a line that says use lib='/path/to/my/OpenGuides/modules'; (using the real path to where your modules are located) in each of them at the top, just before all the other 'use' statements. To me this sucks. You should never need to hack source code to complete an install. An alternative is to add the environment variable PERL5LIB in the .profile or .bashrc for the user account who will be running the script. Are there any issues with this? I see that this has been automated in the install procedure. "Do you want me to munge a custom lib path into the scripts?" If you have installed some or all of the required Perl modules (or indeed the OpenGuides modules themselves) into a private directory, you will need to tell the scripts where to find these modules. Enter the paths to search here just as you would enter them in a 'use lib qw( ... );' in a Perl script. Is this the right way to go? Ivor.

1 0

[OpenGuides-Dev] OpenGuides 0.46 released
by Dominic Hargreaves 22 Dec '04

22 Dec '04

OpenGuides 0.46 has now been released, and now supports geolocation worldwide. It is available from your favourite CPAN mirror, or http://www.larted.org.uk/~dom/computing/code/openguides/OpenGuides-0.46.tar… or, indeed, http://www.larted.org.uk/~dom/debian/openguides/. md5sum: 7d15d07358114a1097e51308a250e58f OpenGuides-0.46.tar.gz Changelog: Minor bug fixes: remove bogus edit link on index listings, add missing default behaviour for geolocation Update supersearch help text URL. Add nofollow to robots meta tag. Added new CSS class "node_name" for inline non-hyperlink references to node names - see README.CSS for details. Fix bug with diff display on nodes containing macros. Fixed distance search paging bug. Fixed bug that allowed autocreation of locales and categories with trailing spaces in the name. Config management refactoring. This should not result in any user-visible changes, apart from introducing a new dependency on Class::Accessor. Make it clearer in documentation that overriding factory templates is a risky activity. Update feedback details and include URL of RT queue. Add missing tests to MANIFEST so they are included with the distribution. Seasonal greetings (where applicable)! Dominic.

1 1

[OpenGuides-Dev] Bug with custom templates
by Rev Simon Rumble 15 Dec '04

15 Dec '04

Further to that, it seems to want custom_ for some of the custom template names, and works fine with others. Could be because I'm using the same dir for both, but I dunno. -- Rev Simon Rumble <simon(a)rumble.net> www.rumble.net The Tourist Engineer Nerds need vacations too. http://engineer.openguides.org/ "It's better to die on your feet than to live on your knees." - Power and the Passion, Midnight Oil

1 1

[OpenGuides-Dev] BOF summary?
by Kake L Pugh 15 Dec '04

15 Dec '04

Can someone report back on the BOF at the LPW please? Kake

2 1

[OpenGuides-Dev] Release imminent
by Dominic Hargreaves 13 Dec '04

13 Dec '04

(this is the last thread from me tonight, don't worry...) I'd like to release in the next day or two to push out a couple of small but irritating and potentiall harmful bugs. Does anyone have anything small that they want to such a maintainance release? I'll assume not if I don't hear anything before I get home late tomorrow evening. Cheers, Dominic.

2 1

[OpenGuides-Dev] Config management
by Dominic Hargreaves 13 Dec '04

13 Dec '04

I've recently uncovered a bug in the config handling of OpenGuides. Sometimes default config values are set inside the script, but inconsistently (and multiple times). This causes problems when the config file is missing an item. In my opinion all software should gracefully handle missing configuration items as much as possible, but at the same time having to set the same default in the code itself (for example, geo_handler is set and defaulted three times in the code) is bad. I suspect the best way to solve this would be something along the lines of a getconf method in OpenGuides::Utils which would look like Config::Tiny, but with hardcoded defaults built in. This would solve the problem of inconsistent defaults, and also abstract away the details of where the config comes from, should we want to expand the possiblities in future (eg reading config from a database, a different Config::Foo module, etc). Another immediate application for this is the possibility of a global config, as discussed in <http://openguides.org/mail/openguides-dev/2003-September/000043.html>. In fact the patch in that mail does provide something quite similar, but I think not relying on another external config file being findable would be best (though supporting it would be good), and I think that patch tries to be too clever (and makes assumptions about file locations). We basically want to be able to do my $config = OpenGuides::Utils->getconf; once and then not care any more. We should also have a definition of what should be considered a required value, because of course some variables do not have a sensible default at all. Something like: # Default configuration definitions my %defaults = (dbname => undef, dbuser => undef, dbpass => undef, dbhost => "localhost", script_url => "http://localhost/cgi-bin/wiki.cgi", use_plucene => 1, indexing_directory => undef, enable_page_deletion => 0, admin_pass => "Change This!", stylesheet_url => undef, site_name => "Unconfigured OpenGuides site", navbar_on_home_page => 1, home_name => "Home", site_desc => "A default configuration of OpenGuides", default_city => "London", default_country => "United Kingdom", default_language => "en", contact_email => "openguides-admin\(a)example.com", formatting_rules_node => "Text Formatting Examples", backlinks_in_title => 0, geo_handler => 1, ellipsoid => "International"); To preempt the possible question "Why do this? The Build script always adds in all the require values": the answer is that software should be robust, and we need to cope with people willy-nilly hacking around with the config files. This includes people who want to build distributions of OpenGuides such as me for Debian. In that context the Build script is not the best way of managing things. By contrast, hard-coded defaults is Utils.pm can be considered immutable. Also, of course, this hardcoding of defaults is already been done, and badly. It would make the code more understandable and less prone to error to be able to look in one place to discover the default behaviour of the code. What do people think of this idea? Would someone like to step up and implement it? If the answer is yes, and rt.cpan.org comes back up, I'll submit it as a wishlist bug. Cheers, Dominic.

2 1

[OpenGuides-Dev] SQLite fails after upgrade
by Rev Simon Rumble 07 Dec '04

07 Dec '04

Doh, I sent this to openguides-london. Sorry. After an upgrade, I get these errors with the SQLite modules: [Mon Dec 6 12:58:25 2004] index.cgi: install_driver(SQLite) failed: Can't locate DBD/SQLite.pm in @INC (@INC contains: /etc/perl /usr/local/lib/perl/5.8.4 /usr/local/share/perl/5.8.4 /usr/lib/perl5 /usr/share/perl5 /usr/lib/perl/5.8 /usr/share/perl/5.8 /usr/local/lib/site_perl .) at (eval 9) line 3. [Mon Dec 6 12:58:25 2004] index.cgi: Perhaps the DBD::SQLite perl module hasn't been fully installed, [Mon Dec 6 12:58:25 2004] index.cgi: or perhaps the capitalisation of 'SQLite' isn't right. [Mon Dec 6 12:58:25 2004] index.cgi: Available drivers: DBM, ExampleP, File, Proxy, SQLite2, Sponge, mysql. [Mon Dec 6 12:58:25 2004] index.cgi: at /usr/share/perl5/CGI/Wiki/Store/Database.pm line 110 Can't call method "header" on an undefined value at /usr/lib/cgi-bin/openguides/index.cgi line 138. [Mon Dec 6 12:58:25 2004] [error] [client 217.34.209.204] Premature end of script headers: /usr/lib/cgi-bin/openguides/index.cgi It seems the upgrade has moved the module to: /usr/share/perl5/DBD/SQLite2.pm I tried symlinking it to: /usr/share/perl5/DBD/SQLite.pm But the other errors remained. Ideas? -- Rev Simon Rumble <simon(a)rumble.net> www.rumble.net The Tourist Engineer Just because you're on holiday, doesn't mean you're not a geek. http://engineer.openguides.org/ Grub first, then ethics. - Bertolt Brecht

2 3

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

OpenGuides-Dev December 2004