Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.
Hi
Very handy module :)
In the results page settings, I have unticked 'Display basic search'. This works fine for logged-in users, but anonymous visitors still see the 'enter your keywords' search field on the results page.
In permissions, all user roles are set to use custom search... including anonymous.
Thanks!
Comments
Comment #1
annikaC CreditAttribution: annikaC commentedComment #2
jdanthinne CreditAttribution: jdanthinne commentedCan you try with the latest dev and tell me if this bug is still there? I can't reproduce this.
Comment #3
czigor CreditAttribution: czigor commentedSame issue here with 7.x-1.10.
Comment #4
hawkdrupal CreditAttribution: hawkdrupal commentedMy version of this is that the Search block (which is intentionally on every page) is DEAD (not recognized as a live form) for Anonymous users, but works fine for logged-in users. ALL users have permission to use it, so why is this happening?
By DEAD I mean, to an Anonymous user, the search block looks normal -- field and button -- but neither is recognized by the mouse, and can't be tabbed to. They just seem to be basic text. The block looks identical to a logged-in user, except it's ALIVE.
Comment #5
jdanthinne CreditAttribution: jdanthinne commentedDo you have a test url where I can see that?
Can you reproduce that bug with the default theme (Garland)?
Comment #6
hawkdrupal CreditAttribution: hawkdrupal commentedZEN: The problem of Search block visible but non-functional happens to anonymous users on all our pages when they use Zen. You can see/test at our primary public site, http://www.advisor.com. To verify that it works once you are logged-in, you can register for an account; respond to the confirmation email and you'll have immediate access.
GARLAND: To test we temporarily set one of our lesser domains to Garland -- and the problem does NOT happen. You can see this at http://transportation.advisor.com. (Note that this site looks poor because we have not attempted to style Garland as we have Zen.)
While we could suspect Zen in general or even our CSS customization of Zen, why would the Search form behavior vary with user login/role? We do not have any conditions applied to the Search Form block.
This re-raises the debate about whether it's worth the (endless) trouble to use a theme other than Garland.
Comment #7
jdanthinne CreditAttribution: jdanthinne commented@hawkdrupal : I've just checked you main site http://www.advisor.com and this bug has nothing to do with any module, but with CSS styling.
You have a #navigation div, positioned absolutely, and taking 100% of the width, so it's overlapping the search block…
Comment #8
hawkdrupal CreditAttribution: hawkdrupal commentedWow! Thank you for discovering the real problem with my Search form block. I had no idea it could be CSS, since it only affected Anonymous visitors.
(Now I'm guessing that a signed-in user caused a change in the login block in the left sidebar which had a side effect of slightly moving the navigation bar so it stopped blocking the Search form in the right sidebar.)
The mysterious width:100% setting was coming from a "hidden" Zen file called responsive-sidebars.css which is NOT in the main Zen CSS folder and apparently loads based on circumstances. I fixed the problem by adding #navigation width:auto to Zen's pages.css.
I'm still wondering whether Zen is worth the trouble. Should we really be customizing Garland?
Comment #9
jdanthinne CreditAttribution: jdanthinne commentedI'm not using Zen at all (I'm an Omega fan), but I think it's still better than Garland…
Comment #10
squeakyferret_sf CreditAttribution: squeakyferret_sf commentedStill have this problem on 7.x-1.11. Disabling search form on results page only works for logged-in users. Anonymous users still see the form.
Comment #11
jdanthinne CreditAttribution: jdanthinne commentedSorry, but I can't reproduce this bug.
I'm using a fresh Drupal 7.18 and Custom Search 7.x-dev, and anonymous doesn't see the form anymore.
Can you tell me how permissions are configured (for Custom Search), and how Custom Search / Results page is configured as well.
Access to the admin of your site could help.
Comment #12
pglynn CreditAttribution: pglynn commentedI'm experiencing this as well with the following settings:
But unfortunately I'm still seeing the form when anonymous. I can still see the form in the HTML, but when logged in the form elements are wrapped in an additional div.element-invisible and not when anonymous users visit so this isn't a CSS issue. By checking those boxes, does custom_search not unset the search form altogether?
Module v. 7.x-1.11
Core 7.19
Comment #13
jdanthinne CreditAttribution: jdanthinne commented@pglynn : I've just tested on a clean install (Core 7.22, Custom Search 7.12), and everything seems ok.
Can you send me a test url?
Comment #14
BraveKenny CreditAttribution: BraveKenny commentedI am having the same issue with Core 7.22 and Custom Search 7.x.1.12. Anonymous users still see the form on the results page (and can use it) despite the checkbox being unchecked in the results tab. I did add permission for anonymous users to "use custom search".
Admin, on the other hand, does not see the search form on the results page anymore.
Sadly, I cannot undisclose this website, so I cannot share any information on the sources or anything else...
UPDATE: just tried using the dev version of Custom Search, same problem. Hidden for admin, but not for anonymous
---------------- ONGOING DEBUG... ----------------
So apparently, on anonymous, the following statement (within custom_search.module) resolves to false:
because $form['advanced'] is NULL on anonymous, whereas it contains a big array on logged user. Therefore, the statement that is supposed to hide the basic search never gets hit on anonymous.
---------------- TEMPORARY FIX -------------------
So I resigned myself to add this piece of code at the end of the first if scope in custom_search.module:
That fixed it, but then I realized that it still left some rectagular space messed up by my css (because of the form element still being there and not hidden), which I had not seen in admin because there are already some ugly tabs (for content and users).
-------------- DIRTY PERSONNAL FIX ---------------
So I decided to just fix the issue by using a quick'n'dirty css statement in my style (inspired/stolen from the "element-invisible" class):
And then I just undid the changes I had made to the module file. Ugly, but effective! But I admit this does not solve the actual issue from the custom search module.
Comment #15
jdanthinne CreditAttribution: jdanthinne commentedStill unable to reproduce this bug…
Can you tell me the exact permissions you have given for each role, for both Custom Search module and core Search module, and the exact settings for the Custom Search Results page?
Comment #16
pakmanlhI have the same issue with 7.26 core version and 1.13 version of this module, the anonymous users could see the basic search box on search results page.
I have applied permissions to all users could to use custom search and still fails.
I attached a patch using the solution of #14 that works and solve the problem.
Thanks @BraveKenny for your contribution!
Comment #17
jdanthinne CreditAttribution: jdanthinne commentedI'm ready to commit the fix as soon as some user confirm it's ok.
Comment #18
hoegrammer CreditAttribution: hoegrammer commentedI'm still getting this issue in 7.x-1.x-dev.
My debugging suggests that the check for
isset($form['advanced'])
is returning false for anonymous users.Comment #19
hoegrammer CreditAttribution: hoegrammer commentedLooks like the code for hiding the "basic" form needs to be outside of the check for whether "advanced" is set. Here is a patch to fix this.
Comment #20
jdanthinne CreditAttribution: jdanthinne commented