Am i right in assuming that this means that even if the processes are followed, scanning enabled and questionaires filled in, that PCI Compliance cannot be achieved with Community Edition when payments are being processed on the server?

Overview

There are a number of reasons you might want to change the domain name that Magento runs under.  The most common reason being in moving from a development domain to a live domain, but thats not the only reason, may people find it a lot less painful to convert an existing (working!) Magento to a completely different setup and product range rather than starting from scratch.

Complexity

Easy.

Suitable for:

Shared Hosting
VPS Hosting
Dedicated Hosting

Basically this guide works for any Plesk and Magento setup.

Requirements

Access to your Hosting Control Panel.
The ability to update DNS or nameservers on the new domain so it points correctly.

Howto :

As ever Nublue recommends that you backup your entire site using your Hosting Control Panel backup utility before undertaking any significant changes to your site.  We regard changing the underlying domain of your site to be a very significant undertaking

1) Ensure you have backed up your site in your Hosting Control Panel.  This method is robust and we have been using it for several years, but failure to follow it fully can have far reaching implications.

2) For Magento 1.4 Users Only : Ensure that System -> Configuration -> Web -> Redirect to Base URL if requested URL doesn't match it is switched off during these changes.  It shouldn't make a difference but I have a pathological fear of it as a "feature", its fine to turn it back on once the work is completed.

3) Change the domain within the Hosting Control Panel using the Domain Administrator button (Login -> Home -> your_domain.com -> Domain Administrator).  Simply edit the very first text box deleting the old domain and adding the new domain (without www.).  Ensure that the www is ticked if required.  Click OK at the bottom of the page (all other options on the Domain Administrator page should be left as-is).

4) We now need to change the base URLs within the Magento database through PHPMyAdmin (To get to PHPMyAdmin : Login -> Home -> new_domain_name.com -> Databases -> Database_name -> DB WebAdmin).

5) Once PHPMyAdmin has loaded (it opens within a separate browser tab/window) click on the table "core_config_data" in the left hand sidebar to open it up in the main frame (Note it might be that the table is prefixed with, either way the listing is alphabetically sorted).

6) Click on Search and for the form section that says path select the LIKE %...% option, then enter "secure" into the text box for path and click on the Go button.

7) For all the entries returned that contain the URL for the old domain name you need to edit each one and update the details to reflect the new domain URL (you must ensure you maintain the preceding http:// or https:// and any / or directory names on the end of each specific entry).  You can edit each entry by clicking on the appropriate pencil icon, making the change and saving.  For convenience I open each entry that requires editing into a new window and then work my way through each one saving as I go.

8) Clear the Magento cache using the Clear Magento Cache button in the Hosting Control Panel.

Thats it, assuming that DNS is correct for the new domain it should load fine when entering the new domain name in your browser.

Possible Issues :

