Refactor header bar and footer menu to be configurable section plugins #5002

aleksip · 2026-01-13T09:45:36Z

Follow-up to #4796

- Also adds a description option to the menu button component - Header menu template supports a `below` key for creating dropdown menus

demiankatz

Thanks, @aleksip -- here is a partial review, primarily focused on the documentation in the configuration files. I thought it might be best to finish this discussion and make sure the docs are correct before I check the implementation more carefully.

config/vufind/Footer.yaml

config/vufind/Header.yaml

module/VuFind/src/VuFind/Navigation/Footer.php

aleksip · 2026-01-13T13:48:53Z

@demiankatz Many of the keys documented in the configuration files were copied over from existing plugins and not actually used at all. Supported keys depend on a combination of plugin PHP code and HTML template code. I have now tried to check that only the keys actually currently used are documented.

demiankatz

Thanks, @aleksip -- a few quick thoughts in response to the latest changes. I'm off to meetings for most of the day now, but I'll review the rest as time permits!

demiankatz · 2026-01-13T13:55:42Z

config/vufind/AdminMenu.yaml

 #   - iconMethod: method to dynamically create the icon name; ignored when
 #     icon is explicitly set.
-#   - checkMethod: the name of an AdminMenu navigation plugin method to perform
+#   - checkMethod: the name of an AdminMenu section plugin method to perform


Is it worth a separate PR to fix the AccountMenu/AdminMenu docs, since that's not directly related to the rest of this PR?

I see you rolled out those changes but haven't opened a separate PR yet. Is that on your to-do list? Do you need me to do anything?

Have now opened a separate PR: #5012. Probably best to merge it only after this and the third section follow-up PRs have been merged.

demiankatz · 2026-01-13T13:58:02Z

config/vufind/FooterMenu.yaml

@@ -0,0 +1,71 @@
+# If this file is empty or missing, default settings will be used, matching


Is it worth adding a "purpose statement" first line to all of these files, like:

# This file configures the Footer section plugin, which renders menus at the bottom of every page.

I also wonder if we should call this FooterMenu, since it's really a menu in the footer and not the whole footer.

Thanks for the rename. What do you think about the earlier suggestion about adding a first-line comment explaining the context/purpose of the section to each of these files?

Yes, a good idea. Did not have time to do it before, but have added them now.

demiankatz · 2026-01-13T13:59:14Z

config/vufind/HeaderBar.yaml

@@ -0,0 +1,48 @@
+# If this file is empty or missing, default settings will be used, matching


If we rename Footer to FooterMenu, I'm not exactly sure what to call this. It's also not exactly the header in its entirety, but it's more than just a menu....

Because of the functionality it contains, instead of just links to pages? It does configure items in a single navbar though. So calling it HeaderMenu would perhaps not be horribly wrong.

The current header.phtml does contain the searchbox, but the section helper call could be moved from layout.html to header.phtml?

Yes, my thought was that the FooterMenu is very much a menu with a specific shape... but the Header section is much more open-ended, with multiple sub-templates that can all do different things. Something like HeaderBar might be fine, though -- I just don't think its exactly a Menu.

I would definitely favor moving the section helper calls inside header.phtml and footer.phtml rather than going directly to layout.phtml, because in many cases (certainly in real practice for several sites at Villanova), the entire files may be overridden with customizations that completely replace the default functionality. Running the extra configuration processing, etc., only to render a totally unrelated template seems counterproductive.

aleksip · 2026-01-15T12:14:25Z

@demiankatz Just noticed that e.g. if the third footer column is removed in local/config/vufind it has no effect since the config files are merged by default. What would be the best approach to override inherited and merged config?

demiankatz

Thanks, @aleksip, I've done a more thorough review of the code. I haven't done any hands-on testing yet, but I thought getting through the documentation and technical review first would be a good place to start. I'll actually try things out once we've finished this part of the conversation.

demiankatz · 2026-01-15T11:43:13Z

config/vufind/FooterMenu.yaml

+#     a check whether to show the group. If omitted, group will always display.
+#
+# Array keys for every menu item could be:
+#   - name: name of an item


