Migrating to Revolution

I tried everything I could think of and nothing worked so I reverted everything and it’s back to normal.

Is anyone using 3372 with the default theme?

BTW, in the old version I have, (3371, I think), the Manager is hatched in IE7. Much of the right panel is hidden behind the left panel and there’s no toolbar at the top. It’s fine in FF.

I’m running on rev 3373 with no issues (FF/mac) using the default theme, also tested on FF/win as well. Not sure what your problem could have been.

I’ve noticed the problems in IE7 myself with the top toolbar - can’t say I noticed a problem with the panels, but then it was only a brief look over lunch at work.

Quote from: BobRay at Feb 13, 2008, 04:12 PM

BTW, in the old version I have, (3371, I think), the Manager is hatched in IE7. Much of the right panel is hidden behind the left panel and there’s no toolbar at the top. It’s fine in FF.

This is a known issue - if anyone wants to help me figure out why IE can’t get it’s JS in line, it’d be highly appreciated.

Also, whenever I personally make a commit that requires a rebuild, I put "REBUILD REQUIRED" as the first part of the commit. I recommend we make this a standard procedure for commits.

This is a known issue - if anyone wants to help me figure out why IE can’t get it’s JS in line, it’d be highly appreciated.

I’m pretty close to having it licked - I think Just a bit of tweaking with the MODx.Layout to keep ole’ IE happy.

Well, things have gotten pretty strange here.

When I did the original update, dozens of files were updated and when I did the revert, they all went back.

I tried another SVN Update but only got about 6 files (Garyn’s revisions). Then, I reverted again to see what would happen and *nothing* got reverted.

When I do an upgrade now, everything at the site says Complete at 3373. I did another build and an upgrade install and got the same errors I listed above. The manager looks more or less normal and I can see my docs in the tree now, but when I try to edit a document, I get a blank right-hand panel.

Here’s where things get *really* strange. I made a whole new directory, and checked out 3373 to it to try and compare the files. I did the build and new install using a newly created database called "dummy." The install went without error and the I got the normal manager with no files in it. When I created a new document, it got the doc ID of 89. When I previewed the "dummy" site, I saw my content from the other site. When I went into PhpMyAdmin, there was the entire content of the old site in the modx_site_content table of the "dummy" database! I used the same table prefix but it’s a different database and the config.inc.php file is correct so I can’t imagine how it got there. PhpMyAdmin reports that all the tables are fine (at least not corrupted in any way it can recognize). In the "dummy" site’s manager, I can click on "recent documents" and see (and edit) the docs from the old site although they don’t show in the tree.

I guess it’s time to delete everything and start over but I hate to lose all the work I did importing the content from the 0.9.6 site. I had about figured that my SVN directories were corrupted but that doesn’t explain the database weirdness.

I wonder now if some of the steps I did in migrating the 0.9.6 site to 0.9.7 messed up the database so that an upgrade install of 0.9.7 corrupted it further.

As an aside, the error messages during the install would be a lot more helpful if they gave the name of the database table in addition to the class names.

Bob

I tried to run a test install a few weeks ago and no dice. Then I tried again today and it just wasn’t working. It finally worked when I used the default database of modx with prefix modx_

So from my cursory tests, only the default database (and maybe prefix) worked.

Im using MAMP, osx 10.4, with PHP 5.2

I’ve got it working on different databases, both MAMP and on a typical remote Linux server. I am using the default modx_ table prefix, though.

Maybe prefix is the key. I was frustrated and set them both to their default, and low-and-behold... It was working

Quote from: ProWebscape at Feb 14, 2008, 02:56 AM

Maybe prefix is the key. I was frustrated and set them both to their default, and low-and-behold... It was working

Did you edit the table prefix in build.config.php?

I think you have to do that before running transport.core.php.

Bob

I am not really sure now. Im not even sure I changed the prefix (i usually leave it as default on the dev machine). Ill have to try to recreate the errors later.