Blank Dashboard and Administration Screens on WordPress


Apparently, there are a number of potential causes of a blank or empty screen when trying to access the Dashboard or administration screens of a self installed version of WordPress.

Before doing anything to your installation, I’d strongly suggest making a complete backup of your Database and installation folders. If your web host offers a handy way to do that, take advantage of it. There are plenty of walk-throughs on the Internet available with explanations of how to manually perform a backup. Don’t skip this step.

The most common apparently is a bad or incompatible plug-in. To test that theory, using an FTP application, just rename the plug-in folder that’s located in the wp-content folder.


Navigate to the root of your WordPress installation, then the wp-content folder. Rename the folder currently named plugins to something like plugins-test. This temporarily disables the plug-ins. Don’t worry, the settings for the plugins aren’t stored here.

Try again to navigate to the Dashboard.

Some suggest that a bad theme can also cause this problem. Assuming you haven’t directly modified the original copies of the themes of WordPress that are included with the default installation, twentyeleven and twentyten, rename the folder of your current theme (just add “-test” to the end again for example). This causes WordPress to revert to the default (which currently is twentyeleven).

Try again to navigate to the Dashboard.

Another option is to delete several of the folders of your installation and copy in the current versions. (Follow this if you’d like to try it). While fun to do, it didn’t help with my problem.

In my case, and the reason I’m posting this, is that it wasn’t any of those things. Somehow, the configuration file located in the root of the WordPress installation was no longer compatible with the current version of WordPress. I have no idea how this happened.

I made a copy of the original file wp-config.php (by copying it locally to my computer). If you just make a backup on your web site host, don’t give it an extension that makes it downloadable as it contains the keys to your installation. Smile

Open the copy of the wp-config.php file that you’ve made locally on your computer. By doing that, it will be much easier to grab the values from there that you’ll need shortly.

Now, as soon as you perform the next step, your web site will be unavailable for  a few moments while you get things running again. It’s up to you if you want to do something special during this time (you could make a backup of index.php for example and edit the file to say that your site is undergoing a bit of maintenance).

I chose not to as I knew that it would take about 30 seconds to create a new configuration file.

Delete the file, wp-config.php from the root installation directory. Your web site is now officially down.

Now, using your browser navigate to the root folder of your WordPress installation and append wp-admin/install.php to the URL. It might look something like this:

“blog” represents the root of the WordPress installation in the example above.

WordPress notices that your installation is missing a configuration file. Go ahead and walk through the few steps. Refer to the original wp-config.php file that you opened locally to provide answers to its questions. Pay attention to the table prefix question in particular and make sure that it matches with what you were using before. Look for a line that looks like this in the configuration file:

$table_prefix  = ‘wp_’;

The value in single quotes (wp_ in the example above) represents the prefix for the database tables that were created and being used by your WordPress installation. If you’re using a shared database, it’s very likely that you didn’t use the default of wp_. If you don’t match these up, you’ll end up with a completely fresh installation of WordPress, which isn’t likely what you want. (Don’t worry, if that happens, delete the config file and start over and this time, be sure to enter the correct prefix).

The other questions it asks should all have equivalents in the wp-config.php file you’ve got opened locally.


When it’s done, try logging in again. As soon as I completed the steps above, the WordPress Dashboard became available again. I renamed the plugin folder (removed the “-test” I’d added) and renamed my theme folder (again, by removing the “-test” I’d added). I went to the Plugins to re-activate each of them (as apparently, they became deactivated by default).

I verified the web site again was working and behaving as expected, and went on my regularly scheduled day. Hours lost: 3. Sad smile

Hopefully this will help someone else.

(FYI, the new configuration file that was generated by the “fresh install” was syntactically and structurally different from the original. I don’t know why this was the case or when it happened, but I was happy to get things working again).

Adobe Lightroom and exporting to subfolders

For some reason, versions 1 – 3 of Adobe Lightroom cannot export images in a way that mirrors the original structure of your photo library. I can’t offer a reason why other than it was missed by the development and design teams. There’s been enough interest in it apparently that there are more than a few free and pay solutions to the problem.

