Closed (fixed)
Project:
Drupal core
Version:
8.0.x-dev
Component:
configuration entity system
Priority:
Normal
Category:
Bug report
Assigned:
Unassigned
Issue tags:
Reporter:
Created:
15 Jun 2014 at 19:15 UTC
Updated:
29 Jul 2014 at 23:41 UTC
Jump to comment: Most recent, Most recent file
Comments
Comment #1
tim.plunkettLet's see what breaks.
Comment #3
tim.plunkettNo idea why we have that status handling. If a config entity wants status, they specify a key. They all currently use 'status', which defaults to TRUE.
Comment #5
tim.plunkettComment #7
tim.plunkettAdded this to ConfigEntityBase help debug tests:
+ function __get($name) {
+ throw new \Exception($name);
+ }
Comment #9
tim.plunkettComment #10
tim.plunkettOkay, took this into a testing issue, this should pass (without the __get hack).
Comment #11
tim.plunkettComment #12
berdirThis overlaps with #2144263: Decouple entity field storage from configurable fields, which will introduce a new method for this (as it also needs to work for non-entity field definitions there)
This is usually done as language()->id, we need a langcode() method.. :)
Comment #13
alexpottRe @Berdir's #2 - how about using $entity->language()->getId()
Patch also changes a couple of copies of the $status property to protected.
Comment #15
alexpottSo #1936216: Configuration language selectors should have English even if English is not on the site means that Config Entities should be able to be in English even if the site does not have english enabled. This is interesting since
Entity::language()means that we can end up in situations where$entity->language()->getId() != $entity->langcode.Comment #16
gábor hojtsyLooks good to me.
Comment #18
alexpott15: 2286681.15.patch queued for re-testing.
Comment #19
alexpott#17 was a head fail and a rtbc queue retest... so back to rtbc.
Comment #20
webchickCommitted and pushed to 8.x. Thanks!