Having a bit of a hack about: i have been experimenting with the idea of how themes might work in Umbraco (e.g in a starter kit or similar). So it could be easy for the user to switch between look and feel, frameworks etc.

Having a bit of a hack about: i have been experimenting with the idea of how themes might work in Umbraco (e.g in a starter kit or similar). So it could be easy for the user to switch between look and feel, frameworks etc. One way to achieve this (with minimal having to write theme extensions and custom partial commands into views) might be to add locations to the folders that asp.net looks for .cshtml files in. (the viewLocations) This is fairly standard AspNet Core (and how Umbraco does it) - so I have some example code to add extra folders https://gist.github.com/KevinJump/2d981be4ed51a0ce3f071636d6a11f60

This 'Works' but only if you add the additional views before

AddWebsite()

is called in the startup.cs e.g

services.AddUmbraco(_env, _config)
              .AddBackOffice()
              .AddAubergineThemes()
              .AddWebsite()
              .AddComposers()
              .Build();

However this has two problems: 1. you can't add the themes in a composer (so users would have to alter this file) 2. because Umbraco adds its views to the front of the list, they will always be found first, what I would want is the files in

/views/theme/mytheme/

to be used and fail back to

/views

looking at the code, I think this is probably because inside

AddWebsite()

models builder does something fancy to the views in

AddInMemoryModelsRazorEngine

(see https://github.com/umbraco/Umbraco-CMS/blob/5bfab13dc5a268714aad2426a2b68ab5561a6407/src/Umbraco.Web.Common/ModelsBuilder/DependencyInjection/UmbracoBuilderDependencyInjectionExtensions.cs#L142:L165) I think this is the point when any new config options are not being loaded into the

RazorViewEngineOptions

So question for the Umbraco brains, - do we think this is something that can be 'fixed' inside the core - so views can be added after Umbraco has added its own? (if so i am happy to see what that might mean.. but its a little out of my depth). - Is there infact another way to add views that would work currently? - Or is this baked into Umbraco and probably isn't the way to go?

Oh wasn't a discussion, was just a message in this channel https://discord.com/channels/869656431308189746/882984798719729704/898303301366448128

If implemented I think the theory is we wouldn't even need composers anymore as could just add to service collection from your hosting startup also.

but probably need pipeline setup to enable ordering.

In terms of overridable views, razor class libraries deserve a look. @User might have thoughts on what's achievable with this.

But then this is backoffice views so I guess you mean angular views as opposed to razor views? Can also go in an RCL, and for allowing loading from multiple providers e.g. from static files and falling back to embedded files etc it's worth looking into https://docs.microsoft.com/en-us/dotnet/api/microsoft.extensions.fileproviders.compositefileprovider?view=dotnet-plat-ext-6.0

Better link for composite file provider here https://docs.microsoft.com/en-us/aspnet/core/fundamentals/file-providers?view=aspnetcore-6.0#composite-file-provider

because they are mutable, whereas packages etc not so much

What does a theme do, add classes, change markup?

think wordpress themes 😉

But they will be Immutable

Very similar to Wordpress themes in that sense

(these days at least)

It essentially ships the views in their compiled state

except for static assets which needs extra work with composite file provider

should be a decoupled frontend build

no i misunderstand, this is for theming a frontend site

I think we need both

but ...

it can have its theme changed, (by the user) so its look and feel could be picked, / frameworks maybe ?

i am going to try RCLs 😄

and Umbraco adds its views to the front of the list

so \views\mytemplate.cshtml is found before \views\themes\mytheme\mytemplate.cshtml

i would want that the otherway around so the theme fell back to the template

(example theme folder paths, could be anywhere)

which I'm hoping to hack on for v10

Although I think Jason took the idea a lot further than I did 😄

At the moment it's only really things that are nodes in a tree that I can't move out of app_plugins

It probably can be tidies up even more, my build scripts will need a tidy for sure

have you tried referencing it from nupkg, Jason mentioned something goes wrong with static assets when that happens, I haven't got round to trying yet (oh that was only when playing with StaticWebAssetBasePath)

it appears to work when you include it as a package. as far as i can tell its a very similar hack as to the one we are already using....

it generates a .props file that goes into your package during development , this means there is an xml file in obj\{enviornment}\staticassets that points back to the nuget cache for the files.

i was worried that means your site would somehow be relative, but when you do a dotnet publish ....

it puts everything into the wwwroot of the site under a _content folder

you can also set the base path -

<StaticWebAssetBasePath>App_Plugins/uSync</StaticWebAssetBasePath>

and this means it behaves "Almost" like its really in App_Plugins, (Umbraco still doesn't load the lang xml files, because its not really there, but other stuff looking for a file (e.g a tree node root) now work, because

/App_Plugins/{Plugin}/backoffice/{plugin}

is now a valid path)

Maybe we can get umbraco to look for plugin assests via the fileproviders they are registering, that way we could read lang files even during debug regardless of if they are in project folder

And a similar trick for finding package.manifests I guess

@User has some simple code for adding the package manifest (which i've used), but it would be good for it to auto load. if lang folders could be added programatically it would fix it

but assume there's a workaround for v9

wwwroot/umbraco/plugins seems pretty reasonable

Some discussion here https://github.com/umbraco/Umbraco-CMS/discussions/10638

for plugins at least, i'd still like to move logs away from config etc

simplify all the gitignores, csprojs, targets etc

on the flip side though, it sounds like it would make RCL easier to utilize for plugin development as wouldn't have to find workarounds for paths

My understanding is though that because v8 will be around LTS so long, and v9 is up and coming that multi targeting would be more useful

but v10 is a new LTS and no one really should stick on v9

just pitched in here and there

is it not ok for you to just say, new features v10 only, v7/8/9 is security fixes only?

(100k is for translation service not us!!!)

I guess my thinking here is, v10 is going to be around a long while, and the same discussion will be for vnext after that also, there's not really a good time for things to move

I'd much prefer a stable convention that is documented and lasts forever, right now things are just a bit chaotic on the filesystem

but then I don't have any packages to maintain so it's very easy for me to say 😄

but i suppose you're right that the best time might be new backoffice

don't think it should be too hard to handle two locations

nice thing about a transition instead of a cutover is that could go into 9 though, 9.3 could add support for wwwroot/umbraco/plugins

then i guess that sucks too, writing a 9 plugin which do you pick, hopefully everyone will apply minor and patches more frequently with 9

but maybe it's better to do such things alongside a major 😕

@User pointed out what the Orchard folks are doing which is probably smarter than my msbuild hack in my POC for static assets in core vs downstream project https://github.com/OrchardCMS/OrchardCore/blob/b0c5e2be69689d99b9987e0396d9e8b7ab33b272/src/OrchardCore/OrchardCore/Modules/Extensions/ApplicationBuilderExtensions.cs#L20-L22 Static assets embedded in dll, with physical file provider taking precedence over the embedded provider