TYPO3 Core

1) I have a similar problem with tt_news. Because of "extralarge" encryptionkey the chash does not always fit in TABLE: index_phash -> FIELD -> cHashParams which is normally a TINYBLOB (max 255 chars).

I changed it to MEDIUMBLOB ...

2) to provide the pathlink also with params, find this line (1400 in .../pi/class.tx_indexedsearch.php) in function makeINfo($row):

$out.="<BR>".$this->pi_getLL("res_path")." ".$this->linkPage($pathId,htmlspecialchars($this->getPathFromPageId($pathId,$pathMP)));

and change it to:

$out.="<BR>".$this->pi_getLL("res_path")." ".$this->linkPage($pathId,htmlspecialchars($this->getPathFromPageId($pathId,$pathMP)),$row);

This problem is still here in Typo3 4.01 and the indexed search version that comes with it.

I'm having same problem - seems that sometimes data doesn't fit into cHashParams database field - so some news item links doesn't contain required parameters on indexed search result page.

Same was reported in Bug
http://bugs.typo3.org/view.php?id=3696

Can someone fix this!

The path link also lacks the ability to add the search words, neither when forwardSearchWordsInResultLink is set.

Hi,

I'm using 4.0.2 with realurl and also had the problem with tt_news. The link on the title worked but not the link on the path.

I changed the function makeInfo and now it seems to work:

} else {
                        $pathStr = htmlspecialchars($this->getPathFromPageId($pathId,$pathMP));
/* add this code /
                        $copy_row = $row;
                        $copy_row['data_page_mp'] = $pathMP;
                                                $tmplArray['path'] = $this->linkPage($pathId,$pathStr,$copy_row);
/ end /                                                
/ comment out the original code 
                          $tmplArray['path'] = $this->linkPagE($pathId,$pathStr,array(
                                'data_page_type' => $row['data_page_type'],
                                'data_page_mp' => $pathMP,
                                'sys_language_uid' => $row['sys_language_uid'],
                        ));
end */
                            }

hi there any news on this one?

The attached patch (bug_1235.diff) was made against TYPO3 4.1.6, please confirm if it fixes your problem.

Seems that attached patch (bug_1235.diff) was made against 4.1.2, not 4.1.6.
However - worked with 4.1.6 and indexed_search 2.10.0: Search results of tt_news (2.5.0) articles link after patching to correct singleview, parameters are set correctly.

typo3 vers. 4.2.0, indexed_search 2.11.0
The patch worked to remove strange "?0="-Parameters, reported in http://bugs.typo3.org/view.php?id=2376.

But this problem remains:
$row['cHashParams'] is not passed over from
function makeInfo
to
function linkPage

function makeInfo reduces the $row array only to tree parts.
I think, the solution of Christian Ehret does the job well, because it adds $pathMP to the row array and $row['cHashParams'] remains.

bug_1235.diff contains a small, but important glitch:

+ 'cHashParams' => count($this->cHashParams) ? serialize($this->cHashParams) : '',

cHashParams is later deserialized in class.tx_indexedsearch_modfunc1.php and if no cHashParams are stored, the default '' cannot be properly deserialized and the following fatal error pops up:

[05-Jun-2008 15:24:38] PHP Catchable fatal error: Argument 2 passed to t3lib_div::implodeArrayForUrl() must be an array, boolean given, called in .../typo3_src-4.2.0/typo3/sysext/indexed_search/modfunc1/class.tx_indexedsearch_modfunc1.php on line 452 and defined in .../typo3_src-4.2.0/t3lib/class.t3lib_div.php on line 1635

So one would have to fix either side - i.e. serialize cHashParams, whatever it is (null -> N; '' -> s:0:"";) or do better checking in the backend module.

Attached diff does not include Christian Ehrets patch.
Work with both patches with version 4.2.2-dev from svn

In Typo3 4.2.2 this bug still persists.
But unfortunately the patch above can not be applied. Some functions obvioulsy are now on different places.
Hope this bug is fixed soon. Is there a working patch now?

I solved the problem in indexed_search in version 2.11.0 with the patch from http://bugs.typo3.org/view.php?id=2376
There are other line numbers in 2.11.0, but adding the relevant line manually works.

I would like to confirm by a notice in http://bugs.typo3.org/view.php?id=2376 - as Michael wants us to - but I can't add a notice there.

I would like to confim http://bugs.typo3.org/view.php?id=2376, too. I'm wondering that the bugfix is still in the 4.2.6 core!?

is it possible to get a solution for this problem into the Core ?
with the new Version TYPO3 4.3 the bug is still there.

for an example of this bug, you can use the search of typo3.org, type in 'Documentation'

and look at the produced links
http://typo3.org/documentation/document-library/extension-manuals/?0=&no_cache=1&sword_list%5B0%5D=documentation

there you can find the ?0=

or use other TYPO3 Pages:

http://www.fc-koeln.de/
...index.php?id=1109&0=

http://www.olympiapark.de/
...index.php?id=679&L=0&0=

http://www.bayertechnology.cn/
.../index.php?id=401&L=0&0=

this bugfix works very well :
http://bugs.typo3.org/view.php?id=2376

Should we set up a Top-10 list of immortal TYPO3 bugs?!
Considering the number of installations affected and the age of 5 (five!) years, #1235 would most likely have a top ranking...

I advertise 50 EUR for a solution that makes it into core. Not much - I know - but maybe YOU want to join me and add on top of it. ;o)

Oh yes, and here is a quick workaround that simply hides the path output by CSS settings:

.tx-indexedsearch-info BR{
display: none;
}
.tx-indexedsearch-path{
display: none;
}

There is a remaining empty "Path:" at the end of each status line, which can not easily be catched by CSS rules, but IMHO it is not too disturbing.

I just hat a short look ...could anyone try the 4.4 patch and report if it works? If so i would post it to the core list.

I tested the 4.4 patch on a 4.2.12 and on a 4.3.2 system and it works lovely. My test contained pages with extension query strings. I did not test any more complex scenarios like mount points or indexed files.

Question:
So far I have always seen the Path to link to the same target as the page link itself. So what is it good for? I understand the advantage of showing the path, but why should it be linked? Having two links in each search result IMHO suggests that they are there for a reason and link to different content.
Or could it be that the Path becomes different, when files or external media are indexed?

Jörg: ok great that it works.

Regarding the question: To be honest, i don't know ...
I'll post the patch to the core list and we will see ;)

Pending in core list.

I have a feeling somebody will cash some bounty soon... :o)

Committed to 4.3, 4.4 and 4.5. Revisions 8161, 8162 and 8163.