The two most likely errors are typos when updating the URLs and failing to reset the cache.  Using the phpMyAdmin search facility check all the base URL entries with absolute URLs in them are spelled correctly (and have the preceding and following http(s):// and / respectively).

Reversing the Change

Just follow the guide but swap round old domain and new domain.

Other Options

This is the way that we change the underlying domain for Magento.  The primary benefit for us in this method is that we don't need Magento admin panel access to do it. You could change the baseURLs from within Magento's admin panel at Step 2 (System -> Configuration -> Web -> Unsecure and Secure Base URLs) and then skip Steps 4 to 7 but as soon as you Save the configuration your Magento store will break till Step 8 is completed.  We've not done this often so we can't vouch for how reliable a method it is.

Looking at this blog post http://www.blastedthing.com/magento/que … to-faster/

I tend to skip anything that talks about installing modules as from experience, modules are never kept current wtih magento versions and you just end up with more hassle than worth. really all I did was the Gzip compression.

So from that post I did step #2 Gzip compression, around line 74 in the .htaccess for magento's root

Mine now looks like this, and I have a saving of around 80% according to this compression test tool http://www.whatsmyip.org/http_compression/

<IfModule mod_deflate.c>
 
    AddOutputFilterByType DEFLATE text/html text/plain text/xml text/css text/javascript
    AddOutputFilterByType DEFLATE application/xml application/xhtml+xml application/rss+xml
    AddOutputFilterByType DEFLATE application/javascript application/x-javascript
    AddOutputFilterByType DEFLATE application/x-httpd-php
 
    BrowserMatch ^Mozilla/4 gzip-only-text/html
    BrowserMatch ^Mozilla/4\.0[678] no-gzip
    BrowserMatch \bMSI[E] !no-gzip !gzip-only-text/html
 
    SetEnvIfNoCase Request_URI \.(?:gif|jpe?g|png)$ no-gzip dont-vary
    SetEnvIfNoCase Request_URI \.(?:exe|t?gz|zip|bz2|sit|rar)$ no-gzip dont-vary
    SetEnvIfNoCase Request_URI \.(?:pdf|doc)$ no-gzip dont-vary
    SetEnvIfNoCase Request_URI \.(?:avi|mov|mp3|mp4|rm)$ no-gzip dont-vary
 
</IfModule>

Step #3 is something I think NuBlue would have to carry out, if they havn't already. If they have I would like to know which is installed, Xcache, APC or another?

If none are installed.. Can it be looked into?

So to reiterate all I did was the Gzip compression, id like to speed up magento further.

Google's webmaster tools shows "On average, pages in your site take 2.7 seconds to load (updated on Mar 29, 2010). This is faster than 54% of sites"

Now 2.7 is faster than 54% of sites but id be interested to see if Magento can be squeezed in to the 1-2 seconds bracket?

Overview

Gzip compression is a quick and simple method of speeding up page load times for visitors to your site.  Its very simple, rather than send the browser a 100k file with the html (or css or javascript) for a page its quicker to compress the page on the server, send the compressed data, then have the browser uncompress it.  Trust me it is, even with broadband connections it is still expensive in terms of resources to transmit data to the end user.

There is an overhead involved with compressing data on the fly, it increases the cpu load on the server (or vps), however in almost all cases there is spare CPU capacity, whereas in many cases for our VPS customers bandwidth is at a premium (so two reasons to do this!)

Complexity

Easy.

Suitable for:

Any VPS!

Although its possible that this will conflict the Fooman Speedster for Magento as everything else does.

Requirements

Administrator Access to your Hosting Control Panel, we're going to use the File Manager within the Virtuozzo Power Panel to make the changes.
Alternatively these changes could be made with root shell access.

Howto :

We are going to add an Apache Web Server configuration file to the VPS, this means we have to edit files as root and restart Apache.  If the file is not edited correctly then Apache will not restart.  To fix this you will only need to remove the file and restart Apache again.  We recommend you follow the instructions carefully to prevent this happening.

1) In contrast to the shared hosting guide (See the Shared Hosting forum) we don't really care whether your site is currently using compression or not, as we are going to make the configuration change at a higher level, thereby applying gzip compression to every site on the VPS and also speeding up the compression process (albeit only by a few milliseconds per file).

2) In your Hosting Control Panel navigate to the Virtuozzo File Manager (Login (as administrator) -> Virtuozzo Side Bar Option -> File Manager).

2.1) Navigate to /etc/httpd/conf.d/ by clicking on each directory in turn.

2.2) Once there, click on the Create File option.

2.3) Create a file named mod_deflate.conf and with the following content :

<IfModule mod_deflate.c>
AddOutputFilterByType DEFLATE text/html 
AddOutputFilterByType DEFLATE text/plain 
AddOutputFilterByType DEFLATE text/xml 
AddOutputFilterByType DEFLATE text/css 
AddOutputFilterByType DEFLATE text/javascript 
AddOutputFilterByType DEFLATE application/x-javascript
</IfModule>

2.3) Click on Create to save the file. NOTE The file must end with .conf as that is how the Apache Web Server identifies its configuration files.

3) Now navigate back into the main section of the Hosting Control Panel to the Service Management page (Server Sidebar Option -> Service Management)

3.1) Restart the Apache Web Server (Click on the far right hand orange button on the Web Server (Apache) row)

