First of all, this module is pretty amazing. I really like the architecture and the direction that it's going. I was wondering if there were any plans to move away from the exported PHP code in the exported configuration.datastore.inc files. Although this works, and works great, the majority it of the cases, we're just exporting arrays of content. Outputting this into straight PHP code can be considered a security risk when testing third party configurations. It also seems a bit wonky when all we want to store is a pretty-looking data array.

I don't mean to open up a bike-shed argument, or start a religious/performance debate, but as of PHP 5.4, json_encode() is getting the JSON_PRETTY_PRINT option, which allows us to output a PHP array directly to JSON, while keeping the new lines in to keep the JSON looking all pretty. We could also get around the limitations of PHP 5.3 easily enough too, with a bit of fixing...

What are your thoughts? Again, I don't mean to re-start an endless debate, just doing some brainstorming. Thanks so much for all that you've done. This module is looking absolutely amazing, and I'm really excited about where it's going!

Comments

tom friedhof’s picture

Thanks for the feedback on the module! Indeed, I want the config files to eventually look very similar to what Drupal 8 configuration management initiative config file output. Right now the module works very much like features module, except that rather than calling the "default_hook" off the file system to get configuration, it only calls the default hook when "activating" a configuration, and then its up to the module to with the data as it wishes.

So far this module is just a first pass at what we're trying to do, which is pull the configuration part out of features. Now that we have base code published on d.o. that for the most part works, the idea is now we can iterate on how to start incorporating better solutions for how configuration is managed, like the output format of the configuration files.

The json_encode route you mentioned might be easier to incorporate, since it sounds like it'll output a PHP array directly to JSON, but I think we should try to stay as close to Drupal 8 CMI as possible using XML files for configuration. I'm hopeful that as Drupal 8 CMI matures, this module matures alongs with it incorporating ideas back into this module. At the same time this module could be a good testing ground to incorporate ideas in D7 that maybe the D8 CMI can pull from as well.

dragonwize’s picture

Title: Exported PHP? » Exported format PHP/XML/JSON?
Component: User interface » Code
Category: bug » feature
dragonwize’s picture

Status: Active » Postponed

I doubt this will happen in D7 because it would be to much to change the already existing ctools exportables code base we already have spread everywhere. I am leaving this as postponed though in case anyone else want to take this on or discuss the possible solutions.

dagmar’s picture

Version: 7.x-1.x-dev » 7.x-2.x-dev
Status: Postponed » Needs work

Moving this to the 2.x branch. The new architecture contemplates the posibility to use a different Storage system than PHP arrays. The main issue is that, even if we provide classes to handle this, we should write a custom function for each module that provide it own method of export (like views).

For the standard drupal core configurations is much more easier because, for example the YAML, parser returns valid data that can be used to save the configuration.

dagmar’s picture

Status: Needs work » Active
lucascaro’s picture

+1, YAML and getting rid of evals is a big plus :)

benjy’s picture

Started on a JSON storage format today. #2125837: Implement JSON storage format