I looked at a few of the options and for one reason or another, I decided that I didn’t want to use the plug-ins/extensions and came up with a simple solution using a bit of naming trickery. I use this technique for SnugUp.

Here’s what I did in Lightroom version 3.

  1. I selected the photos I wanted to export.  (I generally use the Quick Collection Feature)
  2. File > Export (CTRL + SHIFT + E)
  3. Adjust the Export To option to point to a specific folder of your choosing (in the example below, I set the folder as E:\PhotosBackupJPG
  4. You may optionally put them in a subfolder of your choice (I did not)
  5. Next click the Rename To option and select "Edit…
  6. Clear any value that may already be in the text box below the Example (just highlight the text and press delete).
  7. Then, edit the template to be Folder Name and then Original filename. Select those by using the Image Name grouping. Click the Insert button after each.
  8. Then, I added some text that I knew would be unique to be used as a separator (=-= equals minus equals). To add the text, just click with your mouse  between the two values you just inserted. I know that none of the file names in my library have this exact combination of characters in them. It’s important later. You can confirm this by using the search feature in Lightroom if you’re not sure.
  9. Click on the Preset (yours may say something else) and then click “Save Current Settings as New Preset
  10. Give it a name that you’ll remember (I called mine Folder-Filename) and hit Create.
  11. Adjust the remaining settings per your export needs and begin the process by clicking the Export button.
  12. Wait patiently. Then go do something else as you realize it’s going to take a lot longer than you had expected/wanted.
  13. Now, the next step is the simple trickery. What we’ve done is named all of the files so that they include the folder name as well. So, using a Powershell 2.0 script (Powershell is available for all modern versions of Windows as part of a package download here). So, download it now if you don’t already have it. (You can check for it by looking for Powershell ISE as described in the next step if you’re not sure. You probably have it if you’re using Windows 7).
  14. Start Windows Powershell ISE (in Vista and Windows 7, just type “power” into the Start menu search):
    imageThe reason I suggest the ISE (integrated scripting environment) is that it’s easy to just get stuff running without a lot of hassle.
  15. The ISE will start:
  16. I performed the move/rename in two steps so I could verify things between each step. If you’re familiar with Powershell, feel free to combine them into one step. It’s simple enough. First grab the entire script below and paste it into the top pane (under the tab labeled Untitled1.ps1):
    $root = #"E:\PhotosBackupJPG" $items = Get-ChildItem $root foreach($item in $items) { $path = [regex]::split($item.Name, "(=-=)") if ($path.length -eq 3) { $destPath = $root + "\" + $path[0] if (!(Test-Path -path $destPath)) { New-Item $destPath -type directory "New folder: " + $destPath } Move-Item $item.FullName $destPath } }

    I’ve intentionally left an error in the file so that you’re forced to make the change. Unless you have an “E” drive and the path, “PhotosBackupJPG”, the script needs a tiny modification to make it work.

  17. The first line of the script, $root = #”E:\PhotosBackupJPG” needs to be changed to match with the export location you selected earlier AND also the “#” needs to be removed (it’s a comment character in Powershell script). So, if you exported your photos to C:\Users\Steve\ExportedPhotos, remove the “#” and remove the text inside of the quotes on the first line and replace it with your photo location.
  18. After confirming the location points to where you exported your photos (and videos), hit the Run button (the green arrow in the screen shot below). Or hit the F5 key on your keyboard.


  19. The output (or any errors if you made a typo) appears in the light blue box in the center and when it’s complete, the word “Completed” appears in the status bar at the bottom of the application. It may take a few minutes to complete. I’d suggest looking at your export directory using Windows explorer to confirm everything looks fine before continuing. At this point, you should have some subfolders and all of the files should have been moved into the proper subfolder. Next, renaming.
  20. Click the “New” icon (first icon on left shown above) to create a new Powershell script file (or just replace the existing one, you won’t need it again for this process). In the new file, copy this Powershell script and paste it:
    $root = #"E:\PhotosBackupJPG" $items = Get-ChildItem $root -recurse foreach($item in $items) { $path = [regex]::split($item.Name, "(=-=)") if ($path.length -eq 3) { # $destPath = $root + "\" + $path[0] Rename-Item $item.FullName $path[2] } }

  21. Again, fix the $root to match with the export folder you created.
  22. Confirm it, and hit the Run button.
  23. All of your photos (and videos) will be renamed to only the original file name. The extra folder name and =-= are removed.
  24. Bask in the glory of Powershell and your file wizardy. No plug-ins necessary.

If you’d like to use something other than =-= as the delimiter between the folder and file names, you’ll need to fix the Powershell scripts. The delimiter is on the line:

$path = [regex]::split($item.Name, "(=-=)")

But, unless you understand how Regular Expressions in Powershell work, you may want to avoid this change … it’s not necessarily as simple as just replacing the text.

The scripts above do these things with each file:

  1. Check to see if it has the right pattern
  2. If so, grab the folder name and check to see if the folder exists.
  3. If it does not, create it.
  4. Move the file to the new folder.
  5. Rename the file name, removing the folder and delimiter

If you have questions, please leave a comment.

While this shouldn’t cause any harm, (especially if you just point it at a folder of exported photos and videos, which worse case you just re-export), you use technique and code this at your own risk. I can say I successfully used the script on over 30,000 exported photos without a single problem. Smile

WPF & System.Windows.Baml2006.TypeConverterMarkupExtension "The image format is unrecognized"

SNAGHTML4534e6a2If you recently added an icon to your WPF project (any .NET version, including .NET 3.5, and .NET 4.0) and it has support for an alpha channel (often referred to as the Vista icon format), stop. Why? Your WPF application won’t run on the latest service pack of XP as it’s not capable of decoding the format unfortunately. It’s a very frustrating error and a stupid "feature that Microsoft overlooked. I’ve hit this a few times unfortunately.

To fix, remove all of the alpha channel images from the ICO file and recompile.

Alternative to ApplicationSettings in .NET

After dealing with lost settings, an unclear upgrade path, and my own confusion surrounding the magic of Settings in a .NET client application, I decided to build my own.

You’re probably familiar with this UI in Visual Studio. It hasn’t changed much since it was first created:


A list of properties, data type, scope and a default value. Admittedly, it makes things simple. However, with my WPF .NET application that I created a few years ago (SnugUp), I’ve always been troubled by the magic of the settings. It was too easy to get in a situation where a user would loose their settings doing uninstalls, reinstalls, upgrades.

While I’m sure it’s possible to make the built in settings classes to work, it wasn’t worth the effort for me to understand them and learn what the nuances of where they’re placed, how to do a decent upgrade, how not to loose them, etc.

In the SnugUp WPF UI, the code uses a two-way bindings to directly edit the settings of the application (like: "{Binding AppSettings.DebugMode}"). It was simple, and all I needed. It’s handy that ApplicationSettingsBase implements the INotifyPropertyChanged interface which WPF needs for simple two-way data bindings.

My solution, which I admit is heavier than the original as it requires a large additional assembly is to use JSON.NET as the serializer/deserializer for a new settings class I created.

So, the basic pattern:

   1: public class ApplicationSettings : INotifyPropertyChanged

   2: {

   3:     public event PropertyChangedEventHandler PropertyChanged;


   5:     private bool _debugMode;

   6:     private string _albumNameFormat;

   7:     private string _extraFileExtensions;

   8:     private bool _automaticRun;

   9:     private string _galleryCreationSubCategory;

  10:     private bool _filenameOnlyCheck;

Properties created the standard way for INotifyPropertyChaged:

   1: private DateTime _nextUpdateCheck;

   2: public DateTime NextUpdateCheck

   3: {

   4:     get { return _nextUpdateCheck; }

   5:     set

   6:     {

   7:         if (_nextUpdateCheck != value)

   8:         {

   9:             _nextUpdateCheck = value;

  10:             RaisePropertyChanged("NextUpdateCheck");

  11:         }

  12:     }

  13: }

I wanted a predictable path for storing settings (so it would be easy to document and backup for users). I used the AssemblyCompany attribute and the AssemblyProduct attribute as the folder names:

   1: internal static string GetSettingsDirectory()

   2: {

   3:     string path = Environment.GetFolderPath(Environment.SpecialFolder.ApplicationData);

   4:     var attrs = Assembly.GetEntryAssembly().GetCustomAttributes(typeof(AssemblyCompanyAttribute), false);

   5:     if (attrs.Length == 1)

   6:     {

   7:         path = Path.Combine(path, ((AssemblyCompanyAttribute)attrs[0]).Company);


   9:     }

  10:     attrs = Assembly.GetEntryAssembly().GetCustomAttributes(typeof(AssemblyProductAttribute), false);

  11:     if (attrs.Length == 1)

  12:     {

  13:         path = Path.Combine(path, ((AssemblyProductAttribute)attrs[0]).Product);

  14:     }

  15:     return path;              

  16: }

In this WPF application, in the AssemblyInfo.cs file, the attributes are set as follows:

   1: [assembly: AssemblyCompany("")]

   2: [assembly: AssemblyProduct("SnugUp")]

On my machine, that maps to this path:


Loading settings then is straightforward using JSON.NET:

   1: public static ApplicationSettings Load(string filename)

   2: {

   3:     ApplicationSettings settings = null;

   4:     var directory = GetSettingsDirectory();

   5:     var path = Path.Combine(directory, filename);


   7:     if (File.Exists(path))

   8:     {

   9:         string fileData = File.ReadAllText(path);

  10:         try

  11:         {

  12:             settings = JsonConvert.DeserializeObject<ApplicationSettings>(fileData, new JsonSerializerSettings { });

  13:         }

  14:         catch { }

  15:     }

  16:     if (settings == null)

  17:     {

  18:         settings = new ApplicationSettings();

  19:         SetDefaults(settings);

  20:         // initialize settings once

  21:         Save(settings, filename);

  22:     }

  23:     return settings;

  24: }

In my code, if the settings file didn’t exist or fails to serialize into something meaningful, a new settings file is created with a few defaults. (I haven’t decided what to do when there’s an exception when reading the file, hence the empty catch).

Saving the settings is just as easy:

   1: public static void Save(ApplicationSettings settings, string filename)

   2: {

   3:     Debug.Assert(settings != null);

   4:     var directory = GetSettingsDirectory();

   5:     var path = Path.Combine(directory, filename);


   7:     JsonConvert.SerializeObject(settings);


   9:     if (!Directory.Exists(directory))

  10:     {

  11:         Directory.CreateDirectory(directory);

  12:     }


  14:     var fileData = JsonConvert.SerializeObject(settings, Formatting.Indented, new JsonSerializerSettings { NullValueHandling = NullValueHandling.Ignore, DefaultValueHandling = DefaultValueHandling.IgnoreAndPopulate });

  15:     try

  16:     {

  17:         using (StreamWriter writer = File.CreateText(path))

  18:         {

  19:             writer.Write(fileData);

  20:             writer.Close();

  21:         }

  22:     }

  23:     catch { }

  24: }

The SerializeObject method returns a string which is then written to a file using a StreamWriter.

I added a Save method to the instance of the ApplicationSettings:

   1: public void Save()

   2: {

   3:     ApplicationSettings.Save(this);

   4: }

This preserved the functionality that exists in the built in Settings support in .NET (which was being used in my application).

By keeping all of the property names the same and making a few tweaks to the types of some fields in my application, I had swapped out the entire “settings” infrastructure in about 45 minutes.

I’m planning some other JSON activities within my application, so the overhead of using JSON.NET is acceptable.

The best part of this alternative is that there isn’t any magic. It’s all easy to manage. Further, I can easily modify my installer to properly handle/update, etc., the settings file with just a few clicks.

I’m not going back to the built-in .NET settings support again. I’ve learned my lesson.  Smile

What have you done for “user” settings?