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!

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

annikaC’s picture

Version: 7.x-1.x-dev » 7.x-1.9
Status: Postponed (maintainer needs more info) » Active
jdanthinne’s picture

Version: 7.x-1.9 » 7.x-1.x-dev
Status: Active » Postponed (maintainer needs more info)

Can you try with the latest dev and tell me if this bug is still there? I can't reproduce this.

czigor’s picture

Status: Postponed (maintainer needs more info) » Active

Same issue here with 7.x-1.10.

hawkdrupal’s picture

My 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.

jdanthinne’s picture

Do you have a test url where I can see that?
Can you reproduce that bug with the default theme (Garland)?

hawkdrupal’s picture

ZEN: 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.

jdanthinne’s picture

@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…

hawkdrupal’s picture

Wow! 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?

jdanthinne’s picture

I'm not using Zen at all (I'm an Omega fan), but I think it's still better than Garland…

squeakyferret_sf’s picture

Still 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.

jdanthinne’s picture

Status: Active » Postponed (maintainer needs more info)

Sorry, 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.

pglynn’s picture

Version: 7.x-1.9 » 7.x-1.x-dev
Status: Active » Postponed (maintainer needs more info)

I'm experiencing this as well with the following settings:

  • Unchecked the boxes under custom search results page to NOT show the basic or advanced search forms

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

jdanthinne’s picture

@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?

BraveKenny’s picture

I 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:

if (isset($form['module']) && $form['module']['#value'] == 'node' && isset($form['advanced']))

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:

elseif (isset($form['module']) && $form['module']['#value'] == 'node') {
        if (!variable_get('custom_search_results_search', TRUE)) {
          $form['basic']['#prefix'] = '<div class="element-invisible">';
          $form['basic']['#suffix'] = '</div>';
        }        
      }

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):

body > .search-form {
	    clip: rect(1px, 1px, 1px, 1px);
    height: 1px;
    overflow: hidden;
    position: absolute !important;
}

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.

jdanthinne’s picture

Still 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?

pakmanlh’s picture

Issue summary: View changes
Status: Postponed (maintainer needs more info) » Needs review
FileSize
561 bytes

I 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!

jdanthinne’s picture

I'm ready to commit the fix as soon as some user confirm it's ok.

hoegrammer’s picture

I'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.

hoegrammer’s picture

Looks 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.

jdanthinne’s picture

Status: Needs review » Fixed

  • jdanthinne committed 0d00d47 on 7.x-1.x
    [#1567340] fixed by hoegrammer: test for hiding the basic search form...

  • jdanthinne committed 1ddf4bb on 8.x-1.x
    [#1567340] fixed by hoegrammer: test for hiding the basic search form...

Status: Fixed » Closed (fixed)

Automatically closed - issue fixed for 2 weeks with no activity.