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 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.

Setting default commit template in Git

Well-formed commit messages can be rather helpful in terms of tracking the history or generating the changelog automatically. Here we will configure a commit template to help writing commit messages in a good format. You can force it across the whole team.

Configure Git commit message template

Write you own commit template file, such as ~/.gitmessage. Below is a good example :

<type>: subject (try to keep under 50 characters)

Multi-line description of commit to explain
what, why and how this change is being made
(try to limit each line under 72 Characters)

Provide ticket numbers or links to other relevant resource
[Ticket: #53]

This template structure contains 3 sections:

  1. head, a subject line starting with a commit type, for example feat: add settings page (followed by a blank line).
  2. body, explains the commit.
  3. foot, optional, provides tickets or other information.

Setup it as the default commit template with below command:

# Config a custom commit template
$ git config --global commit.template ~/.gitmessage

When you run git commit command, an editor opens containing something like this.

Subject line (try to keep under 50 characters)

Multi-line description of commit to explain
what, why and how this change is being made
(try to limit each line under 72 Characters)

Provide links or ids to relevant issues or other resources
[Ticket: #53]
# Please enter the commit message for your changes. Lines starting
# with '' will be ignored, and an empty message aborts the commit.
# On branch master
# Changes to be committed:
#   (use "git reset HEAD <file>..." to unstage)
# modified:   my-plugin.php

Then replace the 3 parts with your actual content.

Commit types

The commit types known to developers that you can set:

Commit Type Description
feat New feature.
fix Fix a bug.
refactor Refactor production code.
style Format issues like missing semi colons, etc, no code change.
docs Change documentation files.
test Add or refactor tests, no production code change.
chore Update grunt tasks, no production code change. Some examples of grunt tasks: configuration changes (.gitignore, .gitattributes), tool changes or something that would not go into the product.

You can put commit types in the template file to help to pick the proper commit type as Git commit template shows:

# <type>: (If applied, this commit will...) <subject> (Max 50 char)
# |<----  Using a Maximum Of 50 Characters  ---->|

# Explain why this change is being made
# |<----   Try To Limit Each Line to a Maximum Of 72 Characters   ---->|

# Provide links or keys to any relevant tickets, articles or other resources
# Example: Github issue #23

# --- COMMIT END ---
# Type can be
#    feat     (new feature)
#    fix      (bug fix)
#    refactor (refactoring production code)
#    style    (formatting, missing semi colons, etc; no code change)
#    docs     (changes to documentation)
#    test     (adding or refactoring tests; no production code change)
#    chore    (updating grunt tasks etc; no production code change)
# --------------------
# Remember to
#   - Capitalize the subject line
#   - Use the imperative mood in the subject line
#   - Do not end the subject line with a period
#   - Separate subject from body with a blank line
#   - Use the body to explain what and why vs. how
#   - Can use multiple lines with "-" for bullet points in body
# --------------------
# For updated template, visit:
# https://gist.github.com/adeekshith/cd4c95a064977cdc6c50
# Licence CC


Ignoring files in Git

Normally there are some files or folders that you do not want them to be tracked. Here you will learn how to set up various ignore rules to exclude them from git repositories.

Ignore files in a git repository

Use .gitignore to allow sharing ignore rules (version controlled)

If you want some files being untracked in a repository, create an .gitignore file at its root directory and commit it. .gitignore file is used to list all the file patterns to ignore, standard glob patterns work in it.

Basic rules for patterns have been included in below example .gitignore file :

# ignore all .class files

# exclude lib.class from "*.class", meaning all lib.class are still tracked

# ignore all json files whose name begin with 'temp-'

# only ignore the build.log file in current directory, not those in its subdirectories

# specify a folder with slash in the end
# ignore all files in any directory named temp

# ignore doc/notes.txt, but not doc/server/arch.txt

# ignore all .pdf files in the doc/ directory and any of its subdirectories
# /** matches 0 or more directories

Remember to commit and push to share the rules in the repository. If you forget to do that, .gitignore will only take effect locally.

$ git add .gitignore
$ git commit -m 'chore: add .gitignore'
$ git push

Note: Adding new patterns in .gitignore won’t affect the files already tracked by Git. You can stop tracking a file.

You can have more than one .gitignore file in subdirectories. Its content will only apply to the folder it resides.

Use .git/info/exclude to only ignore files locally (not version controlled)

If you just want a personal and local ignore configuration without committing a .gitignore file, use .git/info/exclude to achieve that.

What you do is just adding exclude rules in .git/info/exclude within in the root of a repository.

Any rule added in the file will not be pushed to a remote repository. This way enables you to ignore locally generated files and no need to worry about other users.

Ignore files in all repositories

If you want to ignore some files for all repositories, you can set a global gitignore file. Below is an example to ignore .DS_Store files :

File ~/.gitignore_global :


Then configure it as your global gitignore settings in Git :

$ git config --global core.excludesfile ~/.gitignore_global

Debug gitignore files with check-ignore command

check-ignore command can be used to debug if a file/folder match some ignore rules in .gitigonre (or other input files to the exclude mechanism).

Debug ignore rule

# -v, verbose, output details about the matching pattern (if any)
# for each given pathname.
$ git check-ignore -v <pathname>

With -v, if the pathname matches an ignore pattern, it outputs the pattern’s line number, the pattern itself and your queried pathname, or it output nothing. Without -v, if some pattern matches, only the pattern is output.

Below example debugs if user.csv is excluded:

# Debug whether user.csv is exclude by some ignore rules
$ git check-ignore -v user.csv
.gitignore:3:*.csv      user.csv

Here user.csv is ignored by *.csv pattern in .gitignore.

Note: By default, tracked files are not output since they are not subject to exclude rules. If a file is tracked before and untracked currently, it can be output.

With --no-index option, it will also output files that has been tracked but ignored in .gitignore.

# Track user.csv even it has been ignored.
git add -f user.csv

# Check without --no-index, nothing is output
git check-ignore -v user.csv

# Check with --no-inxex
git check-ignore -v --no-index user.csv
.gitignore:3:*.csv      user.csv

Debug ignore and exclude rules

If user.csv is ignored by *.csv but then excluded by !user.csv in .gitignore, such as below .gitignore file.

# ignore all .csv files

# exclude user.csv

Then it will only output the ignore rule.

$ git check-ignore -v user.csv
.gitignore:3:*.csv      user.csv


Compared with check-ignore command, you may just want to see whether a file is tracked. ls-files command will help you.

# Check whether user.csv is traked or not
$ git ls-files -- user.csv

# List all untrancked files excluding ignored files
$ git ls-files --others --exclude-standard

Read more