What is name used for? We should probably explain why you would use/want this.

This was left over from a copy-paste, now removed.

demiankatz · 2026-01-15T11:44:06Z

config/vufind/FooterMenu.yaml

+# Array keys for every menu item could be:
+#   - name: name of an item
+#   - label: the text shown as link, will be translated - required
+#   - route: route name used to generate link target - route or url required


This might make it slightly more clear that we're talking about which settings are required, rather than the content of this setting.

Suggested change

# - route: route name used to generate link target - route or url required

# - route: route name used to generate link target - required unless url is set

demiankatz · 2026-01-15T11:44:21Z

config/vufind/FooterMenu.yaml

+#   - label: the text shown as link, will be translated - required
+#   - route: route name used to generate link target - route or url required
+#   - routeParams: parameters for dynamic routes
+#   - url: target url, alternative to route - route or url required


Suggested change

# - url: target url, alternative to route - route or url required

# - url: target url, alternative to route - required unless route is set

demiankatz · 2026-01-15T11:45:04Z

config/vufind/HeaderBar.yaml

@@ -0,0 +1,53 @@
+# This file configures the HeaderBar section plugin, which renders menus at the


Would this be more accurate? Or maybe "menus and other controls"?

Suggested change

# This file configures the HeaderBar section plugin, which renders menus at the

# This file configures the HeaderBar section plugin, which renders controls at the

demiankatz · 2026-01-15T11:46:29Z

config/vufind/HeaderBar.yaml

+# Array keys for every menu item could be:
+#   - name: name of an item
+#   - label: the text shown as link, will be translated - required
+#   - route: route name used to generate link target - route, url or template required


Suggested change

# - route: route name used to generate link target - route, url or template required

# - route: route name used to generate link target - required unless url or template is set

demiankatz · 2026-01-15T12:14:56Z

module/VuFind/tests/unit-tests/src/VuFindTest/Navigation/FooterMenuTest.php