4) Wait a few moments then test your sites are all working.  Then test for gzip compression here

Possible Issues :

If all your sites stop working then its most likely a typing error or extra digits in the mod_deflate.conf file that we created.  Return to the Virtuozzo File Manager and using the pencil icon on the mod_deflate.conf row edit and check the file.  If you can't see any errors then save the file and simply delete it.  Then restart Apache again.

If not all your sites are affected then try renaming the .htaccess file for the site not working to see if that resolves the issue.  If it does there are overlapping or conflicting compression rules in the .htaccess and by judicious editing of the .htaccess you should be able to resolve the problem.

Failing that, its likely you have a site that is based on some very old web application software and you'll have to revert back.  You can however follow the shared hosting version of this guide that utilises the .htaccess on a per site basis to provide gzip compression.

Reversing the Change

Delete the /etc/httpd/conf.d/mod_deflate.conf file and restart your Apache Web Server.

Further Reading

This article does a very good job of explaining how gzip compression works and also links out to other useful articles.

Overview

Gzip compression is a quick and simple method of speeding up page load times for visitors to your site.  Its very simple, rather than send the browser a 100k file with the html (or css or javascript) for a page its quicker to compress the page on the server, send the compressed data, then have the browser uncompress it.  Trust me it is, even with broadband connections it is still expensive in terms of resources to transmit data to the end user.

There is an overhead involved with compressing data on the fly, it increases the cpu load on the server (or vps), however I can say with some authority that cpu overhead is not currently an issue for any of our servers nor for any of our VPS customers, so the slack is there to be picked up and used to improve page loading times.

Complexity

Easy (Though it does have the potential to break your site if things go wrong its very easy to revert back)

Suitable for:

Shared Hosting - Almost any site, with the possible exception of Interspire sites as its already there!
(For VPS and Dedicated hosting there is a slightly different method that is much more efficient, see here)

Although its possible that this will conflict the Fooman Speedster for Magento as everything else does.

Requirements

Access to your Hosting Control Panel.
Alternatively FTP Access to your site and an FTP Client that allows you to view files starting with . (or hidden files as they're sometimes called).  We recommend the Filezilla FTP client.

Howto :

As ever Nublue recommends that you backup your entire site using your Hosting Control Panel backup utility before undertaking any significant changes to your site.  In this instance we're only going to edit one file, so if you're feeling confident you could just make sure you have a copy of your current .htaccess file (if it exists) that you can revert back to if things go awry.

1) Check whether your site is already gzip compression or not.  Entering your home page at this site will tell you whether your html files are being compressed.  You should also examine your page source and extract a URL for a css or javascript file and check whether these types of files are being compressed.  If your pages are already being compressed it may be worth continuing anyway as there are two methods of compression (Apache based and PHP based, the Apache method is more efficient and its worth swapping if you're currently using the PHP method).  If your data is not being compressed then we know what we need to do.

2) In your Hosting Control Panel navigate to your web root in File Manager (Login -> Home -> your_domain_name.com -> File Manager -> httpdocs).  Here look for a file named .htaccess(You may need to click the All on the right to stop pagination).  If the file doesn't exist then you can jump straight to Step 3.  If it does exist then now is a good time to make a copy of the .htaccess file.

2.1) Select your .htaccess file, then click on the Copy/Move option :

2.2) Choose a name for the copy of your .htaccess (I've chosen .htaccess_bk) and append it to directory path already in the textbox (/httpdocs/). Click the Copy button.  You now have a backup of your .htaccess file.

2.3) Now open the file for editing : Click the pencil icon in the middle of the .htaccess row.

2.4) Check for the following words, these are all indications that compression is setup, you have the choice here of leaving as is, or commenting out the existing lines and replacing them with the code in Step 4 to see if there's an improvement:
AddOutputFilterByType
SetOutputFilter
php_flag zlib.output_compression on
<IfModule mod_deflate.c>
Pay close attention to whether these rules are active (for example a default Magento .htaccess file contains all these entries, but all of them are commented out or inactive).

3) Creating a .htaccess file : To create a new .htaccess file click on Add New File.

