Corporate Blogging Experiences

Introduction

I have been on a quest lately to improve communication within the corporate space. I have been primarily focused on using the latest social networking technology - namely, blogging technology powered by WordPress. I thought the following might be worth sharing in case it is of use to others.

Background

Five months ago, I instigated a movement at work by setting up a blog for my team which then blossomed company-wide (well, not really but I’ll explain more in a bit). I did this because I wanted a way in which to capture what I was working on as well as see what others were doing within the team. The idea was each of us is doing interesting things so lets share it. For example, maybe the problems that I am solving apply to something another person is working on and visa versa, maybe I learned a new way of writing code, or maybe I learned a new software trick that made what I do faster. I see blogs as a way to capture these nuggets of info that can be stored for future use as well as be easily searchable. It also serves as a way in which to record breadcrumbs of information allowing someone who is following your trail to easily pick up where you left off. If nothing else, blogs help foster a community. A way to make the job just a little bit more fun and interesting. That is the idea anyway.

To help build a foundation for those new to this type of software, I have given a tech talk, written documentation, created screencast tutorials, and provided many links for reference within the walls of the company. I spent a lot of time and effort making this possible because I believed in what I was doing and I also believed that the company get would become engaged.

In addition to the educational materials mentioned above, I have also been very active amongst all internal sites (which are roughly fifteen in total). In my team alone, I am the most active blogger posting things that I learn and develop on an almost daily basis.

To me the idea and its implementation was helpful and streamlined. However, the experiment did not turn out as I had planned.

Experiences

The problem was no matter how hard I tried to educate the company and its employees, only a handful made use of it. They would much rather stick to e-mail - which is overused in my opinion (see my post on Corporate E-mail Pitfalls for more info). The paradigm shift from e-mail to blogging (or anything that supports syndicated feeds) seemed too complex versus the status quo.

Because I view blogging as a way of life, I had no good answer to their objections. I view blogging as something you should want to try it out. The value is not necessarily realized by watching but by doing. This is HUGE hurdle to overcome because people need to get their jobs done and blogging can be considered wasted time.

My motivation stems from my use of what I write because if no one reads what I write then I will. As time rolls on, I might forget certain details and having a blog is an excellent way to go back in time and dig up something that I’ve done and might need to do again. That alone has saved me many times that the benefit far outweighs the cost. Even better, once you have written about it you can easily send a hyperlink to someone who might be asking you for advice.

Though I wish my passion for blogging had been shared by my company and fellow employees, I can not say that my experiences were purely positive. Out of the fifteen sites within the company today, only two of them are active. The rest have been abandoned. By this I mean that management has requested that all employees write weekly reports once a week that summarize what they have done, what they plan to do in the coming week, and any outstanding issues they might have had during the week. These reports can be useful but most are just badly formated noise. This counts as abandonment with no real involvement.

I remain optimistic, despite my particular obstacles, and hope that over time people will become more involved.

Lessons Learned

• Choose software that is easy to configure, maintain, and use. My choice, as mentioned, is WordPress, but there are others out there that might suite your needs better.
• Make sure some basic blogging guidelines are in place and people are aware of them.
• Appoint a champion early on to lead the effort and do not take this lightly. Not only do you need a champion but one who has the official blessing and approval of management. This needs to be made known company-wide.
• Start education early. Get people engaged and pick leaders from the various teams within the company to help you spread the love (so-to-speak).
• Provide plenty of tutorials and examples. Make it really easy for those who are stubborn or resistant to change to jump in. Anything you can do to lower the learning curve, the better.
• Do not let management mandate what people should or should not do. Any time there is a management mandate then it feels more like work and takes a bit of the fun out of it. This needs to grow organically.
• Actions always prove louder than words. Lead by example. Give people something to aspire to but don’t make it so daunting that they will be easily discouraged.

Parting Thoughts

Check out an article by Path & Vinegar called Egos and Silos and Social Media. Food for thought.

Tags: WordPress, WordPress MU

WordPress MU DNS/IP Conversion

Introduction

Lets say that you have installed WordPress MU using the directory instead of domain install (you can make only one choice and once made it is irreversible…well…not without a lot of work). Lets also assume that you have a lot of blogs up an running and you initially were only using an IP address for your server or maybe you were using a DNS name but have recently changed it to something else. None-the-less, you need to change the IP to DNS or simply rename an IP or DNS address for all posts/pages across all blogs.

What do you do?

Its a lot of work to go through ever single one of your blogs and fix every single post and page ever created. The following can help you fix up your WordPress MU settings by going into your MySQL database and making all your changes directly.

