Project

General

Profile

Actions

Bug #79389

closed

Indexed Search cHash error on plugin rendering

Added by David C. almost 8 years ago. Updated over 4 years ago.

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

0%

Estimated time:
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


Files

Actions #1

Updated by Angelo Previtali almost 8 years ago

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

Actions #2

Updated by Michel Rossier over 7 years ago

I have the exact same issue on TYPO3 8.6

Actions #4

Updated by Riccardo De Contardi over 7 years ago

  • Category set to Indexed Search
Actions #5

Updated by Sven Teuber almost 7 years ago

TYPO3 8.7.9, composer install - same problem

Actions #6

Updated by Sven Teuber almost 7 years ago

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

Actions #7

Updated by Sven Teuber almost 7 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.

Actions #8

Updated by Benni Mack over 4 years ago

  • Status changed from New to Closed

Will close this issue. TYPO3 v9 and site handling solves the cHash issues completely IMHO. Can you rechek? If you see that there are still issues, let me know, so I can re-open the issue.

Actions

Also available in: Atom PDF