I am about to create a new Umbraco project. I wish to follow best practices and run the latest (or at least LTS) version of Umbraco. The site we're currently working on, is a messed up Umbraco 8 installation. One giant mono-project. I would like to do better this next time around, and break everything up. How do you normally structure your solutions? My idea at the moment is to have at least two projects. Web.UI <--- Umbraco Web <--- References Umbraco.Cms.Core packages The idea is to have the Web.UI project only contain views, javascript and css, and stuff like usync exports and the like. And everything else to be housed in the Web project. this is also where I would like my models to be exported from the Modelsbuilder. (i have another thread on here with just how much of a pain in the behind that has been) But I wanna ask this community, how do you structure your new umbraco projects?

As you described but with different names 🙂

I think philosophies will differ quite a lot on this - but having just been through the upgrade of a "messy 8" to 13, we went a bit back and forth on our project structure and actually landed on just 3 projects for simplicities sake. We have project.web project.frontend and project.code and that's it. Anything that is cshtml, app_plugins or a frontend-dist lives in .web anything that is frontend lives in .frontend and then we've settled on a folder-based project for code instead of splitting it up into many projects where we then have to deal with / manage project-dependencies. https://cdn.discordapp.com/attachments/1258323441992466512/1258330925893161010/image.png?ex=6687a77f&is=668655ff&hm=eab2f87adda17441f47988fd2b0894adf5c0b9000ec1fe6005e52abe323c2d3c&

Nice @Kaspar Boel Kjeldsen just what i was looking for. Where are you models published though?

Always find myself coming back to Dennis' post about this https://adolfi.dev/blog/umbraco-project-structure/

yeah that's the one I was gonna follow @rickbutterfield

@User May I suggest “Umbracians” instead of "guys"? We use gender inclusive language in this Discord. 😀

As soon as you go into multi projecting you normally need them somewhere outside of the website project

@Pekdon our models go into Models/Generated if they are from modelsbuilder and into Models/Shared if they are manually build We then use Models/Shared/Partials for models that specifically extends a generated models. Importantly, this is the one place we don't follow folder-structure equals namespacing as we need our models to share a namespace, so they all get namespace Finansforbundet.Code.Models

otherwise you have to go back to .Value for everything

You got the "UnsafeModelsDirectory" option to work then @Kaspar Boel Kjeldsen

A Directory.Props file takes some of the hassle out of managing dependencies across projects. But I've always liked starting with just a .Web project, and then add projects as needs arise

care to show me your Appsettings?

I had SOOO many problems getting that to work yesterday

obviously you don't want ModelsMode nothing while building

i get "inavlid models path"

if thats production you only need ModelModes 🙂

gonna give it another shot today, and be on Umbraco 13 instead of 14

@Matt Wise as you mention we don't need the rest - it is actually set up this way as a fail-safe. Our .local, and .dev appsettings changes the modelsmode, so if someone does anything silly with an appsettings, they can't make models The snippet above is from our appsettings.json which -will- start on it's own without being merged with any of the other appsettings, but in a "mostly harmless" state. Ie. database/apis/elasticsearch/hangfire/etc are pointed towards dev. Ie. the appsettings is bootable even if it doesn't get merged with anything, but you end up running against dev everything but otherwise in production mode, including the runtime mode. It's a bit of a convoluted setup as it's a rather large scaleable site, so we have appsettings.json and .local .dev .staging .staging-edit and .production and .production-edit

Models builder wise we have appSettings as Nothing so it can never make it to production and the rest go in .Local / dev

@Kaspar Boel Kjeldsen and/or @Matt Wise

that should not matter

I know it shouldn't 😦

I'd also support your decision to try Umbraco 13.4, 14 feels a bit experimental still - not that I think that has anything to do with your models-trouble.

yeah

I have a Dev drive so everything is D:\ProjectName 😄 it helps avoid path length issues

just added this https://cdn.discordapp.com/attachments/1258323441992466512/1258340810966044702/image.png?ex=6687b0b4&is=66865f34&hm=b59363685975aa95a8aeecfc22053cac464bd5fb4799d6867f6804b3db802025&

I trust the folders exist? 😉

@Pekdon great!

how do you handle client javascript?

https://skrift.io/issues/vite-and-umbraco-v13/ this is the way I've been leaning recently

@rickbutterfield definitely a good read, especially for new projects. Especially liking the tying together. My project has been dragging a frontend along for a while now, that while it could use a rewrite, is a bit too big for the client to bite on that right now. I've replaced webpack with esbuild, which I believe vite is also utilizing ? 🙂

Alpine.js, HTMX and pretty much just inline blocks of whatever those two needs. Mostly I can do everything with their magic html attributes.