Make ECK entities translatable (entity translation integration).

Is there any update on this?
Would it mean an incompatible change letting entity translation do the heavy lifting?

Requires entity_translation patch from comment 1 #1866076: Add support for non-entity load tokens when declaring translations

Here is a stab at it.

Whoops looks like I forgot the translation handler.

Here is another.

Thanks for your work on this!

I tried your patch and it allowed me to translate my eck entity
and the translated field values are shown alright.

I haven't found a way to get the field *labels* translated, though.

You can use the field translation module in i18n to translate the labels: http://drupal.org/project/i18n

The patch does not work for me. I'm getting:

Exception: Cannot initialize entity translation path variables (invalid path scheme). in EntityTranslationDefaultHandler->initPathVariables() (line 1431 of /Library/WebServer/Documents/test/processing_org/sites/all/modules/entity_translation/includes/translation.handler.inc).

when trying to view a bundle of an entity that has been set to be translatable ( /entity_name/bundle_name/id ).

I have
Drupal 7.18
entity_translation 7.x-1.0-beta2+7-dev
eck 7.x-2.0-rc1+6-dev

I found that during that call a false bundle instance is passed around, not sure where that comes from ... it arrives in EntityTranslationECKHandler as $entity with an id NULL and type set to the actual id.

In reply to myself (#8), i filed a bug at entity_translation about this: http://drupal.org/node/1877032

Still requires #1866076: Add support for non-entity load tokens when declaring translations
Adding support to replace title with translatable field as well.

@fjen try ECK 7.x-2.x-dev

the previous patch in #10 missed the file eck/includes/translation.handler.eck.inc and will cause some fatal error about a class not found.

I rolled another one to add that part back (find that part from #5).

Still requires #1866076: Add support for non-entity load tokens when declaring translations

ignore me

Apart from the issue discussed here, which focus on field-level translation, I've started to work on Entity-level translation (Translation Set API from i18_translation).

Code is shared in this sandbox : http://drupal.org/sandbox/garphy/1966680

The last patch doesn't seem to apply. Has there been any progress on this or any workarounds? This makes ECK quite unusable.

Re-roll against 7.x-2.x

still requires #1866076: Add support for non-entity load tokens when declaring translations

+++ b/eck.entity.inc
@@ -440,14 +446,26 @@ function eck__entity__form($form, &$form_state, $entity) {
+  if (module_exists('entity_translation') &&
+    entity_translation_enabled($entity->entityType())) {
+    $handler = entity_translation_get_handler($entity->entityType(), $entity);
+    $langcode = $handler->getFormLanguage();
+  }
+  else {
+    $langcode = NULL;

I think you can use just entity_language() here.

I've applied both patches cleanly (to eck and et) and enabled translation for my field of my eck entity bundle but there is no translate tab anywhere. Am I missing a trick?

Did you enable another language?

Check if the translation is on nodes.

Permissions?

If anyone else had problems with patching:
seems like eck-entity_translation_integration-1798646-12.patch does not apply succesfully against eck-7.x-2.x-dev - failing to add

; Entity translation integration
files[] = includes/translation.handler.eck.inc

to eck.info

Adding the string manually makes entity translation work, although there is an error/warning appearing:
Strict warning: Only variables should be passed by reference in entity_translation_get_handler() (line 1777 of entity_translation/entity_translation.module) - but it seems like an issue with patch for entity_translation.

Yeah it's a little odd that the packing code would be in the way. On another note it still applies to 7.x-2.x HEAD.

Also @plach re:: entity_language() It has been a while since I have rolled this patch, but when patching this entity_language was not being set by entity_translation() soon enough, maybe it works now though? I don't recall the exact reason why this was not the case.

Hi
any news about adding translation to custom entities? before using the --dev version I had the language dropdown selection working at least, but no way to add transaltions ot the same entity. Now i tried the --dev version and the translations settings are gone in my bundles.
Is translation possible at this point? ECK looks very promising.
tx
Simone

Hi

any updates here, is this still working/applicable ? any intention to support any sort of translation before the 3.x branch is released ? :)

Thanks

This is a re-roll of the patch in #15 that applies to both 7.x-2.x and 7.x-2.0-rc2

It also fixes a bug(?) where title fields appear in the "Manage Fields" section for entity types that don't have titles.

...thanx

Hi,

Can someone explain what should happen when entity translation is enabled for ECK entities?

I've succesfully applied following patches but I can't see anything new :

• ECK : https://drupal.org/comment/7898133#comment-7898133
• Entity Translation : https://drupal.org/comment/7320766#comment-7320766

I've enabled translation at field level for my entity type, cleared cache. But I can't see any "Translate" tab when viewing my entity?

Thanks!

see these issues on Field Collections
#1344672: Field Collection: Field translation (entity_translation) support. - entity translation
#1316162: Support content translation and host entity cloning - content translation

the ideas being used there might be useful for ECK development

Hi,

I tested the patch via simplytest.me. The patch is still applying to the current dev, but I get no translation tab, also. I just can select the entity language at the edit form.

Any ongoing development? I might help, but where to start?

Thanks for the patches, its going into the right direction!

Edit: Tested the patch in combination with entity inline form for my particular use case. Unfortunately, its not working here, also. (Its still just displaying the non-translated fields. The translateable fields have "NULL" as value)

Patch works for me.

You must configure / enable the entities to be translatable on admin/config/regional/entity_translation to see anything.

Hide old files.

Patch didnt apply to the latest dev:

Checking patch eck.entity.inc...
error: while searching for:
      $wrapper->{$property}->set($form_value);
    }
  }
  
  $entity->save();

  drupal_set_message(t("Entity {$entity->id} - @entity_label has been saved", array("@entity_label" => entity_label($form['#entity_type'], $entity)) ));

error: patch failed: eck.entity.inc:507
error: eck.entity.inc: patch does not apply

Re-rolled the patch.

Just a quick review with some coding standard nitpicks and one item that needs attention.
@see http://drupal.org/coding-standards

1. +++ b/eck.entity.inc
   @@ -381,13 +387,25 @@ function eck__entity__form($form, &$form_state, $entity) {
   +    $langcode = NULL;
   

   Shouldn't this be LANGUAGE_NONE? And you can likely put this as the variable initializer above line 400 before the condition to initialize and save the else lines.

2. +++ b/eck.module
   @@ -835,3 +835,43 @@ function eck_entity_view_alter(&$build, $entity_type) {
   +
   +
   

   Extra line.

3. +++ b/eck.module
   @@ -835,3 +835,43 @@ function eck_entity_view_alter(&$build, $entity_type) {
   +    // Don't add title overrides to bundles without titles
   

   Period at the end of this sentence.

4. +++ b/includes/translation.handler.eck.inc
   @@ -0,0 +1,20 @@
   +    // Since we are using different bundle paths then use the bundle's path scheme.
   

   80 char limit.

Rerolled once again and fixed some of the problems mentioned in #32.

@garphy multilingual and translation are planned as full features for 7.x-3.x, if you roll the patch against 3.x I will go ahead and merge it, and we can have architectural and approach discussions afterwards since we don't even have an alpha of 3.x yet, but that should keep you from having to keep on rolling the patch. Thoughts?

I'd like to check up on the "dummy menu items note". Could you point me where it complains without them?

There is some more coding standards notes. Mostly double \n and lack of \n at EOF. Thanks for the re-roll @garphy!

Also want to keep this issue near the top of the queue:D

1. +++ b/eck.bundle.inc
   @@ -19,6 +19,22 @@ function eck__bundle__menu($entity_type) {
   +
   

   This new line isn't need either.

2. +++ b/eck.bundle.inc
   @@ -19,6 +19,22 @@ function eck__bundle__menu($entity_type) {
   +  // Dummy menu items so that entity translation will not complain about there
   +  // not being a default.
   +  $menu["$entity_type->name/%"] = array(
   +    'page callback' => FALSE,
   +    'page arguments' => array(),
   +    'access callback' => FALSE,
   +    'access arguments' => array(),
   +  );
   +  $menu["$entity_type->name/%/edit"] = array(
   +    'page callback' => FALSE,
   +    'page arguments' => array(),
   +    'access callback' => FALSE,
   +    'access arguments' => array(),
   +  );
   +
   

   Is this really needed? Where does it complain, I'd like to test this out.

3. +++ b/eck.entity_type.inc
   @@ -376,13 +376,55 @@ function eck__entity_type__info($entity_type) {
   +
   +
   
   +++ b/eck.module
   @@ -215,7 +215,7 @@ function entity_table($entities, $select = FALSE) {
        if (eck__entity_menu_access('view', $entity_type, $bundle, $id)) {
   

   Only needs one space.

4. +++ b/eck.info
   @@ -12,5 +12,8 @@ files[] = views/handlers/eck_views_handler_field_link.inc
    files[] = views/handlers/eck_views_handler_field_link_edit.inc
    files[] = views/handlers/eck_views_handler_field_link_delete.inc
    
   +; Entity translation integration
   +files[] = includes/translation.handler.eck.inc
   +
    ; Inline entity form integration
    files[] = includes/eck.inline_entity_form.inc
   \ No newline at end of file
   

   No newline at end of file.

5. +++ b/eck.module
   @@ -866,3 +866,43 @@ function eck_system_info_alter(&$info, $file, $type) {
   +
   +
   

   Same with here.
   https://drupal.org/coding-standards#indenting

@joelpittet: I don't know if the dummy items are really needed. Let's check as it effectively sounds like a hack.

@fmizzell: I didn't yet checked out the 3.x branch so I'm not aware of the differences w/ 2.x. It's sounds reasonnable to commit this in 3.x as it seems quite stable on my 2.x setup since a while now.

(but i'll still need a patched 2.x setup until 3.x can safely take over ;)

@joelpittet Some of the new cs issue might have been introduced by me, let's focus on the functionality, and then we can clean up all coding standard issues in one shot once it is merged. If you have objections to this, let me know. Nevermind, since this is going to be focused toward being a patch for 2.x, let's keep the patch clean :)

@garphy, very well, 2.x is the version most people will be using for at least a couple more months, so I will take on the task of moving things to 3.x.

I'll be glad to help out on the 3.x patch. Let's cross reference the 3.x issue when it's open.

OK I have addressed the reset of the nit picking coding standards from 32 & 35.

I also tested to re-affirm the validity of the dummy items. I suppose alternatively we could possibly remove this additional validation that entity_translation is attempting? Otherwise we still need them.

Incurred notices:

Invalid base path defined for entities of type Foobar: matching menu item not found for foobar/%
Invalid view path defined for entities of type Foobar: matching menu item not found for foobar/%
Invalid edit path defined for entities of type Foobar: matching menu item not found for foobar/%/edit
Invalid translate path defined for entities of type Foobar: parent menu item not found for foobar/%

From: _entity_translation_validate_path_schemes(&$schemes, $entity_type_label, $items = FALSE, $warnings = FALSE)

Code reference: http://cgit.drupalcode.org/entity_translation/tree/entity_translation.mo...

Thanks,

Jonathan

Forgot the new line at the end of the info file.

@fmizzell I'm all for not fixing all the coding standards for the module in this issue and should open up a followup for that. BUT it would be easier to review if the new code or changed code doesn't introduce new coding standards mistakes because it's hard to see the forest for the trees(...If all you see is the trees;).

Oh and @grndlvl nice work! grndlvl++ Looks like you got them all:)

And thank you for re-affirming and the error output you get when the dummy items aren't present. How about opening an issue in their queue and just put an @todo Remove these dummy items once issue https://drupal.org/node/XXXXXXX is resolved.?

That way they are aware of the issue and we can move forward with this patch?

* Created a ticket over at #2273189: Account for entities that may not create callbacks at "entity/ID" or "entity/ID/edit".
* Added todo

Here's a re-roll

Now with patch

And now without the packaging info. The reason that the patch is so much larger is because my editor removes all trailing spaces according to the Drupal Coding Standards.

The reason that the patch is so much larger is because my editor removes all trailing spaces according to the Drupal Coding Standards.

It's generally a good idea to do code style changes separate from functionality changes. It makes it easier to tell what the patch is doing, easier to review the changes, and reduces the chances that the patch will need to be re-rolled.

The easiest way to get rid of those line ending changes would probably be to generate the patch again using git diff --ignore-space-at-eol instead of just git diff.

I could apply the patch only on the 3.x version. Was it not meant in #39 that this is a patch for 2.x and 3.x gets a separate issue? Did I miss something?

Using the patch with 3.x results in

 Fatal error: Class 'EntityTranslationECKHandler' not found in /.../eck-3.x-test/drupal/sites/all/modules/contrib/entity_translation/includes/translation.handler_factory.inc on line 93

if I try to create an entity.

It seems that

diff --git a/includes/translation.handler.eck.inc b/includes/translation.handler.eck.inc
new file mode 100644
index 0000000..b1fda17
--- /dev/null
+++ b/includes/translation.handler.eck.inc
@@ -0,0 +1,20 @@
+<?php
+
+/**
+ * @file
+ * ECK translation handler for the entity translation module.
+ */
+
+/**
+ * ECK translation handler.
+ *
+ * Overrides default behaviours for ECK properties.
+ */
+class EntityTranslationECKHandler extends EntityTranslationDefaultHandler {
+  public function __construct($entity_type, $entity_info, $entity) {
+    parent::__construct($entity_type, $entity_info, $entity);
+
+    // Since we are using per-bundle paths then use the bundle's path scheme.
+    $this->setPathScheme($entity->type);
+  }
+}

Is missing in the latest 2 patches.

Try 44 against 7.x-2.x HEAD.

OK, I can confirm that #44 is at the moment the patch that applies against 2.x and hast all the translation handler stuff.

Commit 6b2be8f39e976260df1a30a8dda73f6ede3a5c6a made #44 non applicable on latest 2.x.
I'm rerolling #44 to accomodate coding standards enhancements.

Great work, I really need this to work :)

I think all is working great except like axe312 I do not get a translation tab on my entities. I did configure / enable the entities to be translatable on admin/config/regional/entity_translation.

Any ideas what I am doing wrong?

Jens

Hey there,

we use this patch to create translatable entities build with eck referenced within an node page. For several times we ran into problems setting this environment up. Here is a short description how to to that:

Patch it:

• Patch ECK with: https://www.drupal.org/node/1798646
• Patch IEF with: https://www.drupal.org/node/1545896
• Patch ER with: https://www.drupal.org/node/1674792

Configure it:

• Make sure your entity reference field is NOT translatable.
• Enable the language property for your eck entity -> /admin/structure/entity-type/[YOUR_ENTITY_TYPE]/edit
• Enable entity translation for your entity -> /admin/config/regional/entity_translation

A lot of stuff to do, but it is working for us in several projects :)

Greetings from Berlin, Germany
Ben

Patch #55 not suitable for last dev, however I managed to "manually" applied those changes, and it works ok, together with eck_revisions btw.

The following change present in #55 is already present in last dev.

@@ -376,13 +382,23 @@ function eck__entity__form($form, &$form_state, $entity) {
     }
   }
 
-  $form['submit'] = array(
+  $form['actions'] = array(
+    '#type' => 'actions',
+  );
+  $form['actions']['submit'] = array(
     '#type' => 'submit',
     '#weight' => 10000,
     '#value' => t('Save'),
   );

Hi, I edited patch #55 to fit 7.x-2.x branch but I can't get it work...

Drupal version: 7.35-dev
ECK version: 7.x-2.0-rc4
with https://www.drupal.org/files/issues/eck-entity_translation_integration-1...
Entity Translation version: 7.x-1.0-beta3
with https://www.drupal.org/files/entity_translation-add_support_no_load_toke...

I can see Translate tab in my entity view but in translate form there is no data filled (from original lang and it should be) and after save its not saved without any message and I can see errors "Strict warning: Only variables should be passed by reference in entity_translation_get_handler() (line 1779 of /var/www/sitename/sites/all/modules/contrib/entity_translation/entity_translation.module)."

The last 59 patch failed against last dev because:
There is a new line 'view callback' not expected by the patch on

@@ -378,13 +378,54 @@ function eck__entity_type__info($entity_type) {
     ),
    // Inline entity form module integration.
    'inline entity form' => array('controller' => 'EckInlineEntityFormController'),
    'view callback' => 'eck__entity__view_callback',
    'translation' => array(

And translation.handler.eck.inc should be located inside the includes folder, but it is created on the root module.

I finally got it working today with this:

1) Last Dev 7.x-2.0-rc6+6-dev

2) Patched from 55 (no 59) applied manually to understand what's going on (and because neither 55 or 59 didn't work out-of-the-box):
- Some code is already present in dev
- When patching eck.entity_type.inc > function eck__entity_type__info($entity_type),
insert the code 'translation' => array( .... before the'view callback'.

    // Inline entity form module integration.
    'inline entity form' => array('controller' => 'EckInlineEntityFormController'),
    'translation' => array(
      'entity_translation' => array(
        'class' => 'EntityTranslationECKHandler',
        // This will be populated based on the bundles.
       'path schemes' => array(
          'default' => array(
            'base path' => "$entity_type->name/%",
            'path wildcard' => '%',
          ),
        ),
      ),
    ),
    'view callback' => 'eck__entity__view_callback',
  );
  // Add title replacement support for translations.

- make sure that the file "translation.handler.eck.inc" is created inside the includes folder

3) As stated in #57 Enable the language property for your eck entity

@pedrosp can you please create a clean patch against the latest dev so others can test this easy ? Thanks.

There you are.
Be kind, this is my first patch, git powered a-la-drupal, ever ;)

BTW, I wonder if there is a way to make mandatory through code, the language property on the ECK when this code is applied.

i can't apply #63 against 7.x-2.x-dev with drush make.
when applying it manually the translation.handler.eck.inc file is created in the root directory

Removed trailing "garbage" from the .info file (previous patch maybe made against a .tar.gz -dev release ?)
Replaces patch #66 which doesn't apply against a git checkout.

+++ b/eck.entity.inc
@@ -354,6 +354,12 @@ function eck__entity__form($form, &$form_state, $entity) {
+  ¶

Extra whitespace.

+++ b/eck.entity.inc
@@ -392,7 +398,14 @@ function eck__entity__form($form, &$form_state, $entity) {
+  $langcode = LANGUAGE_NONE;
+  if (module_exists('entity_translation') &&
+    entity_translation_enabled($entity->entityType())) {
+    $handler = entity_translation_get_handler($entity->entityType(), $entity);
+    $langcode = $handler->getFormLanguage();
+  }
+
+  field_attach_form($entity->entityType(), $entity, $form, $form_state, $langcode);

Missing comments explaining what the code is doing.

+++ b/eck.entity_type.inc
@@ -384,14 +384,54 @@ function eck__entity_type__info($entity_type) {
+    $info[$entity_type->name]['translation']['entity_translation']['path schemes'][$bundle->name] = array(
+      'base path' => "{$entity_type->name}/{$bundle->name}/%",
+      'translate path' => "{$entity_type->name}/{$bundle->name}/%/translate",
+      'path wildcard' => '%',
+    );

Missing comments.

Updated patch addressing code review in #68.

After applying the patch to the latest dev-version pulled by drush and applying the patch I get Fatal error: Class 'EntityType' not found in /var/www/sites/all/modules/contrib/eck/eck.module on line 301.

I'm also using the latest Entity Translation Dev from drush.

Re-tested this with a new installation.

eck 7.x-2.0-rc6+7-dev
ET 7.x-1.0-beta4+8-dev

Patch #69 eck-entity_translation_integration-1798646-69.patch

This is the combination that works.

Now that #1824772-21: Add entity properties to "Manage Fields" form has been committed, the title field will be added to the Manage Fields UI (if enabled per-bundle at admin/structure/entity-type/ENTITY_TYPE/BUNDLE/edit).

Re-rolled without eck_field_extra_fields().

Latest dev from eck has the patch already included but i cant see a translation tab. i enabled the entity_translation for my eck type and enabled translation for the bundle. i see the language field but no translation tab. any suggestions?

EDIT: It was a "Path error" when i go to /contents//edit i see the translation tab but admin/structure/entity-type//contents/ the tab is not available.

This causes issues if example panels is defining a path that matches the eck dummy paths.

Sorry re-opening this because those dummy paths cause more problems then they sole I believe. Maybe a follow-up is warranted?

Here's a partial revert.

Actual remove instead of comment out.

I get patch#72 cannot be applied

@Yuri #72 has been committed.

I'm trying to revert this because it breaks paths that match the entity name.

@joelpittet out of curiosity, how is it breaking it? I haven't had a chance to test it in a while, but I may during Drupalcon.

Hello.
Now I have a problem with view enitity with bundle. After enable translation I have an error
Missing bundle property on entity of type component. in entity_extract_ids()

Menu item have no load callback. /entity/bundle/%/translate while accessing this url I have fatal error because base path, translate path, path wildcard were not correct, we should use wildcard here %eckentity.

I have attached the patch. Please check it. Thanks.

@grndlvl sorry forgot to answer. I had a panels path that matched the entity name. (eck entity named 'away', panels page path called 'away/%')

The new eck path was taking precident and setting access to FALSE preventing anybody from going to that path.

#83 looks good too, but also need my patch in #79 for what I've described in #84

Setting to needs work because of #85

@vladimir.krupin Could you combine them?

Here's both combined #79 + #83, @vladimir.krupin might be busy.

So, I'm working on some tests. So far, using the latest Entity Translation dev snapshot it seems like ECK entities are translatable out of the box?

Not sure why it is saying "no tests found" when that's all the patch contains?

@DamienMcKenna

So, I'm working on some tests. So far, using the latest Entity Translation dev snapshot it seems like ECK entities are translatable out of the box?

That would be because the integration was already added into dev, however, there is a small remaining issue as mentioned in #77, #83, and #84.

It would probably be beneficial for testing these instances as well and rolling #88 into the patch to see if it was resolved.

Tests to show that the correct embedded entity is loaded when it's attached to an untranslated field on a translated node; all translations handled using Entity Translation.

So are the other issues related to path precedence and partial matches? Could someone please expand the tests to show how the paths would fail?

Some @todos for later, and an improved description for the translation tests.

I've moved the tests into #2889325: Add simpletests for D7 so that this can focus on just these edge cases. We might consider moving the edge cases to a separate issue and putting this one back to "fixed".

Skipping my patches from #89, #92 and #94, I've tested out #88 on a site where the local tabs weren't showing and it fixes that problem.

That said, I now get these errors, as reported in #40:

• Invalid base path defined for entities of type L3 Product tabbed section: matching menu item not found for l3_product_tabbed_section/%
• Invalid view path defined for entities of type L3 Product tabbed section: matching menu item not found for l3_product_tabbed_section/%
• Invalid edit path defined for entities of type L3 Product tabbed section: matching menu item not found for l3_product_tabbed_section/%/edit
• Invalid translate path defined for entities of type L3 Product tabbed section: parent menu item not found for l3_product_tabbed_section/%

Putting the code back in from eck.bunde.inc makes these go away, i.e. just sticking with #83 seems to solve the problem. Correct me if I'm wrong, but this is because of #2273189: Account for entities that may not create callbacks at "entity/ID" or "entity/ID/edit", right?

I'm using the current dev version and tried applying all the latest patches but I still don't see any translate tab - what could I be missing?

I also applied patch #88 to the latest released dev version. Although the patch applied cleanly, I did not see the translate tab either. Then I tried applying patch #88 to the latest dev version from the git repository and got the following:

mac-admin:eck lxt$ curl -s -O https://www.drupal.org/files/issues/make_eck_entities-1798646-88-partial-revert-with-83.patch
mac-admin:eck lxt$ patch -p1 < make_eck_entities-1798646-88-partial-revert-with-83.patch
patching file eck.bundle.inc
Hunk #1 FAILED at 19.
1 out of 1 hunk FAILED -- saving rejects to file eck.bundle.inc.rej
patching file eck.entity_type.inc
Hunk #1 FAILED at 429.
1 out of 1 hunk FAILED -- saving rejects to file eck.entity_type.inc.rej

Reroll of #88

@pifagor Why was this committed even though the last status was "Needs review"? Could you provide some background?

@cis: I think pifagor just forgot to update the status to "fixed", no mystery.

@DamienMcKenna I was referring to the status prior to the commit (which was Needs review). Your comment in #97 also seems to imply that the patch in #88 (which is the basis for the latest reroll in #100) still has issues. Hence me asking.

Hello @ciss
Patch #100 worked for me. I just did forget to post status "Reviewed & tested by the community" and moved the changes. If there is any problem, please describe them, and I will either turn revert the changes, or we will fix the problem.

@pifagor Thanks, I just wanted to be sure that the patch wasn't committed prematurely. I also just noticed that @DamienMcKenna reran the tests in #2889325: Add simpletests for D7 successfully. That's all the peace of mind I need. :)

Thank you for your concern. If you will have any problems write me.

Thank you for committing that, I've been using that patch to resolve the menu routing being overridden for a while!

Did this commit 4c4cd91 get reverted in -dev? I'm seeing this code again and referencing #2273189: Account for entities that may not create callbacks at "entity/ID" or "entity/ID/edit"