Category: Search

This is the default behavior in search engines like Google


Also reported here: [tiki-view_tracker_item.php?itemId=166]

and:
{QUOTE(replyto=BillMac)}
I have found that, if I want to find something on tw.o sites, I should disregard TW's search feature and use Dogpile to look things up. The TW search capability is so weak that it is almost "a missing feature." At the very least, "TermA TermB" searches should be "termA AND termB" not "termA OR termB." The plus/minus markers are fine if you're in the know, but they don't work well either. Using the category/group filters renders a whole different set of answers; not GOOD answers, just different. Without those filters, unauthorized users see parts of pages they are not supposed to see at all. Not a missing feature, a broken feature.

Gosh, I hate to be so negative.
{QUOTE}
Source: ((Major Features Missing in TikiWiki))

Contributors

Text search on files is not usable in 2.0RC4. Table tiki_files "search data" is empty. Files were uploaded, then I defined MIME types, then reindexed. I clicked on "Reindex all files for search" in Admin>File Galleries but can't tell if anything happened; nothing is in Tiki Logs (I already know there is no code for Debug Console to show what Admin>File Galleries is doing). I defined the MIME filters in http://doc.tikiwiki.org/tiki-index.php?page=Search+Admin&bl=n

This apparently sometimes works. In my "trunk" development system I have different text/.doc files uploaded and those were reindexed after I defined the MIME types.

UPDATE: I had trailing spaces in the MIME type names and the filter commands, due to cut-and-paste behavior. I request that trailing spaced be trimmed from the MIME filter input fields.

Our site has a lot of child pages that are included by parent pages. When accessed individually, they make much less sense than if they are accessed as part of the parent page that includes them.

Is there a way to restrict the Search functionality of TikiWiki to only return pages that meet a certain criteria? Eg, pages that would be in the format tiki-index.php?page=Title/PageGroup

I have referred to the tiki-admin.php?page=search page but could not find anything that fit the bill.

Contributors

This is a workaround for the bug described below. We just had this same problem occur in Tiki Wiki 6.3. Our Architect looked at the code and said the search wasn't recognizing the pages' language. I turned off the multilingual feature that I just turned on last week (May 31, 2011), and our search function worked normally again.

This is a cut and paste of the following open bug I found that describes this problem:

Status open
Rating (1)
Ticket ID 2188
Subject Search function does not work when tiki-searchindex.php is first invoked
Submitted by Geoff Brickell
Priority 9 high
Category Bug: Error
Tiki Version 2.x
Feature Search
Description Using the Search link in the application menu invokes tiki-searchindex.php which does not return any results no matter what you search for.

Having had a 'failed' search you are however now at tiki-searchresults.php and all subsequent searches work fine.

When you use the Search box module you fill in the form and the form 'action' is to run tiki-searchresults.php - and so this works fine.

This was previously logged as id 1696 - but this flagged the problem as a usability problem with the tiki support site rather than a possible coding bug - so have submitted this again.


Lastmod by Geoff Brickell
Created Monday 01 December, 2008 04:40:25 CST
LastModif Monday 01 December, 2008 04:46:34 CST

Here are two screen shots.

The screen shots are showing exactly what my search text box looks like: right in the middle, I see a separator.

In French: {img type="src" src="http://tiki.org/display281"}

In German: {img type="src" src="http://tiki.org/display282"}

When I am browsing in French, the search engine textarea shows a separator pipe right in the middle.

It has nothing to do with my screen size (Cntrl + or minus), I tried.

Does any one else sees the same?

It's cumbersome. Of course it has to do with the restricted amount of caracters that one person can use when writing a menu. In english I don't see it.

The second screen shot shows the same prob in German language.

This prob is not new. It's just me who took a long time to report it or others are seeing the same?

Peharps you can tell me if I need to do something on my browser side

In the Community environment/universe (whatever you call it) it's OK


It does the same with IE
Also, when I tried to upload the images, I was unable to choose a category. I'm using Firefox v.5

Hi,

After display of a filtered list :

Various erratics behavior with the "sort" command by clicking a column of the header :

