Closed (fixed)
Project:
Group Menu
Version:
8.x-1.x-dev
Component:
User interface
Priority:
Normal
Category:
Bug report
Assigned:
Unassigned
Reporter:
Created:
9 Jun 2017 at 20:25 UTC
Updated:
27 Jul 2017 at 15:09 UTC
Jump to comment: Most recent, Most recent file
Comments
Comment #2
ericras commentedThis all has to do with the "Parent item" dropdown on the node form under "Menu settings" for /node/%/edit
Before:
* they see the menus for every group they are a member of, even if the node is not related to some of those groups
* the array is reset so the existing chosen item is lost
After:
* they see only the menus for the groups that the node is related to
* don't reset the array
Comment #3
ericras commentedUpdate to take editing the menu link directly into account
Comment #4
ericras commentedThis builds on #2884746: Menu list not filtered to group menu's when adding a node which only takes creating a node into account.
Comment #5
seanbThank you for spotting this. I have some remarks and questions, but the basic approach seems fine to me. When the node is in a lot of groups this could be an issue, but I guess when you edit a node it is logical to see all menu's of the groups the node belongs to.
I guess we should always use the node groups on edit since a node can belong to multiple groups. If you edit in group B while the node is in the menu of group A, this would still be a problem I think? Maybe we could doe something like this:
This could be an issue when the node is added to a lot of groups. Can we just retrieve the IDs for each group from
$group_contentand doe aloadMultiple()? That would save us a bunch of queries.We can typehint the param like this to document an array of group entities:
@param \Drupal\group\Entity\GroupInterface[]I don't think we need to use
$keyhere?Same here, let's just remove
$key.We can remove the check, since
loadUserGroupMenusByGroup()always returns an array.Comment #6
ericras commented1. Done. Cleans the flow up a bit.
2. Didn't make a change. I saw that the same pattern (using getGroup() in a loop) is used in another couple places in group and groupmenu.
I'm also not totally sure how to change it. I always end up with stuff like ->getValue()['target_id'] which I know is not the "right" way to do it.
This is what I got:
3. Done
4. Done
5. Done
6. Done
Comment #7
seanb#6.2 This should work:
$group_content->gid->target_id.Using magic may not be the proper way to do it, but it is readable and sure is a lot quicker for our use case. So I'd be ok with that. Could you change this? Will commit after this one.
Comment #8
ericras commentedComment #9
seanbSorry, I was about to commit and realised something:
This code will return an empty array for
$groups. Which means that$groupswill return true for theisset()and will filter the enabled menu's even when a node is not placed in groups. I don't think we want that?Small nit, the var will contain group IDs and not groups. We should rename this to
$group_idsComment #10
seanbComment #11
tvoesenek commentedI've updated the patch was suggested and added an extra check to prevent a notice when a node is not placed in groups.
Comment #12
idebr commentedThis approach adds available menus that have not been enabled in the node type. As a result any node type that disabled all menus still has the 'Menu settings' in its node form. The menu ui module also returns a notice:
Notice: Undefined offset: 1 in Drupal\Core\Menu\MenuParentFormSelector->parentSelectElement() (line 91 of core/lib/Drupal/Core/Menu/MenuParentFormSelector.php).
Comment #13
idebr commentedRe #12.1:
Apparently this is a feature that can be configured per Group Content Plugin, so I left this as is.
#12.2
Fixed the notice.
In addition I initialized the $groups variable early in groupmenu_form_node_form_alter() to prevent an exception when filtering the available items.
Comment #15
seanbThanks all! Committed and pushed to dev.