Convert date formats to config entities

Blocked on #2003942: Convert system_configure_date_formats_form() to a controller

This does not change datetime.module or any tests, so it will fail.

Updating the title.

:/

Fixed more stuff.

Will have to talk to someone who worked on #1571632: Convert regional settings to configuration system or #1646580: Implement Config Events and Listeners, and storage realms for localized configuration to find out how to reconcile the locale.config stuff.

+++ b/core/includes/common.incundefined
@@ -1575,12 +1575,14 @@ function format_date($timestamp, $type = 'medium', $format = '', $timezone = NUL
+    if ($date_format = entity_load('date_format', $type)) {
+      $format = $date_format->getPattern($key);
...
+    $format = entity_load('date_format', 'medium')->getPattern($key);

+++ b/core/lib/Drupal/Core/Entity/EntityManager.phpundefined
@@ -185,6 +185,7 @@ public function getFormController($entity_type, $operation) {
+        $this->controllers['form'][$operation][$entity_type]->setOperation($operation);

We should certainly do some performance testing as loading an entity vs. just loading a config seems to be sort of more expensive.

Discuss.

Thinking as an integrator who want to edit his formats directly in the YAML files, in term of usability, date formats as they were originally (in one single YAML file) sounds a lot more nicer to edit than N YAML files where you definitely can't have a global overview of all your formats in one eyeshot.

Does it really worth to replace date formats config file by another config entity? We are generating tons of smaller files VS one single (still small) file. But in the end, we are wasting disk space and polluting config, which then contains more metadata for the entity system than usefull data for the frontend building.

Plus in term of performances, it will probably really hurt in the end: the format_date() function will load a different entity for each call (hence one SQL query or one remote cache backend query depending on configuration) per date displayed in current state, and one per different date format being used later once entity static caching will land). This means that we are multiplying the number of remote storage backend for dates from 1 to N where N is number of formats being used on the same page.

It does not sound like an improvement at all to me. Is there any use case where having entities for date format would be useful?

1 query for laoding all formats at once VS 1 query per for each format displayed is a simple deduction reading the above patch.

Measures won't show any significant different if you add 2 or 3 queries: there are already almost 200 lying around. Nevertheless if everything is converted the same way in the whole system for the sake of consistency, the number of queries could explode significantly.

Drupal 8 has already 50 @EntityType references I could grep in code, found at least 10 being config entities.. Hopefully some are used only via some procedural accessors loading them all and statically caching them, but not all of them.

So, I installed a fresh D8 (justed pull from git) and added two nodes with different types and one comment on the home page, did an anonymous hit with warmed up caches, and used a *cachegrind to look up at the profiling output: 132 queries show up, ~90 are cache, among them ~40 are cached config read operations, ~10 are config entity loads, and we're about to add some others. I didn't added any other fancy stuff, the home page is pretty empty there. I didn't added any other language than english or blocks, this would make the number of queries up to 200 (approximative numbers from my previous week's tests).

EDIT: Anyway this was just some thoughts about config entities, I'm not against consistency either so let's see what happens in the future for performances.

More work on the upgrade path. Still need to fix locale stuff.

Sorry, here's the interdiff.

@pounard

Thinking as an integrator who want to edit his formats directly in the YAML files, in term of usability, date formats as they were originally (in one single YAML file) sounds a lot more nicer to edit than N YAML files where you definitely can't have a global overview of all your formats in one eyeshot.

With the current approach you can't add any new default formats in yml. You need to add some code in module_install to change the default date config.

ux--

So triple +1 for this patch.

More upgrade path test fixes.

More fixes.

Okay!

Whoops, last minute refactoring gone wrong. This should finally pass.

Tim asked me to look at this issue. I must admit I have not looked how language vs. format relations are stored. It looks odd that we'd use the config override system with files of equal content (if I understand right) to the original file, just so we have a list of languages the format applies to?

Core essentially provides a full config translation interface for date formats.
I honestly don't know how to replicate that for config entities, it would be the first instance.

I think this is actually not as terrible as I thought, and can be revisited once/if #1952394: Add configuration translation user interface module in core goes in.

@tim.plunkett: yeah my understanding on what core does is it lets you assign the same date format string to multiple languages. It is not really a translation feature. You cannot translate the date format to other languages. A date format either applies to a language or not. So what the code does is it saves the *same* data to multiple files and then uses the filenames as keys to figure out which languages does the date format applies to. This is no doubt creative use of the config translation system.

Anyway, I see this is somewhat of a prior behaviour, although largely adapted here to work in a custom way on top of config entities.

While we figure out how to handle this, rerolling and ensuring the locked functionality stays in.

Aren't we missing a test for the locked functioanlity? If it came back green before.

Added tests, and moved the locked stuff into an access controller.

The EntityManager hunk was also included in the actions patch.

EntityAccessCheck doesn't work with 'create'.
Also, needed to follow the /manage/ path pattern of other entities.

Finally, used update_7_to_8_install_default_config() instead of config_install_default_config().

Great work @tim.plunkett. I just manually tested by:

1. Applying the patch in #36 in a fresh D8 code base
2. Build site
3. Add a new format
4. Edit default one

Everything works fine exception the localization issue below.

Issues:
1. Selected "Select localizations" is not getting selected/updated properly.

Suggestions:

+++ b/core/includes/common.incundefined
@@ -1295,12 +1295,14 @@ function format_date($timestamp, $type = 'medium', $format = '', $timezone = NUL
+    if ($date_format = entity_load('date_format', $type)) {
+      $format = $date_format->getPattern($key);

how bad idea is it to introduce a helper for this... something like below:

class DateFormat extends ConfigEntityBase implements DateFormatInterface {
...
...
...
  public static function getFormat($type, $pattern) {
    if ($date_format = entity_load('date_format', $type)) {
      return $date_format->getPattern($pattern);
    }
    return NULL;
  }
}

(can be part of interface, if it makes sense)

So that we can replace the code with DateFormat::getFormat($type, $pattern); in all the places?

Fixed the locale form bit, I just left off the default value by mistake.

I'm not sure about adding a static method like that, we don't do that in any other entity types. It would also mean hardcoding Drupal\system\Plugin\Core\Entity\DateFormat::getFormat(), which is not good since entity types are theoretically swappable.

thanks for the update. Tried the same steps in #37 and all working good.

Here is few minor code reviews. Surely not show stoppers :)

+++ b/core/modules/field/lib/Drupal/field/Tests/FieldUnitTestBase.phpundefined
@@ -38,7 +38,11 @@ function setUp() {
+    // Set default storage backend and configure the theme system. If the child

Minor: more than 80 chars
EDIT: This is wrong. it is with in 80 chars

+++ b/core/modules/system/config/system.date_format.html_date.ymlundefined
@@ -0,0 +1,8 @@
+label: 'HTML Date'

+++ b/core/modules/system/config/system.date_format.html_datetime.ymlundefined
+++ b/core/modules/system/config/system.date_format.html_datetime.ymlundefined
@@ -0,0 +1,8 @@
+id: html_datetime
+label: 'Default Short Date'
...
...
...

Minor: All schema follows label as Ucfirst until there is no UI which has different format. I can see that old schema has word cap, but I don't see this labels in D7. So guess this is introduced in D8. If so can we fix this label?

+++ b/core/modules/system/lib/Drupal/system/DateFormatStorageController.phpundefined
@@ -0,0 +1,53 @@
+/**
+ * @todo.
+ */

Minor: Class docblock missing?

Fixed both label and comment issue in #39. Exclude me in commit message, just committing this patch as I've reviewed yesterday and didn't mention #39.

Good to RTBC from my side.

That was actually a bad copy/paste job on my part.

As discussed with Tim on IRC, we may need to create a follow up to fix the name (e.g HTML Datetime => Datetime (HTML), Default Short Date => Short date (Default), etc...). So it's RTBC, if test is green.

Keepin' up with the drop.

Profiling results attached.

Summary of /user/1
Before is on left

Number of Function Calls	40,670	47,637	6,967	17.1%
Incl. Wall Time (microsec)	577,368	758,896	181,528	31.4%
Incl. CPU (microsecs)	556,034	668,042	112,008	20.1%
Incl. MemUse (bytes)	6,268,452	7,061,228	792,776	12.6%
Incl. PeakMemUse (bytes)	6,339,348	7,158,176	818,828	12.9%

Summary of /node with 50 nodes

Number of Function Calls	84,483	93,387	8,904	10.5%
Incl. Wall Time (microsec)	1,140,552	1,182,795	42,243	3.7%
Incl. CPU (microsecs)	1,116,070	1,160,073	44,003	3.9%
Incl. MemUse (bytes)	10,503,128	11,228,720	725,592	6.9%
Incl. PeakMemUse (bytes)	10,583,276	11,323,900	740,624	7.0%

#44: date-format-2003892-44.patch queued for re-testing.

Note that my profiling was done with xdebug on, which I've been told is wrong, will look at it again tomorrow.

formatted version of #45:

Summary of /user/1

Summary of /node with 50 nodes

format_date() is now \Drupal\Core\Datetime\Date::format()

#51: date-format-2003892-51.patch queued for re-testing.

Performance looks really bad, not sure that caching should help here.
Otherwise great patch

+++ b/core/modules/datetime/datetime.moduleundefined
@@ -32,16 +32,27 @@
+    if ($date_format_entity = entity_load('date_format', 'html_date')) {
...
+    if ($time_format_entity = entity_load('date_format', 'html_time')) {

So at least these two entity_load methods will be loaded all the time. What about moving this to the process function?

Let's see if this works.

#value_callback is called before #process. So that's a no go for now.
Rerolling without that.

This needs profiling still, as the previous numbers were run with xdebug enabled.

#60: date-2003892-60.patch queued for re-testing.

Rerolled, it turns out this contained #1987822: Convert system_date_time_lookup() to a new style controller

This blocks removal of MENU_LOCAL_ACTION.

Still needs docs work on my part, just rerolling.

Attempted reroll after language-as-config.

looks like a very nice cleanup!

+++ b/core/modules/system/lib/Drupal/system/DateFormatInterface.phpundefined
@@ -0,0 +1,62 @@
+  public function getPattern($type = DrupalDateTime::PHP);
...
+  public function setPattern($pattern, $type = DrupalDateTime::PHP);
...
+  public function addLocale($locale);
...
+  public function setLocales(array $locales);
...
+  public function getLocales();
...
+  public function hasLocales();
...
+  public function isLocked();

Well, @params and @returns are there but the typical boilerplate docs are missing.

+++ b/core/modules/system/lib/Drupal/system/Plugin/Core/Entity/DateFormat.phpundefined
@@ -0,0 +1,201 @@
+    $this->locales = array_unique($this->locales);

not sure why this is needed? if $locale is string, what about using it as a key? would make the array unique check unneeded

The pre-existing exports were also numerically indexed, not associatively, so I'm using that to maintain the previous behavior.

Added the docs.

well, manually tested, behavior exactly the same, profiling done, cant find anything to complain about, looks ready to me!

Rerolled around #2024833: Adopt load() and loadMultiple() on entity storage controllers

#72: date-2003892-72.patch queued for re-testing.

HEAD was broken #2024833: Adopt load() and loadMultiple() on entity storage controllers

Changing priority as this is part of #1802750: [Meta] Convert configurable data to ConfigEntity system

Replacing format_date() with \Drupal::service('date')->format()

+++ b/core/lib/Drupal/Core/Datetime/Date.phpundefined
@@ -104,13 +104,13 @@ public function format($timestamp, $type = 'medium', $format = '', $timezone = N
+    if ($date_format = entity_load('date_format', $type)) {
...
+      $format = entity_load('date_format', 'medium')->getPattern($key);

In a perfect world this service would have the entity storage controller injected.

+++ b/core/modules/system/lib/Drupal/system/DateFormatListController.phpundefined
@@ -0,0 +1,50 @@
+    $row['pattern'] = format_date(REQUEST_TIME, $entity->id());

+++ b/core/modules/system/lib/Drupal/system/Form/DateFormatDeleteForm.phpundefined
@@ -7,68 +7,20 @@
+      '%format' => format_date(REQUEST_TIME, $this->entity->id()))

+++ b/core/modules/system/lib/Drupal/system/Form/DateFormatEditForm.phpundefined
@@ -7,125 +7,40 @@
+    $now = t('Displayed as %date', array('%date' => format_date(REQUEST_TIME, $this->entity->id())));

+++ b/core/modules/system/lib/Drupal/system/Form/DateFormatFormBase.phpundefined
@@ -24,48 +29,178 @@
+      $format = t('Displayed as %date_format', array('%date_format' => format_date(REQUEST_TIME, 'custom', $form_state['values']['date_format_pattern'])));

format_date can be replaced here as well.

This was RTBC and green, format_date() nitpicks aside. Will reroll tonight.

That was a pretty invasive nitpick, let's leave others for follow-ups.

Nice!

+++ b/core/lib/Drupal/Core/Datetime/Date.phpundefined
@@ -26,11 +26,11 @@ class Date {
+  protected $dateStorage;

I'd be tempted to rename this dateFormatStorage as it does not store dates...

+++ b/core/modules/system/config/system.date_format.html_date.ymlundefined
@@ -0,0 +1,8 @@

@@ -0,0 +1,8 @@
+id: html_date
+label: 'HTML Date'
+pattern:
+  php: 'Y-m-d'
+  intl: 'yyyy-MM-dd'
+status: '1'
+langcode: en
+locked: '1'

Missing uuids from all the default config files.

+++ b/core/modules/system/lib/Drupal/system/Form/DateFormatLocalizeResetForm.phpundefined
@@ -102,7 +102,9 @@ public function buildForm(array $form, array &$form_state, $langcode = NULL, Req
+    foreach (config_get_storage_names_with_prefix('locale.config.' . $this->language->id . '.system.date_format') as $config_id) {

Missing a dot after system.date_format ... just in case we do something mad like create system.date_formatter.settings.yml

+++ b/core/modules/system/system.admin.incundefined
@@ -1440,25 +1374,23 @@ function system_date_format_localize_form($form, &$form_state, $langcode) {
+  $config_prefix = 'locale.config.' . $langcode . '.system.date_format';
+  foreach (config_get_storage_names_with_prefix($config_prefix) as $config_id) {
+    $date_format_id = substr($config_id, strlen($config_prefix. '.'));

Lets add a dot to $config_prefix for the same reason.

+++ b/core/modules/views/lib/Drupal/views/Plugin/views/field/Date.phpundefined
@@ -18,6 +21,54 @@
+  /**
+   * The date service.
+   *
+   * @var \Drupal\Core\Datetime\Date
+   */
+  protected $date;
+
+  /**
+   * The date format storage.
+   *
+   * @var \Drupal\Core\Entity\EntityStorageControllerInterface
+   */
+  protected $dateStorage;

I think these might cause confusion we are in a Field plugin here... the $dateStorage kind of implies that this might store the field... perhaps DateFormatStorage? And I would call $date $dateService just to be clear too.

Good points all around.

While re-exporting the CMI files, it rearranged the keys a bit, nothing to worry about as I hand wrote them before.

Also found this (unrelated) bug #2034113: System's entity info is not available during drupal_install_system() while trying to give the date formats UUIDs.

The interdiff itself looks great.

+++ b/core/lib/Drupal/Core/Datetime/Date.phpundefined
@@ -42,13 +42,13 @@ class Date {
    * Constructs a DateFormats object.

nitpick:Is this still valid?

+++ b/core/modules/datetime/lib/Drupal/datetime/Plugin/field/formatter/DatetimeDefaultFormatter.phpundefined
@@ -89,7 +89,7 @@ public function viewElements(EntityInterface $entity, $langcode, array $items) {
+    return \Drupal::service('date')->format($date->getTimestamp(), $format_type);

@@ -100,11 +100,12 @@ public function settingsForm(array $form, array &$form_state) {
+    $format_types = \Drupal::entityManager()
...
+      $format = \Drupal::service('date')->format($time->format('U'), $type);

Can't this be injected now? See https://drupal.org/node/2012118

+++ b/core/modules/datetime/lib/Drupal/datetime/Plugin/field/widget/DatetimeDefaultWidget.phpundefined
@@ -74,7 +74,7 @@ public function formElement(array $items, $delta, array $element, $langcode, arr
+        $date_format = entity_load('date_format', 'html_date')->getPattern($format_type);

@@ -83,8 +83,8 @@ public function formElement(array $items, $delta, array $element, $langcode, arr
+        $date_format = entity_load('date_format', 'html_date')->getPattern($format_type);
+        $time_format = entity_load('date_format', 'html_time')->getPattern($format_type);

Shouldn't this inject the date format storage controller and load from that without the call to entity_load?

+++ b/core/modules/datetime/lib/Drupal/datetime/Tests/DatetimeFieldTest.phpundefined
@@ -104,8 +104,8 @@ function testDateField() {
+    $date_format = entity_load('date_format', 'html_date')->getPattern($format_type);
+    $time_format = entity_load('date_format', 'html_time')->getPattern($format_type);

@@ -175,8 +175,8 @@ function testDatetimeField() {
+    $date_format = entity_load('date_format', 'html_date')->getPattern($format_type);
+    $time_format = entity_load('date_format', 'html_time')->getPattern($format_type);

Should this be?

$this->dateFormatStorage = $this->container->get('plugin.manager.entity')->getStorageController('date_format');
$this->dateFormatStorage->load('html_date');

+++ b/core/modules/system/lib/Drupal/system/DateFormatAccessController.phpundefined
@@ -0,0 +1,34 @@
+    return user_access('administer site configuration', $account);

<ignore>damn you user_access! still a blight on our OO code :)</ignore>

+++ b/core/modules/system/lib/Drupal/system/DateFormatListController.phpundefined
@@ -0,0 +1,94 @@
+  protected $date;

+++ b/core/modules/system/lib/Drupal/system/Form/DateFormatDeleteForm.phpundefined
@@ -7,68 +7,56 @@
+  protected $date;

+++ b/core/modules/system/lib/Drupal/system/Form/DateFormatFormBase.phpundefined
@@ -24,48 +30,189 @@
+  protected $date;

should this use $dateService too (see earlier review)

+++ b/core/modules/system/lib/Drupal/system/DateFormatListController.phpundefined
@@ -0,0 +1,94 @@
+    $row['label'] = String::checkPlain($entity->label());

love seeing this!

+++ b/core/modules/system/lib/Drupal/system/Plugin/Core/Entity/DateFormat.phpundefined
@@ -0,0 +1,201 @@
+    if (\Drupal::moduleHandler()->moduleExists('language')) {

We can't inject this yet can we?

+++ b/core/modules/system/lib/Drupal/system/Tests/Common/FormatDateTest.phpundefined
@@ -40,11 +40,12 @@ function setUp() {
+    $formats = $this->container->get('plugin.manager.entity')

yeah this confirms my comment above about using entity_load

+++ b/core/modules/system/lib/Drupal/system/Tests/System/DateTimeTest.phpundefined
@@ -146,11 +143,12 @@ function testDateFormatStorage() {
+    $date_format = entity_create('date_format', array(

$this->container->get('plugin.manager.entity')->getStorageController('date_format')->create() instead?

+++ b/core/modules/system/lib/Drupal/system/Tests/Upgrade/DateUpgradePathTest.phpundefined
@@ -65,12 +65,12 @@ public function testDateUpgrade() {
+    $actual_formats = entity_load_multiple('date_format', array_keys($expected_formats));

$this->container->get('plugin.manager.entity')->getStorageController('date_format')->loadMultiple instead?

+++ b/core/modules/user/lib/Drupal/user/Tests/UserTimeZoneTest.phpundefined
@@ -30,8 +30,8 @@ function testUserTimeZone() {
+    entity_load('date_format', 'medium')

Same again

Neither widgets nor formatters are using ContainerFactory, so I can't inject anything.

I'm not switching any entity_load()s in tests in a 4xRTBC 90K patch. Someone else can if they want. They're tests.

So given that #2034563: Switch field plugin managers to DefaultPluginManager handles injection for field plugins, this is back to rtbc

Was going to commit but testing and reviewing revealed a couple of things...

+++ b/core/modules/system/lib/Drupal/system/Form/DateFormatFormBase.phpundefined
@@ -24,48 +30,189 @@
     $date = new DrupalDateTime();

the date service is being injected this should be removed...

It is possible to delete all the data formats including medium... if you do this and the go and create an article you will see the following error Fatal error: Call to a member function getPattern() on a non-object in ./core/lib/Drupal/Core/Datetime/Date.php on line 112. This is broken in HEAD to but it just does not fail as bad.

+++ b/core/lib/Drupal/Core/Datetime/Date.phpundefined
@@ -103,14 +103,13 @@ public function format($timestamp, $type = 'medium', $format = '', $timezone = N
     // Fall back to medium if a format was not found.
     if (empty($format)) {
-      $format = $config->get('formats.medium.pattern.' . $key);
+      $format = $this->dateFormatStorage->load('medium')->getPattern($key);
     }

This is why this happens... I think we need to fix this here because before it broke silently and now it's in your face. Afaics we have two options: (a) default to a locked format such as html_datetime or (b) create an new locked format called fallback. I favour the latter as this means distributions can alter this.

And now #2034563: Switch field plugin managers to DefaultPluginManager is done so some of @larowland's review in #85 is relevant

#2035317: DateTimeDefaultWidget should implement ContainerFactoryPluginInterface still blocks some of @larowlan's proposed changes.

Wow, FormatterPluginManager::createInstance() makes using ContaineFactoryPluginInterface ugly as sin.

Good call on the medium/fallback bit.

Sigh.

#92: date-2003892-92.patch queued for re-testing.

I think we should have a test for the fallback logic

+++ b/core/modules/datetime/lib/Drupal/datetime/Plugin/field/formatter/DatetimeDefaultFormatter.phpundefined
@@ -29,7 +33,64 @@
+  public function __construct($plugin_id, array $plugin_definition, FieldDefinitionInterface $field_definition, array $settings, $label, $view_mode, Date $dateService, EntityStorageControllerInterface $date_storage) {
+    parent::__construct($plugin_id, $plugin_definition, $field_definition, $settings, $label, $view_mode);
+
+    $this->dateService = $dateService;

Incorrect usage of camel case in the $dateService arg

+++ b/core/modules/system/config/system.date_format.fallback.ymlundefined
@@ -0,0 +1,10 @@
+label: 'Fallback date'

Let's call this 'Fallback date format' to be a bit more explicit

+++ b/core/modules/system/lib/Drupal/system/Tests/Common/FormatDateTest.phpundefined
@@ -83,7 +83,7 @@ function testAdminDefinedFormatDate() {
-    $this->assertIdentical(format_date($timestamp, 'undefined_style'), format_date($timestamp, 'medium'), 'Test format_date() defaulting to medium when $type not found.');
+    $this->assertIdentical(format_date($timestamp, 'undefined_style'), format_date($timestamp, 'fallback'), 'Test format_date() defaulting to medium when $type not found.');

This was the test for the fallback, it was one of the failures in #90, see the interdiff in #92. I have to change the assertion text.

Here's the full interdiff since the last RTBC.

Looks good to me

+++ b/core/modules/system/lib/Drupal/system/DateFormatAccessController.phpundefined
@@ -0,0 +1,34 @@
+  protected function checkAccess(EntityInterface $entity, $operation, $langcode, AccountInterface $account) {
+    // There are no restrictions on viewing a date format.
+    if ($operation == 'view') {
+      return;
+    }
+    // Locked date formats cannot be updated or deleted.
+    if (in_array($operation, array('update', 'delete')) && $entity->isLocked()) {
+      return FALSE;
+    }
+    return user_access('administer site configuration', $account);
+  }

Hmmm... I suspect that the return; should be return TRUE;. The interesting thing about this is I suspected that this is denying access at the minute... see EntityAccessControllerInterface::access (note this is very different from AccessCheckInterface::access method)

One never "views" a config entity. At least not yet. If entity_reference stops restricting to content entities, then this check will be used.
And yes, I was thinking of AccessCheckInterface :)

#100!

There is a serious usability issue with the use of #ajax in this form that was introduced in #2003942: Convert system_configure_date_formats_form() to a controller and continued in the AjaxResponse. It is annoying that it does a request for each key stroke (keyup), which disrupts the normal flow of typing.

Can we fix this in this issue as well because it is pretty bad?

That behavior is not altered in this patch. Please open a separate bug.

+1 for getting this in now... anyone willing to re-rtbc? :)

yeah this ajax thing was there before, i noticed while manual testing
lets get this in

Opened followup #2038231: Usability issue with the use of #ajax in date format list

Committed 06cb438 and pushed to 8.x. Thanks!

https://drupal.org/node/1876852 needs an update...

The config schema got pretty outdated with this commit. It should be updated: #2038285: Update configuration schema for date formats as entities.

+++ b/core/modules/field/lib/Drupal/field/Plugin/Type/Formatter/FormatterPluginManager.phpundefined
@@ -58,6 +58,15 @@ public function __construct(\Traversable $namespaces, CacheBackendInterface $cac
+    // @todo This is copied from \Drupal\Core\Plugin\Factory\ContainerFactory.
+    //   Find a way to restore sanity to
+    //   \Drupal\field\Plugin\Type\Formatter\FormatterBase::__construct().
+    // If the plugin provides a factory method, pass the container to it.

Not sure what this refers to exactly, but is there an issue opened for this ?

20 days to next Drupal core point release.

unintended status change

#2083415: [META] Write up all outstanding change notices before release

Issue to discus a ways to lock (prevent delete) of config entities #2084567: Implement a EntityLockedInterface and service to allow locking entities

See #2127941: Remove two (out of 3) bogus and duplicate date languages UIs for an in-depth rundown of the user interfaces / behaviours and why they are wrong for localization needs (and should be removed in favor of the config translation module).

Tagging "Missing change record", as completing the change record updates here blocks a beta: #2083415: [META] Write up all outstanding change notices before release

The patch for this issue was committed on July 9, 2013, meaning that the change record updates for this issue have been outstanding for more than six months. Let's get https://drupal.org/node/1876852 updated so that we can close this issue.

Updated the change notice as requested. https://drupal.org/node/1876852/revisions/view/2503042/6882875