1- on "date" no effect or the list is cleared (after a crash of SQL request : before we had the crash, now it is handled but simply clears the list)

2- on "version" no effect at all.

Others not checked again (had been two years ago), who will repair can checked each column sort behavior...

Categories are amazing for a large site. It makes it easier to manage. Next step is to add an option in search which can be filtered by category.

We use your engine for knowledge base items as well as intranet and were wondering if there could be a way, if it doesn't exist and we just haven't seen it, to be able to view words users search on that are not in a wiki, not found etc so we could take that data and make sure to add those words to a tiki page.

We wanted the ability to run reports on what words folks are searching on and not just ones that got hits

Thanks in advance
Mark

I would like to see social implications added to Tiki search results. For example, in addition to pure content relevancy, it would be nice if search results took into account things like:
- Page rating
- Free tags
- Bookmarks
- Trackbacks
- Number of views
etc.

These could be used in conjunction with pure keyword matching to present users with a (potentially) better match.

Calendar data is in the "Modified since your last visit module"

However, event data is not findable via the Tiki search engine.

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

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'

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.

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.

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?

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/

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

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

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

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.

{CODE(wrap=>1)}
(18:30:35) xavi: to reproduce: I did search for "Report" at the top bar search
(18:30:42) xavi: showing this url: http://dev.tikiwiki.org/tiki-searchresults.php?highlight=Report&search=Go
(18:30:47) xavi: with this error:
(18:31:14) xavi: [off] You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near '? and ttif.`value`=? and ttifOut.`fieldId`=?' at line 2 The query was: select ttifOut.`value` from `tiki_tracker_item_fields` ttifOut, `tiki_tracker_item_fields` ttif where ttifOut.`itemId`= ttif.`itemId`and ttif.`fieldId`=? and ttif.`value`=? and ttifOut.`fieldId`=?
{CODE}

---
Update on March 31st 2010, using Last update from SVN (5.0alpha): Friday 26 March, 2010 09:12:40 CET - REV 26326 :

