WordPress: Company Blog
Posted on: May 31, 2009
WordPress is the most popular blogging software written in PHP and MySQL. Years ago we had played with the software when blogging was considered a hobby by the Internet savvy. Now a days, blogging is more and more accepted as a desirable online communication media for spreading and sharing ideas, news and opinions among groups of people within organizations.
A few years ago, we standardized on Wiki-based online commucation for our teams. We find wiki to be very suitable for project documentation: specifications, meeting notes, status reports, Q&A etc. However, recently we decided to give our teams a more informal idea sharing platform — a WordPress blog per team. We are very familiar with WordPress blog from the very beginning; in fact, our very first WordPress blog ran on a IBM thinkpad x600 for over a year before we shut it down. Our recent decision to provide each team with an internal WordPress had two-fold objectives:
- Deploy internal team blogs using WordPress
- Explore the WordPress code, plugin development as part of our R&D
Pre-requisites for WordPress
WordPress uses MySQL database and therefore we created a new database called <team_evoknow_blog> for for each team blog and created appropriate grant privileges using the following sample GRANT statement:
GRANT ALL PRIVILEGES ON database_name.* TO 'username'@'hostname' IDENTIFIED BY 'secret_passsword';
We ran FLUSH PRIVILEGES; command on the MySQL server to ensure that the new database can be readily accessible by the username from the hostname mentioned in the GRANT statement.
Getting Started
Next, we downloaded the latest stable version of the WordPress software from: http://wordpress.org/latest.tar.gz. We extracted the WordPress source code in the document root directory of the Web server using tar xvzf latest.tar.gz, which created a new directory in the Web site. We renamed the directory to reflect the team name. We also changed the file permissions to allow WordPress to read+write in the wp-contents sub directory.
Getting Started (cont.)
Next, we copied the sample wp-config-sample.php to wp-config.php. We also edited this file to modify the default database access information to allow WordPress installer to access our newly created empty database. The lines we changed are as follows:
define('DB_NAME', 'blog');
define('DB_USER', 'blog_dba');
define('DB_PASSWORD', 'yoursecret');
Finally, we were ready to install WordPress using the Web-based installer that can be run from http://server/<wordpress directory>/
Running WordPress Web Installer
The Web-based installer is very simple and therefore we will not discuss details here. Only one setting worth mentioning was that we unchecked the search option since we did not want the blog to be searchable from the Internet.
Changing Admin Password
Once logged in as the administrator using the generated password, we immediately changed the generated password to a new one.
Allowing Self-registration for Users
The idea of an informal blog to allow users to access it easily and without needing approvals from anyone. Why manage user accounts and complicate admin’s life? Instead, let the user register and get started with blogging. Therefore, we choose to allow self-registration by users; and followed the instructions below:
- Clicked on Dashboard >> Settings >> General link on the Dashboard
- Checked “Anyone can register” in the Membership section
- Checked “Users must be registered and logged in to comment”
- Set “New User Default Role” to be “Author”
FYI, you can review this link to learn more about user roles and capabilities.
Check Point: What Have We Got So Far?
We have the blog up and running and anyone can register and start blogging. Now, we need to restrict access to the blog using IP adress and also throw in a highly restrictive robots.txt for peace of mind. The goal is to allow access to the blog from office LAN and forbid any Web spiders from indexing any page. We know that IP restriction will stop the spiders but there is nothing wrong with a two-line robots.txt to increase peace of mind. The robots.txt we installed in the blog directory had two lines:
User-agent: *
Disallow: /
Restricting Access to the Blog
To block all access to the blog from outside, we configured Apache to have the following directives:
# Use a redirect page to say sorry to users
# when they try to access the internal blog from outside
ErrorDocument 403 http://server/sorry.html
<Limit GET POST>
Order Deny,Allow
Deny from all
# Add your office router IP address
Allow from 1.2.3.4
</Limit>
Our Web server that runs the blog site is on the Internet and thus the above-mentioned configuration is necessary. If yours is inside your LAN, this configured is not needed.
Check Point: Day After Blog in Announced
We annouced the availability of team blogs on our Wiki home page, which many of our users visit daily. Within a day, most of usual suspects with a voice signed up and started postings. A good mix of technical and non-technical posts started appearing daily — sharing has begun!
Counting Our Benefits
Many companies worry about making blogs available to employees becuase they fear sharing could lead to office politics, rumors, confusion and overall waste of paid time. We are not expert in corporate behavior trends and analysis; all we can report is that sharing works for us. It allows us to discover in-house talent that are often behind the scene and also improves writing skills — a rare jem among software engineers.
Next Step: Automated Posting via Email
We immediately realized that if we can automate postings from other tools that we use, we can inform everyone about birthdays, other events and highlight interesting stories from outside sorces.
To automate posts, we explored the email-to-blog capabilities of WordPress using the wp-mail.php as a POP3 mail box reader run via a cron job.
We were able to post simple messages by sending emails to the blog but we needed fancier capabilities like posting rich-media (HTML, image, audio, video) via email. Unfortunately, wp-mail.php did not handle rich-media at all. Google searches for plugins to do the same job resulted in finding plugins that do not work well and are written very poorly. We decided this is an area where we can devleop a plugin of our own. This plugin project have already started and will be made available to WordPress community when we are ready with an alpha version.
WordPress Look & Feel Customization
We wanted to change the look and feel of the default blog and found that WordPress theme concept is acceptable for most look and feel customization.
However, we did not quite like the fact that our UI designers needed to have full administrative access to change the theme CSS and other templates. If WordPress allowed a maintenance account role, we would have appreciated it more.
As a workaround, to avoid giving our UI designers access to the admin accout, we simply gave them sendbox blog where they perfected the look and feel with CSS and template changes. Once they were done, we replaced the template files using the Admin account.
Putting on PHP Developer Hat: Code Review
From the early days, we were not too excited about how WordPress uses the traditional “glue-PHP” concept in presentation and business logic separation. It was disappointing to see that WordPress in 2008 still uses embedded PHP scripts in presentation layer instead of using a template engine like Smarty or similar technologies. From developer’s point of view, we are not ready to give WordPress a five-star rating but from popularity and usability point of view it has alreay earned such rating throughout the world. We are now WordPress users.
kamrul24.wordpress.com 
Leave a comment