Early Bird Registration for DrupalCon Portland 2024 is open! Register by 23:59 PST on 31 March 2024, to get $100 off your ticket.
Problem/Motivation
For three content entity types (menu_link_content, shortcut and taxonomy_term), in respective overview form, the operation list is hardcoded (e.g. core/modules/taxonomy/src/Form/OverviewTerms.php:269
).
If I add a new operation via the hook_entity_operation, the new operation don't appear in the list.
Take taxonomy_term as an example:
Define the new operation
function mymodule_entity_operation(EntityInterface $entity) {
if ($entity->getEntityTypeId() == 'taxonomy_term' && $entity->hasLinkTemplate('mymodule-link')) {
return [
'my_operation' => [
'title' => t('My operation'),
'weight' => 50,
'url' => $entity->toUrl('mymodule-link'),
],
];
}
The new operation don't appear in the list /admin/structure/taxonomy/manage/{taxonomy_vocabulary}/overview
Proposed resolution
For me, each entity could provide his operation list.
I would add (like linkTemplate):
- In the entity type (\Drupal\Core\Entity\EntityType): To replace the hook_entity_operation, a couple of method
setOperation()
to add operations andgetOperations()
to retrieve all operations defined for the entity type - In the entity (Drupal\Core\Entity\Entity): a new method
operations()
the get the operation list for one entity - Each entity (e.g. taxonomy_term \Drupal\taxonomy\Entity\Term) can override this method to add own specific operations
Remaining tasks
Discuss
Writing the patch
Comment | File | Size | Author |
---|---|---|---|
#27 | taxonomy-entity_operations-2704387-24.patch | 2.49 KB | kerasai |
#17 | hook_entity_operation-2704387-17.patch | 3.68 KB | woprrr |
Operation_list.png | 19.12 KB | vpeltot |
Comments
Comment #2
woprrr CreditAttribution: woprrr as a volunteer and at Degetel commentedI think this issue is a part to [#1823450: [Meta] Convert core listings to Views] and opérations links are correctly recover in operation collumn in this case. But i am all in your proposed solution to implement an setOperation / getOperation methods in Entity/EntityType interface.
Comment #3
cilefen CreditAttribution: cilefen commentedIs this in fact a regression from 7 and therefore, a bug?
Comment #4
dawehnerYeah I don't get the point either, isn't hook_entity_operation exactly for that usecase? IMHO we should not try to add another method to the entity class, its already so full of stuff.
Comment #6
woprrr CreditAttribution: woprrr as a volunteer and at Degetel commentedhi @dawehner,
I understand and it's true entity class are so full of stuff ! But what we can purpose to retrive all operations available for an entity other than edit / delete ? We can't supose we need to override overview form with RouteSubscriber to re-define all form and not Form-alter (GOOOOOOOOOOOD). The real solution IMHO is migrate all overviews pages in views core like #1823450: [Meta] Convert core listings to Views to retrive dynamically all operations available Or use system core overviews system (that seem to be aborded).
Comment #7
woprrr CreditAttribution: woprrr as a volunteer and at Degetel commentedComment #8
woprrr CreditAttribution: woprrr as a volunteer commented@vpeltot Infact getOperations() method already exist on entityManager system.
I've found these solution for wait better.
we need to change
By
That work fine and retrieve all operations available.
But to do that we need to override Original \Drupal\taxonomy\Form\OverviewTerms with another one extend it and change $operation element for each elements.
What do you think about ?
EDIT : you can seen that tricks on FormModeManagerOverviewTerms on Form mode manager.
Comment #9
woprrr CreditAttribution: woprrr as a volunteer commentedComment #10
effulgentsia CreditAttribution: effulgentsia at Acquia commentedSeems to me that this is a bug rather than a feature request. All core forms that display operations for entities should gather those operations via
hook_entity_operation()
andhook_entity_operation_alter()
. Having lists of these entities on something other thanEntityListBuilderInterface
UIs is ok, but then these custom entity listing UIs still need to gather the operations via the correct hooks.Comment #11
effulgentsia CreditAttribution: effulgentsia at Acquia commentedTagging as a contrib blocker, because according to #2838938: Taxonomy term overview, Form mode manager is one example of a module that needs to add operations to taxonomy terms. It's likely there are other contrib modules running into this as well.
Raising to Major as this is affecting 3 core entity types and is likely causing pain for multiple contrib modules.
Comment #12
effulgentsia CreditAttribution: effulgentsia at Acquia commentedUntagging "Contributed project blocker", because https://www.drupal.org/issue-tags/special defines that tag for blockers to porting a contrib module from an earlier major version of Drupal. Form mode manager is a 8.x only module, so the tag doesn't apply. Furthermore, hook_entity_operation() and hook_entity_operation_alter() are new hooks for Drupal 8, so it's unlikely this issue is causing porting problems for other modules.
Leaving as Major priority though, because nothing in the documentation of these hooks says they don't work for certain entity types, and it's completely reasonable for 8.x contrib modules to want to add operations to entities of these types.
Comment #13
woprrr CreditAttribution: woprrr as a volunteer commentedThat issue is a part of https://www.drupal.org/node/1823450 i think. If we convert that into views (standard) all problems are solved or use my trick on #10 ;) I prefer the first solution.
Comment #14
effulgentsia CreditAttribution: effulgentsia at Acquia commentedLooks like #1823450: [Meta] Convert core listings to Views has an existing child issue for converting
Drupal\taxonomy\Form\OverviewTerms
to a View: #113344: Taxonomy term manager view. However, there's no patch for that yet (last patch on the issue is for Drupal 6).I don't see any child issues of #1823450: [Meta] Convert core listings to Views for converting
Drupal\menu_ui\MenuForm
orDrupal\shortcut\Form\SetCustomize
to Views.Converting all of those to Views is a fairly large effort. I don't see a reason to hold up this bug fix on that.
I think #8 is on the right track. But:
That's a clever hack to use the vocabulary list builder, but no, we need to use the term list builder. Which means we need to add one to
Drupal\taxonomy\Entity\Term
.If you're trying to solve this within a contrib module, then yes, but since this is an issue against core, you can fix it directly in
Drupal\taxonomy\Form\OverviewTerms
itself.One thing we need to decide here is whether to make the scope of this issue about fixing all 3 of the places identified here within a single patch. Or whether to open separate child issues for each of the 3 forms. On the one hand, we might want to get a fix in for
Drupal\taxonomy\Form\OverviewTerms
without holding it up on the other two. On the other hand, we might want to see if a similar solution applies consistently across all the places before committing them.Either way though, uploading a patch here that does #8 with the above feedback would be a great place to start.
Comment #15
willzyx CreditAttribution: willzyx commentedAdding two related issues:
#2469567: Entity operations for terms are hardcoded in taxonomy terms's overview page
#2684577: Entity operations for menu links are hardcoded in edit menu form
Comment #16
zalak.addweb CreditAttribution: zalak.addweb commentedComment #17
woprrr CreditAttribution: woprrr as a volunteer commentedI purpose to Fixe Menu / Menu links problems in other issue to have more simple patch to test etc... That is the patch + one small fix of standards (entity_type.manager service DO use instead of entity.manager).
For Menu links the solution are pretty more complex and i do have more time to verify if all is okay. In ALL CASES we need to add tests coverages to verify if operations are correctly visible on Overview pages.
Comment #19
effulgentsia CreditAttribution: effulgentsia at Acquia commentedThanks for the patch!
Per #14, it's wrong to use the vocabulary's list builder. We need the term's list builder. #2469567: Entity operations for terms are hardcoded in taxonomy terms's overview page has a nice patch that does that, so I suggest continuing over there. Looks like there's test failures (both with that patch and this one) that might require changes to some forum module code to fix.
Comment #20
effulgentsia CreditAttribution: effulgentsia at Acquia commentedI haven't tested it, but just from reading the code of CommentAdminOverview, it looks like those also contain hard-coded operations not using the hooks. So we'll need a child issue for that one too if there isn't one already.
Comment #21
BerdirDo we want to make this a plan/meta issue and split it out into separate issues per entity type/list? We already have one for taxonomy term that's much further along and clearly not trivial at all.
Comment #22
effulgentsia CreditAttribution: effulgentsia at Acquia commentedSounds good to me.
Comment #23
woprrr CreditAttribution: woprrr as a volunteer commented@berdir THANKS to your intervention about that. I am totally agree .. At the begin i just want to fix taxonomy case if we try to fix all cases we finish that in 3 years ...
I think it's good way... @see \Drupal\views\Plugin\views\field\EntityOperations::render views too use that method to retrives all operations. I need to investigate more but the fail is only due to changes entityManager to entityTypeManager i repatch fast !
Comment #27
kerasai CreditAttribution: kerasai at myDropWizard commentedLooks like #1848686: Add a dedicated permission to access the term overview page (without 'administer taxonomy' permission) fixed the entity operations used in the term listing pages for 8.5.x and beyond.
I've attached a patch that adds the bare minimum to get the entity operations working for the terms on the admin listing in 8.4.x.
Comment #28
BerdirIndeed, this is resolved, so I'm closing this as a duplicate.
Comment #29
Sivarama krishnan CreditAttribution: Sivarama krishnan commentedanyone please helpme..
how to unset operation entity (like manage-fields,manage-display,edit)in drupal8
i try like below code.