I was running across a problem where users complained that when hitting submit on an empty search form, they would be directed to a random page with an error message at the top. The expected behavior is that they would stay on the current page, but get the error message.
In doing some digging, I believe the issue is due to the cache settings in the search block definition. DRUPAL_CACHE_PER_USER would store the form action in that block to whatever page that user hit first. In some cases, that would be the homepage, but not always.
Changing the cache settings to DRUPAL_CACHE_PER_PAGE appears to result in the expected behavior I described.
Patch attached!
| Comment | File | Size | Author |
|---|---|---|---|
| #1 | 2345601-search_api_page-block-caching-unexpected-redirects-1.patch | 519 bytes | sjancich |
Comments
Comment #1
sjancich commentedComment #2
sjancich commentedComment #3
drunken monkeyAh, darn, didn't think of that. Thanks for creating this issue! You are right, we need to cache the block per page in this case.
However, we cannot just remove the
DRUPAL_CACHE_PER_USERflag, the correct solution would be a bitwise OR of the two.On the other hand, I don't really know why the block would vary by user – by role, yes, because of the permissions, but not by user.
On the other other hand (I have three, apparently) it seems we don't check access when displaying the block anyways – which seems pretty stupid to me, displaying a search block for a search you cannot access doesn't seem like a viable use case to me.
Anyways, all in all, let's just create a new issue for the block access check (#2358735: Add access check when viewing the search block) and commit your patch for now. I don't really see any way in which the block could currently depend on the user, so I think it should be OK.
Long story short: committed. Thanks again!