Incompatibility with Commerce

I am fairly certain this is a duplicate of #1284056: Entities no longer save after submitting form (taxonomy terms, comments, users, etc.).

#1284056: Entities no longer save after submitting form (taxonomy terms, comments, users, etc.) worked for the other entities not for the Commerce products.
So the Meta tags still stops the Commerce Products.

Then you should probably help debug where the problem actually is - I don't use Commerce. Until we can figure out what is the problem, moving to a support request.

I'm not yet familiar with building modules but I'd like to toss in what I have observed.

Disabling the Meta Tags UI only has no effect, only disabling the API recovers the saving ability.

It seems to be in the load process of */edit: I've opened the edit mode of a node, then disabelded the Meta tag module and then tried to save the node, it didn't save.

(Just in case this has any helpful relevancy.)

there is another issue that seems related #1306106-1: Can't load nodes via a product reference in a rule & #1084426: Fetch Entity by property won't work for all properties.

however, using the last dev now i can save the commerce products

What about a way to enable/disable meta tags based entity/bundle types.

there could be several entities/bundles that are not public or are parts of others (field collection, drupal commerce products, etc) which won't need the meta tags

Shedding a little more light here, since this comes up quite regularly. Disclaimer: I haven't actually used it to see the precise errors, but something goes awry on Commerce entity forms likely due to some sort of form submit handler conflict. Still, I was able to diagnose it down to metatag_entity_supports_metatags() being overzealous in deciding an entity type supports (or even needs) meta tags. That's where the patch in comment 1 came from.

function metatag_entity_supports_metatags($entity_type = NULL, $bundle = NULL) {
  $types = &drupal_static(__FUNCTION__);

  if (!isset($types)) {
    $types = array();
    foreach (entity_get_info() as $entity_type_key => $entity_info) {
      if (!isset($entity_info['metatags'])) {
        // By default allow entities that have fields and have paths.
        $entity_info['metatags'] = !empty($entity_info['uri callback']) && !empty($entity_info['fieldable']);
      }
      // ...
    }
  }

  return $types;
}

So, that default "allow entities that have fields and have paths" is the problem. All of our entities except payment transactions have fields and paths, but none of them will be directly displayed to end users or accessible to search bots. I'm actually not sure why there's this default assumption at all - why not support entity types that have URIs and no fields? Why assume the URI is public facing at all? (In our case, they all lead to administrative pages / edit forms or user access restricted order view pages for customers.)

At this point I have one option: update all of my entity info definitions to include metatags = FALSE. I may do this just to avoid the support requests, but I think it represents a flaw in Meta Tags' approach. What I see here is the same thing I see in WYSIWYG modules that overzealously apply themselves to every textarea on the site by default just because they're there. That sort of blanket approach will almost always cause conflicts, because you simply can't assume every module will be doing the things with those textareas / entity types and pages that you expect.

That's not to say you can't have sensible defaults, though! : ) For this module, for example, why not just default support to the appropriate core entity types you know about (e.g. enable Meta Tags for Node, User, and Taxonomy) and leave it up to site administrators using a checkboxes list in the Meta Tags UI to determine whether or not Meta Tags should be applied to entity types defined by other contributed modules or custom modules on the site. This will allow the system to selectively enhance components coming from other modules instead of requiring those modules to proactively block the enhancement on the off-chance that X module will be used in conjunction with their Y. We can then easily add a documentation page regarding Meta Tags usage with Commerce - the gist of which would be that Meta Tags should be added at the point of display as opposed to on products themselves.

Back to the disclaimer - it seems there's some deeper issue here at play with form level vs. button level validate / submit handlers. I haven't dug deep enough to find it, but I think my recommendation above will apply even with the form conflict solved (and it'll fix the presenting issue in the short term : ).

There should be nothing wrong with validate and submit handlers now (marking this back to postponed in case there actually is a bug but I'm doubtful), and we're going to handle the 'which entities support meta tags' problem at a higher level with #1307726: Being able to edit or view the meta tags for entities should be tied to if a configuration exists or not for now.

I would assume that entity URIs *are* public facing and my gut feeling is that the assumption that they could be public or private (not depending on a permission) is wrong.

It's unclear to me if you're saying I'll need to 1) provide explicit exclusions for Meta Tags in all my entity definitions or 2) wait until that issue is fixed. I'll try to find time to look deeper at the form conflict - that's the main conflict, that submitting a form w/ Meta Tags is preventing my users' entities from actually being saved.

FYI I have also filed core task #1332058: Need a way to distinguish "public/final" URIs for entities from admin and redirected ones to discuss the proper usage of uri_callback in entities.

Cool, thanks. It's also still unclear to me what you'd have me do in the meantime (see comment #9).

Hi, Any progress in this field ? Does metatag work with product entities now please?
Greetings, Martijn

@rszrama: This issue would be fixed if the commerce entities do not implement an URI callback for admin pages, rather than only implementing an URI callback only if the entities have "publicly visible" pages like node/%node, user/%user, etc.

Can you remind me if that core issue to better define the usage of URI callbacks ever panned out? I'm hesitant to remove the URI callbacks in a minor version update to Commerce, but if we can point to a "final word" on the issue, we can always just move them into a contributed module and instruct users dependent on them to grab that module when they update to 1.3. Maybe that's not a bad solution even if we don't have a final word on the core issue yet...

Hi @rszrama, in my smal opinion, I like that solution for 1.3, then meta tags can work on product entities, and the URL callback can be manipulated from the contributed module.
Greetings, Martijn

+1 for fixing this in 1.3 if possible, thanks.

This needs to be fixed for the initial stable release, or in Commerce, but a solution needs to be ironed out before Metatag hits 1.0.

This should now be resolved with #1281770: Disable metatags by default on all entitity types, enable it only on needed and popular types - nodes, terms. Would still be nice if Commerce didn't define URI callbacks that aren't really public-facing URIs as per #1332058: Need a way to distinguish "public/final" URIs for entities from admin and redirected ones and #1392654: Commerce can return invalid return values for uri callbacks..