CGI-Wiki-dev November 2003

cgi-wiki-dev@earth.li

6 participants
8 discussions

Search indexer errors
by Kate L Pugh 28 Nov '03

28 Nov '03

Earle Martin <openguides(a)downlode.org> wrote to openguides-dev: > [Thu Nov 27 23:15:03 2003] index.cgi: > Search::InvertedIndex::remove_index_from_group() - Corrupted database. > Unable to find 'ged_000000000000_c_000000000523' record > [Thu Nov 27 23:15:03 2003] index.cgi: at > /home/earle/openguides.org/lib/CGI/Wiki/Search/SII.pm line 204 > > This is for the London site. Should I be worried? It's deja-vu all over again: http://openguides.org/mail/openguides-dev/2003-September/000039.html Search::InvertedIndex does throw these little errors from time to time. Like, about three times a year, which makes it very difficult to track down. So what can we do about it? CGI::Wiki only has two search backends so far. One is the Search::InvertedIndex one, and the other is based on DBIx::FullTextSearch, which only works on MySQL. There really is a dearth of decent indexing/searching modules on CPAN. Does anyone know of any that I've overlooked? Simon Cozens is working on Plucene, a port of Lucene to Perl: http://blog.simon-cozens.org/bryar.cgi/id_6587 I've not properly looked into Lucene though, since it's written in Java and I only found out about Plucene last night. Anyone here used it? Another option would be rewriting Search::InvertedIndex to be simpler and hence hopefully less likely to go wrong. I did a fair bit of work towards this about a year or so ago, and sent a multitude of patches to the author, but he is very busy and apologised profusely for not having time to integrate them. I am not hopeful that they will ever go into the distribution, but they might be useful for a simple rewrite that could be released as Search::SimpleIndexer or Search::InvertedIndec::Simple or something. I don't want to tread on the guy's toes, and I don't even think he would see it that way, especially as CGI::Wiki simply doesn't need much of the complexity that's in the current distro. The drawback of that approach (ie me writing a new search module) is that I am already overwhelmed with programming tasks. I am deep in the guts of both CGI::Wiki and OpenGuides this week, and I don't want to start a major new project until the current work on those two projects is released. I *may* be able to break the back of the current stuff this weekend. Is anyone else interested in a Search::InvertedIndex rewrite? You could write code, docs, tests or all three. Kake

1 0

New feature for UseMod formatter
by Kate L Pugh 24 Nov '03

24 Nov '03

I set up a wiki here at work but was berated for breaking our branding. We are http://state51.co.uk/ and there is definitely no capital "s" allowed. Now, CGI::Wiki::Formatter::UseMod forces node names in links to be ucfirst, to avoid ending up with six home nodes called things like "home", "Home", "HOME", etc. Consistency is a good thing. You can turn this munging off entirely, but you can't *partly* turn it off. I added an option to let you do some last-minute munging of the node names, but I'm not sure I got the name right. It's currently called "munge_node_name" and its documentation is below. Comments ASAP please - I'd like to upload this as soon as PAUSE comes back. Kake METHODS new my $formatter = CGI::Wiki::Formatter::UseMod->new( extended_links => 0, # $FreeLinks implicit_links => 1, # $WikiLinks force_ucfirst_nodes => 1, # $FreeUpper use_headings => 1, # $UseHeadings allowed_tags => [qw(b i)], #defaults to none macros => {}, node_prefix => 'wiki.pl?', node_suffix => '', edit_prefix => 'wiki.pl?action=edit;id=', edit_suffix => '', munge_urls => 0, ); Parameters will default to the values shown above (apart from "allowed_tags", which defaults to allowing no tags). Internal links "node_prefix", "node_suffix", "edit_prefix" and "edit_suffix" allow you to control the URLs gener- ated for links to other wiki pages. So for exam- ple with the defaults given above, a link to the Home node will have the URL "wiki.pl?Home" and a link to the edit form for the Home node will have the URL "wiki.pl?action=edit;id=Home" (Note that of course the URLs that you wish to have generated will depend on how your wiki appli- cation processes its CGI parameters - you can't just put random stuff in there and hope it works!) Internal links - advanced options If you wish to have greater control over the links, you may use the "munge_node_name" parame- ter. The value of this should be a subroutine reference. This sub will be called on each inter- nal link after all other formatting and munging except URL escaping has been applied. It will be passed the node name as its first parameter and should return a node name. Note that this will affect the URLs of internal links, but not the link text. Example: # The formatter munges links so node names are ucfirst. # Ensure 'state51' always appears in lower case in node names. munge_node_name => sub { my $node_name = shift; $node_name =~ s/State51/state51/g; return $node_name; } Note: This is advanced usage and you should only do it if you really know what you're doing. Con- sider in particular whether and how your munged nodes are going to be treated by "retrieve_node".

2 2

0.50_01 release candidate
by Kate L Pugh 20 Nov '03

20 Nov '03

Since Jody was waiting for me to finish reworking the tests, I hurried up and got it finished last night. Didn't release it though, and now PAUSE seems to be inaccessible, bah. The *only* changes in this release are tests and documentation. I would really appreciate it if as many people here as possible could run the test suite of 0.50_01 and report any failures. You can get it from here: http://the.earth.li/~kake/code/CGI-Wiki-0.50_01.tar.gz Kake

