In theory you can go all the way, in practice it 'depends' on your solution, and plugins and history of your database table index names, and whether all db migrations have run in past... and whether you have hundreds of backoffice users... etc etc the list goes on
But essentially in 7.7.0 the concept of User Groups were introduced and lots of database stuff related to user permissions were changed, you need those migrations to run...
consequently I've found in the same circumstances you are in, that leaping to 7.6.13
is a useful interim step to take.
then to 7.7.13...
then should be fine to move to 7.14 (although I've only ever gone as far as 7.13.2 recently)
There are a number of breaking changes between 7.5.0 and 7.6.13 - did they not cause you any problems? 7.6.0, for example, seems to have a lot of breaking changes.
No, issues I had with going from 7.4 and 7.5 directly to 7.12 and more recently 7.13 have centred around not being able to login to authorize the upgrade which will trigger the database migrations to run, but the database migrations include the database changes that allow you to login... if that makes sense!
So when I've had this issue, upgrading to 7.6.13 is the magic step that makes it work...
What I would suggest is get a vanilla version of Umbraco that you are aiming to upgrade to, and point the connection string at a copy of your site - keep the umbracoConfigurationStatus appsetting blank. keep useLegacyEncoding the same, and see if when running the site, you can login and trigger the database upgrade. If you can and upgrade completes, then you know you can go directly to that version with your solution - if not, then 7.6.13 is likely the interim step to take.
In the last two months, I've upgraded 9 sites, only 2 needed to go via 7.6.13 - then I tend to use the version specific guide to make sure settings that have changed, and dlls that can be removed are manually removed - and use source control for comparing config changes with existing site and upgraded version....
then I tend to use the version specific guide to make sure settings
that have changed, and dlls that can be removed are manually removed -
and use source control for comparing config changes with existing site
and upgraded version
I'm using the command "Install-Package UmbracoCms -Version 7.n.n" in Visual Studio. It usually asks whether to overwrite the config files - should I answer Yes or No? The upgrade guide seems a little confusing over that!?
I too have done around 7 updates to existing websites, and did a similar approach to Marc Goodson's. But in my case with more baby steps.
I have updated to the latest version of each of the versions indicated on the Version Specific upgrades documentation page, so when it says 7.7.0, I updated to 7.7.13.
So my path of upgrade ended up being:
7.3.8
7.4.3
7.6.13
7.7.13
Latest version (at time of writing, 7.14.0, with no version specific upgrades in between)
This way it ended up being easier to test and with no issues whatsoever.
I've found in the same circumstances you are in, that leaping to
7.6.13
is a useful interim step to take.
then to 7.7.13...
then should be fine to move to 7.14
I have successfully upgrade to 7.6.13 and that has been released to Live. Are you saying the route from here is 2 steps (7.7.13 then 7.14), or can I go straight to 7.14? (I appreciate that at the time, you hadn't done 7.14 yourself)
If I have the existing config of the site commited into a git repo then yes I let the nuget install overwrite the config.... Then for each config file you can see in your git client exactly what has changed... Eg settings added or settings removed... Or settings you want to keep that will be overwritten by the fresh upgrade set of config! - the git client makes it easy to see and merge the configs... so that you end up with your Umbraco implementation specific config settings along with any new config added for specific version...
I have just gone from 7.6.13 to 7.7.13 which has introduced the new User management.
There is a mixture of users and the Admin users can login OK. However, I have tried one of the Writer users and it won't login - I have tried resetting the password, I have tried changing the assigned groups, but nothing helps.
I created a new test Writer user and that works fine.
(you could update the userPassword hash to be one that works - if you want to completely rule that out, but from what you describe I don't think that's the issue)
check the userName - for the ones that work is it an email address? and the ones that don't work, are they traditional usernames?
You might have the umbracosetting.config set to
<usernameIsEmail>true</usernameIsEmail>
and so that's why it appears admins work and writers don't...
Also look at rest of columns make sure passwordConfig column is populated for the people it doesn't work on, and make sure any failedLoginAttempts or lastLockoutDate are set to NULL
and userNoConsole should be 0 and userDisabled should be 0
but as I say compare the values with the admin entries that do work to try and spot the anomoly
Then if all looks right in that table, have a look in
SELECT TOP (1000) [userId]
,[userGroupId]
FROM [dbo].[umbracoUser2UserGroup]
make sure your disappointed writers are mapped to a valid user group in there
and that the userGroups they are in are mapped to an app
SELECT TOP (1000) [userGroupId]
,[app]
FROM [dbo].[umbracoUserGroup2App]
If you change anything in the database, eg update column to match admin, make sure to do an app pool recycle before checking whether it's fixed the login.
I have found that if a password is changed for a user, by an admin, via the Users section then that password will not work and the user will not be able to login to Umbraco.
However, if a user logs into Umbraco and changes their own password (via icon in the top left corner), then the password change works correctly.
Hi Marc, I am at 7.7.13 and the initial upgrade has been done. I can log in as an admin. Users can log in.
However, if I (as "an" admin) go to the Users section and change a user's password, then that user will not be able to log in (with that password).
If the user logs in and changes their own password using the logo / icon in the top left corner, then the password change works and the user can log in again.
When a user password change fails (by changing it via Users section), I am able to fix it by updating their record in the database with a known userPassword value.
The userPassword value, when changing it via the Users section (as an admin) is different to that when changing it as the logged on user.
Thanks... And sorry if the questions sound repetitive!.. but I'm trying to picture the scene and remember what I do to troubleshoot....
Anyway...
If you now create manually a new writer user and set to a known password logged in as admin...
Then login as said new writer and change password
Are the hashes the same? Or different as per the existing writer?
If they are the same.. then strongly believe issue is with what is stored in passwordConfig column in the umbracoUsers table for the existing writer.. eg the SHA is different ..
If the same problem persists for new writer... Then feels like a bug in 7.7 and I'd upgrade to 7.13.2 and see if issue persists...
Have only ever used 7.7 as a stepping stone to later version...
Log in as admin, create new user (not an admin), note default password. Log out.
Log in as new user, change own password, log out ... can log back in again. E.g. change password works.
Log in as admin, go to Users section, select new user (added above), change password. Log out. Log in as new user with new password ... log in fails.
In DB, copy known password hash to new user record. Log in now works.
Yes - setting the password as the new user and setting it as an admin generates a different password hash.
The value in passwordConfig, for all users, is the same - {"hashAlgorithm":"HMACSHA256"}
It may well be a bug in 7.7.13, but it would be nice to know before I push this out to Staging and Live.
*Edit - I have just checked and the "Forgot Password" feature also works OK. I tested it with the "new user". So, it appears to be just changing the password via the Users Admin section that fails.
Basically when you change the password via back office it's doing a password reset to a new random password and not the password you want to set it to...
It's fixed in 7.13
I'd just use 7.7 as a stepping stone; once you've used it to upgrade the database - I'd then begin the upgrade to 7.13...
There isn't a compelling reason to stop at 7.7 and release your site on that version? Particularly if your next step is to 7.13!
I have 7.7.13 on our Dev server, which was an upgrade from 7.6.13. Do I need to release this to Live before taking the next step to 7.13?
Or, would it be OK to now do the upgrade to 7.13 (or 7.15?!) on Dev and then release to Live? That would mean Live would go from 7.6.13 to 7.13 (or 7.15) in one go.
I was assuming that these steps needed to be done on each environment.
I would write down the steps to go from current version to target version
To go via 7.7 and then immediately onto 7.13
All you need to do for the 7.7 step is to point a 7.7 solution's database connection string at the database of the site you want to upgrade and login as admin to approve the upgrade .. when that is complete you can immediately point your 7.13 solution at same database login and trigger upgrade to 7.13...
With this approach you don't need to test your site in 7.7... only in 7.13... saving time if you get stuck on a bug that has been fixed in the later version...
By writing the exact steps down to perform he upgrade and overcome any problems in the journey... You can do a test dummy run and measure exactly how long it takes to perform the steps.. so then when your ready for production you know how long it will take for any content freeze.... And you can do it against a copy of the live db ... So if it does unexpected ly go wrong despite your tests and dummy run you can always abort and leave the site as is...
That said if this seems over complicated and you want to release 7.7.13 to production first then you can but don't worry about this password reset thing! It will be fixed in your next upgrade .. and you can short term set passwords via SQL if you need to...
Haha, yes, maybe you should have made a video to show waving hands!! :-)
I have had to make some code changes in our project, for each of the upgrades so far, which means recompiled DLL's. So, I think I'll stick to the easier (although slower) route of one version step-up / test / release at a time option.
Nice to know the User password bug is known, and fixed in a later version.
Main thing is if you encounter a problem, is not to spend too much time stressing on fixing it, have a look in the issue tracker and see if it has been reported and fixed in a later version!
You only need your custom code to work with the last version you upgrade to! - but encountering and fixing it at each step, might give you good progress feedback! rather than boom and bust!
Hopefully I've answered the original question though:
Do I need to get step by step, or can I take bigger steps?
Upgrading Umbraco many versions
I am working on a large Umbraco project which was based on 7.4.2 - I have successfully updated it to 7.4.3 and am just working on 7.5.0.
I am trying to get to the latest v7, if possible, and am wondering if I need to go step by step (version by version), or if I can make bigger steps?
Any ideas and/or suggestions?
Hi Gordon
In theory you can go all the way, in practice it 'depends' on your solution, and plugins and history of your database table index names, and whether all db migrations have run in past... and whether you have hundreds of backoffice users... etc etc the list goes on
The version specific guide is your friend:
https://our.umbraco.com/documentation/getting-started/setup/upgrading/version-specific
But essentially in 7.7.0 the concept of User Groups were introduced and lots of database stuff related to user permissions were changed, you need those migrations to run...
consequently I've found in the same circumstances you are in, that leaping to 7.6.13
is a useful interim step to take.
then to 7.7.13...
then should be fine to move to 7.14 (although I've only ever gone as far as 7.13.2 recently)
regards
Marc
Thanks Marc.
There are a number of breaking changes between 7.5.0 and 7.6.13 - did they not cause you any problems? 7.6.0, for example, seems to have a lot of breaking changes.
Hi Gordon
No, issues I had with going from 7.4 and 7.5 directly to 7.12 and more recently 7.13 have centred around not being able to login to authorize the upgrade which will trigger the database migrations to run, but the database migrations include the database changes that allow you to login... if that makes sense!
So when I've had this issue, upgrading to 7.6.13 is the magic step that makes it work...
What I would suggest is get a vanilla version of Umbraco that you are aiming to upgrade to, and point the connection string at a copy of your site - keep the umbracoConfigurationStatus appsetting blank. keep useLegacyEncoding the same, and see if when running the site, you can login and trigger the database upgrade. If you can and upgrade completes, then you know you can go directly to that version with your solution - if not, then 7.6.13 is likely the interim step to take.
In the last two months, I've upgraded 9 sites, only 2 needed to go via 7.6.13 - then I tend to use the version specific guide to make sure settings that have changed, and dlls that can be removed are manually removed - and use source control for comparing config changes with existing site and upgraded version....
if that makes sense!
regards
marc
I'm using the command "Install-Package UmbracoCms -Version 7.n.n" in Visual Studio. It usually asks whether to overwrite the config files - should I answer Yes or No? The upgrade guide seems a little confusing over that!?
Hi Marc, can you point out where DLLs that are no longer required are listed please?
I decided to make the interim step to 7.6.13 ... I'll get that sorted and released to live, then come back and update to the latest v7.
Hello!
I too have done around 7 updates to existing websites, and did a similar approach to Marc Goodson's. But in my case with more baby steps.
I have updated to the latest version of each of the versions indicated on the Version Specific upgrades documentation page, so when it says 7.7.0, I updated to 7.7.13.
So my path of upgrade ended up being:
This way it ended up being easier to test and with no issues whatsoever.
They are pointed out in the Version Specific upgrades page, being 7.3.0 an example!
Ah, OK. I started from 7.4.3, so the removals as of 7.3.0 don't apply. I will check the other info though, for the later releases.
Marc, previously you said
I have successfully upgrade to 7.6.13 and that has been released to Live. Are you saying the route from here is 2 steps (7.7.13 then 7.14), or can I go straight to 7.14? (I appreciate that at the time, you hadn't done 7.14 yourself)
Try doing a 2 step:
It's more controlled that way!
Hi Gordon
If I have the existing config of the site commited into a git repo then yes I let the nuget install overwrite the config.... Then for each config file you can see in your git client exactly what has changed... Eg settings added or settings removed... Or settings you want to keep that will be overwritten by the fresh upgrade set of config! - the git client makes it easy to see and merge the configs... so that you end up with your Umbraco implementation specific config settings along with any new config added for specific version...
I have just gone from 7.6.13 to 7.7.13 which has introduced the new User management.
There is a mixture of users and the Admin users can login OK. However, I have tried one of the Writer users and it won't login - I have tried resetting the password, I have tried changing the assigned groups, but nothing helps.
I created a new test Writer user and that works fine.
I have useLegacyEncoding="true"
Any suggestions?
Hi Gordon
have a look at the users in the database table
SELECT * FROM [dbo].[umbracoUser]
and compare the columns to one that works
(you could update the userPassword hash to be one that works - if you want to completely rule that out, but from what you describe I don't think that's the issue)
check the userName - for the ones that work is it an email address? and the ones that don't work, are they traditional usernames?
You might have the umbracosetting.config set to
and so that's why it appears admins work and writers don't...
Also look at rest of columns make sure passwordConfig column is populated for the people it doesn't work on, and make sure any failedLoginAttempts or lastLockoutDate are set to NULL and userNoConsole should be 0 and userDisabled should be 0
but as I say compare the values with the admin entries that do work to try and spot the anomoly
Then if all looks right in that table, have a look in
SELECT TOP (1000) [userId] ,[userGroupId] FROM [dbo].[umbracoUser2UserGroup]
make sure your disappointed writers are mapped to a valid user group in there
and that the userGroups they are in are mapped to an app
SELECT TOP (1000) [userGroupId] ,[app] FROM [dbo].[umbracoUserGroup2App]
If you change anything in the database, eg update column to match admin, make sure to do an app pool recycle before checking whether it's fixed the login.
regards
Marc
Hi Marc, yes, all of that ties together.
I have found that if a password is changed for a user, by an admin, via the Users section then that password will not work and the user will not be able to login to Umbraco.
However, if a user logs into Umbraco and changes their own password (via icon in the top left corner), then the password change works correctly.
Hi Gordon
hmm, So just to confirm
Admin user that can login has identical column values in the umbracoUser table to a Writer that can't login?
and if you set their hash keys to be the same for a known password...
(and do an app pool recycle)
the admin can login but the writer can't? or can they both?
and...
if the user changes the password, to the same password that the admin set for them...
are the hash keys different?
and have you proceded now to 7.13?
eg only the admin needs to login to authorize the upgrade...
does the problem with the writer exist in 7.13 or 7.7?
regards
Marc
Hi Marc, I am at 7.7.13 and the initial upgrade has been done. I can log in as an admin. Users can log in.
However, if I (as "an" admin) go to the Users section and change a user's password, then that user will not be able to log in (with that password).
If the user logs in and changes their own password using the logo / icon in the top left corner, then the password change works and the user can log in again.
When a user password change fails (by changing it via Users section), I am able to fix it by updating their record in the database with a known userPassword value.
The userPassword value, when changing it via the Users section (as an admin) is different to that when changing it as the logged on user.
Hi Gordon
Thanks... And sorry if the questions sound repetitive!.. but I'm trying to picture the scene and remember what I do to troubleshoot....
Anyway...
If you now create manually a new writer user and set to a known password logged in as admin...
Then login as said new writer and change password
Are the hashes the same? Or different as per the existing writer?
If they are the same.. then strongly believe issue is with what is stored in passwordConfig column in the umbracoUsers table for the existing writer.. eg the SHA is different ..
If the same problem persists for new writer... Then feels like a bug in 7.7 and I'd upgrade to 7.13.2 and see if issue persists...
Have only ever used 7.7 as a stepping stone to later version...
No problem!
Log in as admin, create new user (not an admin), note default password. Log out.
Log in as new user, change own password, log out ... can log back in again. E.g. change password works.
Log in as admin, go to Users section, select new user (added above), change password. Log out. Log in as new user with new password ... log in fails.
In DB, copy known password hash to new user record. Log in now works.
Yes - setting the password as the new user and setting it as an admin generates a different password hash.
The value in passwordConfig, for all users, is the same -
{"hashAlgorithm":"HMACSHA256"}It may well be a bug in 7.7.13, but it would be nice to know before I push this out to Staging and Live.
*Edit - I have just checked and the "Forgot Password" feature also works OK. I tested it with the "new user". So, it appears to be just changing the password via the Users Admin section that fails.
Hi Gordon
It's a known issue after 7.6...
See
HTTPS://GitHub.com/Umbraco/umbraco-cms/issues/3015
Basically when you change the password via back office it's doing a password reset to a new random password and not the password you want to set it to...
It's fixed in 7.13
I'd just use 7.7 as a stepping stone; once you've used it to upgrade the database - I'd then begin the upgrade to 7.13...
There isn't a compelling reason to stop at 7.7 and release your site on that version? Particularly if your next step is to 7.13!
Regards
Marc
Thanks for finding that!
I have 7.7.13 on our Dev server, which was an upgrade from 7.6.13. Do I need to release this to Live before taking the next step to 7.13?
Or, would it be OK to now do the upgrade to 7.13 (or 7.15?!) on Dev and then release to Live? That would mean Live would go from 7.6.13 to 7.13 (or 7.15) in one go.
I was assuming that these steps needed to be done on each environment.
Hi Gordon
Easier to explain by waving hands around but...
I would write down the steps to go from current version to target version
To go via 7.7 and then immediately onto 7.13
All you need to do for the 7.7 step is to point a 7.7 solution's database connection string at the database of the site you want to upgrade and login as admin to approve the upgrade .. when that is complete you can immediately point your 7.13 solution at same database login and trigger upgrade to 7.13...
With this approach you don't need to test your site in 7.7... only in 7.13... saving time if you get stuck on a bug that has been fixed in the later version...
By writing the exact steps down to perform he upgrade and overcome any problems in the journey... You can do a test dummy run and measure exactly how long it takes to perform the steps.. so then when your ready for production you know how long it will take for any content freeze.... And you can do it against a copy of the live db ... So if it does unexpected ly go wrong despite your tests and dummy run you can always abort and leave the site as is...
That said if this seems over complicated and you want to release 7.7.13 to production first then you can but don't worry about this password reset thing! It will be fixed in your next upgrade .. and you can short term set passwords via SQL if you need to...
Haha, yes, maybe you should have made a video to show waving hands!! :-)
I have had to make some code changes in our project, for each of the upgrades so far, which means recompiled DLL's. So, I think I'll stick to the easier (although slower) route of one version step-up / test / release at a time option.
Nice to know the User password bug is known, and fixed in a later version.
Thanks again for your help.
Cool! - you'll learn a lot on the way too!
Main thing is if you encounter a problem, is not to spend too much time stressing on fixing it, have a look in the issue tracker and see if it has been reported and fixed in a later version!
You only need your custom code to work with the last version you upgrade to! - but encountering and fixing it at each step, might give you good progress feedback! rather than boom and bust!
Hopefully I've answered the original question though:
Do I need to get step by step, or can I take bigger steps?
The answer is: yes, you can take bigger steps...
... but totally ok to choose not to!
Good luck with the rest of the upgrade!
regards
Marc
is working on a reply...
This forum is in read-only mode while we transition to the new forum.
You can continue this topic on the new forum by tapping the "Continue discussion" link below.