{img src=http://dev.tikiwiki.org/tiki-download_item_attachment.php?attId=236 desc="http://dev.tikiwiki.org/tiki-download_item_attachment.php?attId=236"}

Tested on info.tw.o with FiveAlive theme...

Disabling the __Search box__ option on the Admin: Search page, Search Results tab (tiki-admin.php?page=search) will remove the Search bar from the menu.

This is incorrect behavior.

Tiki already shows the category and/or category path when listing wiki pages. I would like to also display the category information in search results.

This would help end-users determine the relevancy of the search result.

I would like Tiki to display each item's freetags when display the search results. This would help end-users determine the relevancy of each item.

I would like Tiki to display each item's freetags when display the search results. This would help end-users determine the relevancy of each item.

Hello, if I search an "entire site" I expect a search in all sections and as result all objects where I have the correct object permission. But this search is implemented with an inconsistent double permission check.

The "entire site" search fist checks the global view permission in each section. If this is true, the search is sent to the search engine of the section, which gives back results depending on the object permission.

As the default search is "entire site" (can be changed via template), all users without the global view permission in the sections get back an empty result-set. A click on the section search button reveals the searchresult depending on the object permission of the section.

This is somehow between a bug and a feature.

As far as I can tell, the solution to show "entire site" search results according to object permissions is very easy.

You can see here:
http://dev.tikiwiki.org/tiki-searchresults.php?highlight=mouseover&where=pages&search=Go

[http://tikiwiki.org/tiki-searchresults.php?highlight=rss&where=forums&search=Search+in+content|Link to error]

On the main forum page of tw.o I enter the text "rss" then search button and get the following:



The following error message was returned:

You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near ')' at line 1

The query was:
SELECT `rssId`, `url`, `actions` FROM `tiki_rss_modules` WHERE (`lastUpdated` < ? - `refresh`) AND `rssId` IN( )

Values:

1. 1270869772

The built query was likely:
SELECT `rssId`, `url`, `actions` FROM `tiki_rss_modules` WHERE (`lastUpdated` < '1270869772' - `refresh`) AND `rssId` IN( )

This would permit cleaner URLs and easier searching.

__Where?__

Wiki page names
Usernames
tags?
etc.

__What?__
Spaces & underscore to be equivalents
a and A are equivalent. This makes perfect sense for page names, user names, etc Accented characters (äâ) should be as well

For wiki page names (see how Wikipedia does it) but it could be that ~np~((User_Profile)), ((User+Profile)) and ((User Profile))~/np~ are equivalent.


Should hyphen (-) be an equivalent character as well?

How about (,) and (.)

. doesn't play nice with rewrite rules




Moved discussion to: ((Character substitutions))

Hello,

I just submit a new search, the SQL request crashes with "system error" as reported in item 3104.

This seems to be solved a few days ago, but it was not a full solution.
Here beyond the beginning of the request :

SELECT tti.*, ttif.`value`, ttf.`type`, sttif.`value` as `sortvalue` FROM ( `tiki_tracker_items` tti INNER JOIN `tiki_tracker_item_fields` ttif ON tti.`itemId` = ttif.`itemId` INNER JOIN `tiki_tracker_fields` ttf ON ttf.`fieldId` = ttif.`fieldId`) LEFT JOIN (`tiki_tracker_item_fields` sttif) ON (tti.`itemId` = sttif.`itemId` AND sttif.`fieldId` = 41) INNER JOIN `tiki_tracker_item_fields` ttif0 ON (ttif0.`itemId` = ttif.`itemId`) INNER JOIN `tiki_objects` tob43 ON (tob43.`itemId` = tti.`itemId`) INNER JOIN `tiki_category_objects` tco43 ON (tob43.`objectId` = tco43.`catObjectId`) INNER JOIN `tiki_tracker_item_fields` ttif1 ON (ttif1.`itemId` = ttif0.`itemId`) INNER JOIN `tiki_objects` tob47 ON (tob47.`itemId` = tti.`itemId`) INNER JOIN `tiki_category_objects` tco47 ON (tob47.`objectId` = tco47.`catObjectId`) WHERE tti.`trackerId` = ? and (`status`=? or `status`=?) AND ttif0.`fieldId`=? AND tob43.`type` = 'trackeritem' AND tco43.`categId` IN ( ) AND ttif1.`fieldId`=? AND tob47.`type` = 'trackeritem' AND tco47.`categId` IN ( ) GROUP BY tti.`itemId` ORDER BY `sortvalue` desc...

You can notice that the syntax uses in "IN ()" clause which is not accepted by MYSQL.

!!Solution, first steps
Check all SQL queries for "IN()" clause and find a bypass anywhere in tikiwiki.

Trebly

This could also be by via category system (with perms)

Hello,

On my system :

__feature_sefurl don't functions normally.__

Important : Subject feature_sefurl : last version 5.1rc1 (current yesterday but may be before). The feature_sefurl don't functions normally (I have not searched why, I don't look at in details to this part).

__So if the option is activated all url(s) as

__''site/<page name> ''__

fail and any action, particularly page-object-display (magnifier icon) reaches a 404 error. __

nota : naturally, if the option is not activated the url generated for display of pages is :
__
''site/tiki-index.php?page=<page name> ''__

which functions normally.

trebly

ref-B00805-01

Logged as user xavi here on dev.tw.o/tracker5 I can't filter by summary (text field): no text input field is shown. Some other type of filter fields work as expected (I didn't try all) but not filter by summary.
Reported April 2nd. Using Firefox 2.0.0.13 ca on GNU/Linux
---
Reproduced as user xavidp (admin rights) using 2.x here again on dev.tw.o/tracker5 using Firefox 3.0 ca on GNU/Linux.

Filter (stored query) feature

While setting up Tiki 6.0 (upgrading from an earlier version) I found that if you enable Full Text Search but not Tiki search, search is treated as a disabled feature on the admin pages.

Also the top search bar works only for tiki search, while the main search function does work with FT.

CLIP from my whining about why the search doesn’t work in TW.



#1 - why isn’t there a proper SEARCH ?

- to start this off can we at least agree on a couple things:
o standard search for - RED BALL would search on RED AND BALL
o TW does RED OR BALL – which is WRONG!!

