Come together with the global Drupal community in Rotterdam, 28 Sept – 1 Oct 2026. Sessions, contribution, connection, and Early Bird savings until 8 June.
So I had no issue with the xmlsitemap_link_bundle_access() hook, it should have just done a better callback handling, like allowing classes methods/services/functions to be passed a callback by using \Drupal\Core\DependencyInjection\ClassResolverInterface::getInstanceFromDefinition()
Now that the function is deprecated my old code should be useless that granted access to a user who has administer create/edit XY node bundle permission, BUT the committed code does not handle node bundles, the node entity itself does not have admin permission, bundles have.
I'd rather add a separate "can override xmlsitemap settings on items" permission, rather than adding this back in. There might be an existing issue for this? You could also form alter that #access property to TRUE with your specific logic.
I do not want to alter form just to make this very simple feature be implemented. I rather like to concept of adding an "access checker services" that could decide if in the given context a user can add/chance XMLsitemap settings or not on an enitty. That service could be easily decorated by downstream devs to extend the implementation.
Granular permissions are always better and if it out of the scope of XMLSitemap to provide those granular permissions to every entity (including nodes) - I do believe it is out scope - then it should provide a simple way of extending the implementations.
Comments
Comment #2
dave reidI have a feeling that this code is no longer used at all. I'll deprecate those two functions.
Comment #3
dave reidComment #5
dave reidSigh, $entity is not an actual entity, but an entity type.
Comment #7
dave reidCommitted #5 to 8.x-1.x.
Comment #9
mxr576Thanks for the quick fix.
Comment #10
mxr576So I had no issue with the xmlsitemap_link_bundle_access() hook, it should have just done a better callback handling, like allowing classes methods/services/functions to be passed a callback by using
\Drupal\Core\DependencyInjection\ClassResolverInterface::getInstanceFromDefinition()Now that the function is deprecated my old code should be useless that granted access to a user who has
administercreate/edit XY node bundle permission, BUT the committed code does not handle node bundles, the node entity itself does not have admin permission, bundles have.Comment #11
dave reidI'd rather add a separate "can override xmlsitemap settings on items" permission, rather than adding this back in. There might be an existing issue for this? You could also form alter that #access property to TRUE with your specific logic.
Comment #12
mxr576I do not want to alter form just to make this very simple feature be implemented. I rather like to concept of adding an "access checker services" that could decide if in the given context a user can add/chance XMLsitemap settings or not on an enitty. That service could be easily decorated by downstream devs to extend the implementation.
Granular permissions are always better and if it out of the scope of XMLSitemap to provide those granular permissions to every entity (including nodes) - I do believe it is out scope - then it should provide a simple way of extending the implementations.