admin settings form cannot save updated value when using i18n variables

@yang_yi_cn, this is a very nice simplification, the original logic was a holdover from the 6.x branch. A few tweaks:

+++ google_appliance.helpers.inc	(working copy)
@@ -23,21 +23,14 @@
+ * variable_get() already cached by Drupal and will not use ¶

Just comment on what the function is doing, not what the change is.

+++ google_appliance.helpers.inc	(working copy)
@@ -50,23 +43,21 @@
+  foreach ($field_keys as $field) {  ¶
+    $settings[$field] = variable_get(
+      'google_appliance_' . $field,
+      constant('SGA_DEFAULT_' . strtoupper($field))
+    );
+  }
 
-    // The empty string in the define block above for block visibility 
-    // settings is really just a flag that nothing has been set yet. 
-    // Using an empty string is problematic, so we just set it to an 
-    // empty array instead.
-    if ($settings['block_visibility_settings'] === '') {
-      $settings['block_visibility_settings'] = array();
-    }
+  // The empty string in the define block above for block visibility ¶
+  // settings is really just a flag that nothing has been set yet. ¶

Clean up whitespace errors.

Finally able to work on this. All of the above is great, but it I don't believe it's actually adequate to get it working with Variable / i18n Variable. For that, we'll need to implement hook_variable_info() and a few other bits from Variable API.

Patch forthcoming.

Essentially #1, with minor comment/whitespace fixes with a google_appliance.variable.inc file and Variable API code.

I noticed that this module saves all variables twice: one time prefixed with "google_appliance_" and one time without the prefix. This was probably caused by the custom submit handler in the admin form.
The patch in this issue fixes that too.

I rerolled the patch so it applies to the current dev-version. (so it's basically the same as #4)

I didn't test if this fixes the i18n-variables issue.

I tested the most recent patch to resolve domain access compatibility. I had to re-roll to apply to 7.x-1.13.

After re-rolling the only extra step (likely needs to be added to the above patch) was that I noticed there is no defined constant for the language_filter_options value, and that it is not being loaded in the _google_appliance_get_settings() function (missing from the list of keys.

Without adding the language_filter_options to the list of keys that field will save, but fail to load (appears that you didn't save the settings even when they are saved.

Next time the above patch is re-rolled I recommend:

- Add the constant

define('SGA_DEFAULT_LANGUAGE_FILTER_OPTIONS', '');

- Add language_filter_options to the list of field keys in _google_appliance_get_settings()

- Add the same code as for block visibility to convert the empty string to a null array (as this value is the #options value for a checkboxes form element.

Thanks for the notes, @EveretteZufelt! Here's a re-roll of #5, with edits based on #6, and added hook_variable_info items for variables that have been added in the intervening months.

I'll be reviewing this on a fresh install as well as my own now.

Resolves issues related to the way error messages were being saved.

Moving on to testing i18n with this patch.

i18n integration so far is flawless...

It seems reasonable to assume that someone may want to vary the "restrict searches to specified languages" configuration per language. Adding that in with this patch.

Since this also fixes the double-variable save, we should also add an update hook to clean up the variables table...

Update hook to clean up variables.

Thanks @yang_yi_cn for the report and initial patch, @Daluxz for the re-roll, and @EverettZufelt for the reviews! Your contributions are appreciated. I'm excited to finally get this bug fix / feature out the door.

I've committed #12 to dev, which will be released in the near future.