NOTE: I am making some assumptions here. I assume you are familiar with WordPress MU architecture and are comfortable with manipulating data in MySQL databases.

Setup

First, make sure you have installed PHP My Admin on your server. It is fairly straight forward to setup and use. You won’t regret it.

Backup

Once PHP My Admin is up and running, I recommend you backup the entire database before you proceed further. No need to start sweating bullets unnecessarily.

Applying the Solution

There are not many tools out there that I know of to help you in this endeavor so one must manipulate the data directly. As you know, with WordPress MU, the following table structure is created for each and every blog (each group of tables is numbered per blog ID):

All you really need to care about is the following tables of each and every blog:

• wp-posts
• wp-options

Simply export each “posts” and “options” table for each blog, do a find and replace on the IP or DNS name you want to change by using your favorite text editor, and then import the new tables back into your database.

The only other too tables you need to perform these same changes on is the following WordPress MU specific tables:

• wp-site
• wp-blogs

That is it, you are done!

Tags: WordPress MU

WordPress Migration

Introduction

Originally, when I first started my job, I installed WordPress for the team that I worked on as a way to easily communicate and share ideas. The popularity of what I had done for the team quickly spread throughout the entire company. Before long, multiple WordPress blogs were popping up. Eventually, from a system administration standpoint, having multiple WordPress blogs became a complete nightmare for managing users, themes, plugins, etc. so I started converting the multiple WordPress blogs to WordPress MU blogs instead.

The following is an analysis of the database structure for WordPress and WordPress MU and the things learned while migrating WordPress blogs to WordPress MU. This assumes you have some familiarity with both WordPress and WordPress MU, otherwise you can following the links provided above or learn more in previous posts by searching this site (specifically the WordPress Usage Demo and WordPress MU Overview).

Getting Started

There are many ways to convert WordPress blogs to WordPress MU blogs but the easiest is to probably grab the WordPress Import/Export Plugin and install it in your existing WordPress blogs (as this comes default in WordPress MU). Once the plugin is installed, you can export the data from each WordPress blog to an XML file which you can then import into WordPress MU. This plugin, unfortunately, completes only part of the conversion process as it only imports/exports your posts, comments, and category data. The rest you will have to do manually. Read on.

Directory Structure

By default, all files uploaded for a post/page usually go the <WordPress root>/wp-content/uploads/ directory. This directory structure is further broken down by month and day sub-directories.

For WordPress MU, the directory structure looks slightly different: <WordPress MU root>/wp-content/blogs.dir/<blog ID>/files. As with WordPress, this directory structure is also broken down by month and day sub-directories. The <blog ID> is a number that varies depending on the order in which one of your WordPress MU blogs were created. For example, lets say that you have the following WordPress MU blogs (created in the order listed):

1. My Blue Blog
2. My Purple Blog
3. My Red Blog

The IDs for each blog would be: blue = 1, purple = 2, and red = 3. The IDs of each blog can be easily found by logging into WordPress MU, clicking on the Site Admin --> Blogs menu, and looking at the IDs of each blog listed. These IDs will correspond to the directories associated with each blog.

With both directory structures understood, all you need to do is copy contents from the <WordPress root>/wp-content/uploads/ directory structure to the <WordPress MU root>/wp-content/blogs.dir/<blog ID>/files directory structure.

While this gets the data in the right place, this does not mean that your posts, pages, and comments are not linking to the data correctly. For that, you will have to manually go through and edit the URLs of each post, page, and comment. Alternatively, you might think about exporting the post and comment tables to an SQL file, doing a find and replace on the URL paths within the code of the SQL file, adjusting the paths for the new structure, and importing the updated SQL data back into the database.

Database Structure

The following is a structural view of the MySQL database used by WordPress MU. PHP My Admin was used to view each table of the database. As mentioned earlier, the same blog ID principals applied to the directories applies to the tables as well.

At this point, you probably do not need to be tweaking anything in the database. If you have used the plugin mentioned above and followed the steps for setting up the directories structures, then you can do the rest of the work within WordPress MU. However, there are some things that are done a little easier using the MySQL database directly. The following highlights the differences between WordPress MU and WordPress and provides a few tips for dealing with the various tables:

wp_<blog ID>_categories

Identical to the WordPress wp_categories table except for the additional fields highlighted in yellow: link_count, posts_private, and links_private.

When importing WordPress data into this table keep in mind that WordPress MU defaults the “Uncategorized” category to cat_ID=1 and the “Blogroll” category to cat_ID=2. This means that you will need to adjust the SQL code exported from your original WordPress table to use cat_IDs higher than a cat_ID of two to avoid conflicts.

