WordPress for CMS

This blog has a lot of articles about WordPress, such as using it for the enterprise, converting from an HTML site to WordPress, and others, but I don’t have a specific blog post about using WordPress for a CMS. This use of WordPress is really at the heart of why I am big on WordPress.

So, let’s go over the basics. What is a CMS. CMS stands for Content Management System. For novice users, a CMS is used to write, edit, and control the text and html used in pages on a website. This is where we have to specifically separate the two concepts in WordPress, a page and a post. When we use the term CMS, we are referring to a page.

A post is simply a short or long article written about a particular matter, while a page is typically a standalone piece of content. This can be somewhat confusing in WordPress, since they are closely related. The big take away here is if you are going to use WordPress like a normal website, you need to understand the difference between a page and a post and in some cases turn off pages and in others turn off posts. Depends on what you want out of WordPress.

So, in the CMS world how does WordPress stand in terms of CMS. It is a difficult question, because on a scale of 1 to 10 as a CMS, I would say WordPress is a 6… Now, you would think that I would recommend something else! But, on the other hand the CMS aspect of WordPress is just one facet of other issues, in which WordPress is a 10 (Posting and SEO and plugins). The benefit of having a CMS with all these features is what makes the package so powerful.

So let’s go over the CMS basic features:

  • Ability to Create a web page.
  • Ability to Edit a web page.
  • Ability to Create Roles for specific users to create and edit pages.
  • Ability to stage a page, and publish on a specific date.
  • Ability to be able to access the system from a remote interface (The Web).
  • Ability to revert a change.
  • Ability to index, categorize, tag, what have you the content information.

Still, this is just the tip of the iceberg, because there are 100 decent paid (non open source) CMS systems on the market… And there’s more than that. There are probably 100 free CMS (open source) in addition to WordPress. There are probably another 2000 home grown CMS used by many a web consulting companies out there.

So, let’s get back to the question at hand… Why use WordPress for a CMS?

It’s straight forward. “It is not about WordPress today; It is about WordPress tomorrow.” The reason I say this, and you can quote me on this, is the system is being upgraded so very often and the plugins are increasingly so much filled with value add; You can’t find a softare movement like WordPress out there that compete’s with it. Here are the reasons:

  • Constant Improvements
  • Upgrades Are Relatively Easy
  • Thousands of Plugins (another name for addons or extensions, and easy to plugin in!)
  • Easy To Use
  • Easy To Setup
  • Easy To Move Around
  • Tons of Online Documentation

I am sure there are a lot more reasons… Anyway, that’s it, there is your reason why…

WordPress For The Enterprise – Article 3

Dealing With Potential Problems During Implementation

After the first two articles about WordPress for the enterprise, Article 1 and Article 2, I am writing this third articles about some of the nuances of the process of converting an old home grown CMS based site to WordPress for the Enterprise. There are and always will be some hiccups along the way. So let’s get into what happened.

WordPress on Load Balanced Servers

Our company deployed WordPress on load balanced servers, so how did we do it. It was supposed to be pretty easy to do, and if your site is configured properly, basically all you do is:

1. MySQL On A Separate Server
Make sure the WordPress MySQL database is located preferably on a separate server, not localhost, or if you are not that sophisticated on one of the two boxes.

2. Firewall Rules
Make sure that there are no firewall rules in place that would hinder the servers accessing MySQL remotely. We had to have firewall rules allowing communications placed between the production servers and the database server.

3. Location of MySQL Server
Also, we made sure the MySQL server is located within the same data center. If your database server is in Houston and your application (WordPress) servers are in Boston, it will be as slow as molasses…

4. Pre-Loading MySQL
Instead of loading MySQL from the initialization process that WordPress automatically uses, we sync’d the QA MySQL with the production DB. This allows us to have an instant production server, and just be able to make an adjustment to the WordPress config files.

5. Third Level Domain Names
Hopefully you will have an SA to help you if you are using load balancing. Very specifically we set up a unique domain (third level TLD) for each production server. For instance if you are Danspetloversparadise.com, you would set up server1.danspetloversparadise.com and server2.danspetloversparadise.com, and test both servers individually. I will get to that in a moment. In addition, in our case, we had an existing production server, with the name of the final site on the production server. Sounds confusing, and if you have questions, just login to this site and ask them. So in this case, you would want to create a new.danspetloverspardise.com, in order to test out the site before going into production. Sounds like a lot of extra third level domain names and work, but that is what it takes to do it right in the enterprise environment.

6. Webserver (Apache) Configuration
So on both servers, you would need to configure one of the third level domains and new.danspetloversparadise.com. Turns out we had some major issues with our apache configuration, and we had to use the SAs to take a look at the Linux based apache config, httpd.conf. Now, I am assuming you are Unix based or Linux based, but this could be an issue for Windows users as well.

7. Server Testing and wp-config.php
Once the sites all showed up, we are ready to go through a series of tests using wp-config.php. Set both wp-config.php files on both server1 and server2 to point to the proper DB, Host, user and password. The conundrum of WordPress in the Load Balancer, is you have to set the database to one site name at a time to do the testing. So here is the sequence:

8. First Test server 1
This would be server1.danspetloversparadise.com as an example. This requires adjusting 2 options in the Database manually under wp_options, site_url and home options. I use phpmyadmin for this. If you have it and know it, use it. The reason I recommend switching this directly in MySQL is it is possible when you go to save the WordPress options in the WordPress settings area, it will reset and push you to the wrong site… So change the site_url and home options to server1.danspetloversparadise.com and then go to server1.danspetloversparadise.com and see if the site shows up. To finish off this test, login to wordpress, and using the Velvet Blues URL manager I recommend in Article 2, swap the QA url for server1.danspetloversparadise.com… And see if it works and you can get around the server1 site without a problem. If it works, time to test server 2.

