I have upgrade my 2.8.4 to last 3.0.2 MODX version and I had a (small) issue with property sets.
I’m using only one but it was not following perfectly : it’s was absent and inactive, but after add new one, MODX retrieve my property set with the correct name and the good settings. After validation everything works like a charm.
Someone have this issue too ?
If you bypassed the 3.0.0 version in your upgrades, that could be the source of your problem.
Oh… Should I migrate to 3.0.0 before 3.0.2?
Why would this be necessary?
I tested it and there seems to be a bug in the upgrade process (or rather one step is missing).
To fix it manually, go to the database table
modx_element_property_sets and add the namespace to the values in the column
For example change “modSnippet” to “MODX\Revolution\modSnippet”.
BTW: At least for this bug it doesn’t matter if you bypass the 3.0.0 version.
Are you sure 3.0.0 has to be installed first or is this just an “urban myth”?
If there was a difference, wouldn’t it be important to mention this somewhere in the upgrade documentation?
That’s a good question. This case could be an oversight in setup. I have seen the recommendation somewhere, but I don’t know where. The .0 versions are where significant changes are made (for example, new database fields, or new System Settings). I’ve seen a number of cases where people who skipped the .0 version were missing DB fields or System Settings, and others who solved
similar problems by backing up and installing a .0 version.
I don’t know if it’s still an issue, but I figure it’s cheap insurance to install every .0 version. And the recommendation is built into UpgradeMODX.
Converting the class keys is just the kind of thing that might take place in 3.0.0, and possibly not in later versions. (If you have the time, it would be easy enough to check).
The new version of SiteCheck, btw, would also have solved this problem. To the best of my ability, it checks and fixes all the class keys in MODX 3. Some extras may still be creating resources, users, property sets, etc. with the old class keys. I’m pretty sure there are a few of mine that I still haven’t gotten to that are doing that.
My recollection was there was a version around 2.3-2.5 when the updated tables were added in the major version release but were not somehow included into the main branch and thus were omitted from the subsequent patches until identified. This did cause issues for people upgrading to the latest and getting permissions errors in a couple of views. I do not believe this issue persists but people do continue to take the x.0 upgrade approach.
In my opinion, it’s just extra work. If you’re using 2.6.5+ you can jump staring to 2.8.x or 3.0.x. Then upgrade all extras.
I’d say in this scenario it could be an actual bug rather than the upgrade process. But, I’d be happy to be wrong if we cold identify some upgrade script that resolves these issues that needs to be in the patch releases.