Item9623: KinoSearchContrib incompatible with 1.1

pencil
Priority: Normal
Current State: Closed
Released In: n/a
Target Release: n/a
Applies To: Extension
Component: KinoSearchContrib
Branches:
Reported By: MichaelTempest
Waiting For:
Last Change By: AndrewJones
KinoSearchContrib is not compatible with Foswiki 1.1 because it calls $Foswiki::Plugins::SESSION->mapToIconFilename($name) to determine the icon to use based on the filename, in Foswiki::Contrib::KinoSearchContrib::Search::renderHtmlStringFor(). Foswiki::mapToIconFilename() does not exist in 1.1; the corresponding code has been moved into Foswiki::Macros::ICON::_lookupIcon().

I think the call to mapToIconFilename() is superfluous. I get the correct icon if I change renderHtmlStringFor() to do $icon = "%ICON{\"$name\"}%"; . This form of %ICON{...}% usage has been documented since tmwiki 4 (certainly since 4.1), so I really don't know why the contrib calls mapToIconFilename().

In 1.0, the ICON macro handler calls mapToIconFilename(). The 1.1 ICON macro handler is backwards compatible. I see no reason not to just use %ICON.

-- MichaelTempest - 04 Sep 2010

Although appears to have solved the KinoSearch issue when using the KinoSearch directly, if Configure websearch is set to use Kino (instead of Fork), it reports a load of Kinosearch errors as shown here.

