Don't rely on $entity_info['path'] attribute

Please take a look at this.

Did you run the database updates after updating Metatag?

Could you please install the Devel module, then edit the function above so that it outputs the $entity_type and $entity_info if $entity_info['path'] doesn't exist? For example:

  function object_load($options) {
    $entity_type = $options['_type'];
    $entity_info = entity_get_info($entity_type);

    if (!isset($entity_info['path'])) {
      dpm($entity_type);
      dpm($entity_info);
    }
    $path_components = explode('/', $entity_info['path']);

Then please upload a screenshot of what is shown? Thanks.

Please also test the latest -dev release.

This error is still there with metatag 1.6 and latest dev (as of june 30, 2015)
There was a change in the above function between the stable version and the latest dev of menu_token module.
For the moment I just added a (!empty($entity_info['path'])) test and the error has gone without any negative consequences (for the moment)

OH! I just realized what this is. The 'path' attribute used to be added by Metatag for core entities but was removed in 1.5. In short the Menu Token module shouldn't rely upon that module but should instead use other methods of identifying the path for a given entity.

@erwangel: where do we exactly have to put (!empty($entity_info['path'])) please?

Edit: that seems to be line 24 of plugins/menu_token_entity_context.inc (current dev) - as mentionned above. Ok, I wasn't sure (and it's monday morning, bear with me).

@knalstaaf: that's right ; not about monday's morning as for me it's sunday evening, but about file's line :)

On line 24 in menu_token_entity_context.inc, $entity_info contains $entity_info['default path']. The attached patch (against 7.x-1.x branch) changes 'path' to 'default path' in the explode() on that line.

I'm not sure if this is enough for what we need, but it seems to work for loading users from context.

#12 works for me, RTBC+1, but we need someone who knows if that is logically OK!

I have a little time before I need to go live with the site affected by this issue. Hoping for a final solution before then... If not, then I will also give this patch a try. Thanks, Anybody, for bringing this thread to my attention.

I got a content inside a panel, and with 7.x-1.6 I started to get the error of this post.

thanks

RTBC! Please commit!

Does not resolve it for me. The failing object is a user, which has neither "path" nor "default path".

Is this code sufficient to fix the problem, or will this code just mask it?

  // place this just before line 24
  if(!isset($entity_info['path'])) {
    return FALSE;
  }

(From https://www.drupal.org/node/2502325#comment-10628980)

I had the same issue when using Panels.

I pretty much replaced that function with the previous one and all is good.

Alright i did this ugly hack and got it working for me although i don't know if this is the correct solution. I'm using menu_get_item to get the path parameter.

  function object_load($options) {

    $entity_type = $options['_type'];
    $entity_info = entity_get_info($entity_type);


    $menu_item = menu_get_item();
    $path = isset($entity_info['path']) ? $entity_info['path'] : isset($menu_item['path']) ? $menu_item['path'] : '';

    $path_components = explode('/', $path);
    foreach ($path_components as $position => $component) {
      // If this is a menu argument, then use the current position to find
      // the entity id.
      if (strpos($component, '%') === 0) {
        break;
      }

      // If the current URL deviates from the expected path, assume the
      // entity is not present.
      if ($component !== arg($position)) {
        return FALSE;
      }
    }

    return entity_load_single($entity_type, arg($position));
  }

I'm not sure why that function was changed to what it is now and also what the intended behaviour is (more comments please in that class).
Hence, I reverted back to the old definition like d0t101101. I'm using the user entity and there is no $entity_info['path'] defined. The default path removes the error message, but doesn't give you the entity id.

Until it gets fixed by somebody who understands that function completely, I recommend rolling back to the old version:

function object_load($options) {
    $entity_type = $options['_type'];
    $entity_info = entity_get_info($entity_type);

    // Taken from entity_uri() to determine the uri callback for this entity
    // type.
    // A bundle-specific callback takes precedence over the generic one for the
    // entity type.
    if (isset($entity_info['uri callback'])) {
      $uri_callback = $entity_info['uri callback'];
    }
    else {
      return NULL;
    }

    $path = @$uri_callback();
    $path = current(explode('/', $path['path']));

    if (arg(0) === $path && is_numeric(arg(1))) {
      return entity_load_single($entity_type, arg(1));
    }

    return FALSE;
  }

A uri callback expects a (full) entity as parameter, so that is probably why the code from that previous version was changed: it simply doesn't work. So the solution using menu_get_item is better, but I combined it with a check on the entity_info data:

    ...
    if (!empty($entity_info['default path'])) {
      $path = $entity_info['default path'];
    }
    else if (!empty($entity_info['path'])) {
      $path = $entity_info['path'];
    }
    else {
      $menu_item = menu_get_item();
      if (!empty($menu_item['path'])) {
        $path = $menu_item['path'];
      }
      else {
        return FALSE;
      }
    }
	
    $path_components = explode('/', $path);
    ...

Hello.
I used the code fietserwin from #24

Menu on site pages works fine, but there are problems with the editing menu item in the administrative interface.
When I press "edit" on menu item with token the site gives error with the text "ERR_EMPTY_RESPONSE" and not open item edit page.

What could be the problem?

Drupal 7.41
Menu Token 7.x-1.0-beta6

Sorry, no idea. I ran into this problem when I was updating a site that I did not build. So far, I never used this module myself, so I can't be of any further help here.

As @fietserwin exposed, we can't use uri_callback() as no entity is available. All $option contains is the entity_type.
Maybe could it be added, but it was not so far.

I'm not sure about the menu_get_item() solution, as @the69 reports, it won't work outside the scope of the item path.

Attached patch provides a check for $entity_info['path'] first, then $entity_info['default path'], and a clean NULL exit if none was available.

@wayaslij Your patch doesn't work for "User from context" option. See screenshot with settings. If we are on /user page link doesn't shows.

Do we need other cases instead of "Show link on view/edit/delete entity page"? We have only global scope(node, user pages), and don't need another scopes. So I think @fietserwin's approach is good as for me.

@annya, unless $path is sent to menu_get_item(), this function will use the actual URL to extract a system path:

  if (!isset($path)) {
    $path = $_GET['q'];
  }

This might work for /user, but imagine you are using the token in an email template, or you have related users on your /user page that also need to use the token. It won't work.

A solution would be to detect where other from $entity_info['path'] or $entity_info['default path'] the needed path could be set, or to find a way to add the entity object to $options when it is built, so we would be able to cleanly use uri_callback().

Please see #2502325: menu_token logs Undefined index: path in menu_token_entity_context->object_load() .