feat: deprecate indigo footer

[HammadYousaf01]

Deprecate Indigo footer package #144

[ahmed-arb]

Is release the right target for this PR?

[ahmed-arb]

LGTM. I just have a few questions

[ahmed-arb]

Is there a reason for changing the alias to its slot ID?

[HammadYousaf01]

I think we should move from the legacy alias footer_slot to the canonical, versioned plugin slot ID org.openedx.frontend.layout.footer.v1. The alias still works for backward compatibility, but using the fully qualified slot ID aligns with current OpenEdx conventions and helps keep the code forward-compatible.

[ahmed-arb]

Looks good. Just change the base branch to main.

[mboisson]

This PR broke our own customizations of footer that we used to add on top of tutor-indigo, which we do through a tutor plugin:
https://github.com/calculquebec/tutor-plugins/blob/cq/ulmo.dev/plugin_slots.py#L102

[mboisson]

This is being discussed in this discuss thread: https://discuss.openedx.org/t/footer-slot-broken-in-ulmo/18329/6

[Faraz32123]

This PR broke our own customizations of footer that we used to add on top of tutor-indigo, which we do through a tutor plugin: https://github.com/calculquebec/tutor-plugins/blob/cq/ulmo.dev/plugin_slots.py#L102

Hey @mboisson,
Basically the purpose of this PR was to follow openedx convention of using plugin slots and reducing the maintenance for indigo footer separately.

And regarding the issue(i.e. overriding the indigo footer) you guys are facing, I had some capacity today to look into it.

Can you guys try using mfe-env-config-runtime-final patch in your tutor plugin like I am using in below code, this way you guys can use your custom footer while keeping the indigo(which offers better theming overall with a dark theme as well) plugin enabled.

from tutor import hooks
from tutormfe.hooks import PLUGIN_SLOTS

PLUGIN_SLOTS.add_item(
    (
        "all",
        "org.openedx.frontend.layout.footer.v1",
        """ 
        {
            op: PLUGIN_OPERATIONS.Insert,
            widget: {
                id: 'custom_footer_change',
                type: DIRECT_PLUGIN,
                priority: 2,
                RenderWidget: () => <div>
                    <h4>Custom Footer</h4>
                    <p>© 2026 Custom Platform. All rights reserved.</p>
                </div>,
            },
        },
        """,
    ),
)
hooks.Filters.ENV_PATCHES.add_item(
    (
        "mfe-env-config-runtime-final",
        """
if (config.pluginSlots && config.pluginSlots['org.openedx.frontend.layout.footer.v1']) {
  config.pluginSlots['org.openedx.frontend.layout.footer.v1'].plugins = 
    config.pluginSlots['org.openedx.frontend.layout.footer.v1'].plugins.filter(plugin => {
      const widgetId = plugin.widget?.id;
      return widgetId !== 'custom_footer';
    });
}
        """,
    )
)

We are open to discussion if you face any further errors.

[mboisson]

We ended up removing tutor-indigo instead. We are replacing the header and footer anyway, and had modified the templates for the legacy pages as well. There wasn't much left from the original tutor-indigo.

If I had to recommend something though, it would be to make sure that the "priority" actually work, i.e. operations with higher priority are applied after operations with lower priority.

[Faraz32123]

If I had to recommend something though, it would be to make sure that the "priority" actually work, i.e. operations with higher priority are applied after operations with lower priority.

It's an upstream issue as priorities for plugin slots are not handled in tutor-indigo plugin. May be you can create one in openedx/frontend-plugin-framework repository to confirm if there is some bug.

[Faraz32123]

Hey @mboisson,
For your convenience, and those who visit this PR, We had a chance to discuss the priorities within our team.
And we reached to a conclusion that purpose of setting Priority isn't to override the default component or component with lower priority.
You can see this example(Link). I have also attached its image.

Let me Explain it a bit,
Default component has a priority of 50.
Let say we are inserting 2 widgets with 10 & 100 priority,
All of these will appear, none of these will be override. Priority just decide the order of the widget(component with lower priority will appear first).

So, we can close this issue: openedx/frontend-plugin-framework#121

[mboisson]

Hey @mboisson, For your convenience, and those who visit this PR, We had a chance to discuss the priorities within our team. And we reached to a conclusion that purpose of setting Priority isn't to override the default component or component with lower priority. You can see this example(Link). I have also attached its image.

Let me Explain it a bit, Default component has a priority of 50. Let say we are inserting 2 widgets with 10 & 100 priority, All of these will appear, none of these will be override. Priority just decide the order of the widget(component with lower priority will appear first).

So, we can close this issue: openedx/frontend-plugin-framework#121

I see... so there's no way to hide something that has been added by another plugin ? (i.e. to replace it) ?

[Faraz32123]

I see... so there's no way to hide something that has been added by another plugin ? (i.e. to replace it) ?

Actually there is, that I have suggested above(Link). We are also adding this patch by default in tutor-indigo(PR) So that if someone wants to override the footer, they can do it while keeping the indigo plugin enabled.