wp_<blog ID>_comments

Identical to the WordPress wp_comments table.

wp_<blog ID>_link2cat

Unique to WordPress MU only.

wp_<blog ID>_links

Identical to the WordPress wp_links table.

wp_<blog ID>_options

Identical to the WordPress wp_options table.

wp_<blog ID>_post2cat

Identical to the WordPress wp_post2cat table.

wp_<blog ID>_postmeta

Identical to the WordPress wp_postmeta table. You might think about editing and updating the URL paths of the meta_value field.

wp_<blog ID>_posts

Identical to the WordPress wp_posts table except for the post_status field highlighted in yelllow. This field has two additional types: “inherit” and “future”. This will not cause any modifications to be made to your SQL code when importing data from WordPress into WordPress MU.

wp_blogs

Unique to WordPress MU only.

wp_blog_versions

Unique to WordPress MU only.

wp_registration_log

Unique to WordPress MU only.

wp_signups

Unique to WordPress MU only.

wp_site

Unique to WordPress MU only.

wp_sitecategories

Unique to WordPress MU only.

wp_sitemeta

Unique to WordPress MU only.

wp_usermeta

Identical to the WordPress wp_usermeta table.

wp_users

Identical to the WordPress wp_users table except for the additional fields highlighted in yellow: “spam” and “deleted”. In my case, I exported the user data from all WordPress site as separate SQL statements, joined them together, and imported the combined data into this table. When joining the user data together, just make sure that all user IDs are unique.

Notes

• The tables that are unique to WordPress MU means that the data they store are are common to all blogs being managed by WordPress MU. The blog specific data is always stored in a table that is identified by a unique number in the name. The number used is determined by the order in which the blog was created.
• There is a table in WordPress called wp_linkcategories that is unique to WordPress and not found in WordPress MU. The data this table stores is used to categorize your blogrolls in WordPress. With WordPress MU, the usage has changed. You can still add links to your blogroll but you end up using the same categories as used for posts instead of having different categories for each.

Conclusion

Hopefully this has been helpful and will get you pointed in the right direction. Feel free to comment on anything discussed.

Tags: WordPress MU

WordPress MU Overview

Experimented with WordPress MU this weekend and found it to be just as powerful as they describe in managing multiple web sites. The following is an overview of the differences between WordPress MU and WordPress and assumes that you are familiar with using the standard WordPress software.

Main Menus

The following screenshot points out the differences between the two menus. With WordPress MU you will see that there is a new Site Admin menu item. This is where most site management takes place. Also for some odd reason the Links menu is renamed to Blogroll and there is no longer an Import menu item.

Site Admin Menu

The following is a tour of the sub-menu items which are sort of self-explanatory. Sort of. As I become more experienced with WordPress MU I will most likely add some setup documentation to my WordPress page for anyone that is interested as the the WordPress MU documentation is almost none existent. Here is the sub-menu slideshow:

Options Menu

The rest of the menus are pretty much the same as the standard WordPress setup although they have added the ability to delete the entire blog within the options menu:

Notes

WordPress MU does have some complications. For example, not all themes and plugins work right out of the box using WordPress MU versus the basic WordPress setup. Be prepared to spend some time fixing your theme and plugin code in order to get the desired behavior you are used to when using the standard WordPress.

When using WordPress MU one should think about creating the initial site as your central site. For example, your company intranet. This allows everyone to have a central place for news and information including the addition or deletion of web sites.

WordPress MU does allow a user, via a hyperlink, to simply create a new web site. This is much the same bahavior as creating a new post or new comment.

You can create sites by domain name (i.e. domain1.foo.com, domain2.foo.com, etc.) or by sub-directory (i.e. www.foo.com/foo1, www.foo.com/foo2, etc.). In my case, I was using the latter. At installation time you are given both choices but once making the choice, there is no option for changing your choice. Choose wisely.

It is definitely nice being able to manage all web sites with the same themes, plugins, and users.

Tags: WordPress MU

WordPress TinyMCE Editor

For those using the default WSIWIG editor in WordPress (i.e. TinyMCE), you might consider disabling it and using either an external WSIWIG editor or just using the non-WSIWIG form of the editor. To do this, sign into WordPress and go to Users–>Your Profile from the main menu and uncheck the visual rich editor option:

The visual editor editor is useful for basic functionality but really starts to falter when you need to do more complex things like create page anchors, complex lists, add images (especially for those using the lightbox plugin), or other formatting.

Tags: WordPress, WordPress MU