3.1) In the dialogue boxes set Create New File to selected, enter the filename .htaccess and ensure Use html template is unticked then click OK.  This will create the file and automatically open it for editing.

4) If the file already exists the append the following code to the bottom of the file (For new files simply paste the code in) :

<IfModule mod_deflate.c>
AddOutputFilterByType DEFLATE text/html 
AddOutputFilterByType DEFLATE text/plain 
AddOutputFilterByType DEFLATE text/xml 
AddOutputFilterByType DEFLATE text/css 
AddOutputFilterByType DEFLATE text/javascript 
AddOutputFilterByType DEFLATE application/x-javascript
</IfModule>

Then save the file with the default settings (UTF-8 and convert to Unix style).

Thats it, now test your site again at Gzip compression testing site mentioned at the start of the article.

Possible Issues :

If all your pages stop working then it will be one of three things:
1) A typo : Recheck your .htaccess file (its still open for editing), try removing and readding the code.
2) A conflict : Some web apps may use per page PHP code to compress their pages and these could conflict with the configuration changes we've made to the .htaccess.  Remove the code we added.

Reversing the Change

Delete the newly created/edited .htaccess : Select the file then press Remove Selected and Confirm.
Rename your .htaccess_bk (you did make one right?) using the frankly bizarre File Rename that sits alongside the pencil icon.
Or restore from your backup.

Further Reading

This article does a very good job of explaining how gzip compression works and also links out to other useful articles.

One method of previewing/developing a site that is not live (ie you're developing it on our server under its correct domain name, but the A record or nameservers point to a live site hosted elsewhere) is to edit your hosts file to bypass DNS and force your local machine to look for a domain on our hosting.

To do this you need to know your domain name, the IP address we're hosting it on (You can find this information in your Hosting Control Panel under Setup), and you'll need to have administrator privileges on your computer.

On Windows XP the hosts file is located within here : windows\system32\drivers\etc\hosts  .  The windows directory is most likely located on your C: drive, but if your computer setup differs from the norm it could be located elsewhere.

Navigate to this file in Windows Explorer, if you find you can't view any of the listed directories you will need to enable Hidden Program or System Files (See guide here.  Once located right click and choose to edit the file in Notepad.

Append to the bottom of the file the following 2 lines, replacing IP_ADDRESS with the IP Address you took from the Hosting Control Panel and DOMAIN_NAME with your domain :

IP_ADDRESS    DOMAIN_NAME
IP_ADDRESS    www.DOMAIN_NAME

Here's an example using my domain name and using my correct IP address :

92.63.138.66    pagrant.co.uk
92.63.138.66    www.pagrant.co.uk

Save the file and you're done (If you can't save the file then you won't have administrator privileges and you'll need to login as an administrator account).  To test ping your domain and it should return the IP address you entered in the hosts file, not the live IP address.

To reverse, simply delete the two lines, save, flush your dns (ipconfig /flushdns in a command prompt) and retest using ping.

Step 1 : Configuring Magento

You can use this  guide for an explanation of how multiple stores work and can be configured within the Magento admin panel.  You should create your multiple websites/stores first here as you will need these settings when you are configuring the passthrough index.php in your webspace.

Step 2 : Configuring Plesk

To enable a multistore setup within Plesk you specifically need to relax OpenBaseDir restrictions to allow different domains on the server to talk to each other.  This can only be done by the use of custom configuration files within your Plesk domain configuration, and you can only write custom configuration files as root.

Once you have become the root user you should navigate to the following directory of your first "child" store :

cd /var/www/vhosts/CHILD_DOMAIN_NAME/conf

If you check the contents of this directory you will find a file named httpd.include, this is the configuration file for the domain and should not be touched as Plesk will frequently rebuild and rewrite this file.

We are going to create two files, both with identical content, the first file covers http requests, the second https (encrypted) requests.

The first file to be created is vhost.conf, and to create it using vim you would type :

vim /var/www/vhosts/CHILD_DOMAIN_NAME/conf/vhost.conf