- BASIC search should be capable of:
o RED BALL = RED AND BALL
o “red ball” = only match “red ball” as quoted
o and then, maybe RED or BALL = RED OR BALL


with a little more digging and some input from marclaporte, redflow and mose I think I have figured out the problem:

- TW supports the concept of FULL TEXT SEARCH (FT)
- this allows user to (from example above) do a search like “+red +ball” to achieve “red AND ball”.
- but these is a bug in concept in searchlib - function _find()
- if FT is set then _FIND does the right thing by doing a MATCH AGAINST sql query
- HOWEVER – if it doesn’t find any results it ALSO will do a simple (i.e. non-FT) search
o in concept this is silly since it defeats whole point of doing FT in the first place
o also, it generates an sql error because for simple search a REGEXP query is done which will choke on the + signs in the search string

The full text search module should provide means to determine what operators work with it. Perhaps a large tooltip or a link to an "advanced search" page. Syntax for the module is [http://tikiwiki.org/tiki-index.php?page=FullTextSearch|here.]

Using the new search box with the search button leads to a fatal error:

Fatal error: Allowed memory size of 134217728 bytes exhausted (tried to allocate 53215256 bytes) in /home/alphafiv/public_html/lib/tikilib.php on line 5118

Using the Titles button works fine.

I have a search module set as:

advanced_search_option=y
advanced_search_help=y
default_button=go
input_size=25
select_size=20
nobox=y
decorations=n
style=position:absolute;top:0px;left:0px;

The "default_button=go" setting is not being honored. Clicking on any of the buttons works properly. Pressing Enter in the control causes a full-text search instead of a title search.

http://tikiwiki.org/tiki-index.php?page=20040302MarcLaporteInterview&highlight=marc%20laporte

Something more than this:
http://irc.tikiwiki.org/

There is a start but can it handle the volume of data we produce?
http://tikiwiki.org/tiki-view_irc.php

The level of integration (all, some or none) with Tiki is to be discussed.

Related/similar software:
http://colas.nahaboo.net/software/irclogger/
http://ircbrowse.com/
http://tools.splitbrain.org/irc/wikiohana/

An RSS feed would be nice.


And some stats:
http://pisg.sourceforge.net/

We would like to unify the search and find boxes on our site into a single module with a text box and Ajax auto-suggest for Wiki page names. If something that had no auto-suggestions were typed, it would do a full text search.

This is similar to MediaWiki. The current interface confuses even software developers.

We would be open to hiring a consultant and contributing the resulting module back to the TikiWiki project.

Hello,

Every time I save a wiki content, I got the following error:

"Search index could not be updated. The site is misconfigured. Contact an administrator.
Utf8 compatible lower case filter needs mbstring extension to be enabled."

I checked phpinfo at http://grip.umich.edu/tikiwiki/tiki-phpinfo.php, and the mbstring extension was enabled.

Hello,

When I run the search through wiki content, I got a blank page, no content, no error, no feedback.
When I changed the option allowing users to use email as user name I could not create new user, I also got a blank page.

Both the Unified Search and the MySQL Search results page displays the wiki syntax instead of parsing it. This occurs with the MySql Search whither or not "Parse the results" is checked on the admin page (there is no similar setting for the Unified Search).

This same behavior has been seen on the tiki.org pages. Here's an example result from searching the Community: {CODE()}CoCoMo
{HTML()}&lt;script type=&quot;text/javascript&quot; src=&quot;http://www.ohloh.net/p/39/widgets/project_cocomo.js&quot;&gt;&lt;/script&gt;{HTML} Reference: http://en.wikipedia.org/wiki/COCOMO
Last modification: Monday 24 October 2011 16:18:35 PDT{CODE}
and
{CODE()}Features/Usability: Re: Re: Re: Re: anyone ? anyideas? anything?
Thanks ricks99, the example you gave is what i want to do. However, when i include the poll in my wiki page, the ratings results still don't show up. I've tried it as a poll using {POLL(pollId=>2)}{POLL} and a module {MODUL
Last modification: Wednesday 02 April 2008 21:56:01 PDT{CODE}

This makes if very difficult for a user to determine if the page is relevant to their search.

It would be nice if some of the simpler formatting was displayed, e.g. bold, code blocks, underlining, etc. to make the results more legible to the user.

v7.1 & 7.2

Searching Wiki pages does not return expected results.

*It appears that the default search only searches part of the page text and not the titles.
The search does not return pages from a structure that I know have the search phrase displayed on the page. When this happens I usually get an empty "List Wiki Pages" with "Exact match" checked (I don't know what the exact trigger of this is but it occurs most often while searching titles). Unchecking this will then return results. It would be nice to have "exact match" be an option -- not the default -- on the admin page to reverse this behavior.
*No search will return a match for text in a structure alias name, even though the text is display to the user.

I setup a test structure like this:
Page 1 -> Page One
Page 2 -> Page Two
Page 3 -> Page Three

The text on each page was "Now is the time for all good men"

Searching for "Three" returned nothing.
Searching for title "Three" returned nothing.
Searching for "Page" returned all three pages.

It seems to me that a user would be typing into the search box a word or phrase that they expected to be on a page, whither it be a title, alias or text and would therefore expect a search of "the entire site" to return one or more pages that display some form of their text without having to click on several buttons.

After a search (general by text) the beginning of text which is displayed is not decoded-re-encode for the context.
On the screenshot joined you can see parts of text with tiki tag (!! for h2), HTML tags, problem of encoding UTF8 probably or old text not re-encoded (not yet checked).

To reproduce, search "wiki" in the admin panel here:
http://branding.tiki.org/tiki-admin.php

And you will get:
"No preferences were found for your search query."

Ideally, the problem is solved, but this is maybe tricky. It could be related to:

{QUOTE(replyto="http://framework.zend.com/manual/1.11/en/zend.search.lucene.index-creation.html")}"Zend_Search_Lucene uses flock() to provide concurrent searching, index updating and optimization. According to the PHP » documentation, "flock() will not work on NFS and many other networked file systems. Do not use networked file systems with Zend_Search_Lucene."{QUOTE}

At the very least, Tiki should detect and report to the site admin that he should use MySQL Full Text Search instead.

Ideally, MySQL Full Text Search would work for tiki-admin.php

__unified_incremental_update doesn't check for feature_search__

Unified Search with Lucene is awesome and is "the future of Tiki".

Now, on certain server configurations, it doesn't work well. An easy workaround is to simply revert to the legacy MySQL Full Text Search.

However, even when using MySQL Full Text Search, unified_incremental_update is defaulted to yes, and tried to update Lucene index, and generates an error message

Workaround is to deactivate unified_incremental_update, or even better, upgrade to 12.x and use Unified Index, with MySQL as storage.
---
Update: this issue has been reproduced in 12.x svn (and untested in 14.x so far, afaik) also with Mysql Full Text Search as unified search engine (on a multitiki install). See: [item5673] . {sign user="xavi" datetime="2015-05-19T09:10:57+00:00"}

Themes.tiki.org is OK:
Indexation
wiki page: 214
forum post: 178
blog post: 59
article: 18
file: 80
trackeritem: 28
comment: 35

But the other sites are unable to complete the indexation.

---
Custom module "Search_tracker_summary" is generating: "Required features: feature_search. If you do not have the privileges to activate these features, ask the site administrator."

blank page here as well:
https://nextdev.tiki.org/tiki-admin.php?page=search&rebuild=now

Search the full Russian word gives a result in the Russian word wiki-pages successfully.

When searching for part of the Russian word search finds nothing.

Search by part of the English word or full word - search is successful.


[http://imageshack.us/photo/my-images/29/18619205.png/|image 1]
[http://imageshack.us/photo/my-images/861/17424549.png/|image 2]
[http://imageshack.us/photo/my-images/809/25798887.png/|image 3]
[http://imageshack.us/photo/my-images/831/71733976.png/|image 4]
[http://imageshack.us/photo/my-images/69/43517748.png/|image 5]
[http://imageshack.us/photo/my-images/708/31417838.png/|image 6]
[http://imageshack.us/photo/my-images/21/59250827.png/|image 7]
[http://imageshack.us/photo/my-images/824/86604157.png/|image 8]

When I attempt to organize objects in categories and I either click on the orphans link or attempt to search for objects, the action fails and the error reported below occurs. Note that on our system tiki is configured to use legacy search (mySQL) since when I configured it to use Lucene the "Search index could not be updated. The site is misconfigured. Contact an administrator." error occurred.

Fatal error: Uncaught exception 'Zend_Search_Lucene_Exception' with message 'Index is under processing now' in D:\Program Files (x86)\EasyPHP-5.3.9\www\tiki\lib\core\Zend\Search\Lucene.php:280 Stack trace: #0 D:\Program Files (x86)\EasyPHP-5.3.9\www\tiki\lib\core\Zend\Search\Lucene.php(529): Zend_Search_Lucene::getActualGeneration(Object(Zend_Search_Lucene_Storage_Directory_Filesystem)) #1 D:\Program Files (x86)\EasyPHP-5.3.9\www\tiki\lib\core\Zend\Search\Lucene.php(211): Zend_Search_Lucene->__construct('temp/unified-in...', true) #2 D:\Program Files (x86)\EasyPHP-5.3.9\www\tiki\lib\core\Search\Index\Lucene.php(40): Zend_Search_Lucene::create('temp/unified-in...') #3 D:\Program Files (x86)\EasyPHP-5.3.9\www\tiki\lib\core\Search\Index\Lucene.php(123): Search_Index_Lucene->getLucene() #4 D:\Program Files (x86)\EasyPHP-5.3.9\www\tiki\lib\core\Search\Index\Lucene.php(82): Search_Index_Lucene->internalFind(Object(Zend_Search_Lucene_Search_Query_Boolean), Object(Search_Query_Order)) #5 D:\Program Files (x86)\EasyPHP-5.3.9\www\t in D:\Program Files (x86)\EasyPHP-5.3.9\www\tiki\lib\core\Zend\Search\Lucene.php on line 297

Every time a link is clicked, add the keywords of the search result in the index...

See also: ((Adaptation))

The search feature on Wiki pages does not find anything

I have a problem with search in tiki.I wish i can search blog,article,forum... belong to author or creator.I'm researching Zend_Search_Lucene.If you have a solution of this problem.Please help me!!!thankful for all.

We have a couple of tracker field type "relations" in a tracker, showing other items from the same tracker, and it displays a search box at the left of the dropdown box.
when we filter for item which have an apostrophe (single quote: '), the filter doesn't seem to find them. Without apostrophe, it does.
I.e., imagine that we have these two items (without the star):

* foo bar
* foo bar'2 foo bar foo bar

if we search for "foo", we find just the first one, not the second.

Apostrophes are very common in Catalan, as they are in French and other languages (in English it can be tested against items with names such as this onem, which has the word "doesn't" in purpose ;-).

Features Classification

To reproduce the issue:

1- Apply profile http://profiles.tikiwiki.org/Jailroot_Demonstration on trunk

2- Pick perspective "B"

3- Search for "contentA1". You find

A1 and B1 (OK)
A1 A2 A3 (Not OK)

tiki-listpages.php exhibits the proper behavior.

Comments to tracker items can be very a useful way to gather ideas, code snippets, links, etc. from the community regarding an a problem or an idea.

It would therefore seem to be natural to include tracker comments in search - otherwise there is a risk of losing valuable community contributions in a black hole of tracker comments.

Tracker comments should of course be included in "Entire Site", and maybe even have their own search category.

After upgrading 1.9.4 to 1.9.5, a search entire site returns the following error. I looked in db/fulltext.sql and didn't see a create fulltext index statement for tracker. What tables/columns should be indexed?

~pp~
in /home/lampp/htdocs/kniki/lib/tikidblib.php on line 134

Context:
File /kniki/tiki-searchresults.php
Url ///kniki/tiki-searchresults.php?highlight=draw&where=pages&search=go
Query:
SELECT ttif.`itemId` AS name, LEFT(tt.`name`, 240) AS data, tt.`trackerId` AS hits,
tti.`lastModif` AS lastModif, tti.`itemId` AS pageName,tti.`itemId` AS id1,1 AS id2,
MATCH(`value`) AGAINST ('draw') AS relevance FROM `tiki_tracker_item_fields` ttif LEFT
JOIN `tiki_tracker_items` tti ON (ttif.`itemId`=tti.`itemId`) LEFT JOIN `tiki_trackers`
tt ON (tti.`trackerId`= tt.`trackerId`) LEFT JOIN `tiki_tracker_fields` ttf ON
(ttf.`fieldId`= ttif.`fieldId`) WHERE ttf.`isSearchable` = "y" AND MATCH(`value`)
AGAINST ('draw') ORDER BY relevance desc, tt.`trackerId`

Values:
Message:
Error Message Can't find FULLTEXT index matching the column list
~/pp~

In the early days of TikiWiki, we used a bunch of modules (last_modified_wiki_pages, last_articles, Last this, Last that, etc.) to show recent changes to visitors. We ended up with many modules and it was cluttered.

All this became a lot better once the "Since your last visit" module came around to adding all the features. As a bonus, it checks permissions and shows the information since the user's last login. Very sweet.

Now, I am hoping to get to the same result for the many edit/input boxes.

In version 3.0, the quick_edit module checks (with Ajax) for names of existing wiki pages to edit. This avoids duplication. Great stuff. Wikipedia does something similar when you are searching for a page name.


I almost always have the search box on.

However, I also add "search page name" because the general search engine may not return the page I am looking for as the search result.

Here is an idea:

A new module which combines three modules:
search_wiki_page
search_new
quick_edit

See top right of http://moinmo.in/ for an example.

The action buttons are grayed out until text is entered in the text box. -> Very nice


Button should be WYSIWYCA


See top-right search box at:
http://www.ohloh.net/projects/tikiwiki
http://www.wikicreole.org/



__Alternatively, we could combine search page name and search text, and in the search results, we would first show pages names, and then, search text. This involves more work, but could be better for the end user UI.__

^I think the existing layout for the search top right in TW is fundamentally good. A text box, then a drop-down then a button. Why because the drop down is more future proof than any of the layouts from the other sites you reference.

If we make the contents of the drop down easy to customise or at the very least document how to add to it. For example the CRM function could add items to the drop down for "Contacts" and "Accounts", webmail could add "Mail Messages" and so on.

I do agree the wikipage create/edit module should be included in the top right search function.

I think this is an example of where considering the future openness of the solution would be very important - MatWho^

{THUMB(id=98)}{THUMB}

Sometimes, I want to restrict who uses Tiki's internal search engine. Maybe I have some non-linked pages, that people can discover via the search engine.

When I type something into the Create/Edit-Search-box there pops up an ajax-autocomplete-box below the search field.

But when I use the regular search box, there is no autocomplete-search. It should also have autocomplete.

This would be a great feature with relatively low effort, because the feature is already implemented for the Create/Edit-Search-box.

Installer fails at the end with the following error:

"Fatal error: Cannot use object of type stdClass as array in
/tiki/lib/core/Search/Indexer.php on line 64"

The ultimate feature of Amazon and all the e-commerce shopcart systems is the one known as "Customers who bought this item also bought .." or "were also interessted in ..".
The feature would show objects or items that were viewed or bought by previous users in conjunction with the actual item or object.

Idea:
Applied for tiki a new plugin "Relation By Views" would allow to list related wiki pages (or even other objects) in a page likewise to existing backlinks and alias plugins as well as semantic links.
Though, the information is based on previous view counts / his of wiki pages (or other objects) that have been hit by users wihtin the same session as the actual wiki page / object.

The enhancement is obvious: we would make a step further to get implicit relations between pages / objects based on user behaviour.
Just as the advantage in ecommerce is crossselling, we would provide cross-links and encourage readers to have a look to further pages / objects.
In regard to enhancements of the basic shopping cart feature in Tiki 5, this plugin could even be used as a real "customers were also interessted in" feature.