Handle entity references on import

@id should be deserialized to a usual entity reference field. REST module should just store that reference, it should not validate it nor should it retrieve the referenced entity.

I don't think we want to determine anything on the reference, the caller/client has to make sure that the referenced entity is already there. The entity validation API could determine If the referenced entity does not exist and throw an error in that case (see also #1696648: [META] Untie content entity validation from form validation).

Do we require UUIDs for entity references? I need to look up how entity references work in D8.

We discussed this on today's REST call. Here's the readers' digest:

In REST speak, URIs are the GUID. In Drupal speak, UUIDs should be the GUID. REST module should favor REST speak, so URIs. However, we also can provide UUIDs as an assist to allow processing code to convert to "SameAs", an RDF/JsonLD property that means "I have a different URI, but I'm really just a copy of X". (Think of it as the more abstracted rel="canonical".)

Client-initiated (pull) vs. Server-initiated (push) content replication: We need to allow for both, as both have valid use cases.

Any entity with an Entity Reference field on it needs to be addressed. That is all nodes (taxonomy and users), so this is a required feature to handle in at least some fashion. However, core doesn't have to provide the ideal solution, just a solution that can be enhanced via contrib in a sane way.

JSON-LD allows for inlining of referenced resources in place of their ID. We're... not sure how to deal with that yet. However, the only problem with every resource/entity being its own request, even when syndicating a large number of objects, is performance via lots of HTTP requests. For now, we don't deal with that.

Our proposed plan, therefore, is:

- Add a "REST Reference" field type (based on Link or ER or both). This field type references another entity by URI, not by UUID or entity ID. It probably looks like a stripped down Link field, and may subclass from either Link or ER. (While our use for this field type is internal only, I don't think there's any reason we shouldn't expose it to the user as a worthwhile field unto itself.)
- The Deserializer gives us an Entity object, but with REST Reference fields on it in place of anything with a URI reference, vis, all ER fields are replaced with REST Reference fields.
- We write a "Deferencer" service that, in core, replaces REST Reference fields with ERs if the target is known, and with an empty ER if not.
- REST module uses Dereferencer on PUT.
- The Dereferencer service is, however, entirely decoupled from the rest of REST module so it can be used by other client code (REST clients, syndication clients, Feeds module, Deploy, etc.) , too.
- Contrib can replace the Dereferencer with one that is more powerful/flexible/configurable/awesome.
- This fancier Contrib-based Dereferencer should use a pluggable strategy approach, so that fields can be configured per-instance how they should be translated. Likely options are: Discard if we don't already have a local copy of the referenced resource; fetch the referenced resource with another GET, save it, then reference it (this would be recursive); Replace a non-local URI with a default value (such as setting all users to some default import user when they're pulled in). There may be others. That's why it's pluggable/configurable.

The nested GET approach would replace Deploy module's current tree-building approach, which all happens sender-side, not client-side. Circular references would be handled by detecting a circular reference and bailing, as Deploy does now, because we don't want to deal with that. Alternatively, a really fancy dereferencer strategy could do a "save A, save B, save A again" approach if it felt like it. Again, yay pluggable.

Possible pitfalls:
- Will the "put on the wrong field and then replace it before saving" logic break Entity API?
- Will the client-side dependency recursion asplode?

Needs feedback from domain experts in the above areas.

Mitigating the complexity of variable depth, that's something we only need to support for GET requests, and therefore it's something that should be entirely cache-safe. So as long as you have a proper HTTP cache active you shouldn't be able to DDOS Drupal, just your cache. :-) (Even if your cache is in-PHP via HttpCache.) We can also set a system-wide maximum legal depth, which we probably want to do anyway.

Ultimately I think the Dereferencer plan sounds sane. I don't have a lot of insight into the implications for Entity API though. Will client-side dependency recursion asplode? Sure but that's the nature of the beast. I think that should be on the client to solve, not us.

I also had a discussion on IRC with crell about the option of inlining referenced entities. I personally am not a fan of this. If someone wants to inline data, they can plug in their own module to do it. When and how to choose to inline data is very very use-case specific, and I'd rather we just not deal with it at all than choose an arbitrary level of nesting with no specific reason in mind. Crell was saying its unlikely this is going to happen anwyays, I just wanted to encourage that train of thought :)

