Migrate your site to new domain name or new server

Posted on by

There’s a plugin I’ve just discovered called WP Migrate DB that makes migrating your site to a new server or a new domain name very easy. (These steps may seem long, but this plugin really makes the process far easier than it has been in the past.)

Here’s how:

  1. Get your new site ready for migration. First, make sure both the old and new sites are running the same version of WordPress. Then setup the new site to have the same admin name and admin password as the old site. (The admin name and pw is not critical – it will be reset to the old site’s in the end anyway.)
  2. Make sure the new site is running and works. If you are just moving hosts, then the new site might not really be accessible – so just follow these instructions carefully, and it should come up after the DNS name server is changed.
  3. Delete the entire /wp-content directory from the new site. Copy the entire contents of the old site’s /wp-content to the new site. This will include all the themes, plugins, and upload content (media, for example). You can do this however you like – make a zip file on the old site using cPanel, download to your computer, upload to the new site, and unpack is one way. You can use FTP to download the old contents and re-upload to the new site.
  4. Install WP MIgrate DB on your old site.
  5. Open the WP MIgrate DB admin page. Fill in the name of the new site (it can be the same as the old one if you are just migrating servers.) and the full path name where the site is hosted. This will likely be different for the new server, even if the site name stays the same.
  6. Save the database from the old site to your computer.
  7. Open the mySQL database manager on the new site (phpMyAdmin most likely.) Select the database name used for the new site. It should exist and be populated since you setup the new site to work.
  8. Select the Structure view of the database, click the Check All option at the bottom, and finally “With Selected” pick “Drop”. Then Go. This will clear all the entries in the database for the new site. (The new site won’t function now because the database just got emptied, but that will get fixed soon.)
  9. Now pick the Import tab, and select the file downloaded in step 6. Upload that file.
  10. You new site is ready to go. If you changed the domain name, it will work under the new name. All the media will be sourced from the new site. The admin and any users will still be there with the same names and passwords. All the plugins and sidebars should still be there. In other words, you’ve completely cloned your old site – but it will run on a new host or under a new domain name.
  11. If you are moving to a new host, you should now update the name server on your domain manager account. This will switch the site from being served from the old host to the new host. This may take several hours, even a day, and you may get the site served from one or the other host overlapping for some visitors. One thing you can do after you’ve moved all the files and the data base, but before you switch the nameserver, is to put the old site into maintenance mode, or change the home page to “Move in progress” or some such. Then change the nameserver. When the change has been propogated, the new site will be displayed, and the maintenance mode message will go away. Then you can delete or cancel your account on the old host.

I tried this process – moving one domain name to a new domain name, and it worked perfectly (well, I forgot to update WP on the new site, so had to post-update it to get everything working again). This is a really great plugin, and the move/clone process is now very easy and reliable. It was totally a non-thinking process: set up the new host, copy /wp-content, clear the new database, use the WP MIgrate DB plugin to fix and download the old database, and load the old site’s db to the new site. All very clear, mechanical steps. Took me about 10 minutes (although the move was to the same server which made copying /wp-content very fast.)

Posted in FAQ

Weaver II Doesn’t Save Settings

Posted on by

From time to time, the support forum will receive a question something like “After I make changes, Weaver II doesn’t save the settings. None of my options are changed.” If you are having trouble getting your Weaver II designs to save, then this FAQ is for you.

It is important to note that the way Weaver II saves settings is a mature, well tested mechanism. If it seems that Weaver II is not saving your settings, then it is almost certainly not caused by a problem with Weaver II, but rather some non-standard host configuration, or an invalid setting value. The known possible causes for “not saving settings” are described below, but will always be one of these 3 general issues:

  1. Caching
  2. Non-Standard Host configuration issues
  3. Invalid option values that cause improper CSS rules to be generated

Caching

First, perhaps the most common reason for this is caching – either a WordPress server side caching plugin, or caching done by your browser. This is covered in a separate FAQ – click here. If that is not your problem, then this FAQ will have some more suggestions.

Weaver II is now a mature, well-tested theme used successfully by thousands of users on many different hosts. Changing and saving settings for both the free Weaver II version, and the Pro version work. There are no known bugs or problems saving settings as long as your WordPress site is properly configured. So if you can’t save options, then there is something wrong with your host configuration or values entered into the settings.  There are no known exceptions to this statement.

The most common issues are discussed in the next two sections. There also is a list of quite rare known host configuration errors or illegal settings values described at the end of this page.

Weaver II Free Version Issues

Outside of  the caching problems mentioned above, there have been very few issues with saving the Free version setting. It has been confirmed that the “White Screen of Death” memory problem can result in a failure to save options instead of total failure, but the solution is the same – you need to get your host to increase the amount of PHP memory.

There have also been a couple of reports of issues communicating with the mySQL database. But this is very rare, and is not an inherent issue with Weaver II. It may be related to using some automatic script installs of WordPress, and doing a manual install of WordPress seems to fix this issue.

