Problem/Motivation

  • hook_menu_link_defaults_alter but .links.menu.yml
  • hook_menu_local_tasks_alter but .links.task.yml
  • hook_menu_local_actions_alter but .links.action.yml
  • hook_contextual_links_alter but .links.contextual.yml

Proposed resolution

Remaining tasks

User interface changes

API changes

Comments

sun’s picture

sun’s picture

effulgentsia’s picture

FYI: #2301317: MenuLinkNG part4: Conversion changes hook_menu_link_defaults_alter() to hook_menu_links_discovered_alter(). Actually, that latter name is already in HEAD in MenuLinkManager::getDefinitions(), but MenuLinkManager isn't used by core until that issue lands. Changes to that name still possible of course.

dawehner’s picture

I would be fine with hook_links_task_discovered_alter, hook_links_action_discovered_alter and hook_links_contextual_discovered_alter

sun’s picture

Not sure why we're moving away from "info", but "discovered" sounds just weird. Either "info" or "definitions"; e.g.:

hook_links_task_info_alter()
hook_links_task_definitions_alter()

Whether "definitions" is correct and not misleading mainly depends on the point in time the hook is invoked; if the alter hook manipulates the raw definitions right after reading them from .yml files, then "definitions" would be correct. However, if the definitions have been preprocessed in any way prior to the alter hook invocation already, then "definitions" is no longer accurate, whereas "info" would be.

effulgentsia’s picture

"discovered" was added to the menu links one, because MenuLinkManager has an addDefinition() method as well. In other words, some menu links are discovered, and only those are altered, and others (custom links) are pushed into MenuLinkManager (with no alter hook at the plugin level, since code has an opportunity to act at the entity level) rather than discovered from it. We don't have this dual pull/push model for any of our other links, or for any other plugin manager in core (pwolanin mentioned we might have one other one in core with a similar pattern, but I can't find it). Note that custom blocks follow a pull model via derivatives, but that isn't scalable, so if we're concerned about supporting sites with thousands of custom blocks, we may want to consider applying the pull/push hybrid there as well.

dawehner’s picture

Note that custom blocks follow a pull model via derivatives, but that isn't scalable, so if we're concerned about supporting sites with thousands of custom blocks, we may want to consider applying the pull/push hybrid there as well.

There is an issue targeting that problem in a generic way: #2312383: Provide a plugin manager interface which allows to add new definitions/update some/remove some Maybe you have some ideas but yeah I think adding and removing definitions
also has to be take into account for the UI, as that many custom blocks would not scale there as well.

cilefen’s picture

Status: Active » Needs review
StatusFileSize
new3.12 KB

Trying hook_menu_local_tasks_alter() to hook_links_task_discovered_alter().

cilefen’s picture

StatusFileSize
new4.06 KB
new4.9 KB

Here it is, with info_alter() instead of discovered_alter().

xjm’s picture

Version: 8.0.x-dev » 8.2.x-dev
Issue tags: -beta target

This issue was marked as a beta target for the 8.0.x beta, but is not applicable as an 8.1.x beta target, so untagging.

I've moved the issue to 8.2.x since it could be possible to implement this with BC in a minor.

dawehner’s picture

Status: Needs review » Needs work

Obviously we can't just change this now. I'm wondering whether we could leverage the type as array functionality of \Drupal\Core\Extension\ModuleHandler::alter,
to provide some BC compatible way. Changing just the documentation as the patch does, doesn't really help, this is quite sure

Version: 8.2.x-dev » 8.3.x-dev

Drupal 8.2.0-beta1 was released on August 3, 2016, which means new developments and disruptive changes should now be targeted against the 8.3.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.3.x-dev » 8.4.x-dev

Drupal 8.3.0-alpha1 will be released the week of January 30, 2017, which means new developments and disruptive changes should now be targeted against the 8.4.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.4.x-dev » 8.5.x-dev

