Bug #79389

Indexed Search cHash error on plugin rendering

Added by David C. almost 3 years ago. Updated almost 2 years ago.

Status:
New
Priority:
Must have
Assignee:
-
Category:
Indexed Search
Target version:
-
Start date:
2017-01-19
Due date:
% Done:

0%

TYPO3 Version:
8
PHP Version:
7.0
Tags:
indexed_search
Complexity:
Is Regression:
No
Sprint Focus:

Description

When requesting a page with the indexed_search plugin placed as content element, 303 redirect to error page as defined in localconf occurs, but only if tx_indexedsearch_pi2[controller] and tx_indexedsearch_pi2[action] are defined as GET vars.

If plugin string is misspelled in GET vars, no redirect happens, but search results obviously wont work.

This has been tested and confirmed on a clean composer installation of TYPO3 8.5.1, so it's definitely a core Problem.

Tracked the error back to somewhere within the cObjGetSingle() function of \TYPO3\CMS\Frontend\ContentObject\ContentObjectRenderer\

When disabling pageNotFoundOnCHashError in install tool configuration, search works fine.

Might also be related to #79108

Captura de pantalla 2017-03-06 a las 19.31.58.png View (49.2 KB) Fernando Arconada, 2017-03-06 20:01

History

#1 Updated by Angelo Previtali almost 3 years ago

I got the same problem, too. T3 version 8.5.1 and PHP 7.0

#2 Updated by Michel Rossier over 2 years ago

I have the exact same issue on TYPO3 8.6

#3 Updated by Fernando Arconada over 2 years ago

TYPO3 8.6.1 php 7.0.x and same problem here

#4 Updated by Riccardo De Contardi over 2 years ago

  • Category set to Indexed Search

#5 Updated by Sven Teuber almost 2 years ago

TYPO3 8.7.9, composer install - same problem

#6 Updated by Sven Teuber almost 2 years ago

Bug vanishes when RealURL is uninstalled - so it's not a core error (alone), but related to RealURL somehow

#7 Updated by Sven Teuber almost 2 years ago

Further investigation revealed that the action-attribute of the search form was missing the page path.
The action should have been:
action="/my/searchpage/?tx_indexed..."

but instead was
action="?tx_indexed..."

With the page UID missing, the cHash calculation went wrong.

The cause of this was a misconfigured RealURL with duplicate path entries in the realurl cache.

I was able to fix it on my installation by doing the following:

- Make sure your realurl_conf.php is working and fitting the installed version of RealURL!
Mine wasn't and RealURL was unable to generate new speaking paths, which I didn't notice because the URL Cache was primed/pre-filled from an earlier version and thus most URLs seemed to be correct. You can easily check by renaming/removing realurl_conf.php temporarily

- Make sure each cached path is unique, especially on your search page!
RealURL will give red error messages in its backend module if the path is cached in more than one instance.
If that happens, clear the wrong cache entries.

So, clearing all realurl tables (!), removing an apparently faulty realurl_conf.php and re-building the realurl cache afterwards fixed the issue for me.

Conclusion: Not a general error in the core or in realurl, but caused by an individual misconfiguration on my server.

Also available in: Atom PDF