Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.
Problem/Motivation
In 7.x, Flag supported displaying links in three ways: As a psudofield, in entity links, and in contextual links. 8.x currently only implements display of flag links as a psudofield.
Implement Entity links display in this issue.
Proposed resolution
Implement hook_node_links_alter(). Display the flag link when enabled in the flagtype plugin.
Remaining tasks
Write patch.
User interface changes
Entity and contextual link behavior in 7.x will be present in 8.x
API changes
None.
Comment | File | Size | Author |
---|---|---|---|
#17 | flag-node_links_support-2411977-17.patch | 6.32 KB | asgorobets |
#11 | flag-node_links_support-2411977-11.patch | 16.61 KB | asgorobets |
#8 | interdiff.txt | 10.89 KB | asgorobets |
#8 | flag-node_links_support-2411977-7.patch | 16.87 KB | asgorobets |
#7 | flag-node_links_support-2411977-6.patch | 6.08 KB | asgorobets |
Comments
Comment #1
joachim CreditAttribution: joachim commentedhook_node_links_alter()!? Wow. It's like being back on D6 ;)
Comment #2
socketwench CreditAttribution: socketwench commentedIs that even the right hook? It was really late when I moved over this issue from Github.
Comment #3
joachim CreditAttribution: joachim commentedLooks like it. I found docs and a change record and everything!
That does mean though that only nodes and comments have links. I think in D7 you could technically stick a links item in the render array for an entity of any type, though I don't remember if anything decent happens...
Might it be an idea to split off the contextual links stuff into a separate issue?
Comment #4
asgorobets CreditAttribution: asgorobets commentedHi, I'd like to help with this issue. Please see first patch for node links support.
I'm still looking into Contextual links, will provide some thoughts later.
One code change besides the node links handling is:
There was a bug that was causing showAsField to display Flag item on all view modes, even if it was not added to the Manage display field, and the order was wrong, I changed that condition here. Let me know if it's better to open a different ticket.
Comment #5
asgorobets CreditAttribution: asgorobets commentedComment #6
socketwench CreditAttribution: socketwench as a volunteer commentedThe patch looks good so far, but I think we need tests for this functionality.
Can you test the contextual link popup in Simpletest?
Comment #7
asgorobets CreditAttribution: asgorobets as a volunteer commentedAdded tests, please review
Thanks,
Alexei.
Comment #8
asgorobets CreditAttribution: asgorobets as a volunteer commentedFinally was able to figure out contextual links caching and how to make it more granular, adding contextual links functionality with basic tests.
Please review.
Comment #11
asgorobets CreditAttribution: asgorobets at FFW commentedHi folks,
Added tests and rerolled according to latest changes.
I have one serious problem that I'd like to discuss, it is Contextual Links placeholder being cached. Looks like contextual links module assumes contextual links are static and rarely change. Contextual links placeholder is only invalidated with node view cache. We can either invalidate node view cache on Flag/Unflag action if we have flags in contextual links, or we need to make the node (entity) cache vary by flag state. For now I had to vary by flag state, but I had to return a previously deleted hook, which was previously used to provide cache granularity for flags as fields, which was probably removed as fields are now using #lazy_builder:
I personally prefer cache invalidation more than varying by flags state, but I don't think we should invalidate Node View cache on every flag/unflag event, this may sound like overkill for someone, unless we do it only in special cases when we know that we're displaying the flag in contextual links.
I've noticed that we are calling resetCache in FlagService::flag method:
If this is due to node view caching fields, we already eliminated the need in this code, because we use #lazy_builder, I guess.
If this code is still needed for something else, then one more note is needed, the resetCache is needed also on FlagService::unflag action then, as this has same effect, need a cache invalidation.
If we want to invalidate Node View cache to solve contextual links problem, I don't believe this is FlagService's job to do that, I guess we can hook via hook_entity_insert/hook_entity_delete or by subscribing to FlagEvents::ENTITY_FLAGGED and FlagEvents::ENTITY_UNFLAGGED. I believe we may need to invalidate Node View cache only if we use Flags as Contextual Links, because Node Links and Flag Fields already use #lazy_builders, in that case I don't think FlagService should be checking for display type, it shouldn't know how the flag is being used.
Let me know if this needs more work ;)
Thanks,
Alexei
Comment #17
asgorobets CreditAttribution: asgorobets at FFW commentedOoops, small correction, added base_path() to URL checks in contextual links test.
I must consider running tests locally under "/something" directory to catch those earlier =)
Comment #18
joachim CreditAttribution: joachim commentedThanks for working on this!
I had a bit of a look at this one yesterday, and it does look rather more complex than I would have thought.
So on the one hand I am wondering whether this issue should really be split into two -- one for node/comment links, and one for contextual.
But on the other hand, both of these features are going to have to deal with the same problem: the links template (links.html.twig -- I guess we don't say theme_links() in D8 any more) no longer accepts HTML links.
On flag D7, we use that to shove our own completely rendered Flag link into the links array:
Just passing in the URL like this isn't going to work with our JS links:
So that's our first problem. Second is that we now have a lazy builder, and I couldn't get that to work with the links array.
I happened to look at this today. showInLinks() returning a view mode name is just weird! I'll file a subissue to deal with that since this needs more work anyway.
This bit might need a reroll -- the API has been simplified here and you no longer need to check for access or pass in $action if you're getting the completely built link.
Good catch! -- but this should be filed as a separate bug please.
Comment #19
joachim CreditAttribution: joachim commentedI've file this core issue: #2587417: Unable to use lazy builders for individual links in hook_node_links_alter(), hook_comment_links_alter().
Comment #20
joachim CreditAttribution: joachim commentedI've been thinking about this some more and I now reckon we *should* split off the fix for contextual links. My reasoning is that contextual links definitely can't have a JS link in them -- they are only going to be the 'reload' type (though what will probably happen is that they'll bypass the link type plugins entirely). So they're something we can fix now, whereas the entity links stuff requires more work.
Comment #21
asgorobets CreditAttribution: asgorobets at FFW commentedHi joachim,
Thanks for your feedback.
Changed title to reflect issue split.
Fired a separate issue for contextual links: #2599304: [regression] Reimplement Contextual Link Display
Fired a separate issue for pseudofield display settings bug #2599074: Flag link pseudo field is displayed on all view modes even if 'Display link as field' setting is disabled
Comment #22
socketwench CreditAttribution: socketwench as a volunteer commentedComment #23
Morbus IffI'm not sure this should have been closed - "Display in Entity Links" doesn't appear to have been fixed (at least, in the current -dev) - instead, we split off a second issue for the contextual links, and then the issue was accidentally closed. Reopening and setting as a beta blocker.
Comment #24
joachim CreditAttribution: joachim commentedThis was possibly closed in favour of #2703229: [regression] Flags not appearing in node and comment links section?
Comment #25
socketwench CreditAttribution: socketwench as a volunteer commentedYep. That's what happened. My fault for not linking in the following issue.