Exclude common page elements from index

Interesting. I think that using the googleon/googleoff tags is content and theme specific. If you put those tags into such places, then the hidden-from-search content won't be indexed, nor will it be found. IMO, controlling what ends up in the index should be handled at the content level. Perhaps you can convince otherwise? Perhaps others have an opinion as well?

Ah, i see. I'll leave this request open and see if we get any input. Thanks for contributing your ideas.

Soliciting opinions on this one.

The Drupal 6 version of this module attempted to handle this to some extent by throwing an extra field on block edit forms (via form alter) that served as a flag. The implementation was pretty severely flawed, but the intention was to wrap the block content with the googleon/off tags based on the flag via a block preprocess.

See #1430656: Hiding blocks from GSA crawler has no effect

I suppose the same concept could be extended to cover fields/entities/menus/taxonomies as well. An improvement would be support for any combination of tags (index/anchor/snippet/all).

The question would be, do we want this module to try and cover all use cases, most normal use cases, or do we leave it as the responsibility of the user?

This isn't critical for me, but I'd be willing to help put this together.

I like to keep the things that apply to all use cases in the module, as we only cover the bases that are necessary for anyone to use the module. Extension is normally what I would do to cover corner cases. Feel free to put a patch together...

Adds some complexity, but the interface is pretty clean and the data storage is pretty clean too. Patch attached.

Interface Changes (Block Configuration Form)

@iamEAP, are the choices in the form mutually exclusive, i.e. would checking "disssociate anchor text" AND "exclude block contents from snippets" be a valid use case if there were checkboxes? Does it make more sense to use check boxes to progressively exclude content? Like so:

Google Appliance Crawler Visibility
[ ] Dissasociate anchor text from target pages within this block
[ ] Exclude block contets from search snippets
[ ] exlude block contents from index

Unfortunately, I was unable to find any documentation regarding the use of multiple tags around the same content. I can certainly see the use cases (and I like your order better), but I'm just not certain it's supported.

@iamEAP, getting closer on this one. If i apply the patch and try to change the setting for any given block, i get "Cannot use string offset as an array in /Users/eric/mamp-localhost/d7-sandbox/sites/all/modules/contrib/google_appliance/google_appliance.module on line 286". Something is fishy with accessing the settings['block_visibilty_settings'] array.

Ah. The last patch attempted to store the block visibility settings as a serialized string because of the way the module's variable defaults are set up (in PHP, constants must be scaler), and it was missing an unserialize in the settings getter. On second thought, I'm not a big fan of storing all of those settings as a serialized string.

Here's more or less the same patch, that instead relies on PHP's dynamic typing to allow the default to be an empty string, but turn it into an empty array wherever necessary.

Note also that I'm moving the trim() that used to wrap all of the variable_get calls in the settings getter to the settings submit handler (because you can't call trim() on an array). There's a slim possibility this could break some sites because their GSA host had a trailing space. If we end up going with this, it may be worth adding an update function that trim()s all of the relevant variables with a note in the release notes.

Yes, this one works much better. Just a few minor notes:

+++ b/google_appliance.moduleundefined
@@ -218,6 +218,130 @@ function google_appliance_block_form_submit($form, &$form_state) {
+        '<p>' . t('For more information, see') . ' ' . l($read_more_link . '#pagepart', $read_more_link, array(

Can the link text/label be a few linked words instead of a full URL?

+++ b/google_appliance.admin.incundefined
@@ -177,4 +177,4 @@ function google_appliance_admin_settings_submit($form, &$form_state) {
\ No newline at end of file

Add the newline.

+++ b/google_appliance.helpers.incundefined
@@ -139,4 +142,28 @@ function _google_appliance_log_search_error($search_keys = NULL, $error_string =
\ No newline at end of file

Add the newline

+++ b/google_appliance.moduleundefined
@@ -218,6 +218,130 @@ function google_appliance_block_form_submit($form, &$form_state) {
+  $read_more_link = 'https://developers.google.com/search-appliance/documentation/50/admin_crawl/Preparing';
...
+ * @see https://developers.google.com/search-appliance/documentation/50/admin_crawl/Preparing#pagepart

Does it make any sense to point to the most-recent version of the docs here? https://developers.google.com/search-appliance/documentation/64/admin_cr...

I was just getting ready to tag out a stable release, so if we can get this one in soon, that'd be groovy.

Oops, missed coding standards. Here's another small edit:

+++ b/google_appliance.moduleundefined
@@ -218,6 +218,130 @@ function google_appliance_block_form_submit($form, &$form_state) {
+          'fragment' => 'pagepart', 'attributes' => array('target' => '_blank',)

Stray comma here.

Got rid of stray comma, using "Google Search Appliance documentation" instead of the full link as link text, and linking to the most recent documentation. Those newline warnings are due to the diff: the old ones didn't have them; the new ones do.

Looking forward to the new release.

@iamEAP, I always wondered why the huzzah those newlines came through on all my patches... thanks for the tip. Anyways, looks good, and committed to dev: http://drupalcode.org/project/google_appliance.git/commit/64e007a. Stable release shortly.

Fixed. See 7.x-1.7.