Rename sites (provision/backend)

I don't think I understand what you mean here. What are the steps necessary to recreate the bug? What behavior were you expecting?

I guess you mean that we can't rename a site, but I wouldn't expect that as a feature just yet.

You can now however alias sites.

I added a 'deploy' command, which allows you to deploy a backup of a site under a new url.

it also handles the files directory changes.

there's no 'rename' command per se tho, but i imagine it will be a slight differentiation on the existing 'migrate' command

We are going to have problems with uploaded files when renaming (or cloning) sites. Maybe we need to abstract that away right now?

Should we have a rewrite rule like this?

RewriteRule /files/ /sites/%{HTTP_HOST}/files/

That would save us a lot of trouble... I'm not sure, however, that Drupal can handle a different frontend and backend path...

The files issue is a separate one: #275022: When moving or aliasing sites, permanently redirect sites/somesite.com/files to sites/$site_url/files..

The only thing missing here is probably a "rename" command that wraps around all this stuff (backup + deploy, whereas deploy fixes files urls).

One of the things I have tried in the past (which works) is use a generic name under my sites folder and then use a symbolic links for domain paths. That would allow you to have the same site deployed across multiple platforms under different domains (e.g. dev/staging/productions) but always keep the file paths the same. The idea is that the site name would be unique in aegir and every platform that had a site folder with that specific unique name could be linked back to the one site object in aegir. That would force every site to have a name that should never change, but you could change the domains easily.

Is that something that could be explored here:

e.g.

Site name: example (a unique site name, but can exist in multiple platforms)
Domain name: example.com (unique across all sites and platforms)

Platform 1:
/sites
  /example
  /example.com -> example

Platform 2 (maybe this i a staging platform):
/sites
  /example
  /staging.example.com -> example

When you looked in aegir at the site "example" it would show versions of itself under each platform.
1. Platform 1 at the url - example.com
2. Platform 2 at the url - staging.example.com

The settings.php should also be updated to always use the file path:
sites/{site_name}/files (rather then the current domain name)

This also has a side effect of often smaller/cleaner urls for file paths (particularly subdomains):
e.g.
http://staging.example.com/sites/example/files/download.pdf
instead of
http://staging.example.com/sites/staging.example.com/files/download.pdf

Site name: example (a unique site name, but can exist in multiple platforms)

see that's already a problem: what happens when you migrate to a platform where that name already exists?

i think we should stick with the unique name (the domain name) for storage. we can update the body and the files table on deploy, the only issue is the external links.

let's take the files issue to #275022: When moving or aliasing sites, permanently redirect sites/somesite.com/files to sites/$site_url/files. (since they also apply to clone) and keep this related to the actual rename stuff.

First off I should define the terms I am using:

site

a project for one client/user in the system, we may want to launch multiple versions of their website for testing/staging changes

website

one instance of the site at a particular domain

The idea here is that "site name" would have to be unique (aegir would need to check that it is a unique name before creating or importing a sites, just like it checks that the domain name is unique).

If you are trying to migrate a website to a platform where the site name already exists it wouldn't be a migration it would be a replacement. As the existence of the same named website would mean it is the same site (just a different versions of the site e.g. testing/production). The only way you would get another version of a site under a different platform would be via a 'clone' operation, creating or importing sites would not allow this to happen. Clone could then provide two outcomes:

1. an exact clone of the same website to a different platform for test or staging a new version of the same site for later migration
2. create a new site based on the current website - this would be a permanent fork of that website for a different site

Replacement is a perfectly valid operation, as there are cases where you want to test out features, show them to a client on a non live version of their website and then when they approve the change migrate (replace) the website for real.

What you get with this solution:

• a unique name for sites (in this context a site is not a website, but rather potentially a collection of websites of the same site at different code versions of itself)
• a simple process to change the domain name of a website (as it just requires a new symbolic link)
• changing domain names doesn't break anything related to the website like the file paths as they never depended on the domain name to start with (I have read the other issue, this solution provides a solution to both these problems, so I think it is worth mentioning here with this issue)

Also this site name doesn't have to be something the users creates themselves, it could easily be created by aegir, e.g. it could just be a node_id

I don't see a lot of reasons to having the same website running on the same platform, normally when you are testing out new features they are related to code changes and therefore a new platform.

So I *think* I agree with you, but what you are really talking about here is clone, not rename, so see #448692: site clone support for that. I will answer in that other issue.

This shouldn't delete the node and recreate it on the front end.

it should just set the $node->title of the node.