Problem/Motivation
$ git grep -li shortcut core/modules/navigation/
core/modules/navigation/config/install/navigation.block_layout.yml
core/modules/navigation/src/Hook/NavigationHooks.php
core/modules/navigation/src/NavigationServiceProvider.php
core/modules/navigation/src/Plugin/Block/NavigationShortcutsBlock.php
core/modules/navigation/src/ShortcutLazyBuilder.php
core/modules/navigation/tests/navigation_test/src/Hook/NavigationTestHooks.php
core/modules/navigation/tests/src/Functional/NavigationSafeBlockDefinitionTest.php
Steps to reproduce
Proposed resolution
Includes removing Shortcut from ConfigImportAllTest.php because Navigation uses simple config incorrectly. See #13
Remaining tasks
Is the manual testing in #25 complete? See the limited results in #29.
Add UpdateTest
Review
Review the change record
User interface changes
Introduced terminology
API changes
Data model changes
Release notes snippet
Issue fork drupal-3581816
Show commands
Start within a Git clone of the project using the version control instructions.
Or, if you do not have SSH keys set up on git.drupalcode.org:
- 3581816-moves-uses-of
changes, plain diff MR !15231
- 3581816-11-x
changes, plain diff MR !16710
Comments
Comment #3
smustgrave commentedGoing to try and help this weekend
Comment #4
smustgrave commentedComment #5
penyaskitoNW per MR review.
Comment #6
smustgrave commentedFeedback should be addressed.
Comment #7
dcam commentedI found a few things and added comments to the MR.
Comment #8
smustgrave commentedI can't resolve threads but can someone do that not sure what's left for this one.
Comment #9
dcam commented@smustgrave, the unresolved action items are:
Comment #10
quietone commentedI've yet to see why ConfigImportAllTest.php is failing on 'search_help'.
https://git.drupalcode.org/project/drupal/-/pipelines/804483/test_report...
Comment #11
quietone commentedFrom the browser output it is failing when re-installing navigation.
Drupal\Core\Config\Schema\SchemaIncompleteException: Schema errors for navigation.block_layout with the following errors: 0 [sections.0.components.00b005e5-d42b-4685-9dc7-272438fbec6b.configuration.provider] Module 'shortcut' is not installed. in Drupal\Core\Config\Development\ConfigSchemaChecker->onConfigSave() (line 98 of core/lib/Drupal/Core/Config/Development/ConfigSchemaChecker.php).Comment #12
quietone commentedThe Shortcut module now uses hook_navigation_defaults to define default content for the Navigation bar. This used to be defined in the navigation module. So, when the configuration is exported in ConfigImportAllTest the navigation.block_layout contains config that requires the Shortcut module. The test installs everything and exports config. It then uninstalls everything and imports the config. It is the config import that fails with the error shown in the previous comment, that Shortcut is not installed. So, by using hook_navigation_defaults it has navigation now has a dependency on Shortcut. At least that is what I see. How to resolve this?
Comment #13
berdirThere is no clean solution to this. The fact that navigation module store plugin configuration with dependencies in a simple config object is fundamentally wrong and not supported. Simple config can not depend on other modules/config. Similar problems would happen if you place a menu block there and then remove that menu.
Since this is about shortcut being removed, I'd go with a quickfix, that is, exclude shortcut from this test, so we don't run into this situation for this test. AFAIK we do that anyway with deprecated modules, so we're just doing it a bit early in this case.
The only proper fix would be to refactor how navigation module stores it's configuration, for example by putting each block placement into it's own config entity, not unlike block.module handles placed blocks. hook_navigation_defaults() wouldn't even need to exist anymore then, shortcut.module could just provide a default block. And it would also automatically handle dependency removal, removing that block when you uninstall shortcut.
Comment #14
quietone commented@berdir thanks! I made an issue in Navigation, #3587499: Navigation stores plugin configuration with dependencies in a simple config object
Comment #15
dcam commentedThere are a couple of items to take care of that I left comments about in the MR. There is a loss of test coverage that needs to be ported to Shortcut. And the CR URLs in the deprecation notices are still placeholders. Also, we'll need a change record.
Comment #16
quietone commented@dcam, thanks again. Yes, I put zeros in the change record URL and intend to get back to fix it. But too often I forget to do that.
Comment #17
dcam commentedThat's fine. I wasn't 100% sure if that was intentional because you were waiting on some feedback or for some other reason. But I figure it's better to document a finding than not. That way there's less chance that someone else comes along to review, misses the placeholder, and then RTBCs the MR. Thank you for considering my feedback.
Speaking of which, my feedback has been addressed. I think this is ready to send up.
Comment #18
alexpottI'm not sure about one of the comments in the MR. It's pointing to a closed issue - so if it is fixed do we need this code - or is it pointing to the wrong issue?
Comment #19
quietone commentedI had a go at improving the comment.
Comment #20
dcam commentedI think @alexpott's concerns from #18 have been addressed. The comment's point is clearer to me now than it was before.
Comment #21
quietone commentedComment #22
godotislateSome comments on the MR.
Couple more thoughts:
moved_classesservice parameters to move NavigationShortcutsBlock and the navigation ShortcutLazyBuilder. See https://www.drupal.org/node/3509577navigation_shortcut_blockcomponent needs to be removed fromnavigation.block_layoutconfig, because now that block plugin won't exist anymorenavigation_defaultshook is invoked as expected, and the shortcut block is added. OTOH, if Navigation is already installed and Shortcut uninstalled, then if Shortcut is installed thenavigation_defaultshook is not invoked, so the the shortcut block does not get added. I think maybe there needs to be code inshortcut_install()to add it, but there may be problems trying to add tonavigation.block_layoutin the situation where navigation and shortcut are both uninstalled, but are installed in the same request. See MR comment.Comment #23
smustgrave commentedaddressed the first 2 bullets but not sure what to do about the third.
Comment #24
smustgrave commentedtest failure seems relevant to the change in shortcut.install now.
Comment #25
godotislateLooking at the test browser output, looks like there are two instances of the shortcut block now. My mistake,
hook_navigation_defaultsis invoked both onnavigation_install(hook_install) ANDNavigationHooks::modulesInstalled(hook_modules_installed), so the change toshortcut_installis not needed.Still, we should manually test the following scenarios
1. Install minimal profile. Then install navigation and shortcut together
2. Install minimal profile. Then install navigation. Then install shortcut
3. Install minimal profile. Then install shortcut. Then install navigation
And make sure the shortcuts block appears in navigation as expected.
Comment #26
smustgrave commentedSince this is the last blocker for shortcut to get removed, asked Claude for some help and it added a check to see if shortcut was already in the navigation. Lets see if that turns green.
Comment #27
smustgrave commentedAll green what do we think or do we need to add more coverage per 25
Comment #28
godotislateUnless I missed it, I don't see an update test in the MR, so we do need that.
I think confirmation of #25 with manual tests is probably fine.
Comment #29
quietone commentedI did the manual testing outlined in #25 and didn't encounter any errors. In all cases I was able to create a shortcut and edit the name of the set. However, #25 doesn't state what is to be tested. So, I have no idea if that is complete or not.
I rebased the MR and updated the versions in the change record.
A reminder to use tags and update the issue summary. If this had been tagged for ' needs manual testing' I would have found this a few weeks ago.
Comment #30
quietone commentedI had a go at an update test.
Comment #31
smustgrave commentedReviewed https://git.drupalcode.org/project/drupal/-/merge_requests/15231/diffs?c... and worked for me (as in ran). This one good to go?
Comment #32
longwaveSome questions about the
moved_classessetup - I thought the point of that was that we didn't need to leave the old class in place at all, but also what happens if the target module is not installed?Untangling this sort of thing is super tricky so thanks for the work so far, most of it looks good - this is not easy at all.
Comment #33
quietone commented#22 suggested using moved_class for NavigationShortcutsBlock and the navigation ShortcutLazyBuilder. NavigationShortcutsBlock was done but it left the 'old' class with the typical deprecation. Which method should be use for NavigationShortcutsBlock? ShortcutLazyBuilder was not done. Should it?
Changing status to get opinions.
Comment #34
godotislateRe: #33, yes if moved_classes is used, then the original classes should be deleted, and the moved_classes functionality should provide the deprecation warnings automatically.
Or if we don't use moved_classes, then the original classes should still exist but with manual deprecation.
Comment #35
quietone commentedOK, then I have removed the moved_classes simply to keep the style of all I've used in other extension deprecations.
Comment #36
smustgrave commentedBelieve feedback about not doing moved_classes has been addressed. Lets land this one hopefully :)
Comment #37
larowlanLeft some MR comments
Comment #38
quietone commented@larowlan, thanks for the review!
I've updated the review based on the feedback. The failing test is unrelated.
Comment #39
gábor hojtsyI checked the feedback was resolved and closed the remaining thread.
On manual code review I was surprised that there was no update to the "new block name", then realized that even though its a new block class and moved to the Shortcut module the block name is still namespaced/named as
navigation_shortcuts. I can see the appeal of keeping the name even though we would not name it like that were it a new block in shortcut module. (I assume it would beshortcut_navigationor something?) I don't think its a big deal to keep the old name and it does simplify things, so let's not block on that further IMHO.Otherwise looks good to me.
Comment #41
catchThis looks good to me. I wasn't sure about the extra shortcuts/navigation test fixture vs adding that to the 11.3.0 dump, but then I realised that fixture will go away when we remove the update, so it makes sense to do it like that.
Committed/pushed to main, thanks!
Will need a backport MR for 11.x
Comment #43
quietone commentedGrrr! This should be reverted. Just like #3614949: Move tests to Olivero, part 1 there is a namespace error.
There were conflicts were in:
Comment #45
catchPushed the revert.
Comment #47
quietone commentedThe test failure on 11.x is Drupal\Tests\ckeditor5\FunctionalJavascript\CKEditor5AllowedTagsTest::testFullHtml, a known random failure.
Comment #48
quietone commentedComment #49
smustgrave commentedSince failure was around namespace https://git.drupalcode.org/project/drupal/-/merge_requests/15231/diffs?c... looks to fix it. Restoring RTBC.
Comment #52
catchCommitted/pushed to main, thanks!
I also committed/pushed to 11.x but composer is failing on 11.x for me today, so had to use --no-verify on the commit.
Comment #54
quietone commentedPublished the change record