With Christmas coming closer and closer, I thought it would be fun to go over my wishes for the Umbraco CMS. I've currently worked around 4 years with the system and I've had my fair share of annoyances with the CMS, but also like working with it very much. I just think that, with these features, Umbraco becomes even better to work with!
Now I know that these features would take a lot more time and never be finished for Christmas. But I can always wish, right?
I also asked people on Twitter what they would like to see in Umbraco. The response was amazing! There are so many different things that people would want. You can find the tweet here: twitter.com/PatrickMooi9/status/14703296919... The following features are all my own opinion. Let me know in the comments what sort of features you would want from Umbraco.
So, let's get started with the first feature!
Better Language Support - Default language
I have to admit that I am starting out with a very big one here! But I think this is easily the most important one on the list. In Umbraco 8, we got support for multi-language websites. We did have the possibility to do it before Umbraco 8 with the Vorto property editor, but that wasn't always the best way and user-friendly way to go about it. Luckily Umbraco 8 makes this a lot easier now!
However, this system also comes with some restrictions that are very annoying for some use cases.
Let's consider the following situation:
We have two languages (en-GB & nl-NL). We have selected en-GB as our default language in Umbraco because we need to have a default language. We've created our blog document type as "varied by culture" along with some of our properties. However, we didn't want to make the property "Publish date" "varied by culture" because that wasn't needed.
After setting that all up there is no issue at all creating a new blog post in the language en-GB. That all works fine and we can even create an nl-NL variant of this after that! The perfect system you would say, right? Well, what if you want a blog post that only exists in nl-NL? You are able to do so, but it is not ideal... Because remember that "Publish date" property that wasn't varied by culture? We are not able to set that one without a version in en-GB!
So unless you make every property varied by culture, there must almost always be a page with the default language. Otherwise, you won't be able to edit the values that are not varied by culture.
Solution?
I think it would also be good to come up with a solution for this issue even if it doesn't end up being the solution that we get. I think there shouldn't be an "Inherited from English" property when your property isn't "varied by culture". I think it would be better to have a shared property between all languages then. Changing it on nl-NL would also change it for en-GB and all other languages.
The main issue I see with this approach is that it might be confusing for the user. But it is already a lot better than the "inherited from ..." functionality.
Better Language Support - Mandatory Language
Oh, you thought we were done with the language system? Oh no no no, there are more things to improve here. Currently, you are able to set a mandatory language for your website. So let's say that you always want there to be an English variant of each page, then you can set English as your mandatory language.
However, what if we have a multi-root system like this?
This is something that we have for quite some projects. You have multiple root nodes for each domain that you have. This can be because of different data like products or for another reason. Well, remember that mandatory language? That is set for all pages on your website! So this means that every page under the three homepages needs an English page. But what if I want the default language for each homepage to be as follows?
- English for the United Kingdom homepage
- Dutch for The Netherlands homepage
- French for the French homepage
Well, that isn't possible. You better also have an English variant or you are in trouble! So how would we solve this issue?
Solution?
I think this one could be quite easy. Or maybe there is a lot more to it. We can still keep the mandatory language as a website-wide setting. Maybe someone, somewhere actually needs it. But also let us set the default language/mandatory language for each node. Every node under that will then use the default language/mandatory language of their ascendants. Problem solved while still keeping the old functionality unchanged! Does that grant me bonus points?
(Thanks to my colleague Jeffrey for making a mockup! You can find his issue here: github.com/umbraco/Umbraco-CMS/issues/7037)
More permissions for groups/users
We have quite some permissions that are able to be set up for each user/group. You can select what sort of nodes that they have access to, whether they are able to edit them, and much more. But I think there should be even more permissions.
I came to this conclusion when adding a new custom dashboard. The dashboard allows you to set rules for different groups. So you can deny everyone in the group "translation" to access the dashboard or only allow them permission to the dashboard. Now, this is all fine, but why are developers choosing those settings? Why can't the content manager of the website say: "Group X will be able to see dashboard A & B, while group Y will only have access to dashboard B".
I feel like the developer shouldn't have to set the permissions for a user. After all, each project is probably going to be different. If I don't agree with the permissions that the developer has configured, then I have no easy way of changing them. And I feel like this should also be extended to content apps & tree nodes. Maybe I don't want users to access this custom content app that I've added.
Solution?
I think I already touched on the solution quite clearly. I think it would be great to start with the dashboards first as they will most likely be used the most. It would also be great to have a general system in place for these sorts of permissions so that the content manager has the ability to configure the project to his teams' likings.
Data objects
This subject is something that I've struggled with a lot. And I think there is still no good solution for this. In many of my applications, we have a data folder with some data objects in it. Something like vacancies, products, tags and much more. You could also put things like settings in this category.
These objects are all document types (as you would expect in Umbraco), but if you think about it. Should they really be document types? Because why would data objects like tags or settings need an URL for on the website? And there are probably a lot of other features that are great for pages, but are completely not needed for data objects. Personally I would just want to have a data object and have it stored like that in the database. Nothing special, just a fast and simple data object.
Solution?
As I've said before, I've had this struggle before and I've multiple conversations with colleagues about this. Ideally we would store the data objects in the database, but what if the client wants an interface to edit them? We do have the package UI-O-Matic, which I think is great, but last time I used it, it was a bit buggy. Although that might already be fixed now.
The other "issue" I have with the approach used in UI-O-Matic is that it lives in its own section away from the content section. I think an content editor would want all content related things to be under the content section for easy editing. Now they are just hidden away.
So for now, we are still using normal document types for this, which I am not that big of a fan of. I think this RFC is moving it towards a better solution though. Have data objects be element types and then having them display on a separate tree. It would separate pages from data objects, making it clear for editors on what is displayed on the website and what is not displayed. As long as it is fast and simple, I am all for it.
Media Providers
I was going to stop at the fourth feature, but I watched this video by Jeffrey Schoemaker and I was also notified of this older package called "Universal Media Picker" and I basically just want this now!
Let me quickly summarize it, but the best way to do this is by watching the video by Jeffrey. He goes into this with a lot more detail and enthusiasm than I could ever do in this post. But the general idea is "What if you could link other media providers instead of only using the Umbraco one?". I currently have a project where the client is using a different media provider outside of Umbraco. We have to write an import task to copy the images to our server, so that they could be used inside the Umbraco media. But with the ability to add multiple media providers, we wouldn't have had to do that!
I think it would be great to still have the normal media picker that we are currently using, but also have something like the Universal Media Picker package. A property picker where you can select the source of the image and then select the image from that given source! Want an image from Umbraco? Just select "Umbraco Media" and select your image. Want an image from Dropbox? Just select "Dropbox", it'll show all Dropbox images and select one.
I think this would be a great feature within Umbraco. The only thing that I am not sure about is how this would work with something like crops and the other parameters that you can give to ImageSharp, but I am sure that there is a way to do that. Umbraco kind of already has that functionality with the blob storage that you can use for images.
Conclusion
And that is basically it! It was a lot of fun writing down my wishes on making Umbraco even better. There are a lot more features that I would love to have in Umbraco, but these are my favorite features to have.
I would love to hear your opinion on my wishes and let me know what your wishes are for the Umbraco CMS. And now I am just hoping that these wishes will be granted to me. Or else I can just copy-paste it to the article of next year...
Thank you for reading!