What to do if your WordPress host IP changed

If your WordPress host IP changed accidently and and you can not login into WordPress, there are several ways to update the site URL without logging in. Then your site will be working properly. If your site does not, check your .htacess file in which you may have settled some redirect rules with the old IP, replace all the old IP with the new IP.

Change the site URL

Changing the site URL provides several ways to change the site URL and this article gives two more ways, choose one you like and then try to refresh your site a couple of times, your site will be OK.

Change URL in database through phpmyadmin

Even your WordPress site does not load, you can access the phpmyadmin tool.

In wp_options table, update two records whose option_name is siteurl or home. Make the records are listed ascendingly by option_id, you can easy find these two records.

Change URL in database through terminal

Open a terminal, connect mysql with mysql -u root -p or /path/to/your/mysql -u root -p if your mysql is not in the path. Here it suppose your mysql user is root. It will prompt you input the password. If you forget, check them in your wp-config.php file.

Input use to select the database you want to change. You can also find the database name in your wp-config.php file. Then you can update the options whose option_name is siteurl or home like below.

# Connect mysql
$ /myfolder/mysql/bin/mysql -u root -p
Enter password: ********
Welcome to the MariaDB monitor.  Commands end with ; or g.
Your MariaDB connection id is 2
Server version: 10.1.31-MariaDB mariadb.org binary distribution

# Choose database
MariaDB [(none)]> use my-database-name
Database changed
MariaDB [training]>

