Customize Footer links in MFEs

[pdpinch]

1. Is there an existing issue for this?

• I have searched the existing issues

2. What new feature or functionality would you like to request?

Legacy LMS provides a way to configure the footer links but the MFE footer has no support for doing this. Currently the only way to achieve this is to fork the footer component repo, which is difficult and time-consuming to maintain.

3. What product area does this feature affect?

MFEs

4. Please describe the scope of the feature

This customization would affect all MFEs that rely on the footer component.

5. Please describe why you see a need for this feature

I need to add links in the footer to my institution's accessibility policy, terms of service, honor code, etc. I used to do this by creating a custom theme, but that approach doesn't work with MFEs.

6. Please describe the potential impact and/or value of this feature

Controlling the footer links via settings is much easier to maintain than forking the footer.

7. Please provide 2-3 use cases and/or user stories in support of this feature

1. As an operator, I need to be able to customize the links in the MFE footer, similar to what I can do with the legacy footer, so I can add legally required links with instance-appropriate URLs and without having to fork the footer component library.
2. As a user, I'd like to see a consistent footer across all pages in an open edX instance.

8. Any additional information you'd like to provide?

Meta question: is this a necessary and appropriate use of the Product Review process?

9. Please include screenshots or screencasts that help describe the UI and UX of this proposal

Note that this proposal is to manage these links via configuration code, so there is no operator UX for adding or changing links.

Here are the UI changes:

1. Custom footer links managed pre-MFE via a custom theme

2. Default footer with the MFE

3. Proposed footer with configured links

[github-actions]

Thanks for your submission, @openedx/open-edx-project-managers will review shortly.

[pdpinch]

For what it's worth, there is already an open pull request that makes this change: openedx/frontend-component-footer#403

[jmakowski1123]

Thanks for submitting this, @pdpinch !

Yes, absolutely the correct use of the product review process.

Couple of questions, and feel free to ping anyone who should be part of the conversation:

This would need to be implemented in a standardized way across all the MFEs. From a product perspective, we'll want to define

a) which MFEs require footers, and
b) what "out of the box" fields should be included, and
c) which fields of that list can be customized.

Am I correct in interpreting that this PR only addresses the legal field in the footer, and not all fields in the footers?

I'm happy to take part in creating those definitions, but wondering who are all the stakeholders involved?

[jmakowski1123]

In the original PR, what's the origin of this list of custom fields? Are these all specific to edx.org?

ACCESSIBILITY_URL
ABOUT_US_URL
HONOR_CODE_URL
CONTACT_URL
SUPPORT_CENTER_URL
SUPPORT_CENTER_TEXT
TRADEMARK_TEXT
FOOTER_LOGO_ALT_TEXT
SHOW_FOOTER_LOGO
TERMS_OF_SERVICE_URL
PRIVACY_POLICY_URL

[pdpinch]

This would need to be implemented in a standardized way across all the MFEs. From a product perspective, we'll want to define

a) which MFEs require footers, and
b) what "out of the box" fields should be included, and
c) which fields of that list can be customized.

a) All MFEs that need a footer should use the shared footer library, frontend-component-footer. It's possible that very old MFEs, like frontend-app-authn predate it and need to be updated.

b) I don't think there are any "out of the box" links in the footer. I think they all need to be defined. @asadali145 can you confirm?

c) Configurable URLs in MFEs are not well documented. frontend-component-footer has a sample .env.development file that suggests a wide range of possible settings.

In the original PR, what's the origin of this list of custom fields? Are these all specific to edx.org?

I believe these were all added by edx.org, but I think they are broadly useful. We use them.

[asadali145]

b) I don't think there are any "out of the box" links in the footer. I think they all need to be defined. @asadali145 can you confirm?

Yes, they all need to be defined. There won't be any links in the footer when these settings are not configured.

[pdpinch]

I added a section to the description with screenshots for the UI changes.

[arbrandes]

@pdpinch,

It's possible that very old MFEs, like frontend-app-authn predate it and need to be updated.

That MFE in particular I think was never meant to have a footer (or a header). It's more like a modal.

Otherwise, yes, I'm sure there are MFEs that aren't well-behaved in this regard. There certainly are some that don't use frontend-component-header.

[jmakowski1123]

Child PRs:

• feat!: footer legal links frontend-component-footer#403

[ali-hugo]

@pdpinch @asadali145 Sorry for the slow feedback on this.

I've chatted to @jmakowski1123, and we decided that the MFE footers should match the footers in the new Studio designs. We are not sure which of the following footer layouts will be used in the new-and-improved Studio, but I am in the process of confirming this with 2U.

• Footer Option 1
• Footer Option 2

I will be in touch as soon as I have received a response from 2U. Let me know if you have any questions in the meantime.

[pdpinch]

Thanks @ali-hugo, but this proposal is just about configuring the links. It should work with any styling.

Do you know if there is a plan for how the footer will be customized by open edX operators?

[ali-hugo]

@pdpinch Oh, I see - thanks for clarifying that. I saw the images in the description and assumed there was a styling aspect to this proposal as well.

Do you know if there is a plan for how the footer will be customized by open edX operators?

I don't, but can ask in the Core Product meeting later today if anyone else does. I'll update you tomorrow.

[ali-hugo]

Hi @pdpinch. No one in yesterday's meeting knew the answer to your question off-hand, but @jmakowski1123 said she will look into it and get back to you.

[bradenmacdonald]

@pdpinch

Do you know if there is a plan for how the footer will be customized by open edX operators?

Check out openedx/frontend-component-footer#405

Unfortunately the review process has been a little slow (my fault in part, but also I'm not sure who the proper reviewer even is), so it didn't make the Redwood cut - but I think we need something like this ASAP. CC @arbrandes

[arbrandes]

Copy-pasting what I just wrote on the PR:

I think that at least for now we're going to go on a different architectural direction. As I've been mentioning elsewhere, the footer (and of course, the header) are perfect candidates for plugin slots: this will allow operators to customize them much more flexibly than just setting a few hard-coded links.

This effort is already in progress via openedx/wg-frontend#178, and we're hoping to make it available in time for the Redwood release.

For the record, there is a competing implementation of the footer as a slot that also allows individual links to be configured via a backend API call. I figure if we're going with this level of granularity at all, that PR is a better approach:

openedx/frontend-component-footer#405

[arbrandes]

I've started a forum thread for us to discuss the question of plugin slots vs configuration. As noted there, I intend to eventually create an OEP (or two) based on that discussion so that we end up with an official stance on when-where-how to use config vars, and when-where-how to create plugin (slots) instead.

https://discuss.openedx.org/t/plugin-slots-vs-configuration/13009

[mphilbrick211]

@asadali145 @arbrandes @jmakowski1123

Per the convo here, can this be closed?

[asadali145]

@mphilbrick211 I would like to get a response from @arbrandes regarding the approach and then I can update this PR.

[mphilbrick211]

Checking in on this, @asadali145 @arbrandes