Shapes from the front end themes are not registered on TheAdmin

[orchardbot]

@sebastienros created: https://orchard.codeplex.com/workitem/16654

Shapes are not registered in ShapeDescriptors if we are on the Admin and the shape is inside the front-end theme. This is an issue as soon as we want to display a part in the Admin, which is embedded in a theme, for instance a Site Settings Part.

Repro:

Create a theme with a settings part Add a handler to register it to "Site" Create a Driver for it and implement the Editor Actual: The part is no displayed in the Site Settings

[orchardbot]

rpaquay commented:

Louis, is this "by design" because we don't have Admin UI composition?

[orchardbot]

rpaquay commented:

The issue is as follows: A theme is not "enabled" in the admin panel. So, if a theme exposes a shape, that shape is not available for rendering in the admin, since the shape rendering code looks at modules, then enabled themes for the request when looking for shape overrides. Fixing this requires design, as there are many possible solutions: An "Admin" attribute for shapes, an "Admin" folder for template looking, an "Admin" attribute on the controller action, etc.

[orchardbot]

@bleroy commented:

The theme cannot add site settings but it could in principle add its own custom settings page that it owns, and its own admin menu entry. I'll investigate.

\ Closed by BertrandLeRoy 12/02/2010 11:54AM

[orchardbot]

@bleroy commented:

Oops.

[orchardbot]

@loudej commented:

Here are some more thoughts about feasability, and a possible approach... Two ingredients may needed: (optionally) an admin controller and other compoents from an enabled theme, and (required) getting the theme's paths in the hunting order when "TheAdmin" is the current theme.

The theme's paths would be a special case added to the ThemeAwareViewEngines.DeepEngines(theme) method. Right now it has the folders for the current theme followed by all modules with active features. If the current theme is "TheAdmin" it would have that theme first, ++followed by folders of all active themes++, followed by all modules with active features.

The second ingredient is to verify that a theme (when enabled) can have components like a controller and/or an admin menu provider for a simple case. To verify more advanced usage (optional) we could check if a theme could also have records, content parts, and migrations for adding theme-specific properties to site settings or content items.

[orchardbot]

rpaquay commented:

Fixed in changeset 8b1499c3b9d4

[orchardbot]

rpaquay commented:

Note that for a Theme, the path for looking at controller/action views is slight different than modules: you have to create a sub-folder in "Views" with the same name as the theme, for example: ~/Themes/[MyTheme]/Views/[MyTheme]/[Controller]/[Action].cshtml (or ascx)

[orchardbot]

@sebastienros commented:

Fixed in changeset 8b1499c3b9d4

[orchardbot]

@sfmskywalker commented:

Fixed in changeset ab3d0a2636a2339c6f0127fd1af09f5c411a81ce