The following data (adjusted for your particular configuration) should be inserted into the text editor (To start typing in Vim simply press "a", then everything you type will pushed to the screen).  You should type this data manually rather than pasting as all lines and line breaks should remain intact, and this will not happen if the data is pasted.  Please note that there are only three lines.

<Directory /var/www/vhosts/CHILD_DOMAIN_NAME/httpdocs>
php_admin_value open_basedir "/var/www/vhosts/CHILD_DOMAIN_NAME/httpdocs:/var/www/vhosts/PARENT_DOMAIN_NAME/httpdocs:/tmp"
</Directory>

Once you have entered this data you can save and exit from Vim with the following command sequence : ESC : w q RETURN (Escape Key, Colon, w, q and then return)

You should then repeat the above process for the SSL configuration file :

vim /var/www/vhosts/CHILD_DOMAIN_NAME/conf/vhost_ssl.conf

After the two files have been created its necessary to alert Plesk to the presence of these files, you can do this by running the following command :

/usr/local/psa/admin/bin/websrvmng -a -v

If you receive any error after running this command you should delete the two files created, then rerun the command.  If you still receive errors you should contact support immediately as its possible that your web server will no longer be running

Assuming you received no errors you should continue.

Step 3 : Adding a passthrough index.php to the child domain

The following file (index.php) needs to be reconfigured to your needs and added to the web root of the child domain :

$mageFilename = '/var/www/vhosts/PARENT_DOMAIN/httpdocs/app/Mage.php';

if (!file_exists($mageFilename)) {
    if (is_dir('downloader')) {
        header("Location: downloader");
    } else {
        echo $mageFilename." was not found";
    }
    exit;
}

require_once $mageFilename;

umask(0);
Mage::run('STORE/WEBSITE_CODE', 'TYPE');

This file can be edited in your usual editor and uploaded to the web root, created via the Plesk File Manager or you can even create it using Vim!

You should now be able to navigate to the child domain and view the appropriate Magento storefront that was configured on the parent domain.

Major new features include, Address Book  featuring Vcard support, photo thumbnails, an improved contact grouping system  and recurrence ability in the Calendar for repeat events.

The redesigned and streamlined interface not only provides a smoother and more responsive user experience but it is also simpler to use and more polished.

New Features:

• Intuitive Drag and Drop support for emails and contacts

• PDF thumbnail support for attachments

• vCard support for your Address book

• Full SSL encryption throughout  for your security and reassurance

• Complete recode using the Zend framework allowing us to easily extend the webmail with useful additional features (we have several exciting add-ons planned already!)

• Greatly improved webmail performance

• Calendar now has recurring event functionality (daily, weekly, monthly, yearly) – Publish recurring events in webmail, and push these to your iPhone

Don’t take our word for it, start using today…

We recommend all existing customers to upgrade to the new webmail today – follow this link to log in to your https://www.nublue.co.uk/web-hosting/login/webmail now! Our old legacy webmail is still accessible via the link under the new login box.

In case you missed it here is this months addition of our hosting Newsletter;
http://bit.ly/NuBlueNews

This issue includes the launch of our exciting iPad giveaway, NuBlue website news and our monthy hosting tip - 'how to speed up Magento with Parellell connections'.

Hope you enjoy!

Cheers

The Nublue Team

If you would like to recieve our monthly newsletter by email please go to http://www.nublue.co.uk/ and submit your email address.

Overview

You can speed up your loading times on unencrypted pages of your Magento store by utilising parallel connections.  Most browsers are limited to making only a small number of connections to a domain in parallel, by fooling the browser into thinking its loading objects from several domains on one page it will increase the number of concurrent connections to the server.

Note : This only works on unencrypted pages, for pages on your store that use SSL encryption this would be counter productive as it would produce unauthenticated content.

Complexity

Easy

Suitable for:

Shared Hosting
VPS Hosting
Dedicated Hosting

Requirements

1) Access to your Magento Administrator Panel
2) Access to your Hosting Control Panel
3) Your site's nameservers are assumed to be with us
4) You are not using the Fooman Speedster extension, as it doesn't seem to honour Magento base URLs (Please be aware that the Fooman Speedster has issues if you try to disable it : See here