Well the primary "client" is probably Feeds module, so we can't punt that question entirely... :-)

I don't think anyone suggested an arbitrary nesting level to always use. Rather, the consideration was to allow the client to specify a recursion level in the URL.

Well, you also suggested hardcoding a max which makes it arbitrary.

As a cap to keep someone from doing /node/5?depth=50000, sure. But for well-behaved clients whether they do ?depth=2 or ?depth=4 should be up to them.

I'm ok with leaving inlining to contrib. Even if someone wants to make an argument for it being in core, I think it can be a follow up rather than bogging down the scope of this issue.

What @effulgentsia said.

Concur

Sorry for coming in a bit late in the game here. I have been busy with other things lately™.
Anyhow, here's my ¢2:

The approach with a Dereference service sounds clean and good. Unfortunately I haven't been involved in the IRC discussions lately, but I assume there's still a lot of things to figure out with that service. One things I come to think about;

How we map between REST Reference fields and Entity Reference fields for the core implementation of that Dereference service? On import we need to know what ER fields we should put in-place of a particular REST reference field. The same goes for export I guess, just the other way around.

On the inline thing; I'm not a huge fan of that either.

If in-lining is out-of-scope for this issue, what is it's main scope then? Dealing with circular dependencies?

Incoming JSON-LD contains entity ref field 'field_er'... deserializer creates a stub entity and uses the value of '@id' for the 'rest_import_uri'.

Entity-API does not suppport the concept of stub-entities any more. Either it's an entity or not, but of course you can come up with an entity-like data structure meanwhile.

