Add update_variable_*()

I can see the point of update_variable_get|set|del(), but the version suffix and so on looks like premature optimization for CMI, which feels a bit designed into the blue right now, as we don't know 1) whether CMI will make it and 2) whether we'll actually need a version suffix then.

Thus, I'd like to remove that version suffix.

In the end, this is still questionable though. There's an issue somewhere which basically attempts to solve this from the opposite direction: Resetting module_list() to nothing before invoking a module update function. Thus, same effect; no hooks can be called. Overall, that sounds like a better approach to me, as we're basically duplicating the entire effin' system in update.inc meanwhile...

Ok, so we don't yet have an API change in variable_set/get and we will likely not have any, since the functions are going away in Drupal 8, right? So regardless of the introduction of their update counterparts, they will not be useable in update functions in D8. Sounds like it will be really a question of the upgrade path of CMI, whether it leaves the variable data lingering for other update functions to run, whether the CMI update will run in early bootstrap and later update functions will need to use its new data source (and replicate those future methods/functions). To me it looks like that is the point when the variable API actually gets a change and at that point, the data source might be very different, so this would need to be revisited entirely, no?

I think it makes sense to do this, given that we know we'll likely want to remove the variable_*() functions, so let's be nice to contrib maintainers who port their modules early.

There's lots of updates using variable_get()/variable_set() already in Drupal 8, those need to be updated but that's possibly a novice task if this patch passes.

Not that many: block, language, locale, node, and system modules. Now that the patch passes, should they be included in this initial patch, or deferred until this initial patch lands?

+++ b/core/includes/update.inc
@@ -285,6 +285,62 @@ function update_module_enable(array $modules) {
+  $GLOBALS['conf'][$name] = $value;

Why are we updating this global, but not also calling cache('bootstrap')->delete('variables')?

Gabor/sun: do your concerns still stand, or are catch's answers satisfactory?

Bumping to get back on everyone's radar. Is this still necessary, and if so, should it be postponed on all of the variable-to-config conversions?

I don't think it needs to be postponed. We just have to get this in (without any conversions) and when all the variable conversions are done we can see what needs to be done. Or we can add the few cases mentioned in #18 that needs updates anyway.

Tagging.

- There won't be a version 1 of the {variable} schema, so the schema suffix in the update_variable_*() functions is needless.

- Setting new variable values on global $conf is pointless, since updates are executed in a batch. Everything that depends on variables during the upgrade should use the update_variable_*() replacements in the first place.

- Fixed phpDocs and coding style.

- Converted all existing variable_*() calls in D7->D8 updates throughout core.

#23: drupal8.update-variable.23.patch queued for re-testing.

Sure. But that means that the global $conf will be different, depending on how you run updates. I can't speak for others, but I don't want to support that. We have enough conditions and varying scenarios in the upgrade path already, I don't need yet another.

Fixed the LanguageUpgradePathTest.

Replaced another variable_get() in locale.install, this seems to work for me now.

Excellent! Thanks @Berdir for figuring out that last glitch!

This works for me. Committed to 8.x. Thanks all.

I think this needs a change notice, should be easy enough to create.

Posted #1717878: Fix summary of update_variable_get() to be under 80 characters.

Something like this: http://drupal.org/node/1721608?

The functions aren't on api.d.o yet, but those are the URLs that will find them.

I think this is clear enough, it doesn't need explicit code examples.