The drop is always movingYou know that saying about standing on the shoulders of giants? Drupal is standing on a huge pile of midgetsAll content management systems suck, Drupal just happens to suck less.Popular open source software is more secure than unpopular open source software, because insecure software becomes unpopular fast. [That doesn't happen for proprietary software.]Drupal makes sandwiches happen.There is a module for that

Easier configuration development for Drupal 8

Submitted by nk on Sun, 2014-07-06 22:56

With config_devel, when you are editing a migration, you can just enter the name of the file being edited at admin/config/config_devel and on every request the module will check for changes and import the file into the active storage. The other direction works as well: say you are working on a contrib module and have a view. Provide the path of the file (this time in the auto export box) and on every change Drupal will automatically export. Once satisfied, just commit. Or perhaps you just want to follow what's in a config file as it's being edited -- provide sites/default/files/some.config.name.yml and it'll be right there on every save.

Both import and export are doable manually with the config module core provides. But I think the automatism makes life easier and I hope the module will be popular among D8 developers. Finally, let me thank beejeebus for cooking up the module originally and handing it over to me despite he knew I will rewrite it from the ground up.

Commenting on this Story is closed.

Submitted by Anonymous on Mon, 2014-07-07 00:58.

So what is the difference between beejeebus's config_devel and your rewritten config_devel?

Submitted by nk on Mon, 2014-07-07 02:31.

One common feature is the ability to write configuration back. However, his used settings; I am using CMI to specify what to write back allowing for an easy UI.

His also was functioning, sort of, to provide config-as-files but it was not doing proper config import. Also, it was exposing every config as a file (if configured with a directory) which is not necessary IMO, just created clutter.

In short, his was more along the lines of "what can config do" while mine is more along the lines of "what developers want to do". I have, so far, identified two very common scenarios (editing a migration in an editor and editing a view/block/etc in the UI) and built the module corresponding to those.