# You can check the old values for the option whose option_name in ('siteurl', 'home')
MariaDB [training]> select * from wp_options where option_name in ('siteurl', 'h
    -> ;
| option_id | option_name | option_value         | autoload |
|         2 | home        | http://xxx.xxx.x.xxx | yes      |
|         1 | siteurl     | http://xxx.xxx.x.xxx | yes      |
2 rows in set (0.12 sec)

# Update the values with the new IP
MariaDB [training]> update wp_options set option_value="" wh
ere option_name in ('siteurl', 'home')
    -> ;
Query OK, 2 rows affected (0.09 sec)
Rows matched: 2  Changed: 2  Warnings: 0

MariaDB [training]> exit

Edit functions.php

Edit your functions.php of your currently used theme, add these two temporary lines to the file, immediately after the initial <?php line:

update_option( 'siteurl', '' );
update_option( 'home', '' );

Use your own IP instead of

Load the admin page a couple of times, the site should come back up. Then remove them after the site is up and running again.

Edit wp-config.php

Add these two lines to your wp-config.php, where “example.com” is the correct location of your site.

define( 'WP_HOME', 'http://example.com' );
define( 'WP_SITEURL', 'http://example.com' );

Note it’s just hard-coding the values into the site itself. You won’t be able to edit them on the General settings page anymore when using this method.

Change old IP in your .htaccess file if any

If your site does not come back, check your .htaccess (probably the top-level .htaccess) file and replace all the old IP with the new one if any.

Fixing WordPress update error: The checksum of the file (xxx) does not match the expected checksum value ()

If you are getting the following error when you trying to update WordPress. Then try the solutions listed in the article.

Downloading update from 

Download failed.: The checksum of the file (xxx) does not match the
 expected checksum value ().

Installation Failed

1. Check disk space and permissions

The two most probable situations you need to check are:

  • Check disk space. You are probably running out of the disk space. If you are on a Linux server, run df -h to check the available space.
  • Check permissions. When you are updating WordPress on the dashboard by clicking Update now button, the user is that one who is running the Web server. Make sure that user have write permission to the WordPress core files. See the tutorial on Changing File Permissions for more information,

2. Restart your Web server

If neither of the situations mentioned above is your problem, and you’ve updated WordPress successfully the last time, and nothing seemed to have been changed afterwards, just try to restart your web server. Then update again.

3. Update via WP-CLI

If no luck once again, maybe you can attempt to update WordPress through WP-CLI (WordPress Command Line Interface). Getting started to use WP-CLI is very simple, just download a phar file on the server, make it executable. Then you are ready to use it. And some WordPress in has been shipped with WP-CLI.

# Update to the latest WordPress version
$ wp core update

# Or you can update to a specified version,
# and/or with a zip file you have downloaded already.

# Update WordPress to latest version of 3.8 release
$ wp core update --version=3.8 ../latest.zip

# Update WordPress to 3.1 forcefully
$ wp core update --version=3.1 --force

More about wp core update and downloading the WordPress zip

Download the latest WordPress zip (or tar.gz) file.

See more about wp core update:

If you see “Error: Another update is currently in progress.”, you may need to run wp option delete core_updater.lock after verifying another update isn’t actually running.

Make sure you have write permissions to the WordPress core files and the updated file can be written by the Web server user (who are running the Web server) afterwards.

A simple method is to execute update command as the root user. This will make the files updated to be owned by the root, you need to reset the ownership and restart the Web server to take effect. What we do here is just to make Web server user have write permissions to these files, remember that.

# Update WordPress as the root
$ sudo wp core update --allow-root

# Reset the ownership to the user who runs the Web server.
$ sudo chown -R <web server user> <wordpress path>

4. Manual update

If all the above solutions do not work for you, mannual update can be a last resort for your.


Fixing expires headers not working

After adding expires headers, you may found they are not working as expected. According to your server’s settings, there are a few situations that cause this issue.

In below checking process, assuming you are using Apache server.

Checking flow of expires headers not working

  1. Check whether .htaccess is disabled in httpd.conf of your apache (generally httpd.conf is located in the /conf folder).

    Check whether the AllowOverride option is set to None. If it is, then .htaccess is disabled. You can add the configuration for adding expires headers in the main configuration file httpd.conf.

  2. Check whether mod_expires is loaded in your httpd.conf.

    There will be a line like below if mod_expires is loaded in httpd.conf. If it is commented out or missed, fix it.

    LoadModule expires_module modules/mod_expires.so
  3. Remember to restart apache. Then you should find that the expires heading are working.

Troubleshooting: WP-CLI displays PHP notices when running commands


When running commands in WP-CLI, it shows a lot of notices like below:

$ wp post list
Deprecated: Methods with the same name as their class will not be constructors in a future version of PHP; QrctWp has a deprecated constructor in xxxwp-contentpluginsqr-code-taglibqrctQrctWp.php on line 11
PHP Notice:  wp_enqueue_script was called <strong>incorrectly</strong>. Scripts and styles should not be registered or enqueued until the <code>wp_enqueue_scripts</code>, <code>admin_enqueue_scripts</code>, or <code>login_enqueue_scripts</code> hooks. Please see <a href="https://codex.wordpress.org/Debugging_in_WordPress">Debugging in WordPress</a> for more information. (This message was added in version 3.3.0.) in xxxwp-includesfunctions.php on line 4231
Notice: wp_enqueue_script was called <strong>incorrectly</strong>. Scripts and styles should not be registered or enqueued until the <code>wp_enqueue_scripts</code>, <code>admin_enqueue_scripts</code>, or <code>login_enqueue_scripts</code> hooks. Please see <a href="https://codex.wordpress.org/Debugging_in_WordPress">Debugging in WordPress</a> for more information. (This message was added in version 3.3.0.) in xxxwp-includesfunctions.php on line 4231


Set WP_DEBUG from true to false in wp-config.php of your WordPress.


define( 'WP_DEBUG', false );

Fixing JetPack related posts not showing for XMLRPC parse error

JetPack related posts are not showing, WordPress says This site cannot be accessed, and xmlrpc test shows parse error. not well formed . Here it shows you how to fix it.

Test your site

Run below command to test your site in an terminal (Any computer is fine.)

$ curl -A "Jetpack by WordPress.com" -d "<methodCall><methodName>demo.sayHello</methodName></methodCall>" https://www.your damain.com/xmlrpc.php

The correct result should be:

<?xml version="1.0" encoding="UTF-8"?>

It is a XMLRPC parse error if the response is:

<?xml version="1.0" encoding="UTF-8"?>
          <value><string>parse error. not well formed</string></value>

Tips: You can also test your site using https://xmlrpc.eritreo.it/. Just input your site and click Check button. Other information like username and password is not needed.

If it is an XMLRPC parse error, the result will be:

Code      Description
-32700    parse error. not well formed

Solution for parse error

Connect to your website host, run below command to install php-xml:

$ sudo apt-get install php-xml

If your host does not have apt-get installed, you may need use (Such as AWS EC2 with Amazon Linux 2):

$ sudo yum install php-xml

Retest your site, it should be OK (Restart your apache sever if needed). After your posts are synced to WordPress site, you may see related posts.

Note: Related posts will not appear unless at least 3 good related posts can be found by JetPack. See more on jetpack related posts.

Tips: For other JectPack connection issues,fix them according to fixing jetpack connection issues.