I would like to insert an edit link as a views field to my entity view, much like I can with nodes. Is this possible?

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

fago’s picture

Yep, sounds good. However, the problem is we don't generally know the edit / delete location, though some entities provide an "edit-url" property and token.

So first, we need establish and document a way for entities to declare their edit / delete location.

mstrelan’s picture

Also, some entity types may not have an edit url, for example Field Collection. The Bean module provides a method editURL(), perhaps this could exist in the Entity class and simply return FALSE.

fago’s picture

The entity class is optional, so it's not good to rely upon it for this.
I think we should make this even more general, so that any entity-type can specify their edit-url location.

bojanz’s picture

I like the "operations" way of doing things (through contextual links).
I have "bojan/%bojan" as the path, handler gets all contextual links, pulling "bojan/%bojan/edit", "bojan/%bojan/delete" or whatever exists and is accessable.
That's how Commerce and many contribs around it approach the problem, seems more flexible than just talking about edit urls or delete urls.

fago’s picture

Makes sense to me, though I fear that pattern doesn't apply in all cases.

Do you support possible other operations too? Are you assuming edit/delete is there for any entity?

Doing an operations URL pattern sounds like a good idea though. E.g. an 'operation url callback' + entity_operation_url() function? Which operations should we support, just hard-coded 'edit', 'delete' ?

bojanz’s picture

You are just saying "get me contextual links for provided $url". Whether the module provided "edit", "delete", "call fago", or something else entirely is up to them :)
No assumptions.

fago’s picture

oh, I see. Well, that should do it for Views but for modules it's probably more useful to have access to edit/deletion URLs? E.g. you could generate a "edit referenced entity" link for an entity formatter. If I only get the whole operations, I cannot control link texts.. :/

Michelle’s picture

I found this discussion because I was curious if how Bean does it was a standard and searched on it. I'm going to follow this in Artesian, too, since it makes sense, but will also keep an eye on this issue in case you go a different direction.

Michelle

fago’s picture

Title: Add "edit link" to entity views integration » Add links to entity views integration

I guess we should just add some general "links" views integration, which we can auto-generate for entities provided with the entity API.

->
View link, Edit link and Delete link - as Views does for node links. Then, those plugins should probably provide the URLs as replacement pattern.

fmizzell’s picture

edmund.kwok recently wrote this functionality for ECK: #1424738: Views integration: Add view, edit, delete link. ECK stores the information about the operations url in the entity_info array, so it can be easily manipulated and accessible. If the urls are specified in the plugins, from what I understand, the urls will be static at that point, right?. I suggest using the properties array as the middle man to store this information. Since not all url properties are operations, maybe we can set a flag or something to let us know that that url is an operation also.

joachim’s picture

The problem is that functions like entity_access() and entity_uri() expect a full $entity to be passed to them. Unlike the handlers for node link and node edit link, we can't just know that the right path is 'node/NID' and 'node/NID/edit'.

That's doable for a Views handler, but it's a drain on performance.

alexweber’s picture

The problem is that when trying to implement this manually using hook_views_data() and implementing a custom handler it breaks the Entity API views integration (not sure why at this point).

EDIT: Ok so apprently Entity API implements hook_views_data() on our behalf (somehow), so if we want to add additional stuff we need to use hook_views_data_alter(), this way we don't overwrite what Entity API generously provides.

alexweber’s picture

I've updated the handbook to reflect this, I lost a good half hour scratching my head because of this :)

AaronBauman’s picture

The way ECK does this, as fmizzel mentioned above, is to alter the entity_info and add crud links, like so:

[entity name] => Array (
... 
 [bundles] => Array (
                    [bundle name] => Array (
...
                            [crud] => Array (
                                    [add] => Array (
                                            [path] => admin/structure/entity-type/slideshow/slideshow/add
                                        )
                                    [edit] => Array (
                                            [path] => admin/structure/entity-type/slideshow/slideshow/%/edit
                                            [entity_id] => 5
                                        )
                                    [delete] => Array (
                                            [path] => admin/structure/entity-type/slideshow/slideshow/%/delete
                                            [entity_id] => 5
                                        )
                                    [view] => Array (
                                            [path] => slideshow/slideshow/%
                                            [entity_id] => 2
                                        )
                                )

This seems like a useful thing to be implemented by all instances of hook_entity_info() (or hook_entity_info_alter()).
Where it's relevant, [crud] might even include "clone", "revert", or whatever other operations necessary.
This also addresses joachim's concern in comment #11: using the structure above, from ECK, we wouldn't need a fully-loaded entity, just the entity id.

joachim’s picture

Status: Active » Needs review
FileSize
3.21 KB

Here's a patch that does the 'view' link part at least -- that's fairly easy to do.

As pointed out above, to support 'edit' and 'delete' links we'll need more entity type metadata.

alexweber’s picture

Hey joachim, I've actually implemented this myself for a couple custom entities and the solution I came up with is pretty generic:

   // In a views handler render(), similar to the "View" one...

   $text = !empty($this->options['text']) ? $this->options['text'] : t('edit');
   $entity_uri = entity_uri('entity_type', $entity); // replace with entity type
   return l($text, reset($entity_uri) . '/edit'); // generates generic edit entity link

The above also works with delete as well, comments before I roll a patch?

AaronBauman’s picture

alex: the problem is relying on the convention that appending "/edit" will take you to the entity's edit form.
though this is true most of the time, it's only a convention and cannot be relied upon exclusively.

testbot is not cooperating, but this patch implements my suggestion from comment #14:
#1309332-10: Expose field-collection operational links in views

alexweber’s picture

@aaronbauman, ohh gotcha ok yeah that makes sense... It's a shame that despite being the convention it is up to the module developer when implementing his hook_menu() so yeah, bummer... maybe we can add extra "edit" and "delete" suffix keys to the hook_entity_info() and we can assume its "entitypath/suffix" from here on out?

JeebsUK’s picture

Issue summary: View changes

Was there ever any consensus reached on this? I've just run into this exact scenario and seen this issue hasn't had any updates for nearly two years.

joachim’s picture

https://drupal.org/project/entity_operations has this feature, precisely because it allows entity types to declare a 'base path' and then operation path elements, along the lines of 'node/X/edit', 'node/X/delete' and so on.

/shameless promotion ;)

joachim’s picture

Small update to the patch:

- added a file docblock
- fixed mentions of 'node' in the views field handler comments

Chris Matthews’s picture

The 3 year old patch in #21 to entity.info, entity.views.inc and entity_views_handler_field_entity_link.inc applied cleanly to the latest entity 7.x-1.x-dev and would still be a great feature to have in 7.x.