譯自 http://heyrocker.com/cmi-feature-freeze

我發現新功能凍結的期限已經過去了，正是一個好的時候更新一下大家設定管理大綱 (CMI)的近況了
TL;DR
CMI 的近況是非常好。我為此感到非常的驚喜和自豪，我們百人以上的合作者在過去兩年一起完成的工作。我們已經完成了全部的主要功能開發，沒有遺漏兩年前定下的目標。當然我們還有很多工作，特別是測試和文檔的部分。

Overview
兩年前我們開始的時候，我心中有一個大概的目標的：

• 將各種設定儲存在一個機器可讀的檔案，使其可以使用版本控制系統管理不同服務器環境
• 提供一個 API 處理設定的修改，和一個基本的介面執行這些更新
• 核心完全使用這個系統
• 多語言系統的支持
• 為開發者和使用者提供使用文檔

這看起來很少，但又非常多。現在功能凍結的期限已經過去了，可以看看這些目標的完成度如何

將各種設定儲存在一個機器可讀的檔案
這已經完成了，而且已經完成了一段時間。這個系統自第一個提交 (commit) 之後經過非常多的修改，包括一次大型的結構修改，由 XML 改為使用 YAML。但對外的 API 就一直幾乎沒有改變過。

核心的更新和介面
雖然 API 的接口很早已經定下了，但一些核心最複雜的部分還沒有完成，包括欄位和內容類型 (fields and node types) 還沒有非常完整地完成測試。這其中有一個可能令這個測試會帶來更多有關依賴關係的問題，有需要的話我們會處理。除了這個以外，還有一些需要幫忙和參與的：

• 實現重新命名
• 實現 hook_config_validate()
• 重构設定的匯入和同步功能

介面在上年的大一月的 BADCamp 完成了，那是一個很基本的介面，但它給用戶看到有那些設定已經準備好匯入，可以一個按鈕就完成匯入。另外的一些條目正在進行中，目的是令介面整合更多功能。

• 加入 Diff 的功能
• 當更新會覆蓋本機設定的時候警告用戶

核心完全使用設定系統
這個工作其實在上年 DrupalCon Denver 的時候已經開展，而且進度很好。其中一個比較大的問題是使用新的 ConfigEntity 處理比較 “即時” 的設定例如 Views, Fields, or Roles。一般的轉換圍繞三個區域：

• 轉換 system_settings_form 到 CMI ﹣ 還餘下兩個
• 轉換全部 variables 到 config and state systems ﹣ 核心中的 variable_get 已經少於 150 個了！其餘的大部分都會和 field/node 系統一齊處理
• 轉換設定上的資料到 ConfigEntity ﹣ 已經完成了很多工作，但這仍然是最大的未完成部分

這些是特別需要留意的：

• 轉換 Field API to CMI
• 轉換 node/content types to CMI
• 轉換 file_public_path to CMI

I would say that we are roughly 80% finished converting core to the configuration system, which I consider really amazing and fantastic. Most notably Views was committed to core fully converted to CMI from the very beginning.
Internationalization and translation
This has probably been the most troubled and difficult aspect of CMI since the beginning. It took a very long time to come to consensus about an approach, and the code took a very long time to get committed. Unfortunately, because of time constraints, some features that would have been very helpful for D8MI (like integration with admin forms) had to be abandoned. However right now we are most of the way there.
• We added a context system which allows configuration to be modified based on arbitrary contexts (language is one such context, but this could also be used by systems like Domain Access.)
• A configuration schema system was added to be able to identify which configuration is translatable and which isn't. The process of creating these schema files is in progress and can be tracked at (http://drupal.org/node/1910624). This is a great place for new contributors to dive in and get involved!
• The config schema now needs to be integrated with locale module. There is a patch in progress for this at (http://drupal.org/node/1905152).
Documentation
Of course, as always, this comes last. However I think the time has come to get started on this seriously. There is an existing handbook page for the technical documentation of the system however it is largely out of date. A fantastic exception to this is the schema and context docs written by Gábor as each of those systems went into place.
In addition to technical docs, we will also need user-centric documentation about working with the system for both simple and advanced use cases. I am hoping to work with an experienced technical writer to build these pages, so if you are/know of someone who is interested in getting involved in this way, please get in touch!
Additional topics
• There has been a lot of discussion and debate about what to do with configuration when a module is installed/uninstalled, and the meta-question of 'Who owns a piece of configuration?' The classic example of this is when node.module provides a default view for the Drupal homepage. Is this node's configuration or views'? What happens to the view if it remains and node is uninstalled? These questions have been discussed in great detail at (http://drupal.org/node/1776830) and that remains our largest outstanding architectural question. Right now it is somewhat blocked while we decide what to do about disabled modules (see (http://drupal.org/node/1199946)).
• There has been a very long and detailed discussion around what to do with the url alias configuration which includes some unique questions about what exactly is configuration and what is content.
• There has not been a lot of talk about content staging since CMI began, but great strides have been made in this area regardless.
◦ UUIDs are now a part of every entity, allowing them to be staged between environments even when serial IDs change.
◦ Entities can now be serialized and unserialized to/from a machine readable format that all Drupal installations will understand.
◦ The new entity API makes saving nodes programmatically safe and reliable.
There are even basic web services for CRUD functionality in core through the REST module! So the basic building blogs for a variety of solid content staging solutions are in place, although those solutions will have to live in contrib, which frankly I think is fine.
Getting involved
The planned deadline for the integration phase (when all APIs are frozen and all conversions are complete) is July 1st 2013. There are three big sprints until then that we plan to use to boost our standing (please come and sign up for these):
• Drupal sprint weekend, March 9th and 10th all around the globe
• Sprints on the weekends both before and after DrupalCon Portland, May 18-19th and 24-26th
• Sprints all week before Drupal Dev Days Dublin, June 24-27th
Thank you to my sponsors
As a reminder, my time on this work is sponsored by the individual donations from ChipIn on my site, as well as the generosity of donations from the following companies:
Acquia
Riot Games
Bluehost
Dennis Publishing
Pantheon
WebEnabled
Reload.dk
Annertech
Comm-press GmbH
Undpaul.de
Thank you all for your support. I will have an update on funding and work on CMI post-feature-freeze in a followup post in the coming days.
And of course THANK YOU TO EVERYONE WHO HAS CONTRIBUTED TO THE SYSTEM. Getting this implemented into core has taken a great deal of blood, sweat and even tears to get done. It has not been easy but we have come so far. I am really excited to see CMI get pushed through these last phases of the core cycle.