1 0

RE: [cgi-wiki-dev] SQLite Backend
by Naved, Masroor 18 Nov '03

18 Nov '03

> -----Original Message----- > From: Kate L Pugh [mailto:kake@earth.li] > Sent: Friday, November 07, 2003 11:02 AM > To: cgi-wiki-dev(a)earth.li > Subject: Re: [cgi-wiki-dev] SQLite Backend > > > > Blimey. ->write_node should not fail silently. The perldoc says: > > Returns 1 on success, 0 on conflict, croaks on error. > > If it's not doing that for you then that's a bug. Can you > send me either as small a test case as possible or failing > that all your code. My mistake, I was not checking the returned value from write_node. I thought it would throw an error in the Apache error log. > I am wondering if it should do so. It'd mean an extra > preliminary database call (to check table existence) every > time you tried to write a node, which would increase load. > Also if you typoed the database name you wouldn't be hitting > the database you expected - which would be a right pain in > the case of SQLite since it'd just create you a new database > file and then you'd be wondering where all your data went. > > Opinions on that please. After looking around I found CGI::Wiki::Setup::SQLite module. Because of my newness with Perl and the CPAN I thought all needed modules and/or related modules would be listed in the webpage of CGI::Wiki at the cpan site, after finding the setup functions, it was smooth sailing. :) > > The pointer to cgi-wiki-createdb is in INSTALL :) Should it > be more prominent, or did you just forget to read that file? > There's a *lot* of info in there. Maybe it should be in > README too - would that have helped? I used the command 'perl -MCPAN -e shell' to start a CPAN prompt and just did a 'install CGI::Wiki'; I never knew that there was a INSTALL doc to look at. I thought that the document on the www.cpan.org site was the INSTALL/README file, I guess I was wrong about that. > Oh, relating to this, Tom - do you want to take out the > 'dbuser' requirement in CGI::Wiki::Kwiki and make a new > release? I keep having to put dbuser => "thisisnotused" and > it's bugging me :) I tried this after finding the CGI::Wiki::Setup::SQLite module, just in case. It worked okay, I use the command without entering a username or password, just a file path. Thanks for the info and help. -Masroor

2 1

Table-prefix support
by Jody Belka 18 Nov '03

18 Nov '03

I've just hacked table-prefix support into my local copy of CGI::Wiki so as to enable all the OpenGuides sites hosted on my system to work out of one central database. Is this something other people would be interested in, and should i sort out some patch files with the changes i made and then email them to the list? Jody knew (at) pimb (dot) org

2 2

Released: CGI::Wiki::Plugin::Diff 0.01
by Ivor Williams 16 Nov '03

16 Nov '03

see http://search.cpan.org/~ivorw/CGI-Wiki-Plugin-Diff-0.01/ I have converted the diff code which was OpenGuides specific, into a plugin for CGI::Wiki. I intend to develop this module further (see Pod section TODO), but I am inviting feedback from others, especially those who are hosting CGI::Wiki sites. The code is a direct rip from OpenGuides::Diff.pm, but I wrote nearly all of this module anyway. Please let me know - reply on-list or off-list, if you would like to see more specific functionality in this module, as I have time to put into it :). Ivor.

1 0

SQLite Backend
by Naved, Masroor 07 Nov '03

07 Nov '03

Hello, I am having some problems get a basic CGI::Wiki up and running. I have one script which only opens a SQLite database, a DB_File_SplitHash for an index, and one write_node command. The problem is that there are no tables in the SQLite database so the write fails (it seems to fail silently) and the subsequent display_node function call throws an error "table does not exist", I had assumed that CGI::Wiki::Store::Database would create the needed tables, but that doesn't seem to be the case. I looked through the documentation and code comments in CGI::Wiki::Store::Database, CGI::Wiki::Store::SQLite, CGI::Wiki to see if I missed something about creating backend tables, but I can't find anything that describes the data model. This might be related to my newbie status in Perl and CPAN packages, but I can't figure out where to go from here. Thanks, Masroor Naved

3 2

A patch for CGI::Wiki::Store::Database.pm
by Ivor Williams 02 Nov '03

02 Nov '03

Kake, Some of the work I will be doing on the search for OpenGuides necessitates an enhancement to the method list_nodes_by_metadata. This will enable SQL LIKE type matches. Patch follows: --- database.pm.orig +++ database.pm @@ -785,1 +785,2 @@ - $self->_get_list_by_metadata_sql( ignore_case => $args{ignore_case} ); + $self->_get_list_by_metadata_sql( match_type => $match, + ignore_case => $args{ignore_case} ); @@ -797,0 +798,6 @@ + + my ($self,%args) = @_; + my $match = $args{match_type} || '='; + + croak "SQL match type must be LIKE or '='" unless $match =~ /=|like/i; + @@ -801,1 +808,1 @@ - . " AND metadata.metadata_value = ? "; + . " AND metadata.metadata_value $match ? "; By the way, I've completed the tidying up of SuperSearch.pm; I'm happy for it to be released in its present form. Ivor.

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

CGI-Wiki-dev November 2003