[silviubogan]

Made a list of all the installed Aurora add-ons below the version information under the control panels' list.

• I signed and returned the Plone Contributor Agreement, and received and accepted an invitation to join a team in the Plone GitHub organization.
• I verified there aren't other open pull requests for the same change.
• I followed the guidelines in Contributing to Aurora.
• I succesfully ran code linting checks on my changes locally.
• I succesfully ran unit tests on my changes locally.
• I succesfully ran acceptance tests on my changes locally.
• If needed, I added new tests for my changes.
• If needed, I added documentation for my changes, either in the Storybook or narrative documentation.
• I included a change log entry in my commits.

---

If your pull request closes an open issue, include the exact text below, immediately followed by the issue number. When your pull request gets merged, then that issue will close automatically.

Closes #366

[sneridagh]

@silviubogan thanks for working on this Silviu! One thing, I wanted this to take the shape of a virtual module like the last we added during the last weeks. Can I amend your work on this PR?

[sneridagh]

@silviubogan btw, I merged: #363 so it has to be added and make it work well with the work there.

[silviubogan]

@sneridagh

I wanted this to take the shape of a virtual module like the last we added during the last weeks.

Please give me some links. I'm curious.

Can I amend your work on this PR?

Yes.

[sneridagh]

@silviubogan, I opened plone/aurora#403 · Add the @plone/registry/app-info… as a base for this one, and I’d like refactor this PR on top of it. Here’s why.

Why a separate PR: reading the add-ons is infrastructure in @plone/registry, and the list in SiteOverview is a UI feature. Splitting them keeps each part small to review, and the registry part is useful outside the control panel too.

Why we’re dropping the Volto approach (addonsInfo from the add-ons loader, stored in config.settings):

It leaks local paths. addonsInfo is the whole Package record of each add-on, including modulePath, packageJson and basePath. These are absolute paths of the machine that built the site. Putting it in config.settings sends those paths to every visitor’s browser.
It isn’t how Aurora does build-time data. Aurora exposes generated data as virtual modules (@plone/registry/blocks-docs, @plone/registry/plate-editor). The Vite plugin generates each one, and each has a safe fallback for tests and Storybook. Nothing gets copied into config.settings at startup.
It ties code to the internal Package type. Using @plone/registry/addon-registry for its Package type means depending on the registry’s internals just to read a name and a version.

What plone/aurora#403 · Add the @plone/registry/app-info… adds: import appInfo from '@plone/registry/app-info' gives { name, version, addons: [{ name, version }] } with no paths. In tests and Storybook it resolves to an empty app (or you can vi.mock it). SiteOverview already uses it for the Aurora version, so cmsui no longer imports apps/aurora/package.json.

For this PR, after rebasing on plone/aurora#403 · Add the @plone/registry/app-info…:

Read appInfo.addons in SiteOverview.
Drop config.settings.addonsInfo, the addons prop and the Package imports.
Keep your UI, copy button, translations and tests. Mock @plone/registry/app-info in the test and the story.
Note that, as it stands now, the list is always empty in the app: addons defaults to [], which is truthy, so the fallback to config.settings.addonsInfo is never reached.

Here is the mockup with how would it work with the current version of the control panel.

Add-ons Info in Control panel main.zip

Thanks again!

[read-the-docs-community]

Documentation build overview

📚 plone-registry | 🛠️ Build #35744885 | 📁 Comparing 54f4e79 against latest (7e3cc8f)

  🔍 Preview build  

1 file changed

± conceptual-guides/add-on-loader.html

[silviubogan]

@sneridagh Please review.