+        $menu = $this->getFooterMenu(
+            $container,
+            FooterMenu::getDefaultMenuConfig(),
+            $this->getFooterMenuCheckMethods(false)


Doesn't this approach of mocking out all the check methods prevent us from covering most of the logic in tests? Do we also need tests covering the unmocked class to confirm that constructor inputs lead to expected check method outputs?

I have now refactored the new tests to not use a mocked class at all. I guess the same thing or something similar should be done to the existing AccountMenu and AdminMenu tests. Should I do those changes in #5012 or in yet another follow-up PR? :)

Feel free to add to #5012 -- all menu-related improvements in one PR is fine with me. :-)

demiankatz · 2026-01-15T12:15:20Z

module/VuFind/tests/unit-tests/src/VuFindTest/Navigation/HeaderBarTest.php

+    public function testDefaultMenuAllCheckMethodsReturnFalse()
+    {
+        $container = $this->getContainerWithSectionRelatedServices();
+        $menu = $this->getHeaderBar(


Same question about mocking also applies here.

demiankatz · 2026-01-15T12:16:38Z

themes/bootstrap5/scss/components/buttons.scss

  color: var(--#{$prefix}link-hover-color);
 }
+
+button,


Does this styling impact existing mechanisms, or is this just for the new submenus? (I just want to figure out what needs testing, and also make sure we're not creating a new kind of menu that conflicts with existing menus already in the system).

The rule is meant to affect the menu-button component wherever it is used. I have tried to make the rule very specific so as to not affect anything else. It should only style the newly added description element which did not exist previously.

demiankatz · 2026-01-15T12:18:22Z

themes/bootstrap5/templates/Section/HeaderBar.phtml

+                          'label' => $belowItem['label'],
+                          'url' => $url,
+                          'description' => $belowItem['description'] ?? false,
+                          'selected' => $_SERVER['REQUEST_URI'] === $url,


Is there a way to do this without referencing a superglobal in a template? That's not generally desirable!

demiankatz · 2026-01-15T12:21:11Z

themes/bootstrap5/templates/Section/HeaderBar/HeaderBar-allLangs.phtml

+          return [
+            'label' => $this->displayLanguageOption($langName),
+            'url' => $this->url()->addQueryParameters(['lng' => $langCode]),
+            'selected' => $this->layout()->userLang == $langCode,


Is there an opportunity here to pass these language settings from the HeaderBar plugin instead of through the layout? Or might we actually need a language-setting-specific view helper?

Again, I don't insist on changing this now, but I'm just thinking in the longer term -- using global layout variables should really only be an absolute last resort, and it feels like there may be an opportunity to more clearly encapsulate these settings.

demiankatz · 2026-01-15T12:35:36Z

@demiankatz Just noticed that e.g. if the third footer column is removed in local/config/vufind it has no effect since the config files are merged by default. What would be the best approach to override inherited and merged config?

If I'm reading the YAML loading code correctly, the easiest solution might be to set either the @parent_yaml or @parent_config_name directive to false -- if one of those is set but doesn't resolve to a valid configuration, then inheritance will be disabled. I'm not sure if this is an intended/documented feature of these directives, but if it isn't, I think it should be, since it is useful in this type of situation.

aleksip · 2026-01-16T10:15:15Z

the easiest solution might be to set either the @parent_yaml or @parent_config_name directive to false

Thank you, this seems to work just fine. I have added a note about the possibility, as I suspect this might be a common requirement. Probably good to add the note to the files in #5012 too?

Refactor header and footer to be configurable section plugins

6a3d787

- Also adds a description option to the menu button component - Header menu template supports a `below` key for creating dropdown menus

aleksip requested a review from demiankatz January 13, 2026 09:45

demiankatz requested changes Jan 13, 2026

View reviewed changes

aleksip added 3 commits January 13, 2026 15:24

Fix and improve documentation

274a427

Rename 'below' to 'submenuItems'

9eb22f4

Pass main configuration to plugins

70dde45

aleksip requested a review from demiankatz January 13, 2026 13:48

Fix comments

54261ac

demiankatz requested changes Jan 13, 2026

View reviewed changes

aleksip added 7 commits January 13, 2026 16:03

Revert changes to out of scope files

34f008b

Add menu suffix

515e7e5

Rename HeaderMenu to HeaderBar

65acb7b

Move section helper calls from layout.phtml

96154da

Add first-line comments

c969db6

Update config comments

a169c45

Update plugin aliases

4f789db

aleksip requested a review from demiankatz January 15, 2026 10:05

aleksip changed the title ~~Refactor header and footer to be configurable section plugins~~ Refactor header bar and footer menu to be configurable section plugins Jan 15, 2026

Better footer keys

f3a2951

Fix broken test

0da640e

demiankatz requested changes Jan 15, 2026

View reviewed changes

aleksip added 6 commits January 15, 2026 14:35

Update FooterMenu config comment

b5216c8

Update HeaderBar config comment

9944e85

Fix PHPDoc

c902e27

Get $allLangsEnabled directly from LocaleSettings

bd09a64

Requested and discussed changes

3594a4c

Add note about disabling configuration inheritance

dee9a2c

aleksip requested a review from demiankatz January 16, 2026 10:17

		@@ -0,0 +1,71 @@
		# If this file is empty or missing, default settings will be used, matching

		@@ -0,0 +1,48 @@
		# If this file is empty or missing, default settings will be used, matching

	# - route: route name used to generate link target - route or url required
	# - route: route name used to generate link target - required unless url is set

	# - url: target url, alternative to route - route or url required
	# - url: target url, alternative to route - required unless route is set

		@@ -0,0 +1,53 @@
		# This file configures the HeaderBar section plugin, which renders menus at the

Refactor header bar and footer menu to be configurable section plugins #5002

Are you sure you want to change the base?

Refactor header bar and footer menu to be configurable section plugins #5002

Uh oh!

Conversation

aleksip commented Jan 13, 2026

Uh oh!

demiankatz left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

aleksip commented Jan 13, 2026

Uh oh!

demiankatz left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

aleksip commented Jan 15, 2026

Uh oh!

demiankatz left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

aleksip Jan 15, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

aleksip Jan 15, 2026 •

edited

Loading