Behind The Blog

---

With Twitter releasing their new “Tweet Button” yesterday, I was naturally interested in figuring out how to add the button to this site. Mashable had the first post out that I saw explaining the easy steps: “HOW TO: Use Tweet Buttons as a Blogger or Site Owner“. In going to Twitter’s “Tweet Button” page, it’s a fairly straightforward process to get the code you need.

---

THE PLUGIN

However, I want to make system admin of this blog server as painless as possible so before I added the code to our theme I looked around for a plugin. I was delighted to see in the comments to the Mashable post that a gent named Alex Cristache had already coded up a “Twitter Button Plugin for WordPress” plugin.

I downloaded and installed it into the wp-contents/plugins and activated it for one of our blogs. (More on site-wide activation in a minute.) It has a very easy to use admin screen that appeared from a link at the bottom of my admin navbar. (Note: I’m still running WPMU 2.9.2 here, so with 3.0.x it may appear differently.) The panel lets me make various config choices. I left it all at the defaults except for three areas:

1. I needed to change the Twitter user name to ours.
2. I changed the recommended user (Alex, the plugin author ) to be one of our other Twitter accounts. This will apparently appear in the window from Twitter after you share the link,although it’s not doing so for me right now. (probably a load issue at Twitter):
   
3. I changed the “margin-top” attribute in the CSS so that the Tweet button appeared in line with the top of the article text. This is a personal preference thing… and I like it this way.

With that, the tweet button was up and running on one of the blogs. I went on to test with another and all worked fine.

---

SITE-WIDE ACTIVATION

We support about a dozen active blogs on blogs.voxeo.com and I really didn’t want to have to go to each one to change around these defaults…. so I started hacking the code before doing the “Activate Site Wide” link.

Diving into wp-content/plugins/wp-twitter-button, I opened twitter-button.php and changed these lines:

