Apparently I'm not the only one having problems with the categories after a Wordpress 2.6 upgrade.

So, time to give something back to the Wordpress community, some screenshots on how I fixed it.

First of all, I upgraded from 2.2.3 to 2.6, it's possible this solution will work for you, but I don't make any promises.

I started by going to phpMyAdmin and having a look at the wptermtaxonomy table, and noticed all the descriptions where missing.

When I took a look at the backup file I made, more specifically, the wp_categories piece, I noticed the counts and ids matched up.

I then manually edited each record, just hit the pencil icon, and filled in all my descriptions again. If you know some SQL you could do this faster, but anyway, everyone can do it manually :)

After I've done this, I visited my admin section and noticed the Descriptions were filled in again. But there was no Name, and all my posts still had empty categories linked to them.

To fix this, visit http://your-site/wp-admin/categories.php?action=edit&cat_ID=1 where 1 is the category id to edit. Fill in a Name and a Slug, the url name for your category, and save it.

Repeat this process for all your categories, until they all have a Name again.

And that's it! Categories fixed, posts linked, category urls working again.

Good luck!

We've seen quite a few patterns so far, and I'm glad so many people like them.

They turned out to be the most popular posts I've ever written when it comes to development. Thanks! :)

A little overview for the late joiners:

• Long Absence - Design Patterns
• Design Patterns - Strategy Pattern
• Design Patterns - Observer Pattern
• Design Patterns - Observer/Event Pattern
• Design Patterns - Decorator Pattern
• Design Patterns - Factory Method Pattern
• Design Patterns - Abstract Factory Pattern
• Design Patterns - Singleton Pattern
• Design Patterns - Generic Singleton Pattern
• Design Patterns - Command Pattern

Today we'll have a look at the Adapter Pattern.

As usual, the definition: "Convert the interface of a class into another interface clients expect. Adapter lets classes work together that couldn't otherwise because of incompatible interfaces."

To continue on our little game, we received a third party library from another team, containing some buildings to include in our game.

The developers of this library didn't work with IBuildings however, but call it a Structure, making all of our code which interacts with IBuilding unusable.

If we look at the definition, we can see the Adapter Pattern is the perfect solution for this, since we need to convert the interface of the third party Structure into the IBuilding we expect, so that they can work together as if their interface was compatible.

Let's have a look on how their interface looks like first.

There are some differences in the logic used in their implementation. We both have a Description, but the way we manage Power consumption is totally different.

Time to adapt their interface to the one we expect.

We'll do this by creating a new class, a so called adapter, which implements the IBuilding interface, since we expect that one, and which uses composition to encapsulate a Structure.

As you can see, our Adapter is actually behaving as an IBuilding to the rest of our code, adapting the calls to our interface into the third party their interface.

And that's it really! The easiest way I remember this pattern is by thinking of electrical adapters, changing the socket from US to UK, or transforming the voltages.

Time to have a look at the full diagram, with the official names written against it again:

Let's also write some test code to see the Adapter Pattern in action.

We can re-use all of our existing code with the new Structures, since it's behaving like an IBuilding right now.

I've uploaded the solution again to have a look at.

Feel free to leave any feedback.

Some additional information on the Adapter Pattern:

• Wikipedia - Adapter Pattern.
• Data & Object Factory - Adapter Pattern Overview.

A moment ago, I decided to upgrade to the latest Wordpress version, I was running a bit behind on 2.2.3 :)

The upgrade went quite smooth, all my plugins still work. But suddenly all my categories became empty strings. And the /tags/ urls didn't work anymore either.

After looking around a bit, I noticed my categories were stored in the wptermtaxonomy table, with empty descriptions. Thankfully I had a backup and manually entered the descriptions for all of them.

At this point, their names showed up in the admin section again, but the post weren't linked to them yet, neither did the /tags/ work.

A little more looking around, and I figured out to access categories.php?action=edit&cat_ID=20 for each category, where I had to enter the category name and category slug.

For some reason, each category's slug was suddenly named -2-2-2-2-2-2-2-2-2-2-2-2-2, with increasing -2 per category.

After doing all that, my /tags/ work again, and my posts seem to be linked again :)

If you notice anything broken, please comment to let me know!

What's a lonely geek to do late in the evening? Write about the Command Pattern of course...

Let's start with the definition: "Encapsulate a request as an object, thereby letting you parameterize clients with different requests, queue or log requests, and support undo-able operations."

And now, time for the spec I just made up: Our UI has three buttons at the bottom of the screen, which contain various actions. These actions are different depending on the selected item however. We need to implement this piece of UI code, without it having any knowledge of our game units.

How would we approach this? Let's say these buttons are nothing more than placeholders, to be filled with real buttons whenever a unit is selected. Our game engine will respond to a selected event and create and pass on the real buttons to our UI code.

So, our UI code will only need to know about one thing, a button. Let's create an interface for this type of button, and coincidentally name it ICommand :)

We'll code our UI code against the ICommand, respecting to program against an interface and not an implementation.

At the end, we'll need some real implementations as well however. So let's create some "buttons", which I'll call Commands from now on.

Right now we only have two types of items, GameUnits and IBuildings. Each Command will perform an action against one of these, encapsulating the object through composition.

For this example, we can make a GameUnit turn Aggressive, Normal and Suicidal. We can also power buildings on and off.

Notice these Commands themselves are written against interfaces as well, our good habits are already starting to pay off.

The NoCommand is a little tricky, it's just a dummy object, which sometimes is called a [Null Object(http://en.wikipedia.org/wiki/NullObjectpattern "Wikipedia - Null Object Pattern") as well. It's being used for buttons which don't do anything, basically their default value.

It's time to create our UI code, the GameControls class. This class will contain the three buttons, ICommands, and helper methods to assign real buttons into the placeholder slots, as well as triggering button clicks.

Additionally, there's another requirement which has surfaced. We want to be able to undo our last action, whenever possible, can't undo suicide ;)

We'll accomplish this by storing the last ICommand, and when an undo action is needed, call the Undo() method on it, since each command provides the exact opposite of Execute() in it's Undo() method.

That's all the code that was needed to implement the Command Pattern actually.

Our GameControls class has no idea GameUnit or IBuilding exists, it's totally decoupled from them.

By using Command objects, we can treat them as little blocks which can be stored in a queue for multiple level undo, we can let several threads pop commands of a queue to process them in parallel, and much more.

Let's have a look at the full diagram, with the official names written on them as well.

Time to put our code into action and test it.

Let's imagine we have a full blown engine, and when a unit is selected, various events get fired, resulting in the creation of the correct ICommand objects, being passed to our GameControls UI code, which causes buttons to be displayed on screen. We'll also simulate a click on the various buttons and the undo button.

That's it! I've uploaded the solution for the Command Pattern so you can have a look at the code of the Command Objects and the details of the GameControls.

Questions? Feedback? Comment!!

Some additional information on the Command pattern:

• Wikipedia - Command Pattern.
• Data & Object Factory - Command Pattern Overview.

A little follow up from yesterday's Singleton Pattern, where I asked for some help on how you would approach a generic singleton.

With the help of Andrew Stevenson and ExNihilo, we came up with the following Generic Singleton Pattern:

Using Reflection, the private constructor is called to create an instance of the class.

Whenever a Singleton is needed now, the only thing to do is to inherit Singleton and pass in the class itself as T, along with making the constructor private.

I've updated yesterday's solution to contain this new code as well, have a look.

I'd like this post to draw some attention from CLR guru's to have a look at the implementation and point out possible problems and how to solve them.