I've had to migrate many Wordpress web sites from different domains on the same server to different domains on different servers. In few cases, a simple export was sufficient. In many cases, an import failed to load the media correctly and I was forced to use a common work around.
Workaround (for those wondering):
I download from the original site and upload to the new site the uploads folder where my media is stored via FTP. Once this transfer is complete, I use the plugin Add From Server to select each individual image, one directory at a time.
This is the best workaround I've found, but it's hardly efficient. It's incredibly time consuming and stressful on your bandwidth.
If you have any better suggestions, I'm all ears. But primarily, I want to know the "Why" to this question. What causes Wordpress to have such a hard time managing media migration while migrating posts, pages, and users are much less of a headache?
There is an excellent tool that certainly eases Wordpress migration WordPress (and others) Search and Replace Tool. With that tool it's easy to search through the entire database for all occurrences of old domain, and replace that with the name of new domain. After replacement all the pictures and widgets should work properly.
The way I'm moving WordPress:
export and import the database with phpMyAdmin
transfer the files with FTP program like FileZilla
edit the wp-config.php settings for a new domain
search and replace on the database with InterconnectIT Search and
Replace Tool
Related
A few months ago I created a staging Wordpress site to implement some changes on my website. The databases run on phpMyAdmin (although I'm not sure if this is relevant). I would like to save the comments (the ones that are already published and the ones I've received recently), so my plan is to save them as it follows:
Save all comments and disallowed IPs from the regular website. I believe this is done by downloading the Commentmeta and Comment databases, although I'm not 100% sure. Are there other relevant databases?
Import those comments to the staging site.
Export the whole staging site (databases and webspace) to the regular website and let it run all the updates.
If this isn't the right way to do it or you know a better / more effective / safer method I'd appreciate to know it.
I'm trying to locate the file in which the Comment Blacklist / Disallowed List of my website is stored. I don't use any comment plugins besides the Subscribe to Comments Reloaded, although I don't think this one would store the data I'm looking for.
I'm fairly new to web developing, but I'm not sure if this file should be on a specific database or on a certain folder of the webspace, so all insights are welcome and much appreciated!
I have two websites abc.com and xyz.com. I buy new domain efg.com. Now I want to transfer complete data using plugins from both websites to the new one. These are ecommerce websites. I try to export xml files but it failed everytime
Can anybody tell me how can i do it?
I would look into why the exporting or importing of the xml's failed. Another Approach would be to access the data directly in the database and "diump" it from there using hand written MySQL queries or the PhpMyAdmin interface.
Some typical reasons why the import/export of xmls fails in WordPress:
The same theme and/or plugins aren't being used
The theme and/or plugins aren't exporting all their data.
The former is easy to fix. The solution to the later is to do manual exports of data from the database using MySQL queries or the PhpMyAdmin interface.
Good luck!
I need to clone one of my WordPress websites with all databases and plugin settings in order to create a 1/1 copy of the whole theme, backend and functionalities except for contents. I don't want to export posts, pages, media files, comments and every other post type or so, but custom fields, posts database structure etc.
Are there any plugin to do this?
Or what queries do I have to run via SQL to do this?
Thanks
I've done many similar things, and honestly this would probably be the most time-efficient for you unless you have thousands of posts/pages or something.
Install BackUpWordPress and create a backup of all your files and the database.
Extract the sql file from that archive. Do a search/replace to swap out URLs if the domain name is changing. Then import it into your new database.
Upload the entire zip file onto your web server.
Extract it.
Manually delete all site content from the WordPress backend. Again, unless you have many thousands of posts and pages, this doesn't really take all that long. You can use screen options to display more than 10 or 20 pages/posts at a time for bulk deletion, but I wouldn't recommend going much higher than 100.
That's it! Sometimes brute force is the fastest way. Don't make things more complicated than they have to be.
Not sure if this is the right place to ask, sorry if its not. I build a lot of Wordpress sites. My problem is, the number of them is getting big and harder to update them all when new releases come out.
I have written an app that will download the latest Wordpress release, and manually ftp the new files to all the clients, but this takes forever... need a new way.
I wanted to restructure this while I can or start a new process at least. Whats the best way to manage multiple Wordpress sites and keep them all updated? Some people have said 1 DB and modded config, others I have seen said to keep all installs separate and use plugins to automatically upgrade, but I don't know whats best to do. Ideas? Thanks :)
If these were all sites you managed on your own server, I'd recommend using a Multisite installation rather than separate instances of WordPress. This way you only have one set of themes, one set of plug-ins, and one copy of WordPress to maintain.
If these sites are on different servers (i.e. you're maintaining sites for clients remotely), I'd recommend you look in to a beta account with WP Remote. This is a service specifically built to allow you to remotely monitor and update multiple WordPress installations. It might be the best solution for you because it allows you to use the one-click update rather than manually downloading/FTP-ing the new files.
You can use this free self hosted app http://infinitewp.com
No limitation in number of sites being managed. You can update WP/plugin/themes, do backups, one click login to your WordPress admin panel.
EAMann is right, especially with the new Multi Site features in Wordpress 3.0, there is no better way to manage multiple sites under one umbrella. Being a developer myself, I know the pain of having to login to all those different accounts!
The way to set it up is create a "master domain name" that you will log into. Place this in your WP Config:
define('WP_ALLOW_MULTISITE', true);
Then login to your admin panel, navigate to TOOLS>Network.
After you've set everything up, copy/paste what it tells you to your HTAccess and WP Config file.
The next step, especially if you are putting clients on this network, is they will want their own domain name, not AIBot.com/theirname right? Thats where Domain Mapping comes in:
http://ottopress.com/2010/wordpress-3-0-multisite-domain-mapping-tutorial/
Check that out and good luck!
What you need is www.managewp.com it can do all of that for you plus a ton of other excellent features.
I want to move a drupal site to another domain and am looking for best practices, gotchas, hint, tips, etc to make sure I get through it smoothly.
Links and comments are appreciated.
You might want to give a try to the Backup And Migrate module.
There is also this handbook page that gives instructions on how to backup your drupal site.
It took me 1-2 hours. I do not have a step-by-step guide (I wish I had written everything down), but it entails updating the configuration files, updating the database (some tables have domain references, but I don't recall which - it could be that this was just for my image references in the Gallery2 database), and doing a cursory search of the content for full domain references in anchor links.
I migrated a Drupal 6 site with about 40 plug-ins, including Gallery2 and Google Maps integration, and I did not run into any major road blocks.
If you (and the authors of the contrib modules you used) did a good job by not putting absolute URL's in the code, it should be dead easy (I do it routinely when migrating the development site to a live production one, for its launch).
Of course I assume that you are doing things sensibly, and for example are not migrating a site from an apache/mySQL server to a nginx/postgres one, maybe also adding the need to prefix your DB tables in the process.
If this is the case, then you simply have to copy your entire file tree and export/reimport your DB.
If you are migrating between two similar architectures then chances are you will only have to change a few things in the settings.php file. The file is well documented. The only two things that I normally have to change are:
DB user/pass
cookies domain
In the file there are also additional configuration options like the possibility to choose the base URL manually in case of problems.
Don't forget to flush the cache once you log in the new migrated site for the first time.
EDIT: Just came to my mind: if you use any, you will also have to update your developer keys to third party API's (for example if you use google maps or google analytics) as these are domain specific.
HTH!
Basically, what mac said (+1)
In addition, I often need to adjust the .htaccess files a bit concerning the rewrite rules. For smaller sites on shared hosting environments, I usually place the drupal installations in subfolders within the document root (e.g. to allow for staging, etc.), 'hiding' the subfolder via URL rewriting. So for every 'move' of a site, I need to fix those rules.
The biggest culprit for me are sites that use modules that have to store absolute URLs in order to do their job (e.g. securepages). For those you should disable them prior to moving the site, adjusting their settings before reenabling.
If you are not sure if some of the modules you use store absolute URLs, it might pay of to extract your database dump locally and search the resulting file for occurrences of 'http://', 'https://' and the likes, as well as for your 'old' domain name (you'll need to exclude the watchdog and cache tables for this).