K, so all I wanna do is move my existing site from d1.com to d2.com, both of which I easily access through cPanel.

So using phpMyAdmin, I download the database, and using File Manager I download the public_html directory. Then I upload those two "things" to the new domain (d2.com). I've done this a thousand times, so no prob.

So now here's my checklist:

  1. Make sure that .htaccess got transferred, because certain settings sometimes cause it to get lost.
  2. Edit settings.php so that
  • the database and user are correct,
  • the BaseURL (if used) is correct
  •  

Please help me complete this list. There are some directory entries in there with pretty weird paths (which I cannot recognize as being in existence), and there's a hash salt thing which I'm not sure what to do with.

Any ideas?

 

Most helpful answers

Please help me complete this list. There are some directory entries in there with pretty weird paths (which I cannot recognize as being in existence), and there's a hash salt thing which I'm not sure what to do with.

Things to usually check are the file system paths on /admin/config/media/file-system (tmp, public, private). They may be the same, but possibly they're not.

Another thing to check are the "Trusted Host Settings" in settings.php.

Update: the hash salt can be left as-is.

Comments

  • Make sure that .htaccess got transferred, because certain settings sometimes cause it to get lost.
  • Edit settings.php so that the:
    • Database name and password are correct
    • The BaseURL (if used) is correct
    • Make sure the path for the config directory is correct
  • Make sure that the files directory and config directories are in the expected locations - and that the hash in the config directory name matches the one in settings.php
  • Make sure that your domain is pointing at the correct directory
  • Check the permissions on you files and directories to make sure they match the old site. 

If have tried these things and are still having difficulties, please share some details and/or error messages and we'll try to help you trouble shoot them.

I break my sites down in my head into four components:

  1. Code base
  2. Database
  3. Files directory
  4. Config directories

In a default site, the config directory is in the files directory, so you might not need to treat them separately. But, some sites place the config directory outside of Backdrop root, which then requires that it be treated separately and that you take additional care. 

  • Make sure that the files directory and config directories are in the expected locations - and that the hash in the config directory name matches the one in settings.php

Okay, this one is the puzzler. The settings.php file shows these directories with mile-long goofy names that are nowhere to be found, AFAIK.

And please explain about the hash.

Thanks!

When your site get's set up, Backdrop CMS generates a long random hash that is uses as part of the directory name for your config. This is a security measure to make it more difficult for a hacker to guess the exact location of your config files. 

Here is how the settings.php file appears for a sample site I just set up. the config directory "config_f9883598c96c0953f54e4685b215f28f" is expected to be found in the files directory, which is expected to be in Backdrop CMS root directory. 

Here you can see the actual config directory, which is inside the files directory as expected. The name and location of your config directory MUST match what is in the settings.php.

If you found the configuration for this in the settings.php, but can not find the actual directory with the same name, then you have identified a problem.

Some sites put the config directory outside of Backdrop root, in a sub-directory. I would not expect this on shared hosting, but it is possible.

Does this help?

@stpaultim:

Yes, this is very helpful. Thank you for the explanation. I shall now go looking for my config directory... Perhaps I was just in hurry-up mode before, when I looked and couldn't find it. (My knee-jerk assumption was that since I had compressed and downloaded the entire public_html tree, then it should have uploaded and extracted, if it actually existed...). But it seems like I Iooked and didn't see it.

Anyway, although everything about this site is default AFAIK, I would be surprised to see it outside (e.g., above) public_html. If, however, that is the case, then that would perfectly explain my experience. 

Another couple of questions:

  • Is there anything inside the config directory which is domain-specific, which would require manual editing after migration?
  • What's the difference between the /active directory and the /staging directory?

I'll report back later with my findings... 

@ericfoy

I'm also curious why you didn't get the config files when you took the entire html directory, I also would have expected them to be there. BUT, it's not certain. So, good luck.

I'm pretty sure that there is not anything domain specific in the config files, under normal circumstances. BUT, it can't be ruled out 100%. In theory, config management is specifically for moving config between environments - so there should not be anything there that would break when moving your site.

Your staging directory is only used if you are importing config through the user interface. You should not need to worry about this, if you put the active config from your old site into the correct place on the new site.

This page might be useful:

https://docs.backdropcms.org/documentation/working-with-configuration

Okay, I'm starting to catch on. But one more question: 

  • What is the purpose of putting the config files and folders outside the /files directory? Is it just to get them out from under the public umbrella?

BTW: having looked closer, I have discovered that the config folders do, in fact, exist on my new domain, so I will be redoing my migration, starting over from the beginning. I suspect that whatever problem I was experiencing must have had some other cause, and since I have screwed around with a number of things, I'm just gonna start over, being more careful and more analytical with my approach. I shall document my procedures for everyone's benefit... 

> I'm just gonna start over, being more careful and more analytical with my approach.

Yes, sometimes this is what it takes. Hopefully, this time it goes better. 

> What is the purpose of putting the config files and folders outside the /files directory? Is it just to get them out from under the public umbrella?

I'm not an expert on this, I've heard it recommended as being even more secure, although I have not heard that sites that do not do this have had any problems. 

The files directory is easier to access, because some files must be accessible to the browser. I believe that the thinking is, that the browser never needs to access config files, so if you have complete control over your file structure, WHY NOT (for security reasons) move them outside of Backdrop root where they are less accessible. 

Since my company manages our own server, we've adopted this practice, just because we can. But, I dont' think there is any reason why anyone should worry if they have their config files in the files directory and are using the hash code (in the directory name) to hide them.

Here is an example of a slightly more complicated file structure used by some developers with the config files outside of root. 

- .git
- .gitignore
- config
- - active
- - staging
- documents
- - backup and migrate
- - - scheduled backups
- - - manual backups
- - private files
- html (backdrop root directory)
- - index.html
- - core/

Again, in my opinion, this kind of file structure is not necessary or required for most sites. 

If anyone else has anything to add or correct in my explanation, I welcome additional thoughts on this topic.

indigoxela's picture

Please help me complete this list. There are some directory entries in there with pretty weird paths (which I cannot recognize as being in existence), and there's a hash salt thing which I'm not sure what to do with.

Things to usually check are the file system paths on /admin/config/media/file-system (tmp, public, private). They may be the same, but possibly they're not.

Another thing to check are the "Trusted Host Settings" in settings.php.

Update: the hash salt can be left as-is.

Final Update:

I re-migrated, starting over from scratch.

Everything went swimmingly. I don't know what happened the first time around, but everything appears to work just fine now.

The guidance given in the various comments above will continue to be very helpful, so Thank You all for the information and assistance!