The code

        if ($recaptcha_ajax_api) {
          // By default CAPTCHA turns off page caching on
          // any page where a CAPTCHA challenge appears.
          // If recaptcha is using AJAX API, set caching
          // back to it's old state as stored in DB.
          global $conf;
          $cache = variable_get('cache', FALSE);
          $conf['cache'] = $cache;
        }

won't reset $conf['cache'] to what is inside the DB as variable_get() uses the global $conf as well. So this will stay FALSE as set by the captcha module even if ajax is used as you write the same value to the variable as it was before.

function variable_get($name, $default = NULL) {
  global $conf;

  return isset($conf[$name]) ? $conf[$name] : $default;
}

Currently I don't have any idea how we can easily get the original value back except for a custom query. I will so a patch asap if I get a good idea to what to do here.

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

Kars-T’s picture

Status: Active » Needs review
FileSize
597 bytes

The only way I found was using a direct query. I kept it as small as possible. But this makes sure we get the setting from the database.

Liam Morland’s picture

Why WHERE name LIKE 'cache' instead of WHERE name = 'cache'?

Kars-T’s picture

We are looking for a string and so I am "used" to use LIKE.

http://dev.mysql.com/doc/refman/5.1/en/string-comparison-functions.html

Per the SQL standard, LIKE performs matching on a per-character basis, thus it can produce results different from the = comparison operator:

As we use a fixed value here that does not demand LIKE we can use = as well and it might be faster by some ms. So choose what you LIKE ;)

Should I reroll the patch to = than?

Liam Morland’s picture

Please do. Thanks.

Kars-T’s picture

FileSize
594 bytes

New patch version with "="

Liam Morland’s picture

Version: 7.x-1.x-dev » 6.x-1.x-dev
Status: Needs review » Patch (to be ported)
FileSize
1.37 KB

Fixed in 94ede9404f8e60a561d8c990e64d9b054b47276f. Patch as-committed attached.

  • Liam Morland committed 94ede94 on 7.x-1.x, 7.x-2.x
    Issue #1759334 by Kars-T: Reset $conf['cache'] to database value.
    

  • Liam Morland committed 94ede94 on 8.x-2.x
    Issue #1759334 by Kars-T: Reset $conf['cache'] to database value.
    

  • Liam Morland committed 94ede94 on 6.x-2.x
    Issue #1759334 by Kars-T: Reset $conf['cache'] to database value.
    
hass’s picture

Issue summary: View changes
Status: Patch (to be ported) » Fixed

  • hass committed 071f79c on 6.x-1.x
    Issue #1759334 by hass: $conf['cache'] is not reset to database values.
    

Status: Fixed » Closed (fixed)

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