Drupal 8.4.0-alpha1 will be released the week of July 31, 2017, which means new developments and disruptive changes should now be targeted against the 8.5.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.5.x-dev » 8.6.x-dev

Drupal 8.5.0-alpha1 will be released the week of January 17, 2018, which means new developments and disruptive changes should now be targeted against the 8.6.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.6.x-dev » 8.7.x-dev

Drupal 8.6.0-alpha1 will be released the week of July 16, 2018, which means new developments and disruptive changes should now be targeted against the 8.7.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.7.x-dev » 8.8.x-dev

Drupal 8.7.0-alpha1 will be released the week of March 11, 2019, which means new developments and disruptive changes should now be targeted against the 8.8.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.8.x-dev » 8.9.x-dev

Drupal 8.8.0-alpha1 will be released the week of October 14th, 2019, which means new developments and disruptive changes should now be targeted against the 8.9.x-dev branch. (Any changes to 8.9.x will also be committed to 9.0.x in preparation for Drupal 9’s release, but some changes like significant feature additions will be deferred to 9.1.x.). For more information see the Drupal 8 and 9 minor version schedule and the Allowed changes during the Drupal 8 and 9 release cycles.

Version: 8.9.x-dev » 9.1.x-dev

Drupal 8.9.0-beta1 was released on March 20, 2020. 8.9.x is the final, long-term support (LTS) minor release of Drupal 8, which means new developments and disruptive changes should now be targeted against the 9.1.x-dev branch. For more information see the Drupal 8 and 9 minor version schedule and the Allowed changes during the Drupal 8 and 9 release cycles.

Version: 9.1.x-dev » 9.2.x-dev

Drupal 9.1.0-alpha1 will be released the week of October 19, 2020, which means new developments and disruptive changes should now be targeted for the 9.2.x-dev branch. For more information see the Drupal 9 minor version schedule and the Allowed changes during the Drupal 9 release cycle.

Version: 9.2.x-dev » 9.3.x-dev

Drupal 9.2.0-alpha1 will be released the week of May 3, 2021, which means new developments and disruptive changes should now be targeted for the 9.3.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.3.x-dev » 9.4.x-dev

Drupal 9.3.0-rc1 was released on November 26, 2021, which means new developments and disruptive changes should now be targeted for the 9.4.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.4.x-dev » 9.5.x-dev

Drupal 9.4.0-alpha1 was released on May 6, 2022, which means new developments and disruptive changes should now be targeted for the 9.5.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.5.x-dev » 10.1.x-dev

Drupal 9.5.0-beta2 and Drupal 10.0.0-beta2 were released on September 29, 2022, which means new developments and disruptive changes should now be targeted for the 10.1.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 10.1.x-dev » 11.x-dev

Drupal core is moving towards using a “main” branch. As an interim step, a new 11.x branch has been opened, as Drupal.org infrastructure cannot currently fully support a branch named main. New developments and disruptive changes should now be targeted for the 11.x branch, which currently accepts only minor-version allowed changes. For more information, see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

smustgrave’s picture

Status: Needs work » Postponed (maintainer needs more info)
Issue tags: +stale-issue-cleanup

Thank you for creating this issue to improve Drupal.

We are working to decide if this task is still relevant to a currently supported version of Drupal. There hasn't been any discussion here for over 8 years which suggests that this has either been implemented or is no longer relevant. Your thoughts on this will allow a decision to be made.

Since we need more information to move forward with this issue, the status is now Postponed (maintainer needs more info). If we don't receive additional information to help with the issue, it may be closed after three months.

Thanks!

berdir’s picture

Status: Postponed (maintainer needs more info) » Closed (won't fix)

I think it's fine to close this. It technically still makes sense and we now do have the means to deprecate and introduce new hooks, but we've had those hook names for 10 years now and it doesn't seem worth the trouble of doing the whole BC dance for a better hook name.

xjm’s picture

Saving some additional credits for reviewers and maintainer triage.