Customizable Footer for LMS & CMS

[pdpinch]

Abstract

Make footer links easily customizable, enabling the addition of custom navigation links, the organization’s logo, copyright information, and legal links.

This replaces the proposal #324

Detailed Product Proposal

https://openedx.atlassian.net/wiki/spaces/OEPM/pages/4512514079/Proposal+Customizable+Footer+for+LMS+CMS

Context & Background (in brief, if a Product Proposal is linked above)

Legacy LMS allows for the configuration of footer elements such as navigation links, the organization’s logo, and legal links. However, the MFE footer does not currently support this functionality. At present, the only way to achieve this is by forking the footer component repository, which is both difficult and time-consuming to maintain. The goal is to make the footer fully customizable, enabling the addition of custom navigation links, the organization’s logo, copyright information, and legal links.

Scope & Approach (in brief, if a Product Proposal is linked above)

Following the configuration option proposed in the discussion https://discuss.openedx.org/t/plugin-slots-vs-configuration/13009

Value & Impact (in brief, if a Product Proposal is linked above)

At present, the only way to achieve this is by forking the footer component repository, which is both difficult and time-consuming to maintain.

Milestones and/or Epics

Update the PR openedx/frontend-component-footer#403 to follow the proposals in in the discussion https://discuss.openedx.org/t/plugin-slots-vs-configuration/13009

Named Release

Teak

Timeline (in brief, if a Product Proposal is linked above)

This shouldn't take more than a week once everyone is in agreement about the implementation.

Proposed By

MIT Open Learning

Additional Info

No response

[github-actions]

Thanks for your submission, @openedx/openedx-product-managers will review shortly.

[sarina]

Putting this "In Review" I am taking a look at it

[sarina]

From a product perspective, this is good to go.

Implementation wise, @arbrandes and @brian-smith-tcril will help advise on the correct way forward to meet the product specs. Thanks @pdpinch !

[brian-smith-tcril]

I can speak on a way forward for the links aspect of this implementation-wise.

I'd like to recommend following the pattern that the desktop_main_menu_slot in frontend-component-header uses: https://github.com/openedx/frontend-component-header/tree/master/src/plugin-slots/DesktopMainMenuSlot

I also think having defaults for the links would be good instead of having it be blank by default, but I'm very open to thoughts either way on that one.

My overall thought on implementation is to have a default "out of the box" footer that looks good from a product perspective, and provide frontend-plugin-framework slots to customize the aspects of the footer that people want to customize.

Hopefully that at least answers a bit of the "corrent way forward" question!

[PKulkoRaccoonGang]

I also think having defaults for the links would be good instead of having it be blank by default, but I'm very open to thoughts either way on that one.

I think it is quite convenient 💯 However, while the Studio footer already includes a list of links, copyright text, and other elements, the LMS MFE currently lacks a expanded footer content. Perhaps we should repeat the structure (links, logo, copyright) from the LMS Legacy footer and use them as default values. I think it will be quite user-friendly and for administrators.

As for the UI, I really like how the footer looks in Studio, namely the collapsible help button with a few links at the top. It would be great to see something similar in the LMS MFE footer. Something like this:

I'd like to recommend following the pattern that the desktop_main_menu_slot in frontend-component-header uses: https://github.com/openedx/frontend-component-header/tree/master/src/plugin-slots/DesktopMainMenuSlot

I think this could be a useful starting point for modifying the footer. Thanks!

[arbrandes]

A thread popped up on Slack about this today: https://openedx.slack.com/archives/C04BM6YC7A6/p1741187643034179.

TLDR: I said implementation should not wait for frontend-base, and could go ahead by relying on env.config.jsx.

I agree with Brian it should also leverage slots as much as possible.