Question to Package Developers - handling duplicate aliases
This is a question to anyone who creates packages (and people using packages I guess), and it's about how Umbraco handles importing the following types:
- Macros
- Templates
- Stylesheets
(Language and DictionaryItems but the above three are the primary ones that I'm asking about)
Current when you do the import Umbraco will undiscriminately create a new entry in the DB. This can cause a problem if the alias (or Name in the case of the Stylesheet) alread exists. We came across this problem when trying to deploy template & macro updates. Because Umbraco expects the alias to be unique it can freak out when duplicates are found.
I'm currently looking at fixing this, so that it checks if the alias already exists, and if it does it wont create a new version it'll mearly update it.
The main reason I'm wanting to implement this is because we're wanting to us the Umbraco packaging system for rolling out updates to Umbraco sites, and since those updates may include templates that already exist (but which a changed parent) or a macro who had different properties. Currently this can't be achieved, you end up with duplicates that you still have to clean out.
Question to package developers
Would you be comfortable in the knowledge that your package will overrite not create when an existing item with that alias is located?
Question to package users
Would you be comfrotable in the knowledge that installing a package could replace an existing item if there is a naming conflict?
I've implemented the change in the 4.1 source currently and it works as I stated above, when duplicates are located they are overwritten, but I wont be checking the change in unless this is something that the people it will impact the most are happy with it.
The only other thought I have on how to handle this is having a new option on the package creation screen to ask if you want your package to deploy in "overwrite" mode, and have the deployment mode conveyed to the user when they install the package.
As a package developer (puts hat on) -> Yes, I'd like to have it override the existing items, as most of the times, I'd be building updates to my own stuff!
(putting other hat on) As a package user -> No, as I'm not sure what it will do to the existing system.
If we could alert the user what will be replaced, and let user decide what can/cannot be overwritten, that would be great. Keeps the end user in control of all actions.
Be aware though that package actions will also need this logic and AFAIK, it's not yet possible to plug in some interface to ask for permission to overwrite existing stuff.
Hey Arron the amount of times I had the YSOD when creating CWS on install due to duplicate alias's was too many. Eventually I came up with very specific aliases for everything in order to avoid confllict with other peoples content/data etc...
Another problem I had was that if the install partially installed for whatever reason and then a user came back to reinstall it, it would fail as some of the items would already exist.
My suggestion is to have the normal install and if it detects the items already exist, present a screen telling the user what items already exist (maybe group list into type of items) and asking if they want to overwrite these items. If they hit No/Cancel it aborts the entire install.
Or another option is that the list of items that already exist could be a checkbox list and the user could decide which items they would want to overwrite, either by selecting one, all or none.
For DLL's it would be great if you could display some version information.
Package developers should include information telling their users that overwrites are fine in their install/upgrade docs.
Package developers should also bear some responsibility for making sure that their Macro/Template/DLL/whatever names are *very* unlikely to conflict with other peoples.
Finally, while we are on the subject. If you install the same package more than once, it appears multiple times in the installed packages section of the tree. Could we do something to check version numbers, so only one instance appears in the tree....
Oh, and can the submit to package repository section be removed from the tree assuming that it is replaced by submissions to our.umbraco.
Right now it is quite impossible to make an updated version of a package.
I think it would be nice when a user installs a package, to check if that package allready was installed. If it is, then overwriting existing items should not be a problem (I take it that developers do not change the names during updates of their packages)
If it is not installed, there might be a problem. In that case, a warning could be shown to the user (just like the one about the dll's)
I agree with everyone's points and the overall concesus... alert the user and let the user decide.
I would add that you can make update-specific packages but it is a lot of work over and above the 'fresh install' package... and that becomes another reason that people don't bother with them. Whatever can be done to simplify is extremely helpful. One package should ideally be able to be installed once, re-installed if installation failed for some reason, upgraded from a prior version of the package... giving feedback based on the situation for the user to overwrite or create a second name for each item (with the warning that the package is unlikely to run properly, but at least the files and macros are installed).
So it's looking like the way people think it would best work is to imform the user of any conflicts and let them choose how to handle it, either continue on or back out.
I'll see about getting that done as way it'll work
Great work Aaron. Just a suggestion maybe display the name of those templates, macros etc as well as the aliases. As when you showed the Macro tree obviously the name is different to the alias I set and for enw users to Umbraco that could be confusing.
I personally would still like to see (if it is possible) to have a checkbox list next to those items, allowing the end user to decide what items they want to install.
Don't think checkboxes are a good idea. installation should be all or none, otherwise you could end up with a partially installed package, which IMHO is much worse than a all or nothing situation.
But surely letting the user decide what they want is upto them.
What if for example I worked with CWS2, and customised some of the templates. One of the templates works perfectly fine with my customisation but I managed to screw up another template and cant figure to fix it. I could re-install and only select to install that template.
I think if we gave users checkboxes, it would be the users responsibility if they decided to install only parts of a package, but if worst comes to worse the user could come back and re-install the lot!
If i am the miniority when it comes to checkbox options then thats fine :)
I agree with Warren. I also would like to have checkboxes so it's up to the user if they just want to overwrite files. I would also like to update an existing package. Currently when a package has the same name and the same version the package is displayed twice in the Installed packages folder. The new version of the package overwrites the files of the previous version so wouldn't it be logic if the entire package is overwritten (upgraded) and only the new version is displayed in the Installed packages folder?
I agree with Warren that it would be nice to have a way of selecting only some of the items, rather than the 'all or nothing' approach you've got now. But that's what *I* would like, and I'm not a typical user. Also, package developers have different needs from those installing a few packages on a site. Thus, I'd recommend the approach you've got now and, maybe in time, it will be worth trying to add more features/options. For now, though, it seems a nice solution to the most common issue.
Thanks for your work on this, and for being so open to suggestions and feedback from the community!
@Warren, @Jeroen & @Doug: I understand your reasoning behind the ability to select what you want to install from the package but I must disagree with implementing it. By having opt-out you have the possibility of a package being installed in an unexpected manner. There are a few things you need to consider with having pieces left out:
- Package actions: What if an action expected a certain Macro or Template? Then you need to have the installer with some smarts about the actions that are to be executed. I believe that the CWS installer does have an expectation on a certain Stylesheet which it adds to the WYSIWYG editor (I wrote the SQL, I presume it's still there).
- Upgrading assemblies: Say a user opts-out of a .NET macro, but the DLL with the functionality is still included (because other macros require it). All of a sudden you've got the possibility of code for the macro the dev opted out of still being deployed, as it was all in the 1 DLL.
- Long upgrade paths not being remembered: v1 is fully installed, v1.1 a template is opted out as it was changed, v1.2 is installed by someone unaware that the v1.1 template wasn't upgraded due to customization so it gets upgraded and the site breaks. If you have to change the name of your custom one then you wouldn't have run into that problem.
Also, if your package is large enough that people may only want parts of it then maybe you should break it into a few packages.
Just a few problems I can see with opt-out upgrades, what's your thoughts?
Oh, and Doug, considering some of the problems which have come from the past of things changing without community discussion I thought it'd be best to ask the people who use the feature the most. I'm not a package dev, I just have a need to do this in a particular way now. Best not to change it how I see fit and expect it to be fine with everyone else.
I guess the question is... would Aaron's approach be unreasonable for users, or is there a reason not to do at least as much as he's recommended? Personally, I don't see a problem with his approach and think it would be a big step in the right direction. Perhaps not the last step, but a wonderful first step. How about the rest of you?
Yes I agree with how complex it could get with giving the user the option to choose what they want and on that basis I think this is a great idea Aaron.
Question to Package Developers - handling duplicate aliases
This is a question to anyone who creates packages (and people using packages I guess), and it's about how Umbraco handles importing the following types:
- Macros
- Templates
- Stylesheets
(Language and DictionaryItems but the above three are the primary ones that I'm asking about)
Current when you do the import Umbraco will undiscriminately create a new entry in the DB. This can cause a problem if the alias (or Name in the case of the Stylesheet) alread exists. We came across this problem when trying to deploy template & macro updates. Because Umbraco expects the alias to be unique it can freak out when duplicates are found.
I'm currently looking at fixing this, so that it checks if the alias already exists, and if it does it wont create a new version it'll mearly update it.
The main reason I'm wanting to implement this is because we're wanting to us the Umbraco packaging system for rolling out updates to Umbraco sites, and since those updates may include templates that already exist (but which a changed parent) or a macro who had different properties. Currently this can't be achieved, you end up with duplicates that you still have to clean out.
Question to package developers
Would you be comfortable in the knowledge that your package will overrite not create when an existing item with that alias is located?
Question to package users
Would you be comfrotable in the knowledge that installing a package could replace an existing item if there is a naming conflict?
I've implemented the change in the 4.1 source currently and it works as I stated above, when duplicates are located they are overwritten, but I wont be checking the change in unless this is something that the people it will impact the most are happy with it.
The only other thought I have on how to handle this is having a new option on the package creation screen to ask if you want your package to deploy in "overwrite" mode, and have the deployment mode conveyed to the user when they install the package.
So please give me your responses :)
Comment author was deleted
Hey Aaron,
For me, it would be great if you get some info on the conflicts before you hit the 'Install Package' button.
Like the 'binary files in the package' message.
As a package developer (puts hat on) -> Yes, I'd like to have it override the existing items, as most of the times, I'd be building updates to my own stuff!
(putting other hat on) As a package user -> No, as I'm not sure what it will do to the existing system.
If we could alert the user what will be replaced, and let user decide what can/cannot be overwritten, that would be great. Keeps the end user in control of all actions.
Be aware though that package actions will also need this logic and AFAIK, it's not yet possible to plug in some interface to ask for permission to overwrite existing stuff.
Cheers,
Dirk
Hey Arron the amount of times I had the YSOD when creating CWS on install due to duplicate alias's was too many.
Eventually I came up with very specific aliases for everything in order to avoid confllict with other peoples content/data etc...
Another problem I had was that if the install partially installed for whatever reason and then a user came back to reinstall it, it would fail as some of the items would already exist.
My suggestion is to have the normal install and if it detects the items already exist, present a screen telling the user what items already exist (maybe group list into type of items) and asking if they want to overwrite these items. If they hit No/Cancel it aborts the entire install.
Or another option is that the list of items that already exist could be a checkbox list and the user could decide which items they would want to overwrite, either by selecting one, all or none.
Thoughts on this guys?
+1 for confirming overwrites.
For DLL's it would be great if you could display some version information.
Package developers should include information telling their users that overwrites are fine in their install/upgrade docs.
Package developers should also bear some responsibility for making sure that their Macro/Template/DLL/whatever names are *very* unlikely to conflict with other peoples.
Finally, while we are on the subject. If you install the same package more than once, it appears multiple times in the installed packages section of the tree. Could we do something to check version numbers, so only one instance appears in the tree....
Oh, and can the submit to package repository section be removed from the tree assuming that it is replaced by submissions to our.umbraco.
Thinking as developer:
Right now it is quite impossible to make an updated version of a package.
I think it would be nice when a user installs a package, to check if that package allready was installed. If it is, then overwriting existing items should not be a problem (I take it that developers do not change the names during updates of their packages)
If it is not installed, there might be a problem. In that case, a warning could be shown to the user (just like the one about the dll's)
+1 what Peter said.
I agree with everyone's points and the overall concesus... alert the user and let the user decide.
I would add that you can make update-specific packages but it is a lot of work over and above the 'fresh install' package... and that becomes another reason that people don't bother with them. Whatever can be done to simplify is extremely helpful. One package should ideally be able to be installed once, re-installed if installation failed for some reason, upgraded from a prior version of the package... giving feedback based on the situation for the user to overwrite or create a second name for each item (with the warning that the package is unlikely to run properly, but at least the files and macros are installed).
cheers,
doug.
So it's looking like the way people think it would best work is to imform the user of any conflicts and let them choose how to handle it, either continue on or back out.
I'll see about getting that done as way it'll work
Here is how I have it working at the moment. I've done a change to have the warning panels auto-collapsed as it becomes really huge otherwise.
Hopefully it's what people want, I've done this demo with CWS2 as it's the most complex package I've come across.
http://screencast.com/t/JjHCY9YczdE
Great work Aaron. Just a suggestion maybe display the name of those templates, macros etc as well as the aliases. As when you showed the Macro tree obviously the name is different to the alias I set and for enw users to Umbraco that could be confusing.
I personally would still like to see (if it is possible) to have a checkbox list next to those items, allowing the end user to decide what items they want to install.
Even if this rolls out, its great work.
Don't think checkboxes are a good idea. installation should be all or none, otherwise you could end up with a partially installed package, which IMHO is much worse than a all or nothing situation.
/Dirk
But surely letting the user decide what they want is upto them.
What if for example I worked with CWS2, and customised some of the templates. One of the templates works perfectly fine with my customisation but I managed to screw up another template and cant figure to fix it. I could re-install and only select to install that template.
I think if we gave users checkboxes, it would be the users responsibility if they decided to install only parts of a package, but if worst comes to worse the user could come back and re-install the lot!
If i am the miniority when it comes to checkbox options then thats fine :)
Comment author was deleted
Looks great Aaron, I like it !
I agree with Warren. I also would like to have checkboxes so it's up to the user if they just want to overwrite files. I would also like to update an existing package. Currently when a package has the same name and the same version the package is displayed twice in the Installed packages folder. The new version of the package overwrites the files of the previous version so wouldn't it be logic if the entire package is overwritten (upgraded) and only the new version is displayed in the Installed packages folder?
Nice work, Aaron, this is a huge improvement.
I agree with Warren that it would be nice to have a way of selecting only some of the items, rather than the 'all or nothing' approach you've got now. But that's what *I* would like, and I'm not a typical user. Also, package developers have different needs from those installing a few packages on a site. Thus, I'd recommend the approach you've got now and, maybe in time, it will be worth trying to add more features/options. For now, though, it seems a nice solution to the most common issue.
Thanks for your work on this, and for being so open to suggestions and feedback from the community!
cheers,
doug.
@Warren, @Jeroen & @Doug: I understand your reasoning behind the ability to select what you want to install from the package but I must disagree with implementing it. By having opt-out you have the possibility of a package being installed in an unexpected manner. There are a few things you need to consider with having pieces left out:
- Package actions: What if an action expected a certain Macro or Template? Then you need to have the installer with some smarts about the actions that are to be executed. I believe that the CWS installer does have an expectation on a certain Stylesheet which it adds to the WYSIWYG editor (I wrote the SQL, I presume it's still there).
- Upgrading assemblies: Say a user opts-out of a .NET macro, but the DLL with the functionality is still included (because other macros require it). All of a sudden you've got the possibility of code for the macro the dev opted out of still being deployed, as it was all in the 1 DLL.
- Long upgrade paths not being remembered: v1 is fully installed, v1.1 a template is opted out as it was changed, v1.2 is installed by someone unaware that the v1.1 template wasn't upgraded due to customization so it gets upgraded and the site breaks. If you have to change the name of your custom one then you wouldn't have run into that problem.
Also, if your package is large enough that people may only want parts of it then maybe you should break it into a few packages.
Just a few problems I can see with opt-out upgrades, what's your thoughts?
Oh, and Doug, considering some of the problems which have come from the past of things changing without community discussion I thought it'd be best to ask the people who use the feature the most. I'm not a package dev, I just have a need to do this in a particular way now. Best not to change it how I see fit and expect it to be fine with everyone else.
All valid points, Aaron.
I guess the question is... would Aaron's approach be unreasonable for users, or is there a reason not to do at least as much as he's recommended? Personally, I don't see a problem with his approach and think it would be a big step in the right direction. Perhaps not the last step, but a wonderful first step. How about the rest of you?
cheers,
doug.
Yes I agree with how complex it could get with giving the user the option to choose what they want and on that basis I think this is a great idea Aaron.
Thumbs up from me :)
is working on a reply...