Category: Search

{img src="tiki-download_item_attachment.php?attId=491"}

{img fileId="605"}

If the user is admin, it should offer a link

{CODE()}Click here to rebuild index{CODE}

If user is not admin:

{CODE()}Contact the site administrator. The index needs rebuilding.{CODE}



Please do in trunk, and we can backport later (after 12.0, but before 12.1)

{img fileId="640"}

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

Plugin TrackerList accepts these params: filterfield & filtervalue
( see https://doc.tiki.org/PluginTrackerList )

In Tiki11 they still work fine. In Tiki12, they found nothing. See reproduced example in show.t.o; basically, applying the Bug_Tracker profile and changing the plugin tracker list code to something like:

{CODE()}
{trackerlist trackerId="1" fields="1:2:4" showlinks="y" popup="3" status="opc" filterfield="1" filtervalue="bug"}
{CODE}

Credentials for show.t.o:
u: admin
p: 12345
---
Update: Fixed, thanks! {sign user="xavi" datetime="2013-11-16T17:37:30+00:00"}

12.x svn LTS recent regression: mysql table for unified index doesn't exist and page edit displays fatal error (even if edition saved properly)

I recently noticed that, in a few tikis that I migrated from a server to a new one. They were working fine for a few days, unified search index being updated on a cron job at night time, page edits fine, etc.
And suddenly, page edits in some tiki sites started to display this fatal error message of missing mysql table for the index (using Mysql Full Text Search engine for the advanced unified search).

I also noticed that the index update failed for one site because some tracker field had a perm name too long for Mysql Full Text Search as unified search engine.

Anyway, I'll dop a note here just in case other people start to experience similar issues, so that we can look for common patterns to track the issue down.

In myc ase, workaround was to manually reindex again the site through console. Then no error was shown in further wiki page edits for the same users, etc.

PluginTrackerCalendar (fullcalendar resourceviews) stopped showing events when the Unified Search Engine is set to "Lucence (PHP)" (even if index is rebuilt).

There is a profile used to test the TrackerCalendar feature, where we could easily reproduce the expected behavior with PluginTracekrCalendar since Tiki10.

Applying that profile "((pr:Tracker_as_Calendar_10))" to current Tiki12 fails to show the events in the calendar widget anymore.

That is currently even more visible since that feature was added to one of the Featured profiles: "Collaborative Community_12x".

In short it will be reproduced in a show.t.o instance:
u: admin
p: 12345

Go to http://xavi-9794-5132.show.tikiwiki.org/tiki-index.php?page=Tracker_as_Calendar_10
and you will see that issue reproduced.

This should be migrated to the community site, and handled with ((doc:Organic groups)) and ((doc:User Trackers))

1- Visit http://doc.tiki.org/tiki-searchindex.php?filter~content=ldap

2- Click on the first result:
http://doc.tiki.org/tiki-index.php?page=LDAP+authentication&threadId=208&comzone=show#threadId208

This seems to be a comment on that page, but it doesn't load.

I searched "WYSIwat" in the module search in tiki.org and I got System error.

The url was:
http://tiki.org/tiki-searchresults.php?find=WYSIwat&boolean=on&boolean_last=y&search=Search

Duplicate of {wish id=5360}

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.

This should be migrated to the community site, and handled with ((doc:Organic groups)) and ((doc:User Trackers))

{syntax type="tiki" editor="plain"}
Search for prefs or fulltext search in 30.0beta release (installed from tarball) returns:
{CODE()}
System error.
The following error message was returned:

Variable 'innodb_ft_user_stopword_table' can't be set to the value of 'tiki-fresh/index_pref_en_stopwords'
The query was:

SET SESSION innodb_ft_user_stopword_table = ?
Values:

tiki-fresh/index_pref_en_stopwords
The built query was likely:

SET SESSION innodb_ft_user_stopword_table = 'tiki-fresh/index_pref_en_stopwords'
{CODE}

Similarily for other languages.

{syntax type="tiki" editor="plain"}
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

{syntax type="tiki" editor="plain"}
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.

https://dev.tiki.org/tiki-searchindex.php?filter~content=diagramo&search=Search
misses the result in a wiki page

But Google finds it:
https://www.google.com/?#q=site:dev.tiki.org+diagramo

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.

In some cases, e.g. where reindexing takes a long time, it would sometimes be useful to invalidate certain objects and then do -+index:catch-up+- to process the queue, e.g.
{CODE()}php console.php index:invalidate trackeritem 1234,1235,1236,1237{CODE}
(for instance)

Like we have for PluginTrackerlist or PluginTrackerfilter there is param showinitials to filter and display alphabetical filters. Can we do the same with PluginList?

See: https://tiki.org/forumthread75302

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

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

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}