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
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
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)
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.
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.
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
(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.
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.
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
