Context handler cannot find data object

Hi,

Here's the patch for this issue.

What if we were just to replace all this entity_info stuff with menu_get_item? I'm sure it can even be more simplified than this, as it allready holds the entity. I'm not sure about the entity type checking though:

$entity_type = $options['_type'];
if($menu_item = menu_get_item()) {
  if (isset($menu_item['page_arguments'][0]->entity_type) && $menu_item['page_arguments'][0]->entity_type == $entity_type) {
    $path = $menu_item['path'];
  } 
}

Just a thought.

Here is a better version:

  function object_load($options) {
    $entity_type = $options['_type'];
    $entity_info = entity_get_info($entity_type);
    if(($menu_item = menu_get_item()) && $key = array_search($entity_info['load hook'], $menu_item['load_functions'])) {
      if (isset($menu_item['map'][$key]->entity_type) && $menu_item['map'][$key]->entity_type == $entity_type && $menu_item['access'] == TRUE) {
        return $menu_item['map'][$key];
      }
    }
    // No path available so far, so exit with NULL.
    else {
      return NULL;
    }
  }

The entity type check is probably not needed.

What do you think?

Looks like menu_get_item() resulted in an infinite loop on the menu link edit pages.
Here's a patch that just get's the router item and loads the entity.

There's still a problem with validation of menu link edit pages.
But I think that's best handled in a seperate ticket which is here #2768767: Menu link validation fails

Increasing priority because current beta7 is broken. We need a solution for this as fast as possible.

Thanks @MiroslavBanov, indeed simplified like that. Just a few more questions I want to have answered:

• should we trow an entity_access() in there before returning the entity?
• are there possible ajax scenarios where arg() will not be built on the correct path?

We can go ahead with the patch without knowing the answer to the ajax question. The approach of the patch is an actual extension and improval of previous functionality. People will eventually stumble upon the arg() bug if there is one...

The entity access question we should answer. I can see use cases where we would always want the entity returned and I can see use cases where we would want to have an access check. To me this looks like a hard problem to solve. Maybe we should open a feature request for this as an extension to the menu link edit form where you can set an extra parameter for the plugin class. Such a thing does feel like we are making it complicated for some users. A good solution would be to provide an extra module setting to enable such functionality.

I will try to do some testing today on your patch @MiroslavBanov

I also agree with you @MiroslavBanov.

Allright, I've tested this on regular paths for node, user and taxonomy.
These work as expected. Setting to RTBC. Doesn't mean you shouldn't test :)

We should be expanding the menu_token.test though.
But this is not really useful as long as test are not enabled on this repository...

Doesn't work on views. I'm working on a new patch.

Hi all, so this patch also allows for views arguments to be loaded.
I can't seem to think of any other implementations for the contextual entity loading plugin.

Before we go back to RTBC we need to decide if we want to inform the user about the change in functionality. This because until beta7 the argument position was fixed, and has now become dynamic. A possible side effect of this change could be that menu links will appear where the site builder didn't expect them. It's easily solvable by them by setting the display of the menu only at the desired paths.

A suggestion I have for this is to:

• set a variable during an hook update
• implement hook_requirements to set warning if variable is present
• provide a link in the warning message to remove the variable

I know this will result in cruft code, but I think it's worth it.
Whether or not we decide to do this, for sure this has to be entered into a README.txt (which we surprisingly do not yet have)

Yeah, it is probably professional deformation as I'm in the quality assurance business. But if there were tests for entity tokens in this module we would have never hit this point. I'm surprised there aren't more complaints looking at the popularity of this module.

I'll make a separate issue for tests and documentation. So we can proceed with getting this bug fixed as a priority.

Very good initiative guys.

Thanks alexverb and MiroslavBanov!