Access denied error when previewing ported site

My client has purchased new hosting at GoDaddy, where I also have a hosting account. I have been trying for hours to port the development site from my hosting account at GoDaddy to my client’s hosting account and domain, also hosted at GoDaddy.

Working site: http://newmarketer.us
Port site: http://agenthunter.com.us

Here is the procedure that I used to install MODx and move the site to http://agenthunter.com.au:

1) Downloaded MODx 0.9.6.3, unzipped, and uploaded to the root level
2) Ran install and default MODx site came up fine.
3) Imported data from working site into new database
4) Modified config.inc.php to reference new table prefix
5) Renamed installation manager and asset folders
6) Uploaded assets and manager folders from working site
7) Modified file manager path to new html folder

Here is the current File Manager Path at http://agenthunter.com.au:
/home/content/08/5274108/html/

And here is the PHP include_path:
/home/content/08/5274108/html/manager/includes/ .:/usr/local/php5/lib/php

I am able to login to the manager at http://agenthunter.com.au and view all the files in the file manager there so I know the database connection string is right but I am getting this error when I try to preview the site at http://agenthunter.com.au

Access denied for user ’agnthntr’@’%’ to database ’`agnthntr`’

A month ago, I used the same procedure that I’ve used tonight to install the partially developed MODx site into my development environmnent at GoDaddy. I cannot understand what is the problem and really hope that someone can help.

After a night’s sleep, another re-installation, and the same problem occurring, I took a closer look at the config.inc.php. This was the offending line:

$dbase = ’`agnthntr`’;

I did not maliciously embed those backward ticks enclosing the dbase name but removing them solved the problem. The script generated this format and it only became a problem when I upgraded/customized the site, rather than building from scratch after a fresh install. Those of you who know more about MODx than me, and care about this scenario, can ponder why this is the case. For my purposes, I now know what makes the access error go away and that’s good enough for me.

Marj Wyatt | http://virtuallymarj.com

The database structure may not be the same for a new version, so it’s never a good idea to import the old database *after* doing the upgrade install.

The usual method is to:

1. Back up the current install (including all files and the DB)

2. Copy the new files to the install (making sure that all old files are overwritten -- not all FTP programs do this by default).

3. Run the upgrade install.

I recognize my methodology was unconventional but the boring truth about it is that the working site is in 0.9.5 and the oldest available release of MODx on the site here is 0.9.6.3. Perhaps it is just my inherent "literal-ness" but this isn’t really an upgrade as installing the functioning code results in the version stepping backward. The installation of MODx, initially, was somewhat of a fashion step to get it working in that environment.

Either way, it is up and running on ver 0.9.5 on the "live" environment. I did endeavor to upgrade the code to 0.9.6.3 in the development environment and functionality that works in 0.9.5 does not work in 0.9.6.3, such as an end user subscribe. At this moment, I’m not clever enough to know what to look for as the cause of that so I will focus on getting the main functionality working, as is, and turn my attention to cleaning up code for an upgrade if my client springs for more development dollars after he’s made some money from his site.

This project began as a recovery of a hacked wordpress site. It has led me to learning MODx, which isn’t a totally bad outcome but it is slowing down my productivity.

Adding to my conundrum is that neither the wordpress nor the MODx code that I was given to work with is documented in any way at all. I sure wish that developers understood that documenting their code is not a sign of weakness.

Marj Wyatt| www.VirtuallyMarj.com

Actually, when making a big jump in versions it’s even *more* important to import the content first (before the install) because it’s more likely that the database structure has changed.

You may have latent problems that will surface later and they may be very hard to fix if they involve transformations to the DB that should have been made but weren’t.

Consider yourself warned .

Bob,

I DID import the database before changing the assets and manager folders over but I could see no way to make MODx work without first installing it so please tell me what you are referring to? When I imported the tables, the prefix changed so I modified the config.inc.php to reflect the imported table prefix.

Update instructions at MODx documentation indicate that I should not update program features that were customized. To the best of my knowledge, lacking any documentation, all of the customizations are in folders named "agenthunter" for this site so, in the development environment, I performed the upgrade and did not uncheck any boxes. Prior to running an upgrade install at that location, an end user was able to register as a free member. Now that function fails, although the ID appears to have been created because I can login to it.