- Add a "REST Reference" field type (based on Link or ER or both). This field type references another entity by URI, not by UUID or entity ID. It probably looks like a stripped down Link field, and may subclass from either Link or ER. (While our use for this field type is internal only, I don't think there's any reason we shouldn't expose it to the user as a worthwhile field unto itself.)

hm, exchanging field types on the fly won't work. It's either an ER field or a REST reference field, but not both. Maybe, we could have an interim data structure which are not entities that look different and then in a second iteration make them real entities?

But, is it really necessary to have the REST reference field. Couldn't we just skipping the value and associate an interim REST reference object with it, which holds everything needed until the value can be set? We could just write to $entity->er_field->rest_data ?

We could just write to $entity->er_field->rest_data ?

@fago: can you elaborate on this? With EntityNG/TypedData API, what's the proper way for rest.module to define an additional property on the EntityReferenceItem type? And to make sure this additional property isn't itself persisted to storage or serialized.

@fago: can you elaborate on this? With EntityNG/TypedData API, what's the proper way for rest.module to define an additional property on the EntityReferenceItem type? And to make sure this additional property isn't itself persisted to storage or serialized.

+++ b/core/lib/Drupal/Core/Entity/Field/Type/EntityReferenceItem.php
@@ -52,6 +52,13 @@ public function getPropertyDefinitions() {
+      // @todo Ask fago how to add this from REST module now that
+      // hook_entity_property_info_alter is gone.
+      self::$propertyDefinitions[$entity_type]['rest_import_uri'] = array(

As I understand it, the Rest-import URI is just needed during import.

Thus, what I was referring to is setting arbitrary, custom properties on the object without registering them at all. Such as we do set $entity->content - it's just interim state we throw on the object and remove once we are done.

+++ b/core/lib/Drupal/Core/Entity/Field/Type/EntityReferenceItem.php
@@ -78,6 +85,14 @@ public function setValue($values) {
+    //@todo This really shouldn't be here. Is there a way to add a property to

Nope. Indeed introducing alter hooks at that level would be interesting.

+++ b/core/modules/jsonld/lib/Drupal/jsonld/JsonldEntityNormalizer.php
@@ -44,6 +44,14 @@ public function normalize($entity, $format = NULL, array $context = array()) {
+    // Since this Normalizer only supports entities, require that the entity
+    // reference handler plugin manager is passed in. Calling code should
+    // obtain this from the container.
+    if (!isset($context['entityreference_handler_plugin_manager'])) {
+      throw new UnexpectedValueException("'entityreference_handler_plugin_manager' must be included in the context when denormalizing.");
+    }

Well, we should only throw exceptions if we actually need the reference handler. If we do not encounter any entity reference fields then we don't need it.

And I'm not sure that $context is the right place to inject the reference handler. Can't we add the handler to the serializer service somehow? Or to the normalizers/denormalizer services?

I am not OK with using drupal_container() inside a config entity. :-)

A config entity is a data object. It should not be doing anything other than being an object.

It isn't clear to what extent JSON-LD's processing algorithm will support embedding referenced entities when using the advanced features that we plan to use (property generators & annotations).

I'm not sure I understand what you mean here but you can always add properties to a node object ({ "@id": ...}). Neither property generators nor annotations prevent that.

The processing algorithm still isn't complete and the implementations have bugs which make it very hard to determine.

The algorithms are complete and at least my JSON-LD processor is up to date. Which bugs did you encounter?

I'm speaking specifically about whether round-tripping would be supported if you have deeply nested node definitions and were also using property generators. My uncertainty comes from the discussions in October, there was a lot of talk of flags and node references.

Yes, that's fully supported. We kept it as simple as possible and didn't introduce any flags. You can test everything in my JSON-LD playground.

Even if JSON-LD processors do round-trip in this case, I still don't know that we want to support it. By using both we exacerbate the data explosion problem that you pointed out early in the property generators discussion.

That might be a problem, but if you need the data anyway, it doesn't really matter how you retrieve it. If you don't need it, don't include it or include just the relevant parts (e.g., just @id and the UUID).

I emailed you about the "bug" I was referring to at that time... it turned out it wasn't a bug

Oh OK, I remember. Let me know if there are some missing features that would help you for your task - I would be happy to add them to my JSON-LD processor. As I understood it, you aren't using a JSON-LD but process the data directly, right?

+++ b/core/modules/jsonld/lib/Drupal/jsonld/JsonldEntityNormalizer.php
@@ -112,7 +114,11 @@ public function denormalize($data, $class, $format = null, array $context = arra
+        $context = array();
+        if ($handler_settings = $entityreference_settings->getHandler($fieldName)) {
+          $context['entityreference_handler'] = $this->entityReferenceHandlerPluginManager->createInstance($handler_settings['plugin_id'], $handler_settings['settings']);

I think this should use getInstance() instead of createInstance().

+++ b/core/modules/serialization/lib/Drupal/serialization/Plugin/Core/Entity/EntityReferenceHandlerSettings.php
@@ -0,0 +1,134 @@
+ *   }
+ * )
+ */
+class EntityReferenceHandlerSettings extends ConfigEntityBase {
+

Why is this config entity needed?

Overall I cannot say much about the architecture. I think it is a good idea to start a serialization module, that separates the services better from the rest of core. They won't be needed on every Drupal site.

I just try to re-iterate what I see here: we need to de-reference entity references that come in as fields in the denormalizer. Usually we have references in an @id URI format, example: http://example.com/entity/node/554. We need to resolve that to nid 554. We think that references might look differently, e.g. a format could just contain UUIDs. Therefore we invent the entity dereference plugin system here, so that modules can provide their own strategy how to resolve references in their format.

I wonder if the dereference plugin system is really necessary. Why can't we assume that references always have to be represented as @id = http://example.com/entity/node/332 ? We could hard code that in our core implementation. If a contrib module wants to do it differently it simply creates its own denormalizer for references for its own format and be done with it?

Per #57, I like the separation of dereferencer from normalizer, because I can definitely envision there being multiple formats/normalizers implemented throughout contrib that are all RESTful, and therefore work with URIs, and therefore require something to convert from URI to entity id. That something should be pluggable without requiring every individual normalizer to be overridden.

I also like the upgrade here of a $context array passed throughout the serialization pipeline, and injecting the dereferencer there.

However, I share klausi's concern that a plugin manager and config entity for configuring different dereferencers for different situations feels too heavy. Especially since a UI for configuring this should neither be a requirement for this issue, and potentially, shouldn't even be in core at all.

What if we go back to the suggestion in #4 to make the dereferencer just a simple service (no config entity, no plugins)? However, we make the getEntityId() method on that service take some parameters, like $referencing_entity (hopefully, there's a better name for this: what I mean by it is if we're deserializing $node, and it has a 'user_id' field, then this is the $node entity, not the $user entity), $format, and $field_name (or maybe more info about the field than just its name). That way, in core, we can ship with a simple service that just does one default implementation. However, contrib can swap this service out with something that can route to different plugins based on these arguments. That same contrib module could also provide a UI for managing those configurations. Or, if we decide such a plugin/config based system belongs in core, we can try to work it out in a separate issue from this one, using what's been done here already as a starting point.

For example, how would the URI dereferencer know that JSON-LD uses the @id key for the URI?

Excellent point. I missed where that fits into the architecture. Can the next patch include a test ER handler that uses @id?

From the issue summary:

id: entity_test.entity_test.drupal_jsonld
uuid: 1caf48f3-95b6-4506-9b01-1c44052b3c8f
targetEntityType: entity_test
bundle: entity_test
format: drupal_jsonld
entityreferenceHandlers:
  user_id:
    plugin_id: configured_value
    settings:
      value: 1

First of all, I think targetEntityType is confusing, because in #1801304: Add Entity reference field, 'target' refers to the referenced entity, not the entity containing the ER field. I don't know if there's standard terminology for the "referencing entity". Perhaps here, though, simply 'entityType' would be sufficient.

Secondly, I'm concerned this organization is too granular. It means every ER field of every bundle requires explicit configuration (unless the global default is used), rather than, for example, having per-referencing-entity-type defaults, or per-target-entity-type defaults. Do we have some known, common use cases in mind, that we can use to evaluate the appropriate levels of granularity where defaults should be applied?

Meanwhile I also wonder if it's not granular enough. For a given entity type / bundle / format, do we need to support multiple mappings? For example, during deployment run 1, use node.article.drupal_jsonld.1.yml, and for deployment run 2, use node.article.drupal_jsonld.2.yml. Or, when syndicating from externalsite1.com, use a different configuration than when syndicating from externalsite2.com.

+++ b/core/modules/jsonld/lib/Drupal/jsonld/JsonldEntityReferenceNormalizer.php
@@ -30,24 +30,36 @@ class JsonldEntityReferenceNormalizer extends JsonldNormalizerBase implements De
-  public function normalize($object, $format = NULL, array $context = array()) {
-    // @todo If an $options parameter is added to the serialize signature, as
+  public function normalize($object, $format = null, array $context = array()) {

"null" should be all upper case.

+++ b/core/modules/serialization/lib/Drupal/serialization/Plugin/Core/Entity/EntityReferenceHandlerSettings.php
@@ -0,0 +1,133 @@
+<?php
+/**
+ * @file
+ * Contains Drupal/serialization/Plugin/Core/Entity/EntityReferenceHandlerSettings
+ */

Should start with a "\". Also elsewhere.

+++ b/core/modules/serialization/lib/Drupal/serialization/Plugin/serialization/entityreference_handler/UriDereference.php
@@ -0,0 +1,63 @@
+  public function getEntityId($data, $format, $serializer) {

Doc block is missing.

+++ b/core/modules/serialization/lib/Drupal/serialization/Plugin/serialization/entityreference_handler/UriDereference.php
@@ -0,0 +1,63 @@
+    $entity = entity_load_by_uuid($this->getSetting('target_entity_type'), $uuid);
+    return $entity->id();

This will throw a fatal error if the entity does not exist, because the load returns NULL. So we need some error handling here.

+++ b/core/modules/serialization/lib/Drupal/serialization/Plugin/serialization/entityreference_handler/Uuid.php
@@ -0,0 +1,42 @@
+    $entity = entity_load_by_uuid($this->getSetting('target_entity_type'), $uuid);
+    return $entity->id();

Same here.

+++ b/core/modules/serialization/serialization.module
@@ -1 +1,38 @@
+ * @param $entity_type
+ *   The entity type of the bundle.
+ * @param $bundle
+ *   The bundle.
+ * @param $format
+ *   The format of the data being deserialzed.

Data types are missing.

But overall I guess this makes sense.

I just watched your video Lin. A couple of question and some thoughts about how I would approach this problem.

The basic problem is that you have entities that can reference other entities. This implies that there must be a way to uniquely identify identities. In your case those identifiers are UUID or URLs I think. Since this stuff is being used for a Web API, entities (= resources) should be identified by URLs. You can map them to UUIDs internally (Drupal uses UUIDs internally, right?) but don't need and should not to expose the fact that you are using UUIDs - that's an implementation detail.

Given that you now have a mechanism to uniquely identify each entity, you need to able to serialize/deserialize that somehow. In JSON-LD you would use @id for this. In other formats you would probably use something else. The point is that it depends on the format so I don't think that needs to be configurable via those plugins you describe in your video. The only thing you'll need is a service which translates between the URLs used externally to the UUIDs used internally. Things like changing the author should be either be done as a preprocessing step (format-specific) or better as a postprocessing step. This has the advantage that it's very simple to implement also for other Drupal devs as you have your object structure with its well defined interfaces in place, you just need to traverse the object graph and replace all author references.

I haven't read the whole discussion in this issue so maybe I'm missing something. What happens if you import the same data twice? Will it be duplicated? The reason I'm asking is because in the example actually also the articles itself are entity references. They just don't exist yet in your system (at the first run).

Hope this helps more than it confuses :-)

To be clear, this isn't just about how JSON-LD will handle entity references. It is also about how custom JSON will handle entity references. For example, one API might serve "application/json" using an "href" key, while another might serve "application/json" using a "uri" key

Right, but that's a serialization issue and not a reference-handling issue. Whatever you do, you can't make the plugin's settings near flexible enough to accomodate the differences anyway (I'm takling about the uri_key setting in your video). Just imagine one day you decide to expose it in XML (attribute or value?) or a binary format (hmm.. an offset maybe?). Only the serializer will know how to extract the referenced entity's identifier and can then just pass it to the EntityReferenceResolver (or whatever you call it) to get the internal reference.

Or there could be a Microdata JSON module which uses both "itemid" and particular properties such as Schema.org's "url" property to indicate URIs for resources. Since this is configured on a field instance basis, these use cases could be accommodated. This flexibility is something that Drupal devs are going to have to decide whether we want or not.

I don't understand this. I think the snippet above hasn't much to do with entity references. This is how internal properties are mapped to to external properties (schema.org, FOAF, etc.). That's, IMO, an entirely different problem and probably much easier to solve. Just let a developer supply a (number of) strings (URLs?) a property should expand to. If she doesn't supply any, just generate one using the property's UUID (or whatever you use internally). But, AFAICT, this has nothing to do with how a reference is serialized.

Right, but that's a serialization issue and not a reference-handling issue.

I started delving into the code some more to see where the separation both is currently and could otherwise be made. I continue to like the plugin part of the architecture, but am concerned about the configuration part, so I'm interested in ideas that reduce the configuration that's needed, like the ones by lanthaler. I'll post more here if/when I figure something out that's worth sharing. I welcome others to do the same and/or provide other feedback as well.

Sorry, I think I wasn't clear enough. When I said serializer in my posts above I always meant the combination of a concrete normalizer and encoder. The encoder will remain the same if two serializations use the same syntax (such as JSON-LD and JSON do e.g.). It's the normalizer which has to change based on flavor of the format. So, as you already did, there are two separate normalizers for JSON and JSON-LD.

It also only accommodates APIs which define their own media type. For example, the Stormpath API uses an "href" key where JSON-LD uses "@id".

Isn't that effectively a different format? Even though they don't label their responses accordingly? It's similar to the various XML-based formats (plain XML, Atom, XHTML, ...). What's the advantage of introducing another layer of abstraction in the form of plugins? [That's really a question and not a statement :-)] Isn't it easier for a dev to modify (subclass) an existing normalizer to accomodate the changes than to configure a plugin? How often does that really need to be done? I think only when another API which uses a different contract/format is being integrated.

Maybe the simplest thing would be to define a EntityNormalizerInterface that extends Symfony's NormalizerInterface by a number of methods to normalize/denormalize fields of certain types (e.g. normalizeEntityReferenceField($field)). In most cases you would then only have to overwrite that method for a specific format.

The configuration would then be as simple as choosing the format json (which would be Drupal JSON), json-stormpath, json-ld, etc. Wouldn't that be much simpler and easier to understand (less magic involved)? I just don't think you can capture the differences of the various APIs in a small number of plugins.

Edit: In the end, you could implement those interface methods also using the strategy pattern, so that you would end up having plugins. Nevertheless I think it would make sense to give such a concrete normalizer a name reflecting the "format". When I say format, please don't confuse that with the $format parameter in the Symfony serializer. It could as well be an option for a format (an entry in the $context parameter).

No, we have no way of distinguishing between two "application/json" requests/responses within Serializer. I don't think we want to introduce informal-contract sniffing into our system, either.

TBH, overriding the $format with $context['format'] feels more like a hack to me, especially since Serializer relies on the $format key for caching which Normalizer to use. I'm also not sure how we would populate that $context['format'] parameter... informal-contract sniffing? Define it in the REST plugin metadata for the route?

How do you link the serializer to the the right plugins (instances)?

Btw. Is there a way to have a look at the code via some Web interface (not just patches)?

I watched the video and read #89but still don't have much to say about the proposed architecture. The proposed pattern is used in Serializer as mentioned and it resembles the Matcher/PartialMatcher pattern used during routing.

I also appreciate that this patch adds dereference for uuid fields. Very handy!

So, sounds good to me!

#91: 1880424-91-entity-reference-import.patch queued for re-testing.

However, I think we might want to simplify this.

If you want to post a simplified patch, go for it, but I have no concerns with the approach in #97. I think both ChainResolver and UuidReferenceInterface are sufficiently straightforward.

+++ b/core/modules/hal/lib/Drupal/hal/Normalizer/EntityReferenceItemNormalizer.php
@@ -61,7 +63,43 @@ public function normalize($field_item, $format = NULL, array $context = array())
+    if (!isset($context['target_instance'])) {
+      throw new LogicException('$context[\'target_instance\'] must be set to denormalize with the FieldItemNormalizer');
+    }
+    if ($context['target_instance']->getParent() == NULL) {
+      throw new LogicException('The field item passed in via $context[\'target_instance\'] must have a parent set.');
+    }
+
+    $field_item = $context['target_instance'];
+
+    $field_definition = $field_item->getDefinition();
+    // If this field is translatable, we need to create a translated instance.
+    if (isset($data['lang'])) {
+      $langcode = $data['lang'];
+      unset($data['lang']);
+      if ($field_definition['translatable']) {
+        $field_item = $this->createTranslatedInstance($field_item, $langcode);
+      }
+    }

That's a lot of duplication with FieldItemNormalizer::denormalize(). Can we add a helper function to the base class in order to centralize this?

+++ b/core/modules/hal/lib/Drupal/hal/Normalizer/EntityReferenceItemNormalizer.php
@@ -61,7 +63,43 @@ public function normalize($field_item, $format = NULL, array $context = array())
+      while (is_array($uuid)) {
+        $uuid = reset($uuid);
+      }

Why a while() instead of an if()? In either case, please add a comment.

+++ b/core/modules/serialization/lib/Drupal/serialization/EntityResolver/EntityResolverInterface.php
@@ -0,0 +1,30 @@
+  /**
+   * Resolve an ID to the corresponding entity.
+   *
+   * If the local id is found, the target_id property should be set in the
+   * returned array. Otherwise, if the EntityResolver knows how to dereference
+   * the value, the dereferencer should be set.
+   *
+   * @param \Symfony\Component\Serializer\Normalizer\NormalizerInterface $normalizer
+   *   The normalizer which is handling the data.
+   *
+   * @return array|NULL
+   *   Returns an array containing either target_id or dereferencer, if found.
+   *   Otherwise, return NULL.
+   */
+  public function resolve(NormalizerInterface $normalizer, $data, $target_type);

1. We need PHPDoc for $data and $target_type.

2. The patch doesn't include either a test or any docs on how a dereferencer is expected to work.

This just moves the non-hal-specific services from hal.services.yml to serialization.services.yml to match the module they were in in #97.

Some docs and variable name cleanup. Also changes the return value of EntityResolverInterface::resolve() from an array that can only contain one key, to just the value of that key. Once we add support from some other kind of return value (like a dereferencer), then we can change this interface to support that, but in the meantime, I think this is clearer.

Although the interdiff in #102 includes a small code change, I'll be bold and call it minor enough to RTBC this anyway. If anyone objects to that, please set it back. Or, if anyone objects to that change post-commit, I'd be ok with that interdiff being reverted and discussed in a follow up.

#102: 1880424-102-entity-reference-import.patch queued for re-testing.

Chasing HEAD.

Yay! No more database schema for field configuration! Back to RTBC.

#108: 1880424-108-entity-reference-import.patch queued for re-testing.

Committed to 8.x. Thanks!

Don't think that got pushed, so trying again:

Committed and pushed to 8.x. Thanks!