Port Variable to Drupal 8

As far as I know, most of the functionality covered by this module has become part of Drupal 8 core, specifically the new configuration API.

Are you looking for any features specifically, anything that's not been added to D8 already?

I don't feel I know D8 well enough to decide whether there's a need for a D8 version. @reyero is the main author of this module and can probably judge this better than me.

Either way, it sounds like you have thought about it already, so why don't you create a sandbox and just go for it! See what's needed and what you can work out. Eventually, your code can either be published as a separate module or moved back to this module...

If you decide to do this, it would be great if you could keep this issue updated so others can easily follow your progress! :)

Since the configuration system has been completeley rewritten in Drupal 8, I'm not sure we'll be missing any of Variable module features.

There's full metadata for configuration now, that should replace variable declaration, https://drupal.org/node/1905070
Configuration overrides, languages, etc... https://drupal.org/node/2098119
And there's this module for inspecting configuration, https://drupal.org/project/config_inspector

I guess we'll need to take a look at the new configuration system first, and see whether we'll be missing any feature, not clear for me at this point.

#2282401: D8: Implement translatable variables is missing in core and sounds crucial to me.

Thanks all for your contributions :)

If you guys feel it would be valuable to port Variable module to Drupal 8 then we would be happy to contribute testing patch, quality assurance, documentation, and agile project management services if needed

Related pages

• Drupal 8.0.0 will be released on November 19, 2015
• News about "Porting modules and themes to Drupal 8 "
• "Drupal Module Upgrader" module. Which can do some of the port automatically for you, covering many API hooks.
• Documentation about "Converting 7.x modules to 8.x"

I don't think we'll miss translatable variables, that is included in configuration translation now.

Maybe the most useful thing we could do is providing some updater plug-in to transform module variables to CMI

Updated title so it's easier to read. Using aggregator, drupal.org dashboard and search.

For what it's worth, I just started digging in to the issue of Domain-specific configurations, and there are some potential gaps in core:

* Core works fine if you want to manually edit and load configuration files. The override system handles that cleanly.

* If you want to build a UI for contextual variables, core Config Translation is not sufficient as a model. By design, it only cares about strings, which means it ignores many of the variables that we would want to override per context.

* There are places in core -- specifically entity link registration -- where hardcoded exceptions are made for Config Translation. These instances should, ideally, bu identified and abstracted, so that Config extension via context is more general and pluggable.

So, I can see the use-case for this module as twofold:

* Identifying the parts of core Config Translation that need to be extended and generalized.
* Providing a user interface for elements that Config Translation doesn't cover. (In particular, look at ConfigMapperManager::getDiscovery().

If we don't need to build a UI for managing contextual variables, however, then we should be fine.

After a week of experiments, I see a few options here:

* Ignore the routing system entirely and just create our own forms from schema files -- https://www.drupal.org/node/1905070

The problem with this approach is that it strips the forms from any context, though we will have form labels. We may also have to maintain a lot of field handling code. In this scenario, the base route would always be admin/domain/domain_config/{setting}. An added problem is that not tying to routing means we may lose proper access control checking, which is why the config translation system uses yml files to make explicit the connection between schema and route.

* Ignore the schema system and try to use Form Alters (as Domain Settings did in D7).

The problem with this approach is that it may prevent us from providing a list of config overrides (which is something that config translation models).

* Provide our own version of *.config_translation.ynl files and try to push those into core.

This is what Domain Conf always had to do, partly because many of the settings had to be vetted for use across domains. For instance, Logging settings per domain don''t provide much value.

To really make this work, I think we'd want the Variable module concept.

* Push an issue to core that makes the route part of the config_object schema. e.g.

system.cron:
  type: config_object
  label: 'Cron settings'
  route: system.cron_settings
  mapping:
    threshold:
      type: mapping
      label: 'Thresholds'
      mapping:
        requirements_warning:
          type: integer
          label: 'Requirements warning period'
        requirements_error:
          type: integer
          label: 'Requirements error period'

* Don't build a UI for Domain Config or similar modules.

I filed a core issue -- #2677124: Allow discovery of configuration UI

Here's a quick brain dump of how I see Variable working. The main module would do the heavy lifting -- essentially mirroring and extending what Config Translation does from a UI level. Contrib modules would provide contexts.

If may even be that we can use the existing ContextProvider or Condition plugins to discover variable contexts.

D7 of this module provides [variable:XXX] tokens.

In D8 we have the config system to replace variables. However it still could be useful to have tokens for config. I can't find that feature anywhere in D8 core or token module. Is this something that could be in a D8 version of this module?

I also need a way to create token with variables. And I also need them to be translatable.

@agentrickard thanks, nice picture.

While agreeing there may be some interesting features missing, I just want to point out 'variables' are named now 'configuration' so trying to reuse this 'variable' module for any of those may be just misleading.

This is what we are talking about here, I believe, whether to reuse the 'variable' module name or not, because there's really no code in here that can be reused.

As an example a 'config_tokens' module may be much more accurate name for a module providing tokens out of configuration values.

On the other side we have all the 'variable_' namespace free now, that may be handy if anyone wants to provide some new 'variable_' API.

Thus while I don't see too much value in upgrading the variable module as such, let me know if anyone wants to produce a 8.x version of some variable_ API, I'll just get the project permissions fixed for that.

I was looking for a solution that allows me to store arbitrary values as configuration. After some days of research, I couldn't find a solution for that and decided to create a new project called Parameters. It's not really a successor of the variable module, but for someone interested in creating arbitrary configuration, it might be worth to check out.