Document variables that are used before hook_init()

I am sure I will find more, but at a quick glance I could not seem to proceed without errors in common.inc with "theme_default" variable in the strongarm group.

I would also like to point out that many modules are defining constants that receive variable_get() values within the vody of the main module file. (eg: define('LDAPAUTH_LOGIN_CONFLICT', variable_get('ldapauth_login_conflict', LDAPAUTH_CONFLICT_LOG)); within ldapauth.module)
The module files are included before calling the init() hook thus the module defined constants end up with some default values instead of the strongarm'ed version of the variable.

For modules that do that, just file a bug against it. Constant is something that's unchanging, but variables can change.

Here are the variables: cache_inc, page_cache_fastpath, lock_inc, reverse_proxy, dev_query, session_inc, cache_flush_cache, cache, language_count, language_default, and site_frontpage

though, site_frontpage has a little hack.

Is the site_frontpage hack a good way to workaround this issue? It forces the re-execution of custom_url_rewrite_inbound which I'm not willing to do (too expensive). In our case Drupal is integrated into a larger site that includes other tools (moodle for one) and I use custom_url_rewrite_inbound to tie the systems together. There are easy ways to prevent going back through the path init process, but this seems like a larger question to be considered in any work to address the early variables issue.

language_negotiation is one too, but calling drupal_init_language should reset the language variable. Testing it out to see if has any side effects, I suspect it may be too late for some things though.

Quickie not much tested patch, I still suspect it's too late to effect some things.

the variable is the one that determines how language is determined (based on path, domain, etc).

My 'hack' solution was in hook_strongarm() to variable_set() all 'boot' variables that are undefined since I wanted to 'strongarm' them and more importantly have them stored in code. I am going under the assumption that all my 'boot' modules followed the recommended practice and prefixed their variables with the name of the module.

I am not sure this 'hack' would be applicable for everyone. The below code is just some of my solution, which also includes caching the $strongarm data so that it is not rebuilt on every page request.

One catch to my solution is once a 'boot' variable is set and any changes to the 'boot' variable in-code won't automatically be applied. The Strongarm admin page (admin/settings/strongarm) still gives the user the option to apply any changes to a 'boot' variable.

I hope this helps.
~jake

/**
 * Implementation of hook_strongarm().
 */
function mymodule_strongarm() {

  // Boot modules
  $result = db_query("SELECT name FROM {system} WHERE type='module' AND status=1 AND bootstrap=1 ORDER BY name");
  $boot_modules = array();
  while ($record = db_fetch_array($result)) {
    $boot_modules[] = $record['name'];
  }
  $boot_modules_re = '/^('.  implode('|', $boot_modules) .')_/';

  // Use a unique id to determine if a variable is undefined.
  $undefined = uniqid();

  $variables = array(
    // My very large array of almost all my entire site configuration stored in code.
  );

  $strongarms = array();

  // Convert variables array to strongarm object.
  foreach ($variables as $name => $value) {
    // Set undefined boot variables.
    if ( preg_match($boot_modules_re, $name) && variable_get($name, $undefined) == $undefined) {
      drupal_set_message( t('Boot variable %name was strongarmed and set.', array('%name' => $name)) );
      variable_set($name, $value);
    }

    $strongarm = new stdClass;
    $strongarm->api_version = 1;
    $strongarm->name = $name;
    $strongarm->value = $value;
    $strongarms[$name] = $strongarm;
  }

  return $strongarms;
}

Strongarm integration with Boost suffers from this. An issue has been created: #933662: Strongarm Support.

sub

subscribing

language_content_type_[node-type] can be added to the list for the case where it is used to determine the accessibility of the "Translate" tab on nodes.

sub

subscribing

Add glossary module to the list.

If you thought for a moment that using strongarm on locale_custom_strings_en for string replacements in t() was a good idea (looks at hefox)... You'd be wrongo!

hefox and I dug through after assuming it would work, and found the opposite to be true. No good workaround as of yet, other than ditching strongarm in favor of a same language .po file translation.

I got hit with this and page caching.

My personal take on a solution is to have a blacklist of variables which strongarm will not set. Explain why if people try. I expect a solution for people wanting to have non db variables that can be used earlier in the bootstrap is to define them in settings.php

This will be deprecated with #1094598: Performance issues from strongarm_init() tmk

No longer relavent as variables are back in the database always