Could not perform search. Error was: Undefined subroutine &Foswiki::Store::SearchAlgorithms::Kino::query called at /home2/mywebsitec/public_html/foswiki2/lib/Foswiki/Store/VC/Store.pm line 495. at /home2/mywebsitec/public_html/foswiki2/lib/Foswiki/Store/VC/Store.pm line 495 Foswiki::Store::VC::Store::query('Foswiki::Store::RcsWrap=HASH(0xff34a0)'
'Foswiki::Search::Node=HASH(0x2b3a590)'
'undef'
'Foswiki=HASH(0xfd3610)'
'HASH(0x2a2a550)') called at /home2/mywebsitec/public_html/foswiki2/lib/Foswiki/Meta.pm line 735 Foswiki::Meta::query('Foswiki::Search::Node=HASH(0x2b3a590)'
'undef'
'HASH(0x2a2a550)') called at /home2/mywebsitec/public_html/foswiki2/lib/Foswiki/Search.pm line 349 Foswiki::Search::searchWeb('Foswiki::Search=HASH(0x29770f0)'
'casesensitive'
''
'search'
''
'basetopic'
'WebSearch'
'reverse'
''
...) called at /home2/mywebsitec/public_html/foswiki2/lib/Foswiki/Macros/SEARCH.pm line 32 Foswiki::__ANON__() called at /usr/lib/perl5/site_perl/5.8.8/Error.pm line 415 eval {...} called at /usr/lib/perl5/site_perl/5.8.8/Error.pm line 407 Error::subs::try('CODE(0x2aec440)'
'HASH(0x2aebbe0)') called at /home2/mywebsitec/public_html/foswiki2/lib/Foswiki/Macros/SEARCH.pm line 41 Foswiki::SEARCH('Foswiki=HASH(0xfd3610)'
'Foswiki::Attrs=HASH(0x2b3a3b0)'
'Foswiki::Meta=HASH(0x2b1d1b0)') called at /home2/mywebsitec/public_html/foswiki2/lib/Foswiki.pm line 3030 Foswiki::_expandMacroOnTopicRendering('Foswiki=HASH(0xfd3610)'
'SEARCH'
'\x{a}""\x{a}type="word"\x{a}scope=""\x{a}web=""\x{a}excludetopic=""\x{a}nosearch=""\x{a}c...'
'Foswiki::Meta=HASH(0x2b1d1b0)') called at /home2/mywebsitec/public_html/foswiki2/lib/Foswiki.pm line 2920 Foswiki::_processMacros('Foswiki=HASH(0xfd3610)'
'%IF{"$\'URLPARAM{search}\'!=\'\'" then=\' 

Kinosearch and the default web search appear to be incompatible in 1.1

Not sure if this Kinoindex issue I have is related or not.

-- BobCorless - 18 Oct 2010

Also this issue:-

In my parallel set up to test 1.1.0, I've copied across my websites from the Data and Public directories, so in theory all my Topics and attachments are the same as in 1.0.9

I can run ./tools/kinoindex in a terminal against 1.0.9 and it runs fine and completes with no errors.

However, if I run kinoindex in 1.1.0 it throws out exceptions and fails to run. Interestingly though, kinoupdate works fine.

This is the exceptions I get in 1.1.0

KinoSearch index files init
- to suppress all normal output: kinoindex -q
Uncaught exception from user code:
        OopsException(attention/no_form_def web=>Main topic=>WebHome params=>[MyTopic,TestForm]) at /usr/lib/perl5/site_perl/5.8.8/Error.pm line 184
        Error::throw('Foswiki::OopsException', 'attention', 'def', 'no_form_def', 'web', 'Main', 'topic', 'WebHome', 'params', ...) called at /home2/mywebsitec/public_html/foswiki2/lib/Foswiki/Form.pm line 97
        Foswiki::Form::new('Foswiki::Form', 'Foswiki=HASH(0x1dc8480)', 'MyTopic', 'TestForm') called at /home2/mywebsitec/public_html/foswiki2/lib/Foswiki/Contrib/KinoSearchContrib/Index.pm line 388
        Foswiki::Contrib::KinoSearchContrib::Index::formsFieldNames('Foswiki::Contrib::KinoSearchContrib::Index=HASH(0x1db2420)') called at /home2/mywebsitec/public_html/foswiki2/lib/Foswiki/Contrib/KinoSearchContrib/Index.pm line 56
        Foswiki::Contrib::KinoSearchContrib::Index::createIndex('Foswiki::Contrib::KinoSearchContrib::Index=HASH(0x1db2420)', 1) called at ./kinoindex line 38

I've implemented this trunk to get around another 1.1.0 issue.

http://trac.foswiki.org/export/8893/trunk/KinoSearchContrib/lib/Foswiki/Contrib/KinoSearchContrib/Search.pm

-- BobCorless - 21 Oct 2010

I looked at the

OopsException(attention/no_form_def web=>Main topic=>WebHome 
params=>[MyTopic,TestForm]) at /usr/lib/perl5/site_perl/5.8.8/Error.pm line 184.....

issue above and have found a workaround by ensuring the Web.WebPreferences topic is in Foswiki format (specifically that it does not have any T*iki references..) I will delve a bit deeper if I get a chance but this bring up the bigger issue for clients that are migrating T*iki-> Foswiki non-core webs. There is no facility to Upgrade the WebPreferences (or any of the Web* topics for that manner. perhaps an Upgrade function similar to the new Groups UI is needed?

-- PadraigLennon - 22 Oct 2010

I removed the "test.form" from the "Set WEBFORMS = ..." and the index is running OK. Not sure where that came from as I don't use forms other than the standard ones.

The standard WebSearch still gives errors if the {Store}{SearchAlgorithm} is set to Kino (as described further up the thread).

-- BobCorless - 22 Oct 2010

I'm removing myself from WaitingFor because I have no input to give and I am not going to get to this any time soon.

-- MichaelTempest - 31 Oct 2010

The initial problem, as reported by MichaelTempest, has been fixed and released.

The other bugs, reported by BobCorless, should be discussed in Item10543 and Item10544.

-- AndrewJones - 25 Mar 2011

 
Topic revision: r14 - 25 Mar 2011, AndrewJones
The copyright of the content on this website is held by the contributing authors, except where stated elsewhere. See Copyright Statement. Creative Commons License    Legal Imprint    Privacy Policy