function tb_activate() {
        $default_settings = Array(
                'tb_home' => 1,
                'tb_archive' => 1,
                'tb_feed' => 1,
                'tb_page' => 1,
                'tb_box' => 'vertical', // can be none, horizontal or vertical
                'tb_style' => 'float: left; margin-right: 10px; margin-top: 20px;',
                'tb_position' => 'before', // can be before or after
                'tb_via' => 'Twitter',
                'tb_recommended_id' => 'Blogsessive',
                'tb_recommended_description' => 'Blogging, Social Media and ...'
        );

 

to these lines (changes in red):

 

function tb_activate() {
        $default_settings = Array(
                'tb_home' => 1,
                'tb_archive' => 1,
                'tb_feed' => 1,
                'tb_page' => 1,
                'tb_box' => 'vertical', // can be none, horizontal or vertical
                'tb_style' => 'float: left; margin-right: 10px; margin-top: 0px;',
                'tb_position' => 'before', // can be before or after
                'tb_via' => 'voxeo',
                'tb_recommended_id' => 'tropo',
                'tb_recommended_description' => 'Tropo is a powerful yet simple API ...'
        );

(Note that I have not included the entire “recommended description” in this code example purely for space/layout reasons with this blog post. In the file I have the full descriptions.)

I then went ahead and clicked the “Activate Twitter Button for WordPress Site Wide” link on my Plugins panel and it worked fine.

---

THE END RESULT

I now have the official “Tweet” button working on my WPMU 2.9.2 install and it seems to be working fine. The issues I see so far:

1. TWEET COUNT IS OFF – It seems the big issue everyone has right now is that the count of the number of tweets is off a bit. Commenters to the Mashable post and to the WordPress plugin page both indicate this is a problem. The plugin author stated this:

That ZERO tweets “bug” is actually caused by Twitter’s method to calculate tweets. They calculate them based on the number of search results on Twitter for the shared URL, and since their search history doesn’t go that far behind, some of the posts will display 0. The API they have provided is still far from perfect, but I think they said the button is hosted on a different server which might mean that from now on, all counts will not depend on the search anymore so new posts should be fine.

 

2. WISH THE NUMBER WOULD NOT SHOW IF “0″ – Given that count issue, I wish there was the option to NOT display the count if the number of tweets is zero. It’s just a perception thing… I’d like to not show that a particular article hasn’t had an Twitter-love yet (particularly if it did have tweets and now doesn’t have a count as an artifact of Twitter’s problems) I intend to make the suggestion back to the plugin author… but this may be a Twitter issue.

 

3. DO RECOMMENDATIONS WORK? WHAT IF I ONLY WANT ONE? – So far when I’ve tweeted out a blog post using the button, I’ve not yet seen the “recommendations” screen that Twitter says we’ll see. Is Twitter not displaying it right now? Does it work? What if I don’t want to recommend a second account- do I just leave that field blank in the plugin panel?

Obviously before I can answer any of that I have to see recommendations.

 

Overall, though, it seems to be working great. Kudos to Alex Cristache for coming out with this plugin so quickly. It’s a great help and saved me from hacking away on my theme.

Anyone else found another way (or plugin) to do this? What have you found so far?

If you are a WordPress developer looking for an interesting new project, or if you have an existing WordPress statistics plugin and are looking for ways to add more to it, here is the kind of plugin I would love to have available to me….

Last night I wanted to create a graph of the site-wide quarterly trend in the number of blog posts published across ALL blogs on our blogs.voxeo.com corporate blog portal. After looking through a great number of potential WordPress plugins (with special thanks to the always awesome Andrea_R for her pointers), I got rather frustrated because most of them seem to focus on either site-wide visitor stats, which I’m already tracking through Google Analytics, or provided some “activity” stats – but only for a single blog.  (And if I missed one that does what I outline below, I’d love to hear about it.)

I did finally get the kind of chart that I wanted… but through a kludgey use of SQL and Excel that I’ll describe below.  Here was my end goal:

---

THE REASON

My purpose in this was somewhat simple – I wanted to see and chart the growth of our content creation efforts on the blog server.  I want to show trends in the amount of content we are publishing… and then potentially tie those in to other trends such as increased visits (which I track through Google Analytics) and increased sales inquiries (tracked through Google Analytics and SalesForce.com).

I have other reasons, too. We have set up a number of different blogs on different topics. I would like to be able to see which of the blogs we are writing in more often than others… and which might need some attention – or potentially archiving.  I’d like a chart like the one above for each individual blog over time… or perhaps with the ability to graph multiple blogs on the same chart as a comparison.  You could see this being interesting data in a larger organization with different teams creating different blogs… to see which teams are creating the most online content.

To that point, it would be interesting to see which users are generating the most content… conceivably across all blogs.  In part from a individual performance point-of-view, and in part from a site-wide “health” point-of-view.  Our blog portal used to only have posts written by me. Now there are a good number of writers and to me that is the sign of a healthy content creation environment. As the one responsible for the overall site, I’d like to be able to see how the contributions are across the site.

I’d also like to be able to see the trend in comments.  How many comments?  How many track/pingbacks?

I’d like this data available in a quarterly basis, as I’ve shown here, and perhaps also in a monthly or weekly basis. Maybe even yearly if the site has been around for a bit.

---

THE IDEAL PLUGIN

In my mind, the ideal plugin would be something that is a panel in my WordPress admin interface where I go to generate these reports.  For performance, I wouldn’t want this hitting the database and running all the time – but just there to generate on-demand reports.  Some of the ideas I would like to see:

• Allow me to set a date range
• Choose from weekly, monthly, quarterly and yearly  (perhaps daily needs to be in there, too)
• Allow me to choose which of the blogs I want to get trends on (some of our blogs are experimental or, like our Events blog, have pages only and no posts)
• Choose whether to get trends on only public blogs or also private blogs
• Choose whether to aggregate all data together or to graph blogs separately
• Graph different types of data:
  • Count of posts by blog (or in aggregate)
  • Blog posts by user
  • Comments by blog (or in aggregate)
• Allow some modification of the title, legend, etc.
• Or… alternatively… just create a CSV file with all the data that could be brought into Excel

There’s probably more, like overall word count and stats like that… but that’s a start.  If you are reading this, what would you like to add?

---

THE KLUDGE

To get the chart I wanted, I had to sweep away some of the cobwebs on the SQL knowledge in my brain and play around at the MySQL command line.  I logged into the blog server, launched “mysql“, connected to the “wordpress” database and started playing around with “select” statements.  There is a table, wp_blogs, that lists all of your blogs and, most importantly, shows the “blog_id” for each blog.  For each blog, there is then a table named “wp_<blog_ID>_posts“, as in “wp_4_posts” which contains the info about the posts, dates, authors, etc.  I found that I could get the data I wanted by doing this:

 select ID, post_title, post_date from wp_4_posts where post_type = 'post' and post_status='publish';

Now, I didn’t include “post_author” in my work last night, but I wish I did because it would have let me gather the author stats I want.  Anyway, I continued mucking around until I eventually came up with a SQL statement that gave me a pipe-delimited text file that I could easily import into Excel on my Mac. (I couldn’t use commas because some of my post titles have commas!)  Naturally I then had to automate the process so I hacked up a very quick python script to create the relevant SQL statement and then send that to MySQL.

import os

for i in [4,7,8,11,12,13,15,16,19,22,24]:   # This is a list of the blog_ids of the blogs I care about

    target = "select ID, post_title, post_date from wp_"+str(i)+\    "_posts where post_type = 'post' and post_status='publish' ORDER BY post_date INTO OUTFILE '/tmp/b"+\    str(i)+ ".txt' FIELDS TERMINATED BY '|';"

    os.system('mysql wordpress -e "'+target+'"')

Like I said… a total kludge.

The end result was a series of pipe-delimited text files that I could import into Excel, combine together, and do some kludging there to get me the quarterly data which I could then chart.

If I knew how to use the various MySQL modules for python, I’m sure it could have been done much more elegantly. (And yes, I know that the python “os” module is deprecated in newer python versions and “subprocess” should be used instead… I’m old school and this was a quick late-night hack.) Or if my SQL knowledge weren’t so rusty, there’s probably some big SELECT statement that could join this all together and give me a nice unified output, perhaps even with the counts I want.

---

THE FUTURE

And if someone out there is handy with SQL or already has a WordPress plugin that does some or all of this… it would be great to see!  Given that my usage of WordPress MU (yes, I’m still on 2.9.2, but will be moving to 3.0 soon) is for a corporate blog portal, these are the kinds of statistics and trends that are of interest.  I would think that even if someone were running a more open site, these kind of trends would be helpful to know and understand.

Hopefully there’s just some plugin out there that I’ve missed!

What do you think?  What would you want in a plugin like this?

What do you do if your company has multiple blog sites that you want to maintain as separate distinct sites with their own domains? You could, of course, install a separate instance of WordPress for each domain and run them on separate servers, etc. But if you have your nice shiny WordPress MU running, why couldn’t you just run the different sites on the single instance of WPMU?

The answer of course is that you can very easily do this courtesy of the Domain Mapping Plugin for WordPress MU.

Astute observers of this Voxeo blog site might have already noticed that if you view our blog portal at “blogs.voxeo.com” you might see (depending upon when you visit the site) blog posts from the Tropo blog, as in this image:

When you click on that link, though, you are taken to a site with a different look and feel:

and, in fact, the domain name is different. While the portal and most of the other blogs are off of the “blogs.voxeo.com” domain, this Tropo post is off of “blog.tropo.com“.

Both sites, though, are running on the identical WordPress MU server.

Here’s what I did:

STEP 1: INSTALL THE DOMAIN MAPPING PLUGIN

First I downloaded the Domain Mapping plugin code from the plugin page at the WordPress.org Plugin Directory. I then followed the installation instructions with regard to putting the files in the appropriate places and making necessary edits:

1. Copy sunrise.php into wp-content/. If there is a sunrise.php there already, you'll just have to merge them as best you can.
2. Copy domain_mapping.php into wp-content/mu-plugins/.
3. Edit wp-config.php and uncomment the SUNRISE definition line: define( 'SUNRISE', 'on' );

STEP 2: CONFIGURE THE SITE ADMIN SETTINGS

With the plugin installed, I had a new menu choice under “Site Admin” called “Domain Mapping” where I simply entered the IP address of the blog server and the host name to use for CNAME records (and yes, I crossed out IP address in the image):

STEP 3: CONFIGURE APACHE TO HANDLE NEW DOMAINS

In order for this to work, your webserver has to be able to know that it should be answering HTTP requests for a domain name and what content it should serve up for that domain. In our case, we use Apache and so I edited httpd.conf and added a “VirtualHost” directive pointing blog.tropo.com to my WordPressMU installation (not the real IP address, obviously):

<VirtualHost 1.2.3.4:80>
        ServerName blog.tropo.com
        DocumentRoot /var/www/html/wpmu
</VirtualHost>

Now, I do understand that I actually didn’t need to specifically create a separate VirtualHost entry for blog.tropo.com because I already had an entry for blogs.voxeo.com and because that entry is listed first it would be the default entry for unspecified domains. However, for my own sanity and ease of administration, I like creating separate VirtualHost directives for each domain so that I can easily see in the Apache config what domains it is answering for. More info about using the VirtualHost directive can be found in the Apache documentation. Obviously if you are hosting a zillion domains, you may not want to do this… but in my case I’m only hosting a few.

A quick restart of the Apache server and it’s now ready to answer for that domain.

STEP 4: CONFIGURE DNS TO POINT DOMAIN TO YOUR SERVER

At this point, you need configure your DNS records to actually point to your WPMU server. In my case, I requested our network operations team to add a CNAME record pointing blog.tropo.com to blogs.voxeo.com. In DNS-speak, the record looks like this:

blog.tropo.com.         120     IN      CNAME   blogs.voxeo.com.

For good measure, we also had them point “blogs.tropo.com” over to blogs.voxeo.com in case someone mistyped “blogs” instead of “blog”.

STEP 5: CONFIGURE THE BLOG SETTINGS

With DNS now pointing to your WPMU server, the final step is to configure your blog to respond to this new domain. In the WPMU dashboard for your blog, under the “Tools” menu, there is now a new “Domain Mapping” menu choice as shown in the screen capture on the right side.

This screen lets you add domains to the blog and also configure which domain you want to be the primary domain. Here is a shot of what the page looked like during the setup process after I had added blog.tropo.com to the blog setup:

Once you save the settings and choose the primary domain, your blog now answers with that domain name. If you look at blog.tropo.com you will see that it is its own site and has no sign of being hosted on the “blogs.voxeo.com” server.

[NOTE: The visual difference is because we created a separate WordPress theme for the Tropo blog. It could, of course, have continued to use our standard theme but just started answering from the new domain.]

One note about adding domains…. the box to add a new domain already has “www.” at the beginning, but you do in fact enter the entire domain name into that box, even if you will never use “www.” on the domain. For instance, here I added “blogs.tropo.com”:

I am guessing that the creators of the plugin added “www.” to the beginning of the field so that novices to DNS wouldn’t enter in “www.example.com” if they really wanted “example.com”. I don’t really know why they did it… the key point is that you enter into that box the domain name you want to point to this specific blog.

With the new domain added, here is what the page now looks like – note the link to delete a secondary domain if I wanted to:

That’s it… with these five steps you are done. Your blog will now answer to a different domain name and, with a different theme, can appear to be a completely different site.

DOMAIN MAPPING AND WPMU SITE-WIDE FEATURES

There is one caveat to all this… if you go back to the beginning of this post, I suggested you go to the blogs.voxeo.com portal and click on a Tropo link, which brought you over to a blog.tropo.com post with a different look and feel. There is also one big gotcha here:

There is no way to get back to the Voxeo blog portal from the Tropo blog.

There you are, on the Voxeo blog portal… as you go through the posts for the various (non-Tropo) blogs, they all have the same look and feel and you can easily navigate back to the blog portal or to other Voxeo blogs. Then you click on a Tropo blog link and… ta da… you’re on some other site with no way to get back.

Now this was a deliberate design choice on our part. We want the Tropo blog to be a completely separate site. That’s our choice. And yes, we’ve thought of adding a link to “Other Voxeo blogs” and we may well do that… but for the moment the sites are separate.

My point is that the “blogs.voxeo.com” portal page uses a plugin to display the last 5 entries across ALL blogs hosted on the site.

That plugin doesn’t differentiate between “blogs hosted on the site that answer to ‘blogs.voxeo.com’” and “blogs hosted on the site that answer to other domains“. It just displays the last five posts across ALL hosted blogs.

In our case, I’m okay with it displaying all posts. I want the portal to be an aggregation of all Voxeo content posted out to the web. I’m okay with the user experience of dropping someone into a different site and requiring them to use the Back button on their browser to return to the blog portal.

I’m personally okay with that – but you may not be when you do your own domain mapping…

You need to think about how “site-wide” features will interact with blogs hosted on different domains. If you have a “portal page” like we do that displays the last X posts, will you have it include those from other domains (as I do)? If you use the “site-wide tags” plugin, will you include all posts from all blogs in those lists?

If you do NOT want to include posts from those other domains, you’ll have to muck around with your site-wide plugins to figure out how to constrain the blogs that are included in those plugins. I don’t have any answers here on how easy or not it is to do. I can imagine what I would probably have to do with the site-wide listing I use for our portal page… but again, I don’t have an issue with the current setup. Anyway, you need to think about this.

WHY AM I DOING ALL THIS?

You may be wondering why I went through all this with the domain mapping. The answer is really this:

I want to simplify the amount of system administration we have to do.

With separate WordPress installs, you have to administer each one individually. Separate WordPress upgrades… separate plugin upgrades… separate backups… etc., etc., etc.

I don’t want that. I want to run our sites on one server that I can then centrally administer, backup, etc. I can also easily add or change plugins and make those new features rapidly available across our blogs. If it’s easy to administer, it’s also easy to backup and restore… and I’d rather be writing content than doing sysadmin.

From the Voxeo perspective, setting up “blog.tropo.com” was the first step. We also just moved “labs.voxeo.com” from a static site to one based on the blog server. In the future we’re going to look at moving blog.imified.com over onto this server and maybe even the VoiceObjects developer portal (we’ll see on that one). We also have some older sites like RocketSource.org that we may bring over to host on the site and give them an update in the process.

All in all this ability to do domain mapping is just another example of the power that WordPress gives you to create a blog site for your company or organization.

I hope this post helps with setting this up… feel free to leave comments or questions, although I will say that I have no affiliation with the domain mapping plugin beyond simply using it, so while I can answer questions about what we did, I may or may not be able to answer broader questions about the plugin.

I was delighted to see over the weekend that WordPress 3.0 Beta 1 is now available as this release promises to solve one of the biggest headaches for a WordPress MU administrator – staying in sync with the main WordPress stream – with “the merge“.

Yes, indeed, with WordPress 3.0 the separate “WordPress MU” will go away and “WPMU” will simply become another mode of the main WordPress stream. Per the beta instructions on configuring multi-site capability, it appears that all we’ll have to do is set a WP config variable:

define (‘WP_ALLOW_MULTISITE’, true ) ;

I say “it appears” because I’m admittedly too chicken to try out the WP 3.0 Beta 1 on this production site. After all, the blog post is very clear that 3.0 Beta 1 is an “early” beta. However, I may certainly try it out on one of my staging/testing servers. I’m looking forward to continuing to watch the evolution and to eventually running it here.

---

P.S. Since this “Behind The Blog” site seems to often be read by people investigating WPMU, let me explain the issue a bit more. Right now, WordPress MU is a separate installation from regular, plain-old WordPress. However the main development and evolution of WordPress happens on the regular WordPress code base and then is ported over to the WPMU code base. As a result, when a new version of regular WP is released there is a time delay before when the corresponding version of WPMU is available. Sometimes this isn’t a big deal… but sometimes you might want a specific WP fix or feature in WPMU sooner than the team is able to port it. Also, there are two places to report bugs (WP and WPMU) and also submit fixes, etc.

With WordPress 3.0, the two code bases will be merged so that there is only one stream of code going forward. This should make it much simpler for site administrators overall – and ensure that WPMU sites can always be up-to-date with the latest “regular” WP fixes and features.

Way back in late 2007 when I launched blogs.voxeo.com, one of my very first problems was in trying to figure out how to include snippets of VoiceXML, CCXML and CallXML code. I wrote about trying a number of different WordPress plugins back in March 2008 and at the time didn’t have much luck. When we have been including source code in blog posts, it has admittedly been using the über-kludgey way of converting all the XML tag syntax into HTML character entities, inserting non-breaking spaces, etc. A serious kludge.

Over the weekend I saw the recent post on the WordPress.com blog about posting source code which pointed me to the excellent “SyntaxHighlighter Evolved” plugin from “Alex / Viper007Bond” (view his plugin page) that is in turned based on the JavaScript SyntaxHighlighter package from Alex Gorbatchev. I installed it in WordPress MU, tested it out on an experimental blog I use for testing and then activated it sitewide.

Now, when I simply bracket VoiceXML code with “[ xml ]” and “[ /xml ]” (without the spaces), it comes out looking great. Here is an example:

---

<?xml version="1.0" encoding="UTF-8"?>
<vxml version = "2.1" >

  <form>
    <block>
    <prompt>
      Hello World. This is my first telephone application.
    </prompt>
    </block>
  </form>
</vxml>

---

It is, of course, not limited to merely XML. There are 20+ languages listed on the SyntaxHighlighter ’syntax files’ page. I expect that we’ll be using it now to be able to better write about the Tropo.com languages over on the Tropo blog.

One aspect I quite like about the plugin is the menu you get when you move your mouse over the source code. As shown in the image to right, you can easily:

• view the source code in a pop-up window
• copy the code to your clipboard
• print the code

Given that we’re planning to make more tutorials available, having the ability to copy and paste the code easily directly from the blog post is a great feature.

Many kudos to the two Alex’s for making both the underlying JavaScript library and also the WordPress plugin. And if you run a WordPress or WordPress MU site, you can download the SyntaxHighlighter plugin and install it in your site, too.

P.S. I should in fairness point out that a couple of colleagues have mentioned SyntaxHighlighter to me over the past few months… I just never had a chance to check it out until now.

---

UPDATE #1, a few minutes after posting: So it seems I still need to work out a kink in my own process. I almost always write my posts offline using the MarsEdit editor and then publish them to the blogs.voxeo.com site. However, when I did that with this post, I wound up with code that had tags escaped as HTML character entities:

I had to go back into the WPMU editor on the website and paste in the correct VoiceXML code.

I’m not sure if the issue is with MarsEdit, my WPMU config or the SyntaxHighlighter plugin… but obviously I can’t really write posts with code in them offline until I figure it out…

Back in June, I asked about what people thought the best plugin was for publishing updates to Twitter when there are new blog posts posted here in WordPress MU/WPMU. I was then and have been using Alex King’s excellent Twitter Tools plugin for WordPress, but it was a bit like using a screwdriver to bang in a nail. The Twitter Tools plugin is primarily designed to capture your tweets in a blog post so that you can have occasional posts on your blog site that include all your tweets. The plugin can also publish tweets when you have a new blog post, but it’s real strength seems to be in pulling your tweets into your blog.

All I want to do is publish new tweets… I don’t want to create blog posts with tweets. So I’ve known for quite some time that I’ve been using the wrong plugin for the job… but it’s worked okay, so I continued. I tried a different plugin over on the VoiceObjects Developer Blog, but I haven’t been as happy with it because it tended to shorten the titles of blog posts too much when posting to Twitter.

However, recently my colleague Ron Blaisdell pointed me to WordTwit from BraveNewCode and I have to say that it is outstanding at what I need it to do. Once you install the plugin, there is a very simple configuration screen where you enter your username, password and can change the format of what gets tweeted out:

In our case, I chose to edit the message to be “[title] - [link]” so that there is no prefix on any of the tweets.

You then can choose which URL shortener you want to use – I chose bit.ly:

After you save the configuration options, you then can go back in and enter your Bit.ly login and API key:

This makes it so that all of your shortened URLs then show up in your bit.ly account where you can see statistics around who has clicked on them, etc.

Because we use Google Analytics, I also checked off an option to add UTM tracking codes to URLs so that I can find any inbound traffic in GA easily.

I’ve been using WordTwit here on blogs.voxeo.com for a bit now and have been very pleased with how well it works. I haven’t yet installed it on the VO Developer Blog but will be doing so soon. Kudos (and thanks!) to the folks at BraveNewCode for developing such a great plugin.

Have you tried WordTwit? Or what plugin do you use for updating Twitter?

A few days ago, someone wrote to ask me about what I consider “best practices” in managing user accounts on a WordPress MU installation. Recently this person had set up a new WPMU server with a number of different blogs. In the rush to get it operational the system administrator had just set up a single user account with rights to all the blogs and given the username and password out to something like ten different people who published posts.

I got the impression that the person who contacted me wasn’t sure this was the best plan and was looking for any confirmation of that. I wrote back but then thought I’d share my reasons here as well.

For starters, no, it’s definitely NOT a good idea to have a bunch of people using the same WPMU user account.

Definitely.

Not.

Several reasons:

---

1. SECURITY – If one of the authors leaves the company, or you decide to terminate one of them, that person will know the username/password. You’ll need to change the password and then get the new password out to all the other posters. Much easier if you give everyone their own username and password. Then if you need to part ways with someone, you just disable that one account from being able to login and you are done.

2. AUDITING – What happens if a post goes up that was not supposed to? Or was offensive or plagarized? How do you know WHO was the one who published that post? With a group of people sharing the login you don’t have an easy way of finding out who published the post in question. Perhaps you can try to correlate IP addresses with login sessions or something like that, but it’s hard to get right. If everyone has their own account, you know who published any particular post because a name is associated with it.

3. AVAILABILITY – What happens if one of the group resets the password? Or what if there is some database problem and the single account gets disabled? Suddenly no one can access the blog site. Far better to have the multiple accounts so that authors can still get into the site if there is a problem with one of the accounts.

4. APPEARANCE – If you have a community of blogs with one user account, all posts are going to be from that one user, which would certainly give me the perception that it’s not really that big of a “community” of blogs. With multiple accounts publishing the posts, your sites will look like they have more contributors to the individual blogs – which, in fact, they do. There is also a transparency/authenticity element to this, too, in that people can come to understand more easily that there are different authors on your site with different writing styles.

5. OWNERSHIP – Sort of going along with #2, if everyone publishes posts under their own name, I would believe that there is a bit more of an incentive for them to be sure that the posts are accurate with regard to spelling, etc. If it’s under “someone’s” name, there isn’t as strong a sense of ownership – but if it is your name, even just your first name, there is a bit more ownership at a psychological level.

---

For me personally, point #1 alone carries the day and is why I assign individual user accounts to everyone who writes on this site. I don’t expect anyone to leave (but do we ever?)… I expect them to be here a long time… but if I want to disable someone’s access to this server, I want to be able to do it on an individual basis. My point #2 is big for me, too, as I want to be able to know who makes what changes to the site.

Sure, if you have a network of blogs, it may take a few more minutes to set up new user accounts and assign them to each of the blogs… but we’re talking minutes, not hours or days. A small investment that can have a big payoff later.

What about you? Do you assign everyone individual user accounts? For the same reasons I outline? Or do you have additional reasons?

Here’s the next thing I want to do to this blog site – see that graphic over at the top of the far right sidebar? The one that is currently announcing Voxeo Labs? We’re building up a group of similar graphics as we make more announcements.

So here’s what I want to do – when we have a major announcement out, I obviously want to have that image be a static image that points to the announcement blog post. However, between major announcements, I want to dynamically cycle through those graphics so that visitors see the links to different announcements we’ve had in the past.

In my ideal world, I want a plugin that lets me configure a table like this:

Image URL	Link URL
http://blogs.voxeo.com/voxeotalks/files/2009/05/imifed-button.png	http://blogs.voxeo.com/voxeotalks/2009/05/27/voxeo-acquires-imified-and-gains-ivr-type-self-service-for-im/
http://blogs.voxeo.com/files/2009/07/VoxeoLabs_button.png	http://blogs.voxeo.com/voxeolabs/2009/07/22/adhearsion-and-voxeo-join-to-create-voxeo-labs

and then just cycles through those graphics on an ongoing basis.

I figure there must be a WordPress plugin out there that will do this… it seems like something people would want to do for incorporating rotating ads into a site. I just haven’t yet done the research… and figured out which of the plugins then work with WPMU.

That, though, is one of the next things I’ll be looking into for this site…

The slides are now available on SlideShare for the talk I gave last Thursday at O’Reilly’s OSCON entitled “Building a Corporate Blog Portal using WordPress MU“. The presentation went well and I had some great interaction with those attending. I did record the session on video so I am aiming to get that video out this week.

In the meantime, enjoy the slides…

If you have been reading posts on the Voxeo blog site, you’ll notice that any posts that I have written have included this footer at the bottom of the text:

---

If you found this post interesting or helpful, please consider either subscribing via RSS, becoming a fan on Facebook or following us on Twitter.

---

I want to include this as a direct note asking people to join us in the various conversational services (FB, Twitter) or to subscribe. Yes, we have the same links in our first sidebar, but I also want it in the post itself.

However that text does not show up on anyone else’s posts – only mine. The reason, of course, is because I have been manually adding that footer when I write the blog posts in MarsEdit. This obviously has several problems:

1. As mentioned, it only shows up on my posts.
2. I have to remember to manually add the footer.
3. On the rare occasions when I post through the WPMU web interface (or a mobile interface), the footer doesn’t get added there.
4. Because I have different footer macros in MarsEdit, they have over time gotten out-of-sync. For instance, they have used different URLs for getting to Voxeo’s Facebook page.

This has been very clearly something to automate through adding it to our theme… it’s just been an issue of not having enough of those darn “round tuits”. Today I finally made the change.

Now, the first intuitive place for me to look down in our “voxeo-default” theme was naturally footer.php. However, that puts any text way down at the bottom of a page. I wanted it to appear right up underneath the body text of an entry.

THE SOLUTION

It turns out that there were really three places I needed to add some text. Rather than adding the footer to three separate files, though, I first created a new file that I called “post-footer.php” and included this text:

     <hr>
     <p><em>If you found this post interesting or helpful, please consider either
     <a href="<?php bloginfo('rss2_url'); ?>">subscribing via RSS</a>, becoming 
     <a href="http://www.voxeo.com/facebook/">a fan on Facebook</a>, or 
     <a href="http://twitter.com/voxeo/">following us on Twitter</a>.</em>
     <hr>

Note that I’m using a WordPress variable to show the blog feed appropriate to the specific blog, but in the case of Facebook and Twitter they are both static URLs. (You’ll also note I’m using “http://voxeo.com/facebook” versus “http://www.facebook.com/voxeo“, which does also work, primarily because I’m interested in tracking click-throughs.)

Next, I started changing the relevant files. First, I changed the single.php file to have the following additional text (in red italic):

<div class="entry">
     <?php the_content('<p class="serif">Read the rest of this entry »</p>'); ?>
     <?php wp_link_pages(array('before' => '<p><strong>Pages:</strong> ', 'after' => '</p>', 'next_or_number' => 'number')); ?>
     <?php the_tags( '<p>Tags: ', ', ', '</p>'); ?>
     <?php include (TEMPLATEPATH . '/post-footer.php'); ?>
     <p class="postmetadata alt">

Ta da… this footer now gets added to all posts to our blog site when they are individually viewed.

Second, I changed “index.php” to have this text:

<div class="entry">
     <?php the_content('Read the rest of this entry »'); ?>
     <?php include (TEMPLATEPATH . '/post-footer.php'); ?>
<div>

This addressed the display of posts on the “main” blog page such as http://blogs.voxeo.com/voxeotalks/.

Finally I changed “archive.php” to look like this:

<div class="entry">
     <?php the_content(); ?>
     <?php include (TEMPLATEPATH . '/post-footer.php'); ?><div>

which gets archive pages of multiple posts such as http://blogs.voxeo.com/voxeotalks/2007/12/.

Note that because I modified single.php, anytime anyone clicks on any of the posts shown in the blog index or archive, they will see the post wrapped in the single.php template. If you didn’t want such a footer to appear for each post in the blog index or archive, you could simply not modify those files. I wanted to have the footer appear in all three views.

ALL IS GOOD, RIGHT?

The great aspect about this approach is that I can simply go into our theme and modify that single “post-footer.php” file if I want to update that footer text. For instance, at some point I may actually start using Voxeo’s identi.ca account and so I may want to add that link there.

Going back to my original four issues with manually adding the footer:

1. The footer now shows up on all posts on the site.
2. It is done automatically so I don’t have to remember to include it.
3. Because it is on the display end of WPMU, it doesn’t matter how the blog post is created. It can come in through MarsEdit, through the WPMU web interface, through a mobile interface or really any other means.
4. Footers across blogs never get out of sync because it’s the identical footer across all blogs.

ALMOST…

Now, here is one problem… the footer only shows up when the post is displayed on our site.

My main reason for starting to use the footer, really, was because I saw our content being scraped via the RSS feeds and appearing on other people’s sites. I therefore wanted to include the footer so that those sites blindly scraping our content would wind up including pointers back to our site and accounts.

Ideally, I like to really inject this footer at the time a blog post is created so that it is in the actual content of the post rather than the wrapping template that comes from the WordPress theme. Either that or have it injected in the RSS feed for each entry when that gets sent out.

However, for either of those I have to go outside the theme and get into either:

1. Modifying the main WordPress MU files;
2. Finding a plugin that will do this functionality; or
3. Writing my own plugin to do this.

Perhaps at some point, I’ll do that… meanwhile, I’ll stick with modifying the display of the posts when they are viewed on our site.

P.S. Of course, there is the problem that all the posts that I have written now have TWO of these footers… but that’s just some time going through and removing that text from the content bodies…

Technorati Tags: wordpress, wordpressmu, wpmu