Configurable form overrides.

Yes I know about this, its a known issue, but its also a won't fix. Sorry, but I am not going to remove the form alter in this theme due to the accessibility enhancements it provides. That is why it is there and we (the accessibility team) spent a lot of time working on this and testing it. I appreciate you cannot use modules that also try to alter the search form, however themes can run alters also :)

What features are these? I'm open to potentially moving these to Search Config.

With the minimal functional benefits it seems like it should be a configurable option to override forms like this. This theme conflicts with at least two modules and likely others. As such, offering a configurable option would be wise.

IE: Do you really want to handle type permissions offered by at least 3 other modules.

$types = array_map('check_plain', node_type_get_names());

Search restrict, search config, domain access, maybe others interact with this.

As such, opening as a feature request for you to reconsider.

$types = array_map('check_plain', node_type_get_names()); is from core, please see function node_form_search_form_alter().

To make accessibility opt "in" is the wrong approach, which is why in core we never did this. What we could do is make it opt "out", the theme has a set of theme settings for modifying output, so we could make a setting that allows you to turn off this alter.

Its been a while since I looked at this particular search module, but from what I can tell (reading the project page), it probably needs to do some stuff in preprocess also? That might also be an issue that needs working around.

Looks like a good opportunity to clean up the search modifications in AT Core, haven't looked at it for a while now.

In response to #3, I need to look, I think there are probably some features that can be removed from the theme, such as being able to control the content of the result snippet, I need to look at Search Config and see if it replicates this, if so, smoke it from the theme, its a minor feature.

The big one IMO is the fieldsets in advanced search form, seems like such a minor feature right? Wrong, its a huge benefit to blind users to have groups of related form items grouped in a fieldset. Sighted users can "see" what is related by the fact they are in a vertical list under a label, but screen reader users have more issues, they need semantics or other embedded labels so they can "hear" the structure - the screen reader will announce it as a fieldset, read the legend as the heading and the user will know the options inside the fieldset are a group of closely related items. This is such a big deal that Drupal 8 is likely to ship with a modification to FAPI that automates this to some degree.

The fieldset is the right element to use here for the criterion wrapper, core incorrectly uses a DIV which has zero semantics for screen readers to hook into:

This is the comment from adaptivetheme_form_search_form_alter():

  // The problem with Drupals standard Advanced search form is that each criterion 
  // group is wrapped in a DIV, whereas it should be a fieldset with a legend, this
  // is better semantics and improves accessibility by logically grouping form items.

I have opened this as a side issue: #1496204: Search result settings not working as expected

OK, looks like its just the form alter than is causing grief here, will put some thought into how we can handle this.

Is it safe to test using Search config dev, from git, or use the current stable version?

I hope I wasn't sounding to abrupt before, rushing around getting ready to go for tea :)

From most users perspective, simple theme configuration options that are enable by default would be enough to allow them to disable the form alters without having to manually edit the base theme, which allows users to extend and update without complications.

Something as simple as:

settings[search_form_alter] = 1

# adaptivetheme_form_system_theme_settings_alter()
  // Search Settings
  $form['at']['search-form'] = array(
    '#type' => 'fieldset',
    '#weight' => '97',
    '#title' => t('Search Form'),
  );
  $form['at']['search-form']['search_form_alter'] = array(
    '#type' => 'checkbox',
    '#title' => t('Override Advanced Search Form'),
    '#default_value' => theme_get_setting('search_form_alter'),
  );

// hook_form_FORM_ID_alter().
function adaptivetheme_form_search_form_alter(&$form, $form_state) {
  if (isset($form['module']) && $form['module']['#value'] == 'node' && user_access('use advanced search') && theme_get_setting('search_form_alter')) {
  .....
  }
}

In relation to the fieldsets and the complexity of the form. One of the main use of search config is to increase / reduce the form elements. I end up with just 2 input and 1 set of checkboxes that are reduced down to a minimal set of content type groups. Even on a current project with 40+ content types, we have managed to reduce these to just 8 checkbox groups and makes the search so much easier. E.g. All blogs (4 types), News and Events (7 types), ..., All other pages (about 9 misc types including basic pages, panel pages, etc) A picture says a thousand words, 5 minutes in the admin section gave me the following:

Config overview:
Merged basic & advanced search forms
Label overrides
Hide some fields
Merged and grouped the content types
Hard restriction of some content types (via permissions)
Granted permissions for all users to access search and advanced search (via permissions)

I'm just about to get some free time and was going to look at extending this to the results and (maybe) the user search form too. At the moment, the role of the module in relation to the results is limited to just altering the number of items returned.

So after selling the module, if you want to abstract and add these search features at a module level, I am more than willing to give you co-contributor access.

Is the dev version of Search config useable? I am using it (just checked it from GIT) and some of the settings are not working (using Bartik), should I use the current stable 7.x-1.0?

Adding a theme setting is easy and would do the trick, even throw a warning message from the theme if someone installs search config telling them to disabled or. possibly even an automagical if (module_exists('search_config')), could do that also.

Custom search and search restrict both play with the search form too, so providing module specific warnings could be an ongoing task.

Regards to sc: the user 1 gets overrides by default, bypassing the settings. Strange feature from D6 version that I carried over.

ah, I see, regarding the user 1 thing, yeah, that is an odd feature. Agree totally about the ongoing maintenance issue, its the main strike against it.

I did remove the alter be default and made it a setting, after much thought the support and issue request overhead outweigh the benefits I think, and its still there if you need it, under Extensions > Modify Output > Accessibility