WordPress blank page troubleshooting automation


WordPress blank page troubleshooting automation

WordPress blank page troubleshooting automation

It is been a while since we last published a complete tutorial regarding specific WordPress issues. So far we have gone through the installation process, we have learned how to install themes and plugins. Now is the time to start learning more about troubleshooting automation of more complex issues. WordPress blank page is one of those well-known problems and there are a number of reasons for it. 

The so-called white screen of death could be caused by a faulty plugin, broken theme or interferences between the activated extensions. That said, the most logical approach would be to start turning them on and off one by one. So far, so good. We have a course of action, but what happens if we have 30+ plugins and 5 themes?

WordPress blank page troubleshooting automation

Today we will be speaking about blank page troubleshooting automation and more specifically, we would like to present a shell script that would give insights on the problem. It requires the presence of wp-cli. Its main logic is based on simple loops through active plugins and themes. Here is the body of the script and breakdown of its stages:

#!/bin/bash
#Run the script this way: ./blankpagedebug.sh domain.com or domain.com/wptest/ ot test.domain.com (Do not add http; https or https://www)

url=$1
    if [ -z "$url" ]
    then
    echo "URL is empty"
    exit 1
    else
    test1=$(curl -s -o /dev/null -w "%{http_code}" $url)
    test2=$(curl -s -o /dev/null -w "%{http_code}" https://$url)
    test3=$(curl -s -o /dev/null -w "%{http_code}" https://www.$url)
        if [ $test1 == 200 ]
            then
            echo "The URL is http://$url"
            real_url="http://$url"
        elif [ $test2 == 200 ]
            then
            echo "The URL is https://$url"
            real_url="https://$url"
        elif  [ $test3 == 200 ]
	       then
            echo "The URL is https://www.$url"
            real_url="https://www.$url"
        else
            echo "Unable to detect url"
	    exit 1
            fi
    fi

initialsizecheck=$(curl -s $real_url | wc -c)
wp db export BlankPageDebugger-BKP 2>&1 > /dev/null
echo -e ' \t '"Backup - BlankPageDebugger-BKP"
echo "Starting turning on/off plugins"

getactiveplugins=$(wp plugin list | grep -v "inactive\|name" | awk '{print $1}')
for i in $( echo "$getactiveplugins")
do

    wp plugin deactivate $i 2>&1 > /dev/null
    sizecheck=$(curl -s $real_url | wc -c)

    if [ $initialsizecheck == $sizecheck ]
        then
            echo -e ' \t '"No change after stopping $i"
            wp plugin activate $i 2>&1 > /dev/null
            
        else
            echo -e ' \t '"There is a change after stopping $i"
            wp plugin activate $i 2>&1 > /dev/null
            
fi
done

echo "Starting switching the themes"
wp theme list | grep twentynineteen 2>&1 > /dev/null

    if [ $? == 0 ]
        then echo  -e ' \t '"The default twentynineteen theme is present"
    else
        echo  -e ' \t '"The default twentynineteen theme will be installed"
        wp theme install twentynineteen 2>&1 > /dev/null
        touch checkpoint-2019-sg
    fi

defaulttheme=$(wp theme list | grep -v "inactive\|name" | awk '{print $1}')
wp theme activate twentynineteen 2>&1 > /dev/null

sizecheck=$(curl -s $real_url | wc -c)
    if [ $initialsizecheck == $sizecheck ]
        then
            echo -e ' \t '"No change after setting up twentynineteen"
            wp theme activate $defaulttheme 2>&1 > /dev/null
            
        else
            echo -e ' \t '"There is a change after setting up twentynineteen"
            wp theme activate $defaulttheme 2>&1 > /dev/null
            
fi

if [ -f checkpoint-2019-sg ]
then
rm -f checkpoint-2019-sg
wp theme delete twentynineteen --force 2>&1 > /dev/null
wp db import BlankPageDebugger-BKP 2>&1 > /dev/null
echo -e ' \t '"Backup restored successfully"
fi

It is important to note that the script needs to run this way:

./blankpagedebug.sh domain.com or domain.com/wptest/ ot test.domain.com

Meaning, we ran the script like any other shell script and pass the domain to it. We do not need to specify a protocol, the script itself will identify it. Here is a breakdown of the code:

  • The first part checks which one of the following http://domain.com, https://domain.com or https://www.domain.com would return 200 OK. Once detected, we put it into a variable to be used later.
  • Before turning the active plugins off and on, we check the size using curl and create a database backup
  • We build a list of the active plugins and start applying the following sequence:
    • Stop the plugin
    • Check the new size of the page
    • Depending on whether there is a change or not, we print a message
    • Reverting the changes
  • We check if twentynineteen is present. If not, we install it
  • We identify the active theme
  • We activate twentynineteen and again check the size
  • We revert the changes and remove twentynineteen if it was installed by us. We also restore the backup generated at the very beginning.

Summary and conclusions

When an unexpected problem happens, logically we have to revert the latest changes. This includes deactivation of the plugins we recently installed or activated. The same applies to the themes. If however, we have a large number of extensions, the whole process may become quite complex and time-consuming. The idea of blank page troubleshooting automation is to prepare a script that would loop through the active extensions and perform certain operations. In over 90% of the case, this simple script gives proper directions about the issue at hand.

Summary
WordPress blank page troubleshooting automation
Article Name
WordPress blank page troubleshooting automation
Description
Blank page troubleshooting automation - a shell script to ease the troubleshooting of white screen of death which could be caused by a faulty plugin, broken theme or interferences between the activated extensions. Backup generation and restore. Simple loops through the active extensions.
Author
Publisher Name
WPpotion


Do you want to share your opinion?

Your email address will not be published. Required fields are marked *


*

Рязане и пробиване на бетон Сканиране на бетон Безвзривно разрушаване на бетон
We are not industry specific. We are WordPress specific. We work with everyone to help find solutions for the troubles.
If you show us the problem you are experiencing, we will show you how to fix it. It is that simple.


Easy WordPress automation

Switching from human control to automation is an essential step in increasing the efficiency of website development or maintenance. During the past decade, WordPress advanced a lot and became a fully functional Content Management System. Thanks to some of its internal features a large portion of its functionality could be easily automated. The following articles give ideas on how to apply successful automation:

Speed up WordPress

Speed is an important matter when it comes to website success. In order to appear on the first page except for applying the well-known SEO techniques, you will also have to pay special attention to the performance of your website. We have reviewed a number of options and prepared articles for the most important aspects that include database management and dealing with different types of content:

Extend WordPress features

Extending the standard WordPress functionality by building new features was always a hot topic. Developing themes that provide next-level User Experience could also be described similarly. Thanks to the established standards WordPress developers could create standardized extensions that can be downloaded from the official repository. In the following articles, we described some simple techniques that would help start developing your own extensions:

wppotion - powered by persistence and passion