Category: Search

Right now, if you have a multitiki installation with 10 sites, and you want to rebuild the unified search index for them all, you have to run 10 times the command with the "--site=" para adapted to each case.

However, when you run setup.sh, by default setup.sh runs for all sites in a multitiki installation.

It would be nice if console.php had the chance (by default or not) to be run once for all sites in that multitiki installation at once


with some param like "--site=all":
{CODE(colors="shell")}
php console.php d:u --site=all
{CODE}

I am using Tiki for educational scenarios, and frequentñy I (or my students) want to change misspelled words (for instance) on long wiki pages.

Nowadays I'm taking the content out of the wiki-edit form, search and replace on in external program, anb back.
I could be nice to have this feature integrated into the edit page form.

In Tiki search results, there should be a "also do the same search with the following search engines:"

http://www.google.com/sitesearch/
http://wordpress.org/extend/plugins/bing-404/


{CODE(caption="This code worked in 6.x in templates")}{if $mid eq 'tiki-searchresults.tpl'}<div class="simplebox" align="center" style="padding:5px;border:2px solid #000000">
<img src="pics/icons/information.png" alt="Information" style="vertical-align:middle;" />
For additional results, try searching for <strong>{$words}</strong> in:
<span class="button"><a href="http://doc.tiki.org/tiki-searchresults.php?words={$words}&where=wiki">Tiki Documentation</a></span> or
<span class="button"><a href="http://www.google.com/search?q=tikiwiki+{$words}">Search all over the Web with Google</a></span> or
<span class="button"><a href="http://www.google.com/search?q=site:tiki.org {$words}">Search *.tiki.org with Google</a></span>
</div>{/if}
{CODE}


Since this will be configurable, we could also encourage people to send the site manager feedback, and thus tell us: what they were looking for and what they were expecting to find

Going to Admin Categories > Bug on dev.tiki.org returns alerts on top of the page:
{CODE()}
ErrorErrorError
Tracker list_items ran out of memory after 0 items.Malformed search query: Parsing search query failed: "org.elasticsearch.common.ParsingException: [_na] query malformed, must start with start_object"Notice: invalid variable value: $_GET["maxRecords"] = undefined
{CODE}

Since Tiki24 we have a new search interface to find a plugin in our LONG list of plugin at : tiki-admin.php?page=textarea#contentadmin_textarea-2

This is a real nice improvement saving resources and space however it is not working at Dev.t.o

{file type="gallery" fileId="1747" showicon="y"}

In the Admin, if you search for "socnets" you will have results but nowhere to go as they are wrongly "not found in an admin panel".

{img fileId="1948" thumb="box"}

{img fileId="1949" thumb="box"}

May be temporary ?

the "advanced" search function (which is the default search these days BTW) does not search through anything but Dutch Roman characters (eg the English American character set)

I have 4 pages with the Alón name on them as an example, searching for Alón or Alon shows no results, BTW the non advanced search works correctly

This is on Tiki 4.2

On a multilingual project this makes the search function totally redundant as far as I am concerned

Tested in v3.1 on XP/IEv6, Vista/IEv7, Vista/Firefox. The help button (blue circle w/ question mark) next to "Advanced Search" in the module search_box does not bring up any help info. Instead, it points to the anchor #advanced_search_help on whatever page the user is viewing, but the anchor doesn't exist. IE shows an "Error on page" in the browser status bar.

Tested in XP/IEv6 with "Floating Help" UI feature on - same result. Unknown if "Floating Help" changes results in IEv7 or FF.

Upgraded from 2.4 to 3.0rc1. Upon loading the site for the first time, the header is completely missing, including the search bar. During upgrade the following DB errors ocurred for me, and I don't know if this is related.

#sylvieg 2008-10-29
ALTER TABLE `tiki_tracker_items` ADD index trackerId (trackerId)
Duplicate key name 'trackerId'
ALTER TABLE `tiki_tracker_fields` ADD index trackerId (trackerId)
Duplicate key name 'trackerId'
ALTER TABLE `tiki_tracker_item_attachments` ADD index itemId (itemId);
Duplicate key name 'itemId'
INSERT INTO users_permissions (permName, permDesc, level, type) VALUES ('tiki_p_search_categorized', 'Can search on objects of this category', 'basic', 'category')
Duplicate entry 'tiki_p_search_categorized' for key 'PRIMARY'
INSERT INTO `tiki_menu_options` (`menuId`, `type`, `name`, `url`, `position`, `section`, `perm`, `groupname`, `userlevel`) SELECT 42,'o','Content Templates','tiki-admin_content_templates.php',1256,'','tiki_p_edit_content_templates','',0 FROM `tiki_menu_options` WHERE @fgcant = 0
Duplicate entry '42-Content Templates-tiki-admin_content_templates.php-1256--tiki' for key 'uniq_menu'

