Answered Revo Upgrade Database Issues

Hi all,

This question is somewhat similar to what's been discussed here https://forums.modx.com/thread/79936/dual-installation-query#dis-post-440512. I have a MAMP version of Revo that I've been working on for several months to replace an Evo installation.

Everybody's signed off on the local version and I've been trying to upload the local version to the website.

I've been following the methodology outlined by Bob Ray in MTOG, but when I run (advanced) update I keep getting the dreaded

Could not connect to the existing database for upgrade. Check the connection properties and try again.

I've tried this 5 or 6 different ways, but I'm starting to wonder if it is a database naming issue.
The host I'm using forces all instances of MySQL databases to follow a specific naming convention with a prefix that is my account name. When locally developing the databases, I used a database name that didn't follow this convention. Could this be causing the problem, or is there something else I should be investigating?

And if it is the problem, is there some other way to make this work? (Do I have to do some SQL jiggery pokery to rename the database to conform to the web host's naming conventions, for example?)

Just to be clear, I can install a clean fresh empty version on the site with no problems at all; it's getting the setup script to run after importing the SQL file into the remote MODX installation that causes the problem.

I've spent two days on this and am getting a little frazzled…

Any ideas? Thanks. [ed. note: schelling last edited this post 13 years, 11 months ago.]

Delete the core/cache folders in the dev site, zip it up and move the installation, unzip it, dump and import the database, edit the config.inc.php file to correct the database login info, then run setup. That should do the trick.

Thank for the much-needed and quick reply, Susan.

just to be clear, am I to delete the cache folder inside the core folder or the whole of the core folder?

Thanks again,
Gary

all the folders in core/cache. core/cache itself is left alone. Actually that shouldn't make any difference; the key is to have the correct database login information in the config.inc.php file. Don't forget the database_dsn line! That has tripped up a lot of people!

[virtual fist bump]

At first, it wasn't working, so I looked at the log files and apparently, the change to the admin name wasn't taking, so I went back to config.inc.php and changed $database_user to include the prefix imposed by the web host and then ran just the regular update and shazam!

Two things: I got this message on the install summary screen:

Currently, you are using the PHP suhosin extension, and your suhosin.get.max_value_length is set too low for MODX to properly compress JS files in the manager. MODX recommends upping that value to 4096; until then, MODX will automatically set your JS compression (compress_js setting) to 0 to prevent errors.

Is this something I should worry about?

I pushed through to complete the install and now on page /setup/index.php?action=complete I get a 500 Error. Now what? [ed. note: schelling last edited this post 13 years, 11 months ago.]

Having compress_js set to 0 should not be a problem for now.

Did you rename/remove the .htaccess file before setup? Can you log in or view the site?

After a morning of slugging away, including blowing up the old install, deleting everything from the web host and trying from the beginning, I've managed to get through the install process without it throwing any error messages. However, I'm still getting a 500 error at the end of the install. I've run setup a couple of times and it cruises through the update flawlessly, except for the server error at the end.

I'm convinced that there are some other database connection issues linked to the move from the previous MAMP installation and my web host's requirements to prefix database and database user names with the account name.

Any ideas on how to test to diagnose further? By the way, in core/cache logs I see

(ERROR in xPDOConnection::connect @ /path/core/xpdo/xpdo.class.php : 2999) SQLSTATE[28000] [1045] Access denied for user 'old_dbuser'@'localhost' (using password: YES)

Thanks again.

Sorry, Frogabog, for not answering when I posted but

1. Yes, following Bob Ray's process, I renamed .htaccess to ht.access

2. No, I can't see the site: every page (/manager/index.php, index.php) except /setup/index.php gives me the 500 error

Does old_dbuser have full permissions for the database?

Also, have you checked the config files?

Updating your Config Files

Once you've deployed files to the new server, you need to update the main configuration file: core/config/config.inc.php. You have to update paths to 6 different resources. Open the file and update the values for the following variables doing a find and replace:

/* PATHS */
$modx_core_path= '/path/to/modx_doc_root/core/';
$modx_processors_path= '/path/to/modx_doc_root/core/model/modx/processors/';
$modx_connectors_path= '/path/to/modx_doc_root/connectors/';
$modx_manager_path= '/path/to/modx_doc_root/manager/';
$modx_base_path= '/path/to/modx_doc_root/';
$modx_assets_path= '/path/to/modx_doc_root/assets/';
 
/* HOST (used for command-line PHP stuff) */
$http_host='yoursite.com';

If you are also moving your site into or out of a subfolder, be sure to update the variables such as $modx_connectors_url, $modx_manager_url, and $modx_base_url. They should generally
end with a slash (e.g., $modx_base_url='/' for a site not in a subfolder).
Permissions
Before you can edit your config file, you may need to loosen up the permissions. After you've edited it, be sure you restore the read-only permissions on the file.

There are also 3 additional configuration files that contain two PHP constants:

define('MODX_CORE_PATH', '/path/to/modx_doc_root/core/');
define('MODX_CONFIG_KEY', 'config');

/config.core.php
/connectors/config.core.php
/manager/config.core.php

Make sure you update the paths in these files as well.

Okay, double-checked all the paths in all the config files and they're good.

old_dbuser was the name used on the local MAMP installation I was using for development.

When setting up the remote production version of the site, through cPanel's implementation of phpMyAdmin and MySQL, I was forced to change the database name and all database users to a new name using the scheme "accountcode_dbuser" and "accountcode_dbase".

I suspect that's what's screwing things up. After uploading the development files to the new site (and importing the SQL from old_database to accountcode_database), I have had to go in to all the config files and add the accountname prefix to the relevant names.

As mentioned, I've done it to all 4 of the config files mentioned above, and looked for additional ones in other folders, but no luck.

Any other troubleshooting ideas?