Category: Search

{syntax type="tiki" editor="plain"}
Searching the content (try e.g., "social") FAILS with fatal error after fresh-install/index rebuild:
{CODE()}
System error.
The following error message was returned:

DOUBLE value is out of range in '(round((match `tiki-fresh`.`index_6a5a0961d11ac`.`contents` against ('social')),2) * 1)'
The query was:

SELECT *, ROUND(MATCH(`contents`) AGAINST ('social'),2) * 1 + ROUND(MATCH(`title`) AGAINST ('social'),2) * 2.5 AS `score` FROM `index_6a5a0961d11ac` WHERE 1=1 AND ((MATCH (`contents`) AGAINST ('social' IN BOOLEAN MODE) OR MATCH (`title`) AGAINST ('social' IN BOOLEAN MODE)) AND (`searchable` = 'y' AND `searchable` IS NOT NULL)) ORDER BY `score` DESC
The built query was likely:

SELECT *, ROUND(MATCH(`contents`) AGAINST ('social'),2) * 1 + ROUND(MATCH(`title`) AGAINST ('social'),2) * 2.5 AS `score` FROM `index_6a5a0961d11ac` WHERE 1=1 AND ((MATCH (`contents`) AGAINST ('social' IN BOOLEAN MODE) OR MATCH (`title`) AGAINST ('social' IN BOOLEAN MODE)) AND (`searchable` = 'y' AND `searchable` IS NOT NULL)) ORDER BY `score` DESC
{CODE}

_This happens only for the first initial search. After that first attempt it seems to work normally for any subsequent search._

Steps to reproduce:

# Run -+php console.php i:r+-
# Go to -+tiki-searchindex.php?filter~content=profile&sort_mode=score_ndesc+-

I have a search module which searches into the wiki pages.

On clicking "OK", I do get on tiki-listpages.php?find=mysearchword&go=OK and it displays for a short time the correct list of pages and the correct number of pages. Then the « I'm searching » spinner kicks in and the list of search result pages is replaced with the full list of all pages.