Users see an "All shards failed" error/warning feedback when using Elasticsearch on pages with LIST plugins and sort_mode set in query string (by whatever means, either the page's php itself or whatever). It will happen because if the sort_mode is set to something which is invalid for that search query, Elasticsearch will throw an error.

This issue should actually be handled In lib/core/Search/Query.php, as there is already an attempt at gracefully bypassing sort errors in function search(..), but it is not working (prob because of Elasticsearch upgrades). the sort exception is thrown in lib/core/Search/Elastic/Connection.php using a preg_match('/No mapping found for \[(\S+)\] in order to sort on/, it could be very likely ElasticSearch changed this. In fact, that whole firing different type of errors need to be reviewed for different version of Elasticsearch.

There is nevertheless a workaround for now even if the above isn't fixed - i.e. if you set a sort_arg variable for each of the LIST plugins on the page it will solve it, as then sort_mode in the query string won't affect these LIST searches. https://doc.tiki.org/LIST+-+list+or+pagination+command

Currently, the length of the search result snippet is hard-coded to 250 characters (in searchlib.php). it would be nice if this could be defined by the admin as part of the search preferences.

{syntax type="tiki" editor="plain"}
The Manticore server doesn't find words of length 2, when used by Tiki. It looks very much like only words of length 3 (or even 4) are indexed.

This depends on the configuration used when the __tables are created__ inside of Manticore. It looks like Tiki specifies the "min_word_len" setting to be 3 (or even 4) when creating the "tiki_main_..." table inside Manticore. The SQL command in question is "CREATE TABLE tiki_main_... (...) min_word_len='3';"

I've searched the Tiki settings in the "Search" Control panel and couldn't find a setting for the minimum word length of Manticore.

The minimum __can't__ be configured in manticore.conf, because it is set (so it seems) at table creation time, which is the time when Tiki rebuilds the search index.

This isn't about stopwords. I've tried with 2-letter-word which aren't.

When performing a search which only includes one 2-letter-word, I get the following error message:
{INDENT()}Malformed search query: SQLSTATE[42000]: Syntax error or access violation: 1064 table tiki_main_69a052d856213: P08: syntax error, unexpected ')' near ' ) | (@title )'{INDENT}

It would be nice if visitors to info.tikiwiki.org could search all of the tw.o domains at once. What I envision:
1. A user goes to info.tw.o and searches for "WYSIWYG"
2. Tiki searches all of the *.tw.o domains and presents the results to the user, breaking the results by domain (e.g., all of the doc pages, dev pages, etc.)

Currently, the search results page will provide a box for users to extend their search to other tw.o domains, but (IMHO) it really needs to be automatic. See http://info.tikiwiki.org/tiki-searchindex.php?highlight=wysiwyg&where=pages&search=go for an example.

Maybe this could be expanded to fetch search results from other, non-Tiki search engines, too.

The current ElasticSearch Implementation is very nice but I noticed that it is impossible to specify wildcard search (term*).
This may not be a big deal for englisch users but in languages like german, we combine our words to form new ones. Example: Hoch (high) + Haus (house) = Hochhaus (Skyscraper).
You can imagine that a lot of searches fail because people expect to be able to search for substrings.

Alternatively allow us to manipulate the tokenization of the words by syllables or a dictionary.

When enabled feature_search it is possible for
Anonymous user to read protected pages via
special search request

Just try "a" or any other word that is in hidden
or protected area in search box - tiki-
searchresults.php give U text from hidden
pages

from tiki-searchresults.php



http://tikiwiki.org/tiki-view_forum_thread.php?
topics_offset=0&forumId=4&comments_parentI
d=16071

Any registed user can use "Switch User".

I think this is very important, because everybody is able to be admin. :-(

Or can i dit a Misconfiguration? I dont think so.

---

today i see, everybody IS admin! (but i don't assign admin-perms to these users)

---

I found the Problem:

if i have tiki_p_search-permission so i have all "tiki"-perms too :-(

- How can i configure a group (or all users / anonymous) that they can use "search" (most important function of a wiki, i think) whithout make them admin?

On a quite big and several time upgraded Tiki all unified-index errors were running without errors.
Since a few month I see an error for each article that has the field source filled with an URL.

2022-11-14T07:55:37+00:00 INFO (6): addDocument article 470 {"memoryUsage":"38.5 MiB"}
2022-11-14T07:55:37+00:00 ERR (3): NOTICE: Trying to access array offset on value of type bool {"code":null,"file":"/var/www/vhosts/xxxx/xxxx/lib/core/Search/ContentSource/ArticleSource.php","line":53}
2022-11-14T07:55:37+00:00 ERR (3): NOTICE: Trying to access array offset on value of type bool {"code":null,"file":"/var/www/vhosts/xxxx/xxxx/lib/core/Search/ContentSource/ArticleSource.php","line":56}


{CODE(caption="lib/core/Search/ContentSource/ArticleSource.php, lines 47:59")}
$rss_relations = TikiLib::lib('relation')->get_object_ids_with_relations_from('article', $objectId, 'tiki.rss.source');
$sitetitle = '';
$siteurl = '';
if ($rss_relations) {
$rssId = reset($rss_relations);
$rssModule = TikiLib::lib('rss')->get_rss_module($rssId);
if ($rssModule['sitetitle']) {
$sitetitle = $rssModule['sitetitle'];
}
if ($rssModule['siteurl']) {
$siteurl = $rssModule['siteurl'];
}
}
{CODE}

It would be nice to add autocomplete for "Find" text boxes for the seach module, header search and advanced seach features.

many x.tw.o sites would benefit from that, for instance...

(I add this request here after Jonnyb explicitly asked me to suggest him places where atuocomplete would be adequate (:biggrin:)
)

Tiki has internal ((doc:search)). It is fully integrated, checks permissions, and works on shared server, etc.

However, in some contexts, better support for external search technologies would be useful.


Related:
http://framework.zend.com/manual/en/zend.search.lucene.html
http://www.sphinxsearch.com/
http://www.google.com/sitesearch/
http://lucene.apache.org/solr/
http://ir.dcs.gla.ac.uk/terrier/

{syntax type="tiki" editor="plain"}
On http://profiles.tikiwiki.org, if I enter the following in the "Search Wiki Page (new)" field:

Multilingual_Wiki

I only get one hit for the following page:

Multilingual_Wiki_Test_Data

Yet, there IS a page called Multilingual_Wiki:

http://profiles.tikiwiki.org/Multilingual_Wiki

{syntax type="tiki" editor="plain"}
Hello,

I have yet id3127 id3148 explained the problems of the bug and wishes list.

I returns on the subject :
*before if you were clicking on the column headers, which function is to allow to sort the displayed list, you where generating a crash by an SQL request error.
Somebody have done something.

*Now : When you use this feature the list is simply cleared (if error then return).

Either this tool is without any interest for development or not at all.
If it is without interest it must be suppressed...
if not it must normally function even simply.
Actually the function are very simple but they don't functions.

!!The list sort problem : a display simply cleared...

If it is, anybody can understand that the impossibility to sort a list which is always displayed as playing card poker, makes impossible any revue of a subject.

This is the main problem.

!!Minimum enhancements in my opinion
__A really minimum list :__
*Display the "id" and the "author"
*Display a full date (the day)
*Allow a direct access by the "id"
*Allow selection by check box and display only checked items
*Send by mail the current list
*Optionally send by mail the content of an id

This could allow to check this list...

Trebly

{syntax type="tiki" editor="plain"}
I have some pages where word debugging or debugger apears, but when i put into search box word debug then it want find nothing, if i type debugg then result is ok, but not debug. If i type debug then only find exact pages whith word debug.

Since wiki page names should avoid special characters, we'll need to think about maybe using character substitutions in page names (a instead of à, _ instead of ') and use the description field for the exact format.

Please coordinate here: ((Character substitutions))

php console.php index:rebuild works well

However, it doesn't give any feedback.

The web interface reports:

wiki page: 2850
blog post: 4
article: 1708
file: 4321
trackeritem: 6988
comment: 13

Execution time: 510.07 secs
Memory usage: 116.50MB
Queries: 245172 in 163. secs
Last update from SVN (12.0svn): Friday 02 of August, 2013 11:11:40 EDT- REV 46958

The buttons after the text input in the search module are confusing. I doubt if people generally know whether to click "search" or "go". There should at least be tooltips for these to explain the difference. Also, "Edit" shouldn't display unless the user has wiki edit permission, seems to me.