The future of Umbraco Core

Okay, that's about ten seconds. Alright, so I'm going to try to keep this to time, and apparently there isn't a specific amount of time, but I'll make it like 45 minutes, hopefully. Maybe even less. This is going to be similar to my UK Fest talk. I don't know if you guys were there, I'm sure some of you were. But I ended up talking for an hour and a half, and it was only supposed to be 45 minutes. So if it gets too long, just yell at me or something, but I think we'll just fly through these slides. It is the end of the day. I assume some of you might be tired. I think everyone should get a beer. Don't go get one now if you don't already have one, because I'm starting. But it's the end of the day, so we'll try to make it exciting, and hopefully you'll like it. So, this is the future of Umbraco Core. So this is... Talking about versions of 7s to 8s, etc. So here we go. This morning we talked about this, and I'm just going to show the slide again, because it's pretty important. So this is a quick recap. Now, if you think about how much we did last year, I want to make it even bigger this year. And that is going to require a lot of your guys' help. So more pull requests, more community involvement, and that's sort of what the 7.x series is going to be about. So if you missed this morning, have a quick read, but I'm going to change the slide now. API docs is a brand new thing. I don't know if you guys saw a tweet. We didn't really blog about it or anything. But these are things that have been missing for many, many years. We've just been talking about it, and never really did anything about it. We had Bell docs for the Angular stuff, but never any C-sharp docs. So... The API docs reference is at this address, and they link to two different applications. I know Doug wasn't a huge fan that they don't look identical, and they're not the same exact thing, but at least it's something. Something's better than nothing, and we'll continue to work on these. So this is my first demo to show you these things. Whoo! All right. Okay, so... Oh, hang on. I do this every time in a demo, and I never switch screens properly. There we go. This is PowerPoint's fault, by the way. Oh, dear. Every time I do it. Okay, I can see down there. That's good. So the entry point is reference, and we have two links. C-sharp API documentation. So C-sharp and Angular. I've already opened the links here. So this is the C-sharp documentation. You can search it. You can filter it. It's got all sorts of stuff in here, which pulls out all of our XML comments from in the code. We write a lot of XML comments in our code without being mindful that they were ever going to be on a public site. So you might find some hilarious things in there. There's probably a few WTF-type things or what the heck is going on. Probably some stories. There's probably a few stories in there. Let's have a look at application context. So you can see it gives you all the constructors, you know, like normal MSDN docs, just a bit better. And it's also worth noting... Hang on. I'll close my downloads. That this is made with something called DocFX, which is a Microsoft .NET Core-type thing. You can find it on the repo. If anyone's used Sandcastle... Ugh. It's terrible. This is actually really awesome and super easy to use. The next one up was... All right. Here we go. So they do look slightly different. But, hey, this is my CSS, by the way, and I'm not the CSS guy. But I thought it did a pretty good job. So this is Angular. You can click on all these things, and it tells you... There's a few that have... There you go. Look. Examples and everything. Whoo. All right. All right. That's pretty great. Now, another thing that we tweeted about... Again, didn't blog about it. It's been asked for in the community for quite some time... Is how we go about dealing with security in the core. So we put up a page on the .com site called Security. And if you ever have a client that wants to know how secure Embraco is and what kind of security policies we use for the back office users and members and all that stuff, you can have a look here. It's pretty comprehensive. It should give you all the details you want. It tells you how to log a security issue if you have one. It tells you about security issues we've had in the past and about an auditing company that we're using. So we're going to have the core audited for specific sections, say, quarterly. We haven't fully figured that one out yet. But it's for all new features that we think could impact security. So we are having security auditors tell us if we're doing things right, which is great. It's great for everybody, really. So that's the first demo. I'll see if I can get these slides back up. All right. So let's talk about 7.5. This is out in the wild now. So we got 7.5 beta released. And it works. It works really well. We've been testing and using it for many, many, many months. What's really cool, though, is how many community-driven features are in here. So those are all highlighted in blue. So Health Check has been talked about. We talked about that this morning. Forgot password. Andy Butland, where are you? There he is. Give that guy a round of applause. I mean, that's awesome. This has been an issue. I think I have some notes on it. It might come up in a slide. I think it's, like, issue 23 or something. This was actually imported from CodePlex from 2009 or something. Anyway, it's there now. It's 2016. Took us a while. Thanks, Andy. But these are the version features that we're going to talk about. So we'll go through these. Package version targeting. What does this mean? This is actually the biggest feature, in my opinion, of 7.5. This is the most important thing. Because this will change how you guys make and manage packages for the future. So now, like Nougat, if you make a package on Nougat, you can specify a minimum dependency or a minimum requirement on something. What it means is that if you have all this old code in your package and you said, my package supports version 4 to version 7, do you know how much work is involved to make that backwards compatible? I've called something here reflection-driven development. And that's not a healthy way to develop. So if you have old packages and old packages, all you see is reflection used to call these new and old APIs. With this change, if you publish your package on Embraco 7.5, you can pin it to 7.5. Which means all the future versions will respect that. You won't be able to install higher requirement versions on older ones. And we can demo that in a sec. So that means you can get rid of all that old legacy code. Richard Soatman, where are you? There he is. That guy's been maintaining old, old code for so long. Now you can just wipe the slate clean. Woo! So how do we do this? The bottom tag there is versioning software is easy with version control and tagging. This is exactly what we do with Embraco Core. So if you use Git or Mercurial, but you probably use Git, when you release a version, tag it. And then you move on. If you need to go back to that version to release a patch or a security update, you can do that. You just roll back to that version and release one. It's easy. So this to me is the biggest feature and the best feature of 7.5. I know it seems small, but it will make package development way easier. So let's have a quick look at the package installation UI. Neil showed us some of this this morning, and I'll do a quick demo of this as well. So we can search for packages. Search will work. It already works better than it ever did. And we're going to enhance this before the final release as well. And then you can filter. Then we have our installed packages tab, which will list your currently installed packages. This is all in one spot. It doesn't have a tree of a whole bunch of different random things. You can drag and drop to upload. You can select one. And then accept terms. You see there's no giant red banners and stuff like that. You can just go. So health check, other thing that we showed this morning. Ugo Live's bigger brother. It is plug-in based. So if you want to make one, you just inherit from health check, and that's it. It's very simple. Your health check could do nothing, but if you put some logic in there, it can do anything you want. And you can also render your own little UI bits. So if you wanted to put in a text box or something that's required to fix something, you can do that as well. So here's some quick screenshots. It doesn't quite look like this because this was taken last week. But I'll do a quick demo in a sec. Here we go. My password is test test, by the way. For everything. So here's health check. When you load this up, you can see, oh, we got some more configuration. So I can click on that. Tell me what needs to be fixed. Let's try to fix this one in particular. So this is going to update a value in Embraco settings. I can go over here. And I can show you that this says false. And that's what it's complaining about. Maybe that should be true. So we'll fix it. Okay, that's cool. And now it's true. So that's a health check. It can do pretty much anything you want. So let's head on over to the packages. So there's just one icon. That's easy, right? Yeah, we need to fix up the UI here. Sorry about that. But it's popular and latest for all categories. But I can then go into each category and it'll refresh. So before it had to be exact match search, which isn't the most convenient. But I like to do that. I like to install my favorite package, which is Articulate. And you can just search for art if you want, because it's pretty arty. So I'll show you that minimum version thing. So here I can click to... Oh, yeah. I'll find this folder. CG16, there it is. So I've made a package here that targets versions, 7.6. That's not out, right? So that means if I installed this in 7.5, I mean, it won't work. So let's just see what happens. And if I scroll down... You can't do that. This is not going to work. We'll fix up the UI. This is, again, my CSS. It looks pretty good. So I'll show you how it actually works when you install something for real. There we go. That's a bit off, but that's fine. I'll accept. And then it just installs. We don't have to stay here and wait for it to install, but it does the normal thing, and it'll show the Articulate screen at the very end, and it all works. So it's great. Once that's installed, you can also go see your installed packages here. You can uninstall directly from there, too. And away you go. So all in one spot. Works really good. Super simple. Should have done this a long time ago, but it's in 7.5. And... Woo! All right. Ah. There is one thing I wanted to point out. You may have seen Articulate had a weird icon, which is not the Articulate icon. When you create a package in the back office, there's going to be a couple new fields. One's for the icon URL, which is sort of like your NuGet icon URL. And the other one is to pin it to a specific version. You can't really put the icon in the package to then be browsable on the internet. So it's just a new field. If you want to have your own custom icon, it'll just be a field for it. Okay. Back to slides. Another new feature. And again, this is one of those things we should have done a long, long time ago. Does everyone know their server time zone? No? No? Well, if you ever had to schedule published content, you would have to know your server time zone, which is slightly unfortunate. So you don't have to do that anymore. It should have worked this way all along. So if I'm in America and my server's hosted in England or something, I don't have to post date the time it's going to be scheduled. I can select my local time. And when it detects that your server time is slightly different, it'll show you this little dialogue. We're probably going to change it and change the text of that. But it shows the offset, just to make it clear that this is an offset time, not the server time, so you're not confused. So I guess technically this is a breaking change. But it's mostly a change that you can tell your editors. You don't have to worry about the unbreaking thing that you had to tell them before. So it's better for everyone. There's also an offset time. Sorry, I keep pointing down there. Offset time pre-value. So that means that you can use this functionality for normal date time pickers. And to make it not a breaking change, that's false by default. So it works like it always used to. So forgot password. We already thanked Andy for that. It works super well. It can be turned off if you don't want it, since some people might just want it to not be there. It uses ASP.NET identity, which uses single use token. And you can configure these. Like everything else in ASP.NET identity, you can configure all that stuff on startup via code. Another thing in 7.5 is better memory handling. And this might seem really boring, but it's super, super important. We tested a site with like 150,000 nodes. And on every publish, we would get out-of-memory exceptions, which isn't very nice. So we started having a look through. And I mean, this XML content thing is super old. So it might not be doing the best thing that it could ever have done. So we fixed a lot of that up in 7.5. Before, every time you published, it would allocate a zillion XML fragments that it didn't need to do, almost one per document every time you published. It would also double load that whole XML document into memory. So it would serialize it to bytes. And then it would serialize it to another XML document. I mean, that's super expensive. The site we were testing had like a 70 meg XML document. When you load that into a real XML document in memory, it's already probably like 300 meg. So just by publishing, you're using a gig of memory for one user for one publish. Not cool. So we fixed that, which is great. Reindexing of published content also did a very similar thing. So we've also fixed that too. So if you reindex and you have tons of content, it's just going to, it doesn't need to allocate everything. It just does what it probably should have done the whole time. And this one, I'm going to talk a bit more in depth about. We discovered that every time you fetch an entity from the database and then turn it into a real entity, we are allocating tons of memory bits. And it was actually quite easy to turn that off. And what we did is we did some benchmarking. So this is what happens when you fetch an entity. Before, you would just create the entity, populate the entity from the database, and return it. But by default, that entity has something called change tracking on it, which uses dictionaries and strings and values. So now we get the entity, we disable change tracking, re-enable change tracking, turn off the dictionary allocation by default. And all of this change has actually made the code shrink. And it's much more readable. So that's really great. So I'll show you what the effects of that is. There's a lot of crazy numbers on here. So we went three iterations. The original way, the original way with these better selectors, which made the code look nicer. And then the efficient way, which was turning off change tracking when we populated the element. And you can see on the right-hand side, this is just one iteration of one entity as a test. You don't have to worry about the actual numbers, but it made it 23% faster. And it used 50% less memory. Now, keep this in mind. When you talk about an entity, we're talking about iContent, let's say. iContent references iContent type, which references a dozen different iProperty types, which references a bunch of property groups, which then otherwise references a template, and then properties. Each one of those items, it did this for. So one content item was allocating a whole bunch of stuff. Now it doesn't do that at all. So 7.5 should be way better with memory. A lot of people have talked about how the grid is not indexable or you have to do some very special things. So by default in 7.5, we haven't made it the prettiest way, but it works quite well. Grid data is indexed by default into different fields. So I'll show you. You can clap. I'll show you how it's indexed to give you a better understanding. So this is a screenshot of this awesome tool called Luke. You can see grid on the top one is highlighted, and grid is the property type name I made it. I know that's probably very confusing. But grid is now storing all those values that were extractable and searchable. But we also store a field called grid.article, which is every article item of your grid, storing those specific values, and then grid.headline. So you can see any time you create one of those items, it's going to store specific values. So you can search on the whole grid, or you can search on the parts of the grid, and it just works like that, which is super good. So in v7.x, we'll talk about how we can make that even better. This might be a long segment. When we were at the retreat, we decided to list all the things that we really wanted to do in the core. These were known things, I guess, from last year. And it turns out that people have these amazing ideas. So we wrote them all down. So that eventually we just get them done. Yawning. So in 7.x, this is 7.6, 7.7, 8, you name it. There is actually no high number that we've said we won't make. What we want to do is streamline the way that we output minor releases. We don't want to have major minors. We want to have minor minors, so you're not scared of upgrading. It's like, oh, cool, I want this new feature. Boom, upgrade. That's what we want. We don't want breaking changes. We do allow very, very small changes. Very tiny minor breaking changes that should affect maybe half a percent of people. And we think that's okay. But we'll blog about it and let you know. But we want to make sure that you can go from 7.4, 7.3 to 7.9 if you want to. No problem. So in no particular order, these are the things that we're going to talk about. Blue stands for community-driven features. And these are actually in italic is already in progress. So nested repeated content, Neil's mentioned, is going to go in the core in 7.6. Already started. It's almost done. There's some cool tweaks that we're doing to it. Something called schema types. But if I talk about that, we'll be here all night. Isearchable tree is something we've been working on with the community with Darren. Darren Ferguson. Where are you? There he is. Whoo. And this is to abstract away back off. Which is something that we've been thinking about for a long time. But this is just a really kind of simple way to say what does the user type in? I'm going to grab that and send it off to my own search engine. So that's already started. I would say probably can make it into 7.6. Easier JSON data indexing. So this is what I was talking about with the grid data indexing. We're going to make it more generic so that your property type or sorry, property editors can just take advantage of it. And then we'll loosen what it should index. So that's been started. Lars, Eric, where are you? There he is. Whoo. Awesome. That will probably make it into 7.6. Package migrations. I talked about this at the UK Fest. This is my most favorite thing. This has already begun. It's actually almost done. Morten has been kind of going with it and modifying it to make it work. So let me explain this. We have NuGet and then we have Umbraco packages. We want to make them the same thing so that you can install Umbraco packages in Visual Studio. And then when your site starts up, it will run package migrations for you, which means it will install all that data that you want. And it will do it all seamlessly. And it will use the same migrations code that we have in the core today. So that means that you could create some baselines. You could have packages that install data, packages that install other packages, et cetera, et cetera. You could make a NuGet package, which is actually an Umbraco package, install it in Visual Studio. It would install all your other cool packages that you want, maybe some stub template data. And then your site is up and running and it's exactly the way that you wanted it. So whenever you say, new, I'll restore this package, and now you have a full site running. So that is super exciting and I can't wait to get that in. Next up, property value converters. This is by Jeven. Thanks, Jeven. There he is. That makes querying content in your Razor views much nicer and it's all strongly typed. So looking at 7.6, we just have to make sure we don't break anything for that. New template editor started with Pear at the retreat and it was helped out by a bunch of people, Jeven and Lars-Erik as well. That old template editor uses CodeMirror and we're going to replace it with something called Ace Editor, but it's way nicer. And that'll be all those templates that we edit. So JavaScript, HTML, the Razor files, all that stuff will be brand new and angularized, which is great. So 7.6 probably as well. So I already talked about the NuGet package format that kind of goes hand in hand with the package migrations. So we could have a native Umbraco NuGet style package and we would be able to support both the current way and the NuGet way. System diagnostics is a package. We have a package from Warren Buckley. He made it a long time ago, but we're going to hopefully integrate a lot of that stuff in the core. And that'll just give you a tree to sort of analyze everything that's in your Umbraco install. Document unlock and lock, we had that in Concierge. User group permissions, I know you guys have been talking about this for years, but let's get that in there. Just need a bit of help. Shouldn't be too hard. Well, no, it will be. But it would be really great. And the list continues. How many awesome features can we put into 7.x? I think tons. Save searches is a Niels idea. Hasn't started yet. But you could save your sort of Lucene searches to then just be reused in your Razor views. Tabs in the text editor. So that goes hand in hand with the new template editor. Online property editor search. So when you search for text box, when you're creating a new property type, or not text box, Google Maps. Obviously that doesn't exist in core right now. You could actually go to our and say, I know that there's this Google Maps one that you can install right then and there. That would be pretty handy. UURN. Name. I need a name for this. We'll talk about this in a sec. View as dashboard. So we have dashboard permissions. You can assign different permissions for different user types. But it would be cool as an administrator to say, I want to know what this dashboard looks like as an editor. Content sets. Let's say you wanted to have 12 specific content. Specific documents published at a certain time or a certain day where you click one button. Instead of having to go through all 12. So you could group content. Which would be really good as well. And I've made up this word. Compositional property type sorting. Do you guys know what that means? Someone knows. Anyway, you know how you make compositions of a property or a content type but you can't sort the property types on it? Let's make that happen. Yes. All right. UURN. What? What the hell is this? V5 days. Anyone remember? Hive IDs? We're bringing them back. But we need a new name. And a year in ID is not very good either. We just made up the name. Umbraco Universal Resource Name. We need a name for it. But this is what it could look like. And this is the reason why it's important. Right now we have local links that we put into rich text editors. Right now we save IDs into pre values. Right now we save IDs into all sorts of things. But you cannot distinguish an integer ID from anything. An editor could type in an integer ID. And this makes Umbraco deploy or any deployment work much nicer. Because then we can analyze every field. The reject statement that can only match that. And that's very specific. Your editors are probably not going to be typing something like this. So we know exactly what that is and what dependency it is. So we can start saving IDs in all these fields with year in IDs. Think of a name. What's your name? Package migrations. Okay. I already talked about that. I'll skip through. I got ahead of myself. If you want to check out the branch, it's in the core. It's right there. It works pretty good already. So if you want to have a play with it, you can. Umbraco deploy. I talked about this in the UK Fest as well. This is a rebuild of what Courier is. It will have better APIs. It will be fully testable. Fully tested and integrated right in the core. So a few questions I've had today is can we use the UAS engine in our own site? So we can commit content or content types to get and restore them. We kind of can today with Courier. I mean Courier is the backbone of UAS. So we just have some special code in there that does the committing and extracting. But it just tells Courier to do it. But we want to make that easier for you and we want to have a fully tested project. So this is called umbraco deploy. Currently Courier uses nhibernate, which is kind of weird because we already have Petapoco doing that. We're doing our database stuff. So it's like another database tier. It's kind of hard to maintain. Courier also contains a lot of legacy code that we want to get rid of. It doesn't actively reference umbraco core to use all the stuff that we already have in there. So we want to use umbraco core for what it's good for. And every time we release any sort of update for the core, we have to make sure that Courier works. There might be a sticker at Bingo that says, what about Courier? And now you know why. If you want to make a change, you've got to ask that question. So how are we going to do this? We built from the ground up. Test driven development. We're going to use IOC for its parts. We'll solve these current limitations with GUIDs. We have this concept of send versus sync and content versus infrastructure, which Courier handles right now. But it could be handled in a very more streamlined way. The coolest part about this, and it's like development's already started on this. I don't have a timeframe for when this will be done. But know that development is actively being done. For this type of thing. But the cool part is all the heavy lifting will be done by umbraco core, not by umbraco deploy. Umbrago deploy will be sort of the shell that makes the migrations work in umbraco deploy. Sorry. Umbrago core. So you'll have access to all those APIs to make it do whatever you want. Okay. Everyone still with me? It's only been half an hour. I've got 15 minutes to wrap up. That's going to be a stretch. I'll go quick. V8. Content. Variants. Segmentation. New cache. Mega code cleanup. Latest libs. GUID all the things. Examine V2. We'll talk about each one very quickly. But it's worth noting V8 is the version I've been dreaming of. And in fact, this document has actually been in our documentation for many, many years. It is the goal. And the goal is to only ship with those assemblies or have those assemblies in the umbraco core. You can go look it up. It's been there forever. V8 is about achieving this goal. So we talked about this before. Lines of code reduced 24%. Number of files reduced 33%. This is already, by the way. There's plenty more to go. 48% less files in the output web application. We've reduced the NuGet package size by 31%. And rebuild time is 9% faster. Eventually we'll have 62% less assemblies being shipped. That is amazing. So once we get there, the goal will be reached. I'll be super happy. The dream will be achieved. And then I'll have to make a new one. So examine V2. This has been in production for years and years and years. A colleague of mine, Niels Kuhnel, who's gone to the dark side. That company. But he really helped with examine V2. So it's running on the latest Lucene, which is 3. But 4 is in beta. So it might be upgraded to use 4. It's not based on all this crazy XML structure that examines based on. Because it was strongly tied to umbraco. This is now based on real models. It's super easy to use. We have a better fluent API that supports all those things that you couldn't do before. So you end up writing Lucene queries. It's got facets out of the box and super fast facets. And it's configless by default. So generally when you start up, you will just create an index on startup instead of using config. It's got dependency injection all throughout it. We use a container called LightInject. You can modify this container. You can use this container. It will be the default for Web API and MVC. So you can just get dependency injection right out of the box. But if you don't like it, you can replace it. That's fine. We won't hold you accountable. Totally easy to do. But we will still continue to use that container for our own stuff. You can't replace that internally. But that shouldn't mean anything to you guys. More effective memory usage again. Remember when I talked about the memory efficiency we had before? Well, this gets even better. Because right now we have objects tied to objects tied to objects. We're going to get rid of that. So it's just objects tied to integers. So the icon template doesn't actually hold a reference to the template. That's already in memory somewhere else. It just holds a reference to the ID. So it should be much less memory being used. We talked about New Cache or Le Cache Nouveau. So if you don't like that XML file, we can get rid of it. It's an abstraction. So you can replace it if you want. But what you have to remember is XML at the time was an amazing idea when it came out. It worked very well for Embrago. No other CMS at the time, and maybe even now, holds everything in memory. I know that sounds kind of crazy, but it works really well and it's super fast. And I think a lot of people are going towards a full in-memory approach to a lot of things. So we're not getting rid of that aspect, but we're taking with us all of the cool parts that we had with XML. The other part of XML is it's super heavy, and it just will not work for variants, which we'll get to in a sec. Stefan will show us, I think, some demos tomorrow. Maybe? Yeah, maybe. But preview, we got some of this cool live preview thing. Preview actually works with New Cache, and it works very seamlessly. It's really awesome. So come see us tomorrow. We're doing a session. So nPoco. Apparently that's a picture of what a real database looks like according to Google Images. So we have Petapoco now. We're moving to nPoco. We've already moved to nPoco, actually. If you check out the VA branch and run it, it's running nPoco. Which is a version of Petapoco that's been in production for about three years. They've done a lot of things with it because Petapoco kind of just went off the radar. It's got better memory usage. We have extensibility points that we can plug into it. And the cool part is it already supports ASP.NET Core. So we can just use it. We don't have to do anything about it. It'll just work. We're going to put the latest libraries in there. Whatever the new 4.x, I think 3 is coming out soon. Automapper. The new signed version. I don't know if anyone's had troubles with the unsigned version before. But it'll be all the latest ones. The real log4net version. I'm sure people have had issues with the one that we ship with. The newest JSON.NET. They come out with a new version every day. Mini Profiler. The latest version which we can upgrade to because it's got breaking changes. Newest Lucene. Whatever the Angular 1.x will be. It will not be 2. If we went to 2, we could. But all those property editors. That you guys have made. Won't work. So I think it's in our best interest we stick to 1.x for now. And the latest jQuery. So segmentation. Let's talk about that quick. This is the coolest photo I could find for segments. I'm not going to go through the whole demo that Neil showed before. But what is segmentation? It's essentially tagging the request when it comes in with some metadata. It could be anything. So you set up a provider. You tag the request with whatever it is. You can use it in your views if you want. And then I'll talk about how you can use it with variants. But in your views you can say is this a job referral or is it a small screen. And then you can render things accordingly. So as I said you can create your own. We haven't defined the provider yet. We did a few years ago. But that will probably change. But it will be a plug-in like everything else. Cool and embargo. Also an awesome photo. How do you explain variants? But that's the one I came up with. So what is a variant? A variant is a variant. It's a one-to-one language mapping. But it can be more than that. So it's virtual nodes based on a language and or segment. So I can have English and Danish. I can have Danish and mobile. I can have Danish and small screen. I can have Danish and I don't know, X-Patch or something. You can mix and match these all you'd like. And it's sort of up to you to define the sort order. Because a lot of things in the request can match at the same time. And then you'll take the best outcome. So it's supported in new cache. XML does not support this. Because these are no longer children. We have children and then we have like a third dimension of cache. So we don't have a name for that yet. We'll come up with one. But it's only supported in new cache. And then we can have a language fallback support. So if you don't fill in a field for English. Or sorry, for Danish and your primary language is English. You'll just fall back to the English one. And that's really handy. Because if you have a banner image. Or something like that. You don't want to replace that for every single language. You just want to have one. Okay. I think we're good for time almost. ASP.NET Core. We could call it V9. I'm not sure. There's no guarantees there. But as I said this morning. The most important thing to realize is that V8 is the stepping stone for V9. We cannot make V9 without having V8 done. And achieving that goal. To remove all of that old legacy code. Would definitely not be compatible with V9. Including getting rid of every ounce of web forms that there is. Because ASP.NET Core doesn't know what web forms is. I have a branch of this. So I've been keeping a fork up to date. It's running on ASP.NET Core RC3. Because RC2 wasn't even good enough to port all this code over. All the critical parts of EMBRACO Core are ported. So the whole database layer. The application context. The service context. All those things. It should install. If you can get it working in a console app. And I really wanted to show you a demo of that today. But I didn't have time. Because I had to make these damn slides. So. Sorry. The other part about EMBRACO.web. We've ported a lot of that over. But there's a lot more to go. So converting all the controllers. But there's a lot of progress that's been made there. This is done in my spare time. And if you guys want to help. That's the fork. I'll do a quick. Well it's not a demo. But I'll just show you what the project looks like. And it's also worth noting. When the next ASP.NET Core versions come out. So RTM. They already have an RC5 thing out. Or whatever 1.1 is going to be. The more they release. The easier it is to port. Because the more APIs that we don't have to backport exist. All right. So let's have a quick look. This might not be that exciting. I'm not sure. So here is the solution. It's worth noting. This is a merged solution from the version 8 branch into this branch. We haven't rebuilt anything. This is a port. So you can see the way that I've gone about doing this. Is sort of painstaking. But I've removed the build of all these other things. That I don't want to test yet. Including the tests. So I've only enabled Embraco Core. And with ASP.NET Core. Now it uses a Project JSON. Which is apparently going to go away. So we did all this work for nothing. But that's Microsoft for you. And this is super ugly. But this is how I've gone about doing it. So you can see exclude. So I've excluded all these things that I don't want building. And then I have included every individual file that I want building. One at a time. Until it builds. Over and over again. Super, super annoying. I couldn't find a better way. But it seemed to work. It just took me a while. But we made a lot of headway. And now this whole project. At least all the parts that I want built. I tried to make a console app. It didn't work. So anyway. That's the demo. If you ever check it out. And wonder why that file is so big. That's why. Okay. One last thing. It's perfect timing. It's amazing. In Embraco Core. Or Embraco right now. In the CMS. We have like seven ways to do the same thing. I'm sure you guys have all learned all these different crazy ways. Over the years. They kept getting updated and changed. And you're like. Well which one should I use? And as the HQ or anyone were like. I don't know. Use the latest thing. And as teachers go out to train. You should use this. And they're like. But you told me about this one last year. Yeah. But don't use that one. Use the cool new one. So. As a show of hands. I'd like to know. Does everyone think that we should have a streamlined way of working with content in our views? Yes. That's the answer I'm looking for. Because in V8. We're dropping support for XSLT and Dynamics. Boom. Boom. Okay. So. My slides are there. I made like a nice bitly one. I'm future core on bitly. You can get the slides. And I'd like to take any questions that don't have to do with XSLT or Dynamics. Anyone? Anyone? Yes. Hang on. The microphone is coming. You talked about the package migrations and the versioning in there. Yep. What about upgrading Umbraco? Would that be looking at the package versions in any way? Well, Umbraco is not going to depend on your packages. So you'll depend on Umbraco. So, yeah. It'll just work fine. As long as your packages don't depend on a weird version of Umbraco that you're trying to install. If it's not backwards compatible. If the installed package is not going to run on a new version. For instance, I'm using some kind of obsolete API in the package or something like that. Then upgrading Umbraco might break the package in there. Well, I mean, in theory it shouldn't. You'll have to just know if there's breaking changes in that package that aren't compatible with it. It's the same thing that goes right now for ASP.NET. If ASP.NET 4.6.3 comes out and they say this XYZ is not compatible anymore. You'll still be able to install your package on it. Because your package targets 4.6.0. That's more of a user case. There's no way that we could predict the future to tell your package to not support that. If that makes sense. In theory, we're not going to have breaking changes. There will be breaking changes if you do crazy reflection or something like that. But we'll always publish our breaking changes to make it very clear. And if there's an important one. But it should work like all your NuGet packages. There's nothing stopping a NuGet package from coming out that breaks another thing that relies on it. It's the same principle, I guess. But we will do our best to not have breaking changes. This minimum package version targeting as well is only for a current minor version. So you can pin it to 7.5. But if you tried to install it on 8, it'll just say, well, you can't. Because that's a major version. So that's how we've gone about this currently. Hopefully that answers your question. Anyone else? I got any questions about it? Oh, good. What is the status on code first document types? Not going to happen via the core. We don't see a need. So code first was invented for many reasons. It's kind of just not going to work so well. Because we made this new document type editor, which is super fast. It's much more efficient at creating your document types that way than writing code. And if we make Embraco deploy the way we want it, you'll be able to just deploy those changes between anything anyway. So you shouldn't really need code first, is sort of our opinion. If I can serialize a document type to disk, and then you can deserialize it, that's sort of a code first approach. I mean, you can transfer those between environments. If that's what you're using code first for, which I assume most people do. So with deploy, it will be version controlled anyway? It could do. Everything? It's up to you. We will provide the means to do that, so we can serialize those things to disk. And if you want to version control them, and then pull them out, the core APIs will be there for you to do that. Yes, thank you. I just have two more questions. Okay. Do you have any plans to have like an official IRC or Slack channel for Embraco? Official? IRC or Slack channel? I think there's a community one. There's no official one. There's an official community Slack channel. Sebastian knows what the address is. If you come ask me after, I can get it for you. But there is a community Slack channel where a lot of you folks are active in. Okay, great. Cool. So last question. Which one of you is Klaus? We're close. Where is he? I can't see anything. Oh, there he is. Right at the back. Yeah, he's waving his hand. Thank you. Cool. All right. That's it. Thanks. Bye. Bye. Bye. Bye. Bye.