There is a demo here:
[https://showlistpages.winter.alsawiki.com]
Database available here : [https://showlistpages.winter.alsawiki.com/backups/dump_db.sql.gz]

Tags: Add a modern beautiful and advanced filtering with HTML5 and jQuery, such as Filtrify
https://github.com/luis-almeida/filtrify
http://luis-almeida.github.io/filtrify/
MIT Licensed

We would use it to let users browse more easily Profiles from https://profiles.tiki.org

Demos:
* Multiple categories: http://luis-almeida.github.io/filtrify/movies.html
* Load images with Lazy Load: http://luis-almeida.github.io/filtrify/lazyload.html
* Add pagination with jPages: http://luis-almeida.github.io/filtrify/jpages.html

{syntax type="tiki" editor="plain"}
At https://dev.tiki.org/Wishlist the customsearch displays a status selector.
If you remove the default "open" status it will provoke a logical error as the "empty" or "no-status" option doesn't exist. It shouldn't happen.

UPDATE: I posted a workaround, not sure it is a real solution

When you try to access a wiki page which doesn't exist, Tiki offers you a list of similarly named pages, to search for that word, to create the page, etc.

__Good.__

When you try to access other contents in Tiki (articles, blog posts, etc.) that don't exist (either have been deleted, moved, not yet published, protected, etc.), you get a Tiki error message.

__Good as well.__


But what if you try an URL which is just not possible?

Ex.: If you migrated from another system to Tiki and you are still getting hits with the previous URLs?

Of course, you could check your access logs and add nice redirects. But how can we make this easier for site admins?


The bundled _htaccess file (which you need to rename .htaccess to make active) has an example line:
{img src=images/code.png}%%% {CODE()}
ErrorDocument 404 /tiki-index.php?page=Page+not+found
{CODE}

__This is good.__

Now, how could we use this to provide the Tiki admin with a top-x error pages? And thus, it would help to detect broken links, etc.

Could .htaccess include some configuration info from Tiki? So a Tiki admin could add configuration information without using FTP, all in Tiki, possibly with a secret "system" wiki page.

Great inspiration:
https://github.com/h5bp/html5-boilerplate/blob/master/dist/.htaccess

In Tiki we can filter a large quantity of data but our output is limited to screen.
So in some cases the users are displaying a lot of row only to copy them into a different editor or programs.

IE: Someone perform a search, select annually lines with the mouse, copy and paste into Excel.

We discussed during the January 2022 TRM of an idea of an option to export the results of a customSearch into a CSV file or a PDF or to print it (without the pagination of course). We have something similar for the plugin List table output : https://doc.tiki.org/PluginList-output-control-block#Download_CSV_of_Table_Results

We need this for the customSearch plugin and eventually "outside" the table template.

I need to retrieve post I wrote in the forum 26, and from the forum I was redirected to the Tiki Search page.

In the Tiki search page https://tiki.org/tiki-searchindex.php I used the filters to see only results for the forums.
Choose a filter and press the submit button.
The results page reloaded but the results are not forums type only.

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

{syntax type="tiki" editor="plain"}
Elasticsearch enhanced version supports 30+ languages including:
European: English, German, French, Spanish, Italian, Portuguese, Dutch, Russian, Norwegian, Swedish, Finnish, Danish
Middle Eastern: Arabic, Turkish, Persian
Asian: Chinese, Japanese, Korean, Thai
Eastern European: Bulgarian, Czech, Hungarian, Romanian, Lithuanian, Latvian

Tiki search using Elasticsearch engine work with English stemmer.
See private function getIndexDefinition() at : lib/core/Search/Elastic/Index.php

Due to this, search results for Tiki Wiki website using other languages like German doesn't output expected results.
With an item title "Diplomatie"
"Diplomat" or "Diplomatie " (with an extra space) are found while "Diplomatie" is not found.

Tiki should be able to use the correct stemmer based on the language content.
There should be an automatic language detection to select the relevant stemmer using the $prefs['language'] (the current site language) with a manual override using a new pref in the Search control Panel : $prefs['unified_search_language'] (if you want search language different from site language)

Fallback: Defaults to English if nothing is set

For Multilingual Sites we may need to detect language per document.

{syntax type="tiki" editor="plain"}
In Tiki it is possible for an admin to create a tracker field using an already existing permaname.

This leads to issues for the Unified-Index and search engine.
A recent commit help with the situation : https://gitlab.com/tikiwiki/tiki/-/commit/0ce941f18262d0c01da0d6966c3349d2f56f7e06

However the tracker creation process for such tracker field should include a check and warn, and evantually disallow, the user from creating such field.

Using 1.9.7cvs from mid june 2007

I have an item in a tracker with the word "Carxoferes" in the tracker item title.
http://www.moviments.net/valldelcorb/tiki-view_tracker_item.php?itemId=15&show=view&offset=0&reloff=7&status=o&trackerId=2&sort_mode=lastModif_asc

In the search_new module, trackers doesn't show up in the dropdown box. However, if you search for the Word "Carxoferes" (without double quoting marks), the word "trackers" is listed below search results:
http://www.moviments.net/valldelcorb/tiki-searchindex.php?highlight=Carxoferes&where=trackers&search=go

So is it really searching (or attempting to search) within tracker items?
But anyway, the result is unsuccessful: no pages matches your criteria.
^
! Search results:
Search in:
__All Wiki galleries images files forums blogs blog posts directory articles trackers__


Found "Carxoferes" in 0 trackers

Find [[___________] [[go]

No pages matched the search criteria
Page: 1/0
^

And it should show the tracker item containing that word.
----
Confirmed that the same behavior is happening in 1.10cvs (from July 24th). Checked at:
[http://moviments.net/intercanvis/tracker2]
Adding a new item with the word "senzilles". If I search that word under the tiki search_new module, I can't find it. If I search through Trackers interface directly, I do find it.
----
Update2: using ((doc:Module search_box)) I can find it! (real time indexation works then)
---
Fixed on 1.10cvs. Not sure on 1.9cvs (I couldn't check with latest code). As far as I'm concerned, I leave this bug ask closed. (reopen if you test on 1.9.cvs and it fails)

http://tiki.org/tiki-searchresults.php?find=test&boolean=on&boolean_last=y

{img fileId="831"}

{img fileId="891"}

SVN (19.2svn): Wednesday 08 May 2019 00:59:40 GMT-0200- REV 69939

Thu May 9 00:15:01 CEST 2019
[Wed 08 May 2019 22:15 GMT-0000] Started rebuilding index...
Unified search engine: MySQL, version 5.7.26-0ubuntu0.18.04.1-log
error: Indexing failed while processing "reelnreel" (type user) with the error "Could not perform index modification: Data too long for column 'tracker_field_u_aboutYourself' at row 1"

Search index rebuild failed. Last messages shown above.
Thu May 9 00:58:52 CEST 2019


The error message is wrong. The user does not have a tracker record at all.

This needs to be solved or a big popup/note included when tiki admins activate the search feature.

It should also be listed in tiki-admin_security.php

when performing a search only the first page of results is available, the pagination links at the bottom of the page do not navigate to the subsiquent pages.

I am trying to customize the look and feel of the Site Search Bar that gets added to the top of each page when the "Activate" button is clicked next to the "Site Search Bar" subsection of the "General Layout" tab of the Administrator "Look & Feel" page.

Basically, I just want to add "Enter keywords" here in the textbox.

I am having a hard time finding where this code is defined.

I have looked in the following files:
templates\tiki-searchindex.tpl
templates\tiki-searchresults.tpl
templates\modules\mod-search_box.tpl
templates\modules\mod-search_new.tpl
templates\styles\simple\modules\mod-search_box.tpl
templates\styles\simple\modules\mod-search_new.tpl

Could someone point me in the right direction?

Any insight is appreciated.

Thanks!

Since unified searches are done against an index for performance and scalability instead of against the whole content of the database as before, every new or changed content needs to be indexed. When someone imports a bunch of tracker items through the csv import feature, Tiki knows better than to index all at once, and it indexes 10 items and queues the rest for later indexing (10 at a time). There were 592 items in the queue!

When we edit a page and save it afterwards, there is a bug: Tiki forgets to be clever and presumably tries to index the new page content as well as the whole queue on unindexed data. So, it times out with the following message:
Fatal error: Maximum execution time of 90 seconds exceeded in /data/root_www/promusa.alsawiki.com/20140801_www.promusa.org/vendor/bombayworks/zendframework1/library/Zend/Search/Lucene/Search/QueryLexer.php on line 348

Raising Maximum execution time is no solution: it only blows after more time.

The page is actually saved

Going to the admin → Search → Index maintenance → reindex All
empties the queue and aftewards editing wiki pages is possible again.

On a Tiki24 with tracker and multilingual.
I have a tracker with a multilingual field Name and this field is selected as title.

So for my item237 the Name field has 3 values (one for each language I use):
English: Hourly hour
French: Taux horaire
Hebrew: תעריף לשעה

If I edit the item while the Tiki is set to English as pref.language , the title value saved in the unified-index will be "Hourly hour".
But If later I edit the same item while the Tiki is set to French as pref.language , the title value saved in the unified-index will be changed to "Taux horaire"... and so on.

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

The unified-index "Title" should be consistent and shouldn't depend on the language the editor of an item is using.

Reproduced in the instance:
http://bsfez-11581-8140.show2.tiki.org/tiki-index.php

On a multilingual Tiki23 that was working fine and regularly updated and tested I have for a tracker item name 3 values (for each language):
en = Web App
fr = App Web
he = ווב אפ׳

{img type="fileId" fileId="1702" thumb="box"}

By default the title used by the unified index is the English one "Web App".
And the following filters in a plugin list was working fine no matter which language is selected by the user
{CODE()}{filter field=tracker_id content=16}
{filter field=title exact="Web App"}{CODE}

Since a few commits it is not working anymore and return a "no result found". (tested on Safari and Chrome)
The default title for an item used now is the French one and not the English one as previously. (no matter the language selected on the site)

{img type="fileId" fileId="1703" thumb="box"}

Please see this example:
http://dev.tikiwiki.org/tiki-view_tracker_item.php?trackerId=5&offset=0&sort_mode=lastModif_desc&itemId=1088

Whatever was highlighted in the search in transformed accidentally:

<spanexternal link style="color:black;background-color:#ffff66;">fckeditor</span>

On most of Tiki search tools, I can look for items using the object title with partial terms.
bernard will output : bernard-sfez, bernard sfez, etc.

The same is not true using the tracker field relation find
bernard will output : bernard sfez (only)

To find "bernard-sfez" I have to type the entire string.
This is not consistent with the other place a user may look up for something.
This make this feature harder to use

I even feel like they were a change in behaviour at some point of Tiki23.

''I have the feeling this is a regression as I recall such case where previously handled properly''

I can set a name for a tracker field that will turn into the "Field Prefix". (productssolutionsdetailsandoption)
When I create a tracker field this field permaname will use the tracker field prefix. (productssolutionsdetailsandoptionIllustration)
The index process will add the tracker field prefix. (tracker_field_productssolutionsdetailsandoptionIllustration)

But it won't be able to index such long name.
Or the limit should be changed (to what ? unlimited...) 🤔
Or ahead limiting and warning about the prefix/field length.

{img fileId="2141"}

{img fileId="2142"}

I have a Tiki running elasticSearch set to use the time zone Asia/Jerusalem and the sample on the settings page displays correct information.
{img fileId="1775" thumb="box"}

I have trackeritems with a date field (picker) to select dates.
For exemple I have an item (5761) with a human readable value of : 7/04/2022
{img fileId="1776" thumb="box"}

However the value displayed for this date displayed from the unified index ===is the 6/04/2022===
I can see it in the database
I can see it in the plugin list test tool
And of course in the plugin list used to display the value to the visitors

{img fileId="1778" thumb="box"}
{img fileId="1779" thumb="box"}
{img fileId="1780" thumb="box"}

The index is being rebuilt properly and I don't see any warning there:
{CODE()}2022-03-08T06:27:07+00:00 INFO (6): addDocument trackeritem 5761 {"memoryUsage":"33.4 MiB"}{CODE}

Additional informations:
When I call the value from a different trackers (using a Dynamic Items List) the value displayed for the date is correct:
{img fileId="1781" thumb="box"}

In my smarty template I use dates format:
{CODE()}
<span class="font-weight-bold">{tr}{$days.tracker_field_holidaycampsDayDay|date_format:"%A"}{/tr}</span> <span class="small">{$days.tracker_field_holidaycampsDayDay|date_format:"%d"}/{$days.tracker_field_holidaycampsDayDay|date_format:"%m"}</span>
{CODE}

This was working fine on Tiki23 and is a major regression

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}