If there is a way to export the templates, snippets, and chunks, so they can subsequently be imported into a new installation through the administrative interfaces, it sure isn’t not obvious to me.

I suppose, since I have another working version on 0.9.5 at the client’s domain, I could try to install it differently in the development environment and see if anything is different this time. At least I am aware of the "backward tick" issue that is created by the installation script so I won’t need to chase that down again...

Let me take another stab at explaining it.

Over the course of MODx development, the database structure can be modified -- with fields or tables added or deleted.

When you upgrade, the install script makes a note of the version you are upgrading from and performs any necessary transformations on the database and its contents, without losing your data. It may also delete obsolete files. As I understand your process, this step never occurred.

Unless I’m misunderstanding your process, you installed 0.9.6.3, then imported the tables from 0.9.5 into that install (changing the prefix in config.inc.php so the 0.9.5 tables would be used). So basically, you currently have an 0.9.6.3 install that’s using 0.9.5 tables (and your DB also contains 0.9.6.3 tables containing all the demo content that are currently being ignored).

If there is a way to export the templates, snippets, and chunks, so they can subsequently be imported into a new installation through the administrative interfaces, it sure isn’t not obvious to me.

Normally, this isn’t necessary because you upgrade the install that contains all those elements -- they stay right where they are.

I’d recommend backing up and then upgrading your 0.9.5 site by following the steps outlined here: http://wiki.modxcms.com/index.php/Upgrading_Guide.

You might also consider upgrading to MODx Evolution 1.0.2, which is the current version:

http://modxcms.com/download/

Hi Bob,

If you refer to this post, you will see that I followed your advice but there still are problems with the upgrade that are eluding me at my newbie level of competence.

http://modxcms.com/forums/index.php/topic,42769.0.html

In my scenario from this link, I dropped all tables from the database, imported the 0.9.5 SQL backup, uploaded the 0.9.5 assets and manager folders and the site did come up without running an install script of any sort.

When I used option to on the "how to upgrade" link, which is the same as the wiki you posted to your last note, I moved over customizations from the site to the 0.9.6.3 "fresh" folders, uploaded these 0.9.6.3 folders, with the site customizations, to the server, renamed the 0.9.5 assets and manager folders, and ran the install script as an upgrade to 0.9.6.3. The upgrade did take and the tables were modified as an upgrade, but functionality was lost that used to work.

Something that I’ve yet to find in any MODx documentation is a reference document that points developers in the right direction for errors.

Getting the site upgraded is just something that I feel would be nice to do but, as I mentioned earlier, it is not something that is concerning the client.

Regards,
Marj Wyatt aka Virtually Marj

Changes are made to the database structure in some cases; this is why it’s necessary to run the intstaller in upgrade mode. Unless you’ve uploaded the new assets/snippets folder, make sure to clear all the optional chunk/snippet checkboxes. If you do upgrade all the chunks, snippets etc, both uploading the new versions and upgrading in the database, if there have been changes to the snippets your old snippet tag parameters may no longer work as they did.

If you are upgrading from a much older version, it is best to not upload the new assets/snippets folder, and to clear their checkboxes when running the upgrade installer. Then you can upgrade the individual snippets after you’ve determined if there are differences in the parameters and behavior of the newer versions of the snippets.

Let me see if I have this straight...

You are recommending for me to upload only the latest install folder, run the upgrade without having anything checked, and then apply customizations to that upgraded environment? Based on what I know about application upgrades in general, this doesn’t seem to make sense...

The alternate upgrade option at this link is what was used to go from 0.9.5 to 0.9.6.3.

http://svn.modxcms.com/docs/display/Evo1/Upgrading

Because multiple people are recommending a leap from 0.9.5 to 1.0.2, I backed out the 0.9.6.3 upgrade and I am performing the upgrade again, going straight to 1.0.2. For clarity’s sake, I will tell anyone following this thread that I dropped all the tables from the database and re-imported a backup from 0.9.5 that was captured prior to upgrading the site to 0.9.6.3 last week.

But, before I do this update again, I would like to know if the intention is to upload only the install folder for the latest release.

I’m also not sure how to determine what, if any, core MODx code was changed for this site and the original developer is not available to answer this question. Of course, there is no accompanying site documentation. Clearly, anything is a folder named the same as the site would not conflict with MODx. File modification dates were lost when the zip backup was created in late 2007.