9. Second Test server 2
Swap the site_url and home options in MySQL wp_options to server2.danspetloversparadise.com, then go and and using Velvet Blues URL manager swap server2.danspetloversparadise.com with server1.danspetloversparadise.com. Then test the site as server2.danspetloversparadise.com. If it works good, it is time to test the new.danspetloversparadise.com.

10. Load Balancer Test
Swap the site_url and home options in MySQL wp_options to new.danspetloversparadise.com, and then go and using Velvet Blues URL manager swap server2.danspetloversparadise.com with new.danspetloversparadise.com. Test the site as new.danspetloversparadise.com. You should now be ready to swap the site over.

11. Using Redirection, the program I mention in Article 2, to test out all the old links on Google, Bing and Yahoo before doing the swap. This will take a while and it is critical in not losing old urls that will get zapped in a site migration, if you have a previous none WordPress site.

Next article will cover post migration for WordPress Enterprise users.

WordPress For The Enterprise – Article 1

As many WordPress users know, WordPress has become an application with critical mass. That’s not to say it is perfect or has all the application features you may need. That’s where plugins come in.

So let’s say you use WordPress for your personal blog. Fine. You know how to set it up; you know how to find a free template; you know how to load a plugin and configure a plugin. As you know there are over 4,000 plugins to choose from. Let’s say you are even at a higher level, with years of programming experience, or system experience and have an IT job…

So, you recommend to your employer, hey let’s switch over our sites to WordPress! Sounds good, right? Well, first off, yes, it is a good decision. There are a dozen other rational decisions out there, some of which are better for enterprise-level solutions. However, the reasons why companies implement enterprise solutions are different from a single site you run with some limited pages and posting needs. There is scalability, security, user approvals, multi-lingual (localization), an ability to manage upgrades, an ability to implement features. The list goes on and on.

So why did I recommend to my employer that we implement WordPress across our diversified 5-8 corporate sites and essentially go against all the negatives. Most people when they hear WordPress, only think blog. There is one big reason. Not exactly what WordPress is today, but what is it going to be tomorrow, and how much support and critical mass it appears to be getting. More specifically, to new users or WordPress, it can do a lot more than Post Blog Articles. It can do everything from hosting pages, categorize those pages, to rapidly implement designs, and this is not covering the 4,000+ plugins out there.

Last time I checked, but over 2.8 million people were downloading every new stable version of WordPress. The number and type of plugins, as I will prove, in this series of articles, saved my butt many times over the past few months. And as each version of WordPress comes out, it gets closer and closer to ultimately what I exactly need.

What is interesting is we were able to either write or fill in the gaps where WordPress did not. We created our internal plugins on the open source base product by Automattic, and found the pieces that ultimately filled in the puzzle.

Let’s get to the nitty gritty of the positives. Along with this WordPress conversion all our home grown and purchased CMS’s were slowly removed. That means less code management, and less developer time and energy focused on fixing our code. That is the beauty of open source. Instead of fixing basic problems with an old Cold Fusion CMS we had, we now have the developer working on plugins that add new functionality we need to be fully enterprise.

The standardization of the backend UI. Now all our sites have the same backend and everybody knows what to expect. I have not had to give a WordPress UI class yet. This standardization of how the plugins fit and how the themes just pop in, has made it universal for the standards of the design work to be completed, and has set expectations for outside designers of what we require to implement their design. In many cases the designer has been separated from the coding effort and can work independently on their own wordpress version and when they are ready to implement, the design pops right in.

Then there is the manpower issue. Other than design work, there really has not been a need to hire an additional developer we were looking to hire back when we were supporting multiple CMS’s. We are running a lot of these sites with a part-time plugin developer, a content manager and SAs moving around the code.

There fundamentals of WordPress Enterprise are in place. It will cut your dev costs. It will standardize parts of your applications that make it actually possible to get an upgrade. It will make your world more predictable managing websites. It allows you to access thousands of free open source code to solve programming issues that developers would have to hired for.

If anything, you would think this will reduce programming. In fact we still need lots of programming, but for specialized, strategic dev purposes. What I mean is we used to spend a lot of time on the login, the membership system and other basic functions that WordPress manages for us. Now these are less of a concern and integration and plugins are really where it is at.

In my next article, I will discuss the specific system issues, the plugins we use, the plugins we are developing or have developed, theme management, code management and how we got through the more mundane implementaton issues.

Click Here to go to Article 2, Issues and Plugins
Click Here to go to Article 3, Problems During Implementation

WordPress For The Enterprise

This blog entry is the first in a series of articles about taking WordPress and making it work for the enterprise. I figure, because I am in the middle of it, I might as well share some of the advantages and pitfalls of using wordpress for your enterprise solution, or as many will call it, getting the WordPress to act as a CMS (Content Management System) for the enterprise. This series of blog articles will get into the ins and outs of implementing wordpress for a corporation, and what plugins to use, and what issues you will have to overcome. So, sign up for this blog, come back for a visit, or go to my twitter account at http://www.twitter.com/dgudema to read what I am going through…

social media & the death of the custom cms

Whether it is twitter, linkedin, facebook or myspace, there is no doubt that social media is here to stay as part of the framework of the web. So that is why most cms and blog software are building into them automatically, everything from rss to seo permalinks, to sitemaps, to ping outs. This means that the days of writing your own cms are coming to a close. Whether you prefer Drupal, WordPress or other open source, the days of rolling your own CMS are finished. These may be fighting words for most developers, but the business world sees it differently. This is not even an open source vs. commercial software issue. It is a fact of life. When I look over a company’s portfolio and see links ending in .cfm, .asp or .php, I see the old way, compared with the new way. That is why sometimes you have to stop what you are doing and follow a new way.