Entitycache incompatibility with core forums & Metatag

I've been using EntityCache on my sites with the -dev release without any problems. Have you experienced any specific problems?

I had this same issue, but it was Commerce Entity Cache that was causing the defaults to display when editing a node. I don't think this has anything to do with the Entity Cache module.

I'm going to redact my previous comment. I did in fact have to turn off entity cache as well to get the meta tags working again.

In my case, I am using core revisions, entity cache, and metatags together. Everything saves fine and even displays in the source code just fine. However, in what appears to be random incidences, when editing a node the metatag defaults display instead of the actual data from database.

I'm not sure if it is an Entity Cache or Metatag issue.

I also had the same issue.

In my case, all custom descriptions have disappeared. After turning off entitycache it have appeared again.

Sorry for my english.

I also face the same issue with metatags and entitycache.

We use metatag 7.x-1.0-beta9 and entitycache 7.x-1.2 with redis cache backend.

To reproduce it in our environment:

1) Add metatags to a node and save it. The meta tag will appear properly in the system, even when editing the node.
2) Clear cache.
3) The metatag added will be removed. When edit the node, it show default for metatag fields.

When entitycache module is disabled, the metatags works perfectly.

I'm running into the same issue using entitycache 7.x-1.2 and the latest metatag dev release.

metatags works by using hook_entity_load(). I found that after clearing cache through drush (drush cc all), the metatags would not get loaded onto a node.

metatag_entity_load() calls metatag_entity_supports_metatags(), but metatag_entity_supports_metatags() was returning false.

metatag_entity_supports_metatags() calls entity_get_info() and caches the $entity_types array. The first time that metatag_entity_supports_metatags() calls entity_get_info(), it is returning what seems to be the wrong data. Subsequent calls to metatag_entity_supports_metatags() returned false, since $entity_types was already cached using drupal_static().

Disabling entitycache "fixes" the issue. A workaround to use both modules would be NOT statically caching $entity_types the first time, but that seems ugly.

Curiously, this problem doesn't exist on some other sites using both entitycache and metatag.

@robertstephens: Oh, good sleuthing! Thanks!

Just playing with ideas here, but does this resolve the problem?

Thanks for the patch, but sorry, it does not resolve the issue.

I face the same issue now. I tried the following:

1) Disable entitycache module
2) Created a node with metatags
3) Clear cache (drush cc all) - the meta tags were there in the node.
4) Apply patch to the metatags module
5) Enabled entitycache (the meta tags were still there, when I view or edit node)
6) Clear cache (drush cc all) (The node shows "using default" in metatag - Also when I first reload the node edit page, the metatags tab was not there, I had to reload the page again to get the metatag tab.)
7) Disabled entitycache (the correct metatag values shown when reload the node edit page after disabling the entitycache module)

sadpanda.

I ran through the scenario detailed in #10 with the latest -dev release of both Entity and EntityCache but couldn't reproduce the error. Might another module be interfering with this?

I was working on the same site as roberttstephens. I was running into this issue with the drupal forums enabled. In the metatag.module, I've commented out the lines in metatag_entity_info_alter().

 //if (module_exists('forum') && ($revision_id = variable_get('forum_nav_vocabulary', 0)) && $vocabulary = taxonomy_vocabulary_load($revision_id)) {
  //  $defaults['taxonomy_term']['bundles'][$vocabulary->machine_name]['path'] = 'forum/%taxonomy_term';
  //}

I've tested this with entity cache enabled and everything seems to work. Maybe the get_entity_info() has something to do with the function taxonomy_vocabulary_load running and caching the info array.

@johnle: Excellent research, that greatly helps narrow things down. Thanks.

+1 to johnle figuring this out. The difference between our sites that have this issue and don't have this issue is whether or not they have forums. I'm confirming that commenting out the code above fixes the issue.

It looks like it's just determining which vid is used for the forums. Could taxonomy_vocabulary_load($revision_id) be replaced with a db_select?

BTW did you notice the minor copy/paste typoo? "revision_id"? I guess I missed that one when I went whole-hog replacing $vid with $revision_id. :-)

Does tis fix the problem?

I apply the patch for #16 and it seems to work perfectly.

Thanks!!

Committed! I tweaked the comment a little bit, just to explain the rationale for the custom query. Thanks for helping to debug the problem.

@R.Volk: Oh dear :( Well, please give the latest -dev release a spin and let us know if the problem persists. Thanks.