Tag Archives: Debugging

Tech Friday: Debugging the WordPress White Screen of Death

Leave a reply

motor-1381998_1280Problem: I attempted to change a password for a user of the WordPress web site. I got into the administrator’s dashboard, choose “Users”, found the person’s entry, changed their password, clicked on “save changes” and Poof! I get a blank screen.

 

It turns out there is a name for such screens, and the name is called the WordPress White Screen of Death, or WSOD.

There are a ton of possible causes for this, but many of them relate to a problem with PHP code located someplace  within WordPress, or within WordPress plugins. Since the WSOD is just that…it doesn’t show any kind of detailed error message, one approach to finding the problem is to enable error checking and display at the PHP level. This is a quick entry in the WordPress wp-config.php file located in the root WordPress directory.  Here’s the file as it shows up in FileZilla.

WP_Config

And here is the contents of the file as displayed in Notepad++

WP_DEBUG

The trick is simply to change false to true to enable the display of error codes.  And sure enough,  once I did that and retried the password change operation I saw the following message:

Fatal error: Call to undefined function curl_init() in /var/www/html/wordpress/wp-content/plugins/gmail-smtp/class.phpmaileroauthgoogle.php on line 171

This was an indication that a plugin which I had added was causing the error. Once I removed the plugin, I could change my user’s password without problems and the WSOD was banished, at least for now.

Test PowerShell scripts with VirtualBox

Leave a reply

I’m at the point where I am going to deploy some PowerShell scripts to my end-users, and I want to test the scripts on a fresh installation of Windows before trying them on the user’s workstations.

I use VirtualBox to create virtual machines for Powershell testing. Virtual box works on Linux, Mac and Windows host machines. My 8 gig Win 7 box works fine with one or two “guest OS’s”. On my 4 gig (ancient) iMac, it works, but its pretty slow.

One thing that I find amazing, is you have to run updates on all those Windows Virtual machines. Don’t expect to be fully productive on Tuesdays or Wednesdays, when Microsoft sends out Windows updates. It isn’t unusual for updates to run for an hour or more.

Be sure to install the VirtualBox “guest additions” within your Windows VM, once you’ve got your Windows VM up and running. You may also want to change the network settings to “bridged”, so that your VM is on the same network subnet as your host machine.

One other disconcerting thing; your Windows 7 desktop may come up with a black background depending on whether you are running the aero interface and other such fripperies. You can turn all this stuff on if you want; but it will slow down the performance.

More details on setting up VirtualBox are located  here and here.

winvm

If you have installed Windows 7, you may find that it has come with Powershell V.2 out of the box. You can test that by starting a PowerShell session from the command box (just type Powershell.exe).  Once Powershell is up, issue the following command at the prompt:

get-host | select-object version 

If it isn’t 4.0 or later, download the latest version of the Windows Management Framework from Microsoft.

Debugging in PowerShell

Leave a reply

The PowerShell integrated scripting environment (ISE) has many of the trappings of a full-fledged programming GUI, including a capability for debugging with breakpoints. There is a TechNet article on debugging from which this discussion is cribbed.  The ISE has a subset of the command-driven breakpoint capability, in that it only allows the setting of line breakpoints. In the command environment, you can also set variable breakpoints, which execute when the value of a variable changes, and command breakpoints, which execute when a certain command is reached.

Breakpoints can only be set for a script that has been saved.

In the ISE window a breakpoint can be set from the debug menu, (Toggle Breakpoint)  or by pressing F9 when the cursor is on the line that you want to use for the breakpoint.  Once set, the line will be highlighted.

After setting a least one breakpoint, you can run the single-stepper. This executes the script one line at time.

Step Into: Executes the current statement and stop at the next statement. If the statement is a function or script, it goes into the function or script and then stops.  F11

Step Over: Execute the current statement and stop at the next statement.  If the statement calls a function or script, it executes the function or script and then returns to the next statement in the original script. F10

Step Out: Executes the current function and then returns to the level above in the call stack. If there are statements remaining in the sub-function, those are executed before the return. Essentially this is something like “finish running this function, and return…”

Continue: Execute to the next breakpoint without single-stepping.

What I’ve been doing as I’ve been learning PowerShell is single stepping through a script, which allows me to look at the effect of a single statement before moving on to the next statement.  This involves setting a breakpoint a the top of the script, and then hitting F11 to toggle through the script.

Calling sub-scripts.

Scripts can be called from other scripts using the Invoke-Expression commandlet.  Example:

Invoke-Expression -Command ./PSFTPDEMO.ps1

If the subscript is located in the current working directory, or within the same directory as the main script, it needs to be prefaced with the ./ path as shown above.

The subscript inherits all variables from the main script unless those variables are declared private in the main script.