Footer_slot broken in Ulmo?

Site Operators
,
1

Hi,

We use a footer_slot pluging to replace the default footer

With teak, this worked on all MFEs. Now that we upgraded to Ulmo, this no longer works, except on the Catalog MFE. Did something change ?

2

I have yet to try to reproduce it, but after a cursory investigation based on your report I notice that in the release/ulmo.1 branch, frontend-app-catalog’s package-lock.json installs frontend-component-footer@14.9.3, whereas learner-dashboard and learning install it at 14.9.2. The big difference between 14.9.2 and 14.9.3 is the upgrade to Node 24. I wouldn’t expect this to affect the footer_slot in particular, but it’s certainly worth looking into.

Are you able to make any changes at all to footer_slot in other MFEs, or does the problem only appear when trying to load the external file?

3

Well, our footer_slot is two actions

  1. hide the default footer

  2. add ours

and, I believe that even 1) does not happen. Here is screenshots of the two footers.

Default one:

Capture d’écran, le 2026-01-27 à 12.57.50
Capture d’écran, le 2026-01-27 à 12.57.501339×149 13.6 KB

Modified one:

Capture d’écran, le 2026-01-27 à 13.26.05
Capture d’écran, le 2026-01-27 à 13.26.052546×266 38.7 KB

4

I am trying if bumping `frontend-component-footer` to 14.9.3 fixes it, with

I’m not sure what image needs to be rebuilt and how.

`tutor images build mfe`

alone was not enough.

`tutor images build mfe –no-cache`

was not enough either.

I’m trying

`tutor images build openedx –no-cache`

5

That also did not fix it. So I guess the version of `frontend-component-footer` is not the issue ?

6

I believe I found the issue. The issue is that now tutor-indigo overwrites those very same footer_slots, and this overwrites the change we make:

Comparing v20.0.1...v21.0.0 · overhangio/tutor-indigo · GitHub .

and this change does not affect the new catalog MFE because tutor-indigo does not know about it.

7

I came here to suggest you look into disabling other plugins, as I could not reproduce the issue on my machine which only runs the tutor-mfe plugin. It seems like you already found the culprit!

8

So, I tried to hide the slots that `tutor-indigo` creates with

and even giving them higher priority:

but neither worked. Can someone help me understand the priority system with plugin slots, when multiple operations act on the same slots ?

9

It will probably help to try and debug the resulting env.config.jsx directly in an MFE. You can find it at $(tutor config printroot)/env/plugins/mfe/build/mfe/env.config.jsx. Copy that file as-is to the root of an MFE checkout, then add a mount for it (tutor mounts add .... Start Tutor in dev mode without that MFE running (tutor dev start -d mfe should do it), then finally run nvm use && npm ci && npm run dev at the root of the MFE.

This won’t fix the problem, but you can now easily make changes to env.config.jsx to try and understand what’s clobbering what. Once you have something that works you try and translate that back into Tutor plugin territory.

10

Oh, and I would also simply disable Indigo if you can live without it.

11

Yeah, that’s what I ended up doing, removing tutor-indigo. At this point, with the plugin slots, there isn’t much need for it anyway.

12

Hi Guys, I have added a solution here(Link) using mfe-env-config-runtime-final patch that you guys can use in your tutor plugin, for overriding the indigo footer while keeping indigo plugin itself enabled.

We can discuss this further as well.