Bug #14838

Indexed search results: Link in "path" section does not include extension variables

Added by Steven Bagshaw about 15 years ago. Updated almost 2 years ago.

Status:
Closed
Priority:
Should have
Category:
Indexed Search
Target version:
-
Start date:
2005-06-23
Due date:
% Done:

0%

TYPO3 Version:
PHP Version:
Tags:
Complexity:
Is Regression:
Sprint Focus:

Description

Search results page for indexed search features two links per page returned - one is the title of the page, the other is the path.

The path link is not the same as the one for the title. Specifically, it lacks cHash and extension variable information.

Also, if the user clicks on the path link, it then re-indexes the page without the extension variable info and I lose the extension variables and cHash for the title link for future searches as well.

An example, my title link

http://mysite.com/cms/index.php?id=468&L=0&L=0&myextension[CL]=30&cHash=7e2e0ed250

My path link

http://mysite.com/cms/index.php?id=468&L=0&0=

Using Typo3 3.8, indexed search in sysext, version 2.1.3

(issue imported from #M1235)

bug_1235.diff View (2.01 KB) Administrator Admin, 2008-03-24 14:53

bug_1234_typo3_4_4.patch View (645 Bytes) Administrator Admin, 2010-07-08 18:15


Related issues

Related to TYPO3 Core - Bug #17419: Field index_phash.cHashParams is too short Closed 2007-06-26
Related to TYPO3 Core - Bug #16256: typo3 reset() [function.reset]: .... Passed variable is not an array or object index.php on line 434 ... Closed 2006-06-19
Duplicated by TYPO3 Core - Bug #15498: Strange generated link in indexed_search Closed 2006-01-24

History

#1 Updated by old_hardcoder almost 15 years ago

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

#2 Updated by Steven Bagshaw almost 14 years ago

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

#3 Updated by Andres Toomsalu almost 14 years ago

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.

#4 Updated by Dietrich Heise almost 14 years ago

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

Can someone fix this!

#5 Updated by Christoph Köpernick almost 14 years ago

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

#6 Updated by Christian Ehret almost 14 years ago

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 */
}

#7 Updated by Nikolas Hagelstein almost 13 years ago

hi there any news on this one?

#8 Updated by Michael Stucki over 12 years ago

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

#9 Updated by Florian Busch (floxx) about 12 years ago

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.

#10 Updated by Ulrich Fischer about 12 years ago

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.

#11 Updated by Thomas Keller about 12 years ago

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.

#12 Updated by Alexander Reinhard almost 12 years ago

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

#13 Updated by Ronald Steiner over 11 years ago

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?

#14 Updated by Albrecht Köhnlein over 11 years ago

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.

#15 Updated by Christian Ehret over 11 years ago

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!?

#16 Updated by Sven Juergens over 10 years ago

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

#17 Updated by Jörg Wagner about 10 years ago

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)

#18 Updated by Jörg Wagner about 10 years ago

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.

#19 Updated by Nikolas Hagelstein about 10 years ago

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.

#20 Updated by Jörg Wagner about 10 years ago

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?

#21 Updated by Nikolas Hagelstein about 10 years ago

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

#22 Updated by Nikolas Hagelstein about 10 years ago

Pending in core list.

#23 Updated by Jörg Wagner about 10 years ago

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

#24 Updated by Dmitry Dulepov about 10 years ago

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

#25 Updated by Benni Mack almost 2 years ago

  • Status changed from Resolved to Closed

Also available in: Atom PDF