Weaver II Pro Issues

There is one major difference between Weaver II Pro and Weaver II Free in how your settings are reflected in the displayed site. Weaver II Free includes all necessary CSS rules required to display your design inline in each page <head> section. Weaver II Pro, on the other hand, by default will generate an external CSS file at /wp-content/uploads/weaver-ii-subthemes/style-weaverii.css.

There are two points of failure possible when this file is created and used. First, there can be a failure to create the file. This can only happen when the site admin does not have proper permission to create files in the /wp-content/uploads directory. This will not happen in a standard WordPress installation. One thing to test is if you are able to add and display images in your media library, since those files area also stored in the /wp-content/uploads directory. This problem will likely only happen on private or virtual private servers. It will very seldom happen on typical shared hosts. Sometimes file access permissions have been set improperly. The Weaver II /weaver-ii-subthemes directory needs read and write permission for the admin, and read permissions for the world.

The second problem can come if the visitor can’t read the style-weaverii.css file. There can only be three reasons for this – either the file doesn’t exist at all; the file path to the file is somehow being changed; or the file doesn’t have read permission to the world.

Possible Remedies

  1. If your settings aren’t  “taking” for Weaver II Pro, the first thing to try is to open the Weaver II Pro tab on the Weaver II admin panel. Check the first option: “Use Inline CSS”. In most cases this will both cause your site to display correctly, but also confirm there is an issue with the style-weaverii.css file. Keep reading for possible things to fix.
  2. The style-weaverii.css file is not being created. You should be able to check this using your host control panel, or via FTP access. If the file is not being created, there is a permissions problem. You may have to contact your host to get this figured out. The directory must be write enabled for the WP site admin. Also, do be sure you can upload and use images to the site media library.
  3. The style-weaver-ii.css file exists – it just doesn’t work. This means the visitor’s browser is unable to find that file. The things to check:
    • File permissions – be sure the file gives read access to the work.
    • Permalinks – go to the dashboard Settings:Permalinks tab, and re-save your permalinks settings. This might possiblly fix things.
    • Be sure you don’t have some kind of plugin incompatibility – you may need to disable your plugins one at a time to test this.
    • Issues with your .htaccess file. Perhaps you or some plugin has added extra rules to the site’s .htaccess file that prevents the user from reading the file (this also may stop it from being created.)

If all these measure fail, you may need to re-install WordPress. (You should be able to keep your WP database with all the content.) If you used a script install previously, a manual WordPress install might work the second time around.

But, again, please recognize that if you can’t save Weaver II or Weaver II Pro settings, there almost certainly is some issue with how WordPress is setup and configured on you host.

Other Possibilities – Very Rare, but…

1. Entering Incorrect Color or CSS Values

It has been found that it is possible to enter incorrect values for colors that will have the effect of making it seem settings don’t take. This is because there is then incorrect CSS generated. One specific case is adding a leading paren ‘(‘ to a color – e.g. ‘(#181818′. This adds an extra ‘(‘ to the CSS, and confuses most (but not all) browsers. So after you’ve checked the more obvious problems discussed here, check that you have valid color values in all the color boxes.

And this problem can be generalized – if you enter custom CSS in a CSS+ box, or have custom CSS in the Custom CSS Rules box, then if you have a mistake in your CSS, that will cause incorrect CSS to be generated, and that in turn can make it seem other settings are not taking effect. Leaving off a closing ‘}’ or quotation mark (‘ or “) are common problems.

2. Site Address

Another way to “break” saving Weaver II settings has been reported. Your Dashboard Settings -> General -> Site Address and WordPress address MUST be set correctly and pointing to your site. If you are creating a new, development version of a live site, you MUST NOT use the address of the live site for your development site! This problem can apparently also manifest if you are developing on a subdomain, and don’t specify the Site and WordPress URLs correctly.

3. Not enough $_POST variables allowed

When you save settings from the Weaver II admin panel, all the settings (and there are over 450 of them!) are passed to the save code using the PHP $_POST variable. It is possible that your host has changed the default PHP configuration to limit the number of values allowed to be passed by changing a PHP setting called max_input_vars. There is also a PHP extension called Suhosin that can control the number of PHP settings allowed. If either of these are set (usually by your hosting company) to anything less than about 450, then is is likely that your Weaver II settings will not be saved properly in the WP database. You will likely see the settings reverting back to the default Antique Ivory theme. In that case, you must contact your host and get this limitation increased – preferably to at least 600 $_POST variables allowed. (And a big thanks to mjm4842 for discovering this, and reporting it on the forum!) Beginning with Weaver II 1.2.8, this situation should be detected and produce a warning message.

Posted in FAQ

W3C Validation

Posted on by

From time to time, we get questions and comments about validating your site using an HTML validator, e.g. http://validator.w3.org. For a long time, it was considered important that WordPress sites pass a vlidator The current high level thinking at WordPress … Continue reading →

Posted in FAQ