One final test: I reinstalled again, then very carefully tested at each step. I deleted the core, manager, assets, connectors directories prior to install.
1. Reinstall, login to manager. Resource tree with default Home 1 resource is there.
2. Move the core/components directory back into core from backup.
3. login again, clearing cache each time. Resource tree with default Home is still there.
4. logout, clear cache, and then import the contents of live db into local db. Update db core path.
5. login, resource tree is now gone.
This means that I cannot import or move from one server to another at this point.
This is a massive bug, and it didn't exist until very recently.
It appears that the portable nature of modx is broken, which is to me a show stopper bug of the highest order. ie, moving the db from one system to another breaks something in modx, what, I don't have the means to diagnose.
Oh, I just remembered one other difference, the live site is: https but the local site is http.
But I've imported several times from the live site since the live site went https without issues.
[ed. note: lizardx last edited this post 10 years, 9 months ago.]
As one last test, I also tried using UpgradeModx, to 2.4.2 pl, it runs through all the steps, and claims to have upgraded, but the version still shows as 2.4.1 so I'm not sure what's up with that.
After the apparent upgrade which doesn't seem to have upgraded modx, the resource tree remains empty.
So there appear there to be two issues:
1. something is not working right with the UpgradeModx tool
2. The imported live db is not showing in the resource tree but is fully available in other parts of the manager. The imported chunks, templates, snippets, etc are all there. The Files structure is there. So this bug is restricted to the logic of the Resource tree viewer.
When testing to see what happens if I add a resource, the tree remains blank, so something is crashing it I'd guess, without any error output.
Very bad in my opinion. For now I'm not going to apply any upgrades at all to the live site until I can get this resolved, which can't last that long as a practice due to security issues.
I've tried with and without the css/js compression, makes no difference, this is not related, as you can see in my test, the resource tree showed fine prior to importing the live db data, and vanished as soon as that data was present.
Is there anything in the MODX error log?
One cause of an empty Resource tree is a problem with the parent fields of the resources. For example two resources being parent of each other or a resource being its own parent. I don't know how that could happen with just an export and import, though.
I can't remember if you've tried manually deleting all files in the core/cache directory and clearing your browser cache and cookies. If not, give that a shot -- and definitely leave compress_js and compress_css off.
Another possibility is a character set issue if there are any non-English characters in the pagetitles and the character set specified in the config.inc.php file is different between the two sites.
You may or may not have hit it with the character set of the db in the core/config/config.inc.php. I reinstalled again with that in mind, and this time the resources showed after importing the db tables.
while there were no foreign languages used in titles, there may have been weird characters like long dashes, magic quotes, etc.
Anyway, changing the installation character set to latin1 from utf8 seems to have resolved the issue of the vanishing resource tree, so that was a good last guess, thanks.
And yes, I've been clearing caches all day long, so that wasn't the issue, I don't honestly think it's ever been the issue but it is a good thing to do, and one the installer really should always do automatically, and the upgrader, as a matter of course.
However, now I'm going to have to work on changing the actual live site to use utf8, but it may not be worth the headache.
Looks like the last time was the charm.
The initial cause was I believe a failure to write some files to manager, which then started slowly breaking the interface of manager, which I'd noticed a long time ago, but it all mostly worked so I never worried about it.
Hopefully the upgrader will get more robust in its checks, so that failures to write files would cause errors etc, ideally these things would be checked more thoroughly before the upgrade happens at all.
Note that the upgradeModx didn't appear to work, at least the version number didn't change, but I was only trying that as a desperate last thing anyway.
I think I'm going to stick with manual full upgrades from now on, though I may try changing the character set in the exported db sql to utf8 then try to see how it works just to see, while reinstalling with utf8. In theory there should be very little difference between utf8 and latin1, but there are enough with special characters and whatnot so that might have been the issue.
thanks for your input, it was very helpful.
[ed. note: lizardx last edited this post 10 years, 9 months ago.]
You might find this helpful:
http://bobsguides.com/convert-db-utf8.html. AFAIK, the script there has not been tested on the current version of MODX.