Howto :

(As ever Nublue recommends that you backup your Magento store using your Hosting Control Panel backup utility before undertaking any configuration changes on Magento)
1) Login to your Hosting Control Panel
2) Navigate to your Magento domain
3) Click on Domain Aliases

4) Add the following domains using the image as a guide replacing domain_name.com with your domain.  See the note below if you don't have a Add New Domain Alias button :

css.domain_name.com
js.domain_name.com
media.domain_name.com

5) Test the aliases are working by navigating in a browser to the domain aliases you've created.  You will either see your store on that URL or it will forward to the URL of your store.  So long as you see your store in the end its working!
6) Now login to your Magento Admin Panel
7) Navigate to System -> Configuration
7a) For Magento multistore configurations only : Choose your configuration scope using the dropdown.
8) Choose the Web option on the left navigation bar
9) Ensure you are only looking at Unsecure Base URLs
10) Change the following replacing your_domain.com with your domain, and ensuring you replicate all trailing forward slashes (use the image below as a guide) :
Base Skin URL         Use : http://css.your_domain.com/skin/   
Base Media URL         Use : http://media.your_domain.com/media/
Base JavaScript URL      Use : http://js.your_domain.com/js/
DO NOT make any changes to Base Media URL and Base Link URL.

10a) For Magento multistore configurations only : Untick "Use Default"
11) Save your configuration changes.
12) Refresh your Magento cache (either using our Control Panel option or using the Magento Admin panel Cache refresh option.
13) You can test the results here :
http://www.nubluemagento.co.uk/ (With parallel connections)
http://furniture.nubluemagento.co.uk/ (Without parallel connections)
This is a multistore setup with one store view using parallel connections and one store view not using them.
You can also test using the Firefox extension Firebug, open up the Net tab and load the above pages to see the parallel connections in action.

Please note : Not all web based page load speed tests replicate browser behaviour, so its quite possible and quite probable that they will show no change across the two sites.

Possible Issues :

Some older customers may not have access to the Domain Aliases or Add New Domain Alias functions in their Control Panel, if that is the case simply email in to us at support and we'll get your permissions updated.

Reversing the Change

Should you wish to reverse the settings, here's what a vanilla Magento configuration looks like :

[Edited 04/06/2010 to add warning regarding disabling Fooman Speedster module]

Ive been looking into getting hosting recently as I need a package that will let me host several small domains without having to worry too much about spreading them out across different control systems. Which is something you guys seem to offer beyond the normal 3 domain limit I've been running into elsewhere.

What I was wondering is if one of the sites starts seeing a heavy amount of hits, how difficult is it to upgrade my hosting package ?

Also will we get plenty of warnings before our sites are taken down for passing allocated bandwidth ? Or will we just be presented with the news after the fact ?

Any advise would be appreciated.

Thanks

Just started working on a new project and hoping you can give me some helpful critique on it.

http://www.buymovesell.com

Its pretty brand new, runs off the vBulletin Publishing Suite, (which isnt that great as a CMS it turns out! More of an article suite!)

Anyway, I've moved so many times in the last 2 years I thought id start putting down some questions and answers in the forms of articles to what Ive been asking myself each time I've moved.

In the last two years ive gone through arranging mortgages, renting houses, moving all my stuff between houses, putting things in storage, selling our house and even emigrating (the families' whose house we're renting emigrated to Australia)

Anyway, look forward to some feed back.. though not sure how active you all are on this forum

Please note we do not accept any responsibility for any unintended consequence of following or failing to follow these instructions.  These instructions if followed correctly will duplicate your current Magento store without harming it in any way.  However failure to follow these instructions correctly could result in significant harm to your live install.  If you are not confident following these instructions then you should not undertake this HowTo. 

We offer this as a professional service - if you wish for us to undertake this duplication please contact us via the usual support channels.

Requirements :

Your live site should be fully backed up before attempting this
DNS is pointing at the VPS
Shell access
Magento is in web root. If the Magento install is not in web root then you will need to add the subdirectory to all the file paths.

