How to access theme component setting from another theme component

Is there a way to access one theme component’s settings from another theme component? It seems like settings contains settings only for the theme component that it’s in.

If it’s not possible to access one theme component’s settings from another theme copmonent what is the best way to do that?

  • have a single theme component?
  • move settings into the primary theme (but are those available? I’ve not tested that yet).
This is technically feasible, but as David's stated below, please don't use it

I took a look because it’s quite an interesting question! :+1:

There is a place in discourse/lib/theme-settings-store where the theme settings are stored and exported functions such as getObjectForTheme or getSetting. can be used.

You can retrieve the value of a setting for any theme component as long as you have its ID.
However, I couldn’t find an easy way to retrieve the translation ID ↔ name mapping.

That said, you could do the following trick:

// Retrieves from <link> tags the theme name <-> id mapping for the active theme components
const themesComponents = Array.from(
).reduce((acc, link) => {
  acc[link.dataset.themeName] = parseInt(link.dataset.themeId, 10);
  return acc;
}, {});

// Gets the theme id based on its component name
const themeId = themesComponents["discotoc"];

// Gets all the settings
const themeSettings = getObjectForTheme(themeId);

// Gets a specific setting
const themeSetting = getSetting(themeId, "anchor_icon");




I’m unsure that’s the best reliable way; some helpers would be nice if it does not exist.


Settings from different themes/theme-components are deliberately isolated. Having interdependencies between themes/theme-components makes them very difficult to develop and support.

As @Arkshine demonstrated, it is technically possible to hack your way to find the data, but I would STRONGLY recommend against it. The strategy will break if an admin changes the name of a theme in the admin panel, and is also quite likely to randomly break with future core changes.


My bad, I realized that the code I provided may not be reliable. I should really be careful about what I display here. Hacking is fun, but it lasts till it leads to unwanted usage and issues in the future. :worried:


Oh no worries at all @Arkshine - it’s always good to experiment. Having the [details] note in your post is good to make sure people know the risks they’re taking :chefs_kiss:

If sharing settings like this between plugins and/or theme components becomes a common requirement, then we can certainly work out some more robust options. Perhaps we can use this topic to lay out example use-cases.

My gut feel is that, if a theme is trying to use settings from another theme then… perhaps they should be merged into a single repository?


This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.