Running :

EE 1.6.8 Build 20100121
EE Forum 2.1.2 Build 20100121
EE MSM 1.x

PHP 5.1.5
MySQL 5.0.22

3rd party extensions/modules/plugins

[Edit: We have not upgraded to EE 1.6.9 as some 3rd party extensions are not fully compatible as yet]

What we are trying to acheive

We want to transfer, lock stock an barrel a 100% EE run site on a dedicated server account to a shared hosting account.

What we have done so far

We took a MySQL dump, GZip’d entire directory, ftp’d to new hosting account, created new DB, imported MySQL dump, Gunzip’d directory structure.
[Edit: set permissions on G’unzip directory and files.]

Logged into account on “NEW” server, pointed every “old.domain.com” to “new.domain.com” changed all internal references from “old.domain.com” to “new.domain.com” added “

to config.php to allow us to log into backend on new server.

Set “Output and debugging” to ALL on.

Issues we are experiencing

1. We use the MSM to differentiate between primary content and secondary content. We cannot switch to “site 2”.

2. We can not get template or DB debug info to display outwith our control panel (works in control panel, doesnt on templates).

3. Some registered users have an issue where they have 4Bn+ unread messages (thats billions).

4. An issue with a specific 3rd party extension. Not your concern, just listed for completeness.

5. Unable to remove config.php addition after changing all internal and external references to domains.

Ideas, suggestions and further reading most welcome.

Logged into account on “NEW” server, pointed every “old.domain.com” to “new.domain.com” changed all internal references from “old.domain.com” to “new.domain.com” added “

How did you make the changes? Did you do any sort of direct manipulation of the database?

I used :

http://www.hopstudios.com/software/deeploy_helper/

then manually changed the very few bits it missed. DeePloyhelper is great btw

I did not use, change or manipulate the database directly.

What extensions do you have on this site?

Shee’s lots :

5. Unable to remove config.php addition after changing all internal and external references to domains.

Is the config.php writable? Keep in mind that if you make changes to the config.php file, it will override what you do in the control panel. Which addition is it?

Ok, that was very badly worded on my part, sorry.

After I change config.php and put the session info thing in, I can log in. After I CHANGE ALL and log out, i cannot log back in under any account.

What changes are you making in the CP before logging out that cause logging back in to fail? You shouldn’t need to force ‘admin_session_type’ in config.php under normal circumstances, so try removing that.

Some Follow up after a weekend away from the machine:

We have managed to resolve 3.5 of our 5 primary issues after some time away from the problem and a fresh pair of eyes.

Issues 1,2 and 5 are resolved. We had hard coded the “old.domain.com” in a few places, once we (in this case I mean I) had remembered that, a change or two later we have MSM function, template and sql debug and config issues resolved.
This was purely my fault for not documenting the changes and additions I made 2 years ago properly. I apologize for issuing a support request in this instance, purely my fault.

Issue 3: Some users have a HUGE unread PM count - still there, is there anyway these numbers can be recounted?

Issue 4: We have tracked this to the imgsizer plugin by Lumis. I believe that the plugin itself is functioning correctly as it is creating the correct ‘cache’ directories, but as a limitation of the hosting account cannot create the required cache files, or on the occasions that it does, these files are set with file permissions making the files non-readable.
Having run through the EE requirements Wizard a few times we are getting a clean bill of health to install and run EE (1.6.8).
While this is not an EE support issue, are you aware of any issues or Knowledge Base articles that may point me in the correct direction regarding shared hosting accounts.

FB.

Hi FB,

Regarding Issue 3: We have seen this before, and I believe more recent versions have some additional checks to prevent this (I realize you can’t upgrade to 1.6.9 yet). In the meantime, I think the only sure fix is to log in as each affected user and delete their PMs.  Once that’s done, take a look at the exp_members table, and for each of those users set their ‘private_messages’ value to 0.

Regarding Issue 4: I’m not aware of any articles on this, unfortunately.  It’s possible the plugin could be altered to create its files with more appropriate permissions for your host, but we can’t support it, I’m afraid.

thank you for your help Brandon, we are confident that you can close this thread.

fb.

Please thank Sue, and everyone else that helped out.

Not a problem, and don’t hesitate with further questions.