Step 1 : Create the domain in Plesk

Create New Domain of the format : dev.domain_name.com where your live domain is www.domain_name.com
Add a database
Make a note of all login details.
(Further information if required)

Step 2 : Access the shell

Ensure /bin/bash shell access is enabled in your Hosting Account (Setup -> Shell access to server with FTP user's credentials - /bin/bash)
Access your VPS using Putty logging in as the new domain user.

Step 3 : Duplicate files

Shell Commands :

You will need to replace DEV.DOMAIN_NAME.COM and DOMAIN_NAME.COM as appropriate.

cd /var/www/vhosts/DEV.DOMAIN_NAME.COM/httpdocs/
cp -r /var/www/vhosts/DOMAIN_NAME.COM/httpdocs/* /var/www/vhosts/DOMAIN_NAME.COM/httpdocs/.ht* /var/www/vhosts/DEV.DOMAIN_NAME.COM/httpdocs/ 
chown -R DEV_FTP_USERNAME:psacln /var/www/vhosts/DEV.DOMAIN_NAME.COM/httpdocs/* /var/www/vhosts/DEV.DOMAIN_NAME.COM/httpdocs/.ht* 

(Ignore any errors relating to plesk-stat or var/cache/mage...).

Step 4 : Duplicate Database

Shell Commands :

Dump a copy of the live database

cd /var/www/vhosts/DEV.DOMAIN_NAME.COM/private/
mysqldump -u LIVE_DB_USERNAME -pLIVE_DB_PASSWORD LIVE_DB_NAME > LIVE_DB_NAME.sql

Import it into the new dev database

mysql -u DEV_DB_USER -pDEV_DB_PASSWORD DEV_DB_NAME < LIVE_DB_NAME.sql
rm LIVE_DB_NAME.sql

Step 5 : Point dev domain at duplicated database and update base URLs

Edit file : /var/www/vhosts/dev.domain_name.com/httpdocs/app/etc/local.xml
(If unsure use Plesk CP -> File Manager -> Navigate to file -> Pencil Image )
Change db_name, db_username, and db_password from live_db settings to the dev_db details.
Save the file.

Using Hosting Control Panel / phpMyAdmin :
Login -> Home/Domains -> dev.domain_name.com -> Databases -> database -> DB WebAdmin
Click on core_config_data
Click on the Search tab
Enter %base_url in path and click Search/Go
Change all entries to point to http://dev.domain_name.com/
(Further information on using  phpMyAdmin)
Reset the magento cache using the  "Magento Cache Reset" button for dev.domain_name.com

Step 6 : Enable caching and Magento Connect

Configure file permissions and the pear.ini

find /var/www/vhosts/DEV.DOMAIN_NAME.COM/httpdocs/ -type d -exec chmod 775 {} \;
find /var/www/vhosts/DEV.DOMAIN_NAME.COM/httpdocs/ -type f -exec chmod 664 {} \;
chmod a+x /var/www/vhosts/DEV.DOMAIN_NAME.COM/httpdocs/pear
/var/www/vhosts/DEV.DOMAIN_NAME.COM/httpdocs/pear mage-setup .

TEST REPEATEDLY!
Note : All absolute links entered into the CMS component of Magento will remain wrong.
Login details should be changed so that the logins for the dev site are different to the live site.
Consider using "Protected Directories" to prevent viewing of the dev site.

~Paul

As a new user to Magento I installed it to my domain as domainname.co.uk/magento/ so I could play around with it.  I'm now ready to start using it properly, and want to set it to the root directory.  Can I simply move it, or can I delete it and reinstall?  What's best and what is the procedure needed?

Thanks in advance for your help.

BHLC

I made a backup of my site www.rfshop.co.uk using the plesk control panel and then immediately afterwards accidently loaded the backup. It seemed to load correctly but the front end just shows the

"Welcome

You see this page because you have set up your Web server for serving a new site, but have not uploaded the site content yet. "

I can still access the backend of magento and all my products/catagories, etc seem to be there.

Little help please. This is very urgent !!!