Bug #14838
closedIndexed search results: Link in "path" section does not include extension variables
Added by Steven Bagshaw about 19 years ago. Updated almost 6 years ago.
0%
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)
Files
bug_1235.diff (2.01 KB) bug_1235.diff | Administrator Admin, 2008-03-24 14:53 | ||
bug_1234_typo3_4_4.patch (645 Bytes) bug_1234_typo3_4_4.patch | Administrator Admin, 2010-07-08 18:15 |
Updated by old_hardcoder about 19 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);
Updated by Steven Bagshaw about 18 years ago
This problem is still here in Typo3 4.01 and the indexed search version that comes with it.
Updated by Andres Toomsalu almost 18 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.
Updated by Dietrich Heise almost 18 years ago
Same was reported in Bug
http://bugs.typo3.org/view.php?id=3696
Can someone fix this!
Updated by Christoph Köpernick almost 18 years ago
The path link also lacks the ability to add the search words, neither when forwardSearchWordsInResultLink is set.
Updated by Christian Ehret almost 18 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 */
}
Updated by Nikolas Hagelstein almost 17 years ago
hi there any news on this one?
Updated by Michael Stucki over 16 years ago
The attached patch (bug_1235.diff) was made against TYPO3 4.1.6, please confirm if it fixes your problem.
Updated by Florian Busch (floxx) over 16 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.
Updated by Ulrich Fischer about 16 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.
Updated by Thomas Keller about 16 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.
Updated by Alexander Reinhard almost 16 years ago
Attached diff does not include Christian Ehrets patch.
Work with both patches with version 4.2.2-dev from svn
Updated by Ronald Steiner almost 16 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?
Updated by Albrecht Köhnlein over 15 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.
Updated by Christian Ehret over 15 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!?
Updated by Sven Juergens over 14 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
Updated by Jörg Wagner about 14 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)
Updated by Jörg Wagner about 14 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.
Updated by Nikolas Hagelstein about 14 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.
Updated by Jörg Wagner about 14 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?
Updated by Nikolas Hagelstein about 14 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 ;)
Updated by Jörg Wagner about 14 years ago
I have a feeling somebody will cash some bounty soon... :o)
Updated by Dmitry Dulepov about 14 years ago
Committed to 4.3, 4.4 and 4.5. Revisions 8161, 8162 and 8163.
Updated by Benni Mack almost 6 years ago
- Status changed from Resolved to Closed