WordPress Gets Bigger & Better & Sometimes Too Big

After upgrading about 25 of my client and personal sites to the recent WordPress 4.2 version(s), I can tell you that things are working better than they ever have for WordPress.

Though I have worked on every angle of WordPress from being a user, developing templates, creating and programming plugins to fixing WordPress bugs and installations, I can say now more than ever that WordPress is a great way to go if you don’t need a custom development project.

Saying all that, you would think I am a total WordPress lover.  In fact, the biggest issues I have had to work on recently related to WordPress have more to do with either 1 of 2 user created issues.

Too Many Plugins

The first common problem for users is the user added so many plugins that WordPress is now either broken or has an error in the admin screens or you can’t open the admin.  You can’t blame users for loading up these amazing plugins.  There are about 15 I highly recommend.  But just like your iPhone/Android Phone if you load up too many apps, eventually your cell phone will crash and burn.  I was hired to consult on a WordPress implementation where there were at least 20 plugins.  Once you do an upgrade the likelihood of a having a problem plugin increases exponentially, since all your plugin makes have to have a version that is tested against the new version of WordPress.  So having your website on auto-upgrade WordPress versions can lead to one day opening up your URL and seeing a broken site.

The Dreaded WordPress, Server or Language Upgrades

What happens when you upgrade your version of WordPress is the potential for corrupt files, permission on file issues, database table upgrades and other small quirks.  This the price you pay for being a user of WordPress.  Remember, it is free.  They are doing upgrades like every 30 days sometimes, so the introduction of bugs is very common.  I don’t know a user of WordPress who has not had a small issue.  It is all worth it though, for the value you are getting.  Also just wanted to mention that a hosting company upgrade of some sort has caused me headaches over the years as well.  It is possible that last night the hosting company went from PHP 5.5 to PHP 5.6. Not sure why, but there is a possible incompatibility with WordPress now, especially if you have custom plugin or template code.

What’s Next For WordPress

A couple years ago I read that WordPress was at 8 million downloads per version and 8% of the web.  Now it has to be in the 25 to 50 million range and a good 25% of websites or greater.  You can look this up.  It is big.  It is getting bigger.  Just happens I developed some expertise with WordPress.  It is here to stay and it is important.  The next stages for WordPress look to me like a very similar path of Microsoft.  Once you get to a level where the majority of users are using your system, you have power and the ability to make an impact with a small move.  For instance, the paid side of WordPress coming soon.  Everything that is free in life will eventually have a price.  If you are looking for a WordPress consultant because your site is either locked up, showing a can not open, can not install or other issue feel free to contact me and ask me questions.

Dan Gudema

How To Migrate A Massive WordPress Site

A client of mine called me and told me their WordPress website was growing too big for the server it was on, even though it was a VPS, that the WordPress site was going offline periodically.  They asked me if I could help them migrate this gigantic site.

When I refer to gigantic and WordPress in the same sentence, to me that simply means that instead of megabytes of data in the database they are dealing with gigabytes of data in the database.  And instead of thousands of files, there are let’s say hundreds of thousands of files.

Small Biz Now Has Enterprise Level Issues

Luckily I have dealt with both the small and large servers over the years.  The real question has always been, can WordPress handle this high volume of DB and File issues.  Well, it can, but the issues have to be thought out and a problem like this turns from dealing with minor WordPress hick-ups to corporate-level Unix issues.

Why They Had To Migrate

Their server was just not able to handle what they were doing in terms of server speed, hard drive space, etc.  And this was causing the website to be unmanageable.  So, it was time to migrate. However, this was not your run of the mill WordPress migration.  It had all kinds of potential problems associated with it, like thousands of uploaded files, hundreds of thousands of records in some tables.

Why My Normal Tools Won’t Work

For instance, the database was too big to download using PHPMyAdmin.  Not that this is a big deal, it’s just if you have been a WordPress person for the last 5 to 10 years like me, you may not have all the tools in the tool chest to deal with this. I typically use a desktop ftp program to do this stuff, but not for this size. Using local ftp clients means downloading to your Mac or PC. It is not recommended at this level. For instance, if you are not on a fast enough download client, you are screwed…

The Tools

The reason I am writing this blog entry is so I can grab all those tools again in the following order in order to do this kind of migration again.

Here Are The Steps I took:

  1. Sized out the proper new server for the client. (My preference is StormOnDemand by Liquid Web, WHM/Cpanel cloud)
  2. Had the client buy the new server and handed over to me the login credentials.
  3. Received all the login credentials I need from the original server.
  4. Created a new website in WHM/Cpanel, generating a new IP.
  5. Created a temporary domain name for the new site and pointed the DNS to the IP.
  6. Created a Database Name, Database User in CPanel with the same name as the old DB Name and User.
  7. From the Shell command line (I use putty.exe) I used the tar command to zip up all the files beneath public_html.
  8. From the Shell command line I ran a mysqldump of the old database, creating a command line .sql file.
  9. From the Shell command line I ran FTP as new account name (not root) on new server and Put the tar file (like files.tar.gz) onto the new server.  (it was in the multigigs)
  10. From the Shell command line I ran FTP and Put the .sql file onto the new server. (it was over a gig)
  11. On the new server from the shell I unzipped the tar file.  Remember to position this right above where you want it to land.
  12. On the new server I switched over to root user (su root) to be able to import mysql.
  13. On the new server from the shell I ran a mysql import command which updated the database.
  14. Finally, while in test mode, there were two lines wp_options which need to point to the right domain.
  15. Make sure all the previous plugins are activated.
  16. We tested the new site with the temp domain name.
  17. Once we were ready, we switch the old IP at the DNS record to the new IP.
  18. Final thing is to rename the site name from the temp domain name to the actual domain name.
  19. Everything went relative smoothly and the site migrated.

That is all the actions I took, now here are the commands I used specifically:

he tar command to zip up the files to a .gz from right above the public_html directory:

The tar command to unzip the files from a .gz right above the new public_html directory:

The FTP commands I used to connect from Linux server to Linux Server:

The mysql command I used to dump the entire mysql database at the command line on the old server:

The mysql command I used import the entire mysql database at the command line on the new server:

Conclusion

Hopefully if you are reading this, you will use this to reduce the amount of time I took looking around the web for the right commands to do this. You may have to look up those other websites, because each of these commands have dozens of options. For instance, if you need to move more than one file at a time, using FTP, you would have to use mput and not put. So, keep up the good work. I hopefully will use this guide for myself next time.

Enterprise WordPress – Things You Have to Change – Robots.txt, wp-config.php, etc.

After all the hullabaloo in getting WordPress ready and implemented for the enterprise, with a DEV, QA and PROD environment, there are a lot of small gotchas that are still sitting around. For those of you trying out WordPress for the Enterprise level, these are the little gotcha’s to worry about, and Robots.txt is one of them:

  • Robots.txt
    Robots.txt needs to be different in each level of DEV, QA and PROD. If you are using SVN this can be a challenge. If you don’t know what SVN or CVS are, then don’t worry about this one. Basically as you copy the site from DEV to QA to PROD, you end up with the same robots.txt. This can’t happen from a technical perspective, since you really want robots.txt to block the search engine bots on DEV and QA, and not on PROD.
  • wp-config.php
    wp-config.php, the settings file for WordPress, needs to be modified if you are spanning the code across DEV, QA and PROD. Simple answer for this, use the old PHP switch statement and change the site based on server name with case statements. The variable to use for this is $_SERVER[‘SERVER_NAME’]. A good example is below:

    // ** MySQL settings – You can get this info from your web host ** //
    switch( $_SERVER[‘SERVER_NAME’] )
    {
    case “dev.strategicpoints.com”:
    define(‘DB_NAME’, ‘dbname’);
    define(‘DB_USER’, ‘dbuser’);
    define(‘DB_PASSWORD’, ‘dbpassword’);
    define(‘DB_HOST’, ‘localhost or SERVER NAME’);
    break;

    case “qa.strategicpoints.com”:
    define(‘DB_NAME’, ‘dbname’);
    define(‘DB_USER’, ‘dbuser’);
    define(‘DB_PASSWORD’, ‘dbpassword’);
    define(‘DB_HOST’, ‘localhost or SERVER NAME’);
    break;

    case “www.strategicpoints.com”:
    case “strategicpoints.com”:
    define(‘DB_NAME’, ‘dbname’);
    define(‘DB_USER’, ‘dbuser’);
    define(‘DB_PASSWORD’, ‘dbpassword’);
    define(‘DB_HOST’, ‘localhost or SERVER NAME’);
    break;
    }

  • Server Name in Mysql
    It is important to make 2 changes in each DB when migrating MYSQL between DEV, QA and PROD. These are in the wp_options table, and if you have been through this drill before they are pretty explanatory. The option names you have to change are “siteurl” and “home” to the full path of the site such as http://www.strategicpoints.com.

To solve some of these incompatibilities between the DEV, QA and PROD there are plugins and other things that need to be put in place in order to keep these versions in sync. This is a major challenge. As I solve each one of these issue or more issues, I am going to update this blog post.

WordPress In The Enterprise – Article 5, Post Mortem

This article is article 5 in a series of articles about implementing WordPress in the Enterprise. This article is about some of the aftermath of our big conversion of enterprise sites to WordPress. In some ways it never ends, the tweaking and upgrading and improving of WordPress sites. This is both good and bad. Good in that we don’t have to keep such large web development staffs around and we are keeping up to date with current SEO, security and other WordPress driven stuff. Bad, in that it never ends…

Here are the original articles if you want to start at the beginning

WordPress For The Enterprise – Article 1 – Setting The Mood
WordPress For The Enterprise – Article 2 – Issues And Plugins
WordPress For The Enterprise – Article 3 – Implementation Problems
WordPress For The Enterprise – Article 4 – Upgrading

Some of what I am going to discuss in this article has to do with small details which occurred after the implementation and continue to happen. These small details are important because they are some of those gotchas after a big migration. They are just listed here in random order:

301 Redirects On Additional Domains

Let’s say you own about 10 other domains that you have pointed to the same web site as your base site. This would be like having http://www.strategicpoints.com and then having http://www.internetanalysistools.com and then pointing internetanalysistools.com to strategicpoints.com. It just happens that on additional domains, WordPress should take care of this for you. Just set the DNS to point to the same server and make sure the apache conf (in Linux is set) and you are good to go. The second domain should hit the site and switch over to the real site. This also works the same way for www.strategicpoints.com and strategicpoints.com. Set it to one in wordpress admin and it will always redirect to the other. This is important for the search engines to have one domain for the site to avoid duplication and getting crawled incorrectly on the secondary domains.

Nofollow Meta Tags Left On (kind of like your headlights left on)

Just happened that prior to our migration, we set the dev and QA sites to not be indexed by the search engines. This setting is under Settings/Privacy. It is called Blog Visibility, and the exact wording is “I would like to block search engines, but allow normal visitors”. We had these Dev and QA sites set this way, so that we would not get these sites indexed. However, somehow this template theme was transferred to the components of our enterprise production system which are not WordPress sites. This means that we copied the template as is, and it had the follow Meta tag because of this setting:

<meta name="robots" content="noindex,nofollow" />

In particular we ended up leaving this in production on these non WordPress sites. It was an oversight, and one we immediately fixed. But this just says that even after you do your QA and job and the best you can, there is still a potential problem that you are not aware of in these environments. So you have to be vigilant and look things over periodically.

I am going to keep adding to this article as issues slowly bubble to the surface on the enterprise wordpress implementations we have been through.

WordPress In The Enterprise – Article 4, Upgrading WordPress!

This article is the 4th of a series of articles about WordPress In The Enterprise. This article is a work in progress, I am going to add to it as I go about this process, since I am tackling an issue that right now has no easy answer in the enterprise, and that is how to upgrade enterprise driven WordPress implementations. Why upgrade? Well, every chicken little on the WordPress blog/web has said if you don’t you may have a security issue. This is the kind of corporate implementation that includes a development server, a QA server and a load balanced production server.

If you want to start at the beginning and read them in a sequence use the following links below:

WordPress For The Enterprise – Article 1 – Setting The Mood
WordPress For The Enterprise – Article 2 – Issues And Plugins
WordPress For The Enterprise – Article 3 – Implementation Problems

Ok, now that you have read up on the first series of articles, let’s get to the heart of the problem with upgrading from an enterprise perspective. First off, the real issue is that WordPress is not an enterprise product, just yet. This does not mean it won’t be in the future, so like a WordPress plugin that does not yet exist, we have an issue that just needs to be solved. The big issue is testing a new WordPress Version on a development server and then somehow easily upgrading the QA and production servers.

Upgrade Method
If you use the WordPress upgrade method right out of the box, you are somehow violating a holy grail of upgrading from development to QA to production. Or are you? The current WordPress recommended method of upgrading is to load the new set of version files like from 2.8 to 2.84 (not overwriting wp-content’s themes & plugins directories, or anything else unique) and just letting the new version, like 2.8.4 do its magic. By magic, I mean it sometimes, but not always makes modifications to MySQL table structures. If that were not an issue, this would kind of be a mute point, because then we would just copy the development site over and be done with it. If you need the most recent version of WordPress, you can get it by clicking here.

Testing Plugins
Let’s take a little diversion here. Obviously one of the most important issue in the enterprise solution that I am trying to figure out, is testing plugins. Apparently you have to update certain plugins with the most recent version of the plugin to make sure it is compatible with an upgrade. This is a bit taxing on plugin makers who have to keep up with major revisions. The task at hand is to test plugins like seo-all-in-one-pack, google analytics, redirection, and others for compatibilities. If a very important plugin can not be upgraded and remains incompatible with the new Version, well, let’s just say you will be going to the backup.

The Backup
An important step in the upgrade process is the backup. I am not talking about the system backup you get from your server folks when the server crashes dead as a doornail, I am talking about backing up MySQL fully before you do the upgrade. Not explicitly required for the non-enterprise version, but for enterprise it is a must. Simply back it up to a .sql file and keep it handy, even in the development site before an upgrade. Good practice and that is what enterprise WordPress is all about.

The Upgrade Process
Once you have gone through the standard copy of the files over the development, you need to surf wp-admin area of WordPress. Immediately it will come up and there is a button that says UPGRADE to version x.x.x. You click it and hopefully it all goes well. Simple enough and that dev version is upgraded.

The QA Process
Tedious as it is, you need to go through and not just test out the content, permalinks and categories, but you need to take a look carefully at the plugins from both a site perspective on the outside and in the admin and tools areas as well to make sure they are functional on the inside. Once this is complete and tested, it is time to push it.

Pushing It
By pushing it, I mean pushing files up to the QA server, along with a mysql copy. This may be more of an SA task, but up till now it has been in the hands of the person managing the WordPress version. If you had left it purely up to SAs, it probably would not have happened right. All that has to happen at this point in the process is complete duplication of 2 things: files and Mysql DB. The duplication on the QA and production server will complete the process…hopefully.

Until somebody writes the ultimate publishing plugin for WordPress Enterprise, this will be a bit of black hole. Trust me somebody out there is going to fill this void. We have been hard at work on our own internal WordPress publishing plugin, but I am sure there will be open source versions sometime soon on the web.

Dan

Next Article WordPress In The Enterprise – Article 5 – Post Mortem

Fixing Broken Links After Migrating To WordPress

This article is related to the first three posts about Implementing WordPress in the Enterprise Environment. One of the lonely tasks following the migration of our website from HTML and Cold Fusion based files to PHP and WordPress was to fix several thousand incoming links from Google and other search engines. Without these Redirection fixes, the migration would have basically crushed our traffic.

To solve this problem, there are several places to look, including Google and doing a site:YOURWEBSITENAME.com search and clicking on every link to using Google Analytics. The Google Analytics method is the best, since it automatically tells you what needs to be fixed. This does not mean you should ignore the google search engine and looking at what are big incoming links in advance. Remember once you find a broken link, and you are using the WordPress Redirection Plugin, I highly recommended in a previous blog entry (click here to learn more info), you need to enter the entry into Redirection and fix it. If you are just learning that this did not require an .htaccess entry in Linux or htapi entry in windows, you are learning about a whole new world of improvement…

So back to Google Analytics. First of all you need to have a 404 page, which is where all the pages end up when they find no entry in WordPress, including the redirection plugin. This typically will be a 404.php page in the theme directory you are using. If you are sending people to your site map page, that is fine as well.

There are several ways to get this info in google analytics. I recommend using page title. For instance, on our site, the page title of our 404 page is called “Page Not Found”. Go into Google Analytics and click on “Content” and then on “Content by Title”. If you have just migrated, and the first day has passed, just set the date to the current day, to remove anything that is older than today, and find the “Page Not Found” (or other) title. If you click on this title name itself, another screen will open and reveal all the URLs that arrive at that page. This is your list of incoming broken links, sorted by the most important links at the top of the list.

Now is the detailed nitty gritty work. You need to re-enter each of these links into a url to test them and make sure they are broken. Once you are have found one that is being clicked on from a website out yonger, take it, copy it into the redirection plugin. You do this by Adding a new Redirection, then copying the link into the Source URL. Remember to not use your full path, just the /filedirectoryetc/ path, and then go over to another browser and find the end URL you want to send the visitor to and then copy and paste this path into Target URL and click Add Redirection. The default is a Permanent 301 redirect.

There are a lot of other options in the redirection program like using Regular Expressions. These work fine as well, but make sure you read the instructions carefully, since some redirections are impacted by other redirections…sequentially.

Let me know if you have any comments are questions about this process, because almost all sites come to point of migration, and this blog entry is really about the aftermath of a big migration. Our last WordPress migration did go through, but it had lots of small items that we had to fix along the way. I am going to add another blog entry covering these additional problems we ran into, creating a load balanced WordPress Enterprise solution!

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 2

WordPress Enterprise Issue And Plugins

Now that you have read my first article,WordPress For The Enterprise – Article 1, which is really more about reasons why to do a WordPress enterprise implementation, let’s get into what is missing; how we are dealing with it; the absolutely necessary plugins that are out there and the big issues. Here is the big issue and the Plugins I recommend (I am sure there are more out there, and I promise to update this blog with them):

DEV vs. QA vs. PROD
The first and foremost problem with not having an enterprise based solution in WordPress is resolving the enterprise issue of building in a dev environment, testing and QA’ing content in a QA environment, and finally publishing into a secure environment. A lot of gaps here and probably good enough reasons for many IT execs to back off and go for Interwoven, a customized CMS or some other relic of the past. But like I have been saying in Article 1, you have to take the good with the bad, and go with this train, because it is moving so fast, solving so many SEO and other issues along the way, that what the heck, let’s go for it. For now, the answer is still not simple. Across a dozen WordPress implementations, we are currently syncing the Databases. Now that may be a silly answer… albeit let’s get to the real answer. And like all web developers, if there is a problem, there is a solution. That is why have been developing an in-house Enterprise Publishing solution. It is still under development, and it will fit right into the WordPress admin system. When a writer is ready to sync a page from QA to Prod, and it has been approved, there will be a checkbox next to each page, and when they are ready to go, walla, the system will push the content from mysql DB QA to mysql DB PROD… Once we are done with this solution, there probably will be 10 or so plugins just like it on the market. This is coming. Maybe you will be using ours one day.

Anyway, that was the tough news to hear… Now here are the plugins that we can not live without:

Redirection
This plugin is like the old .htaccess in the linux environment that sets the redirects of incoming links, without having to create directories or redirection files. Found this one a while back and it has really improved our migration from non-WordPress sites to WordPress. If you are not familiar with this one. I would take a look. You may not be ssh’ing to the box after you find this to fix your URLs.

Velvet Blues Update URLS
Sounds kind of funky and kind of important. This small utility plugin simply allows you to flip all URLs in the site, including all content pages, from one URL to another. Now, why would you need this. It’s simple. You want to create a temporary site on the production box before you go live. Let’s say your site is called StrategicPoints.com. So before I go live I want to see it as as WordPress site and not mess up the current site. So I create a new.StrategicPoints.com. Let’s say the Mysql DB is coming from the QA site, qa.strategicpoints.com. So you go into Velvet Blues and flip qa.strategicpoints.com to new.strategicpoints.com. (Just a comment that if you do this, you still need to get into the MYSQL db to swap the DB options first before you run this. I recommend PHPMYADMIN for the faint of heart out there, who were not an SA like me in the old Bell days). I will get more into the production migration process in my next article, so we will get back to this process later on.

Exec-PHP
This is a very simple plugin which allows you to drop PHP code into the content area on any page. Sounds like a silly thing, but this could be important in making your widgets and making dynamic things happen in your code.

Breadcrumb-navxt
A plugin that allows you to show your bread crumbs as you surf around a WordPress website.

PagesPlus and My Page Order
Plugins that allows you to manage a large amount of pages better. I have not yet used these yet, so I won’t comment, but if you are dealing with over 100 pages of content, this could be important.

Ax-sidebar
This allows you to better manage the side bar content

All-in-one-seo-pack
A variety of SEO related tools, and seems to be the best one for the enterprise. There are many of these WordPress SEO tools out there, but this one appears to cover most of the needs of SEO.

Google-analytics-for-WordPress
This is one of several Google Analytics installer plugins. This one seems to work. I have tried a few, and this one is ready to go. If you are new to Google Analytics, well you should know the drill by now. Put Google Analytics on the site and you will know the anlaytics

Googe-sitemap-generator
Great tool for generating a sitemap.xml file for Google Webmaster Tools. If you have not logged into this part of Google yet, you really need to, because it is the best way of letting Google know what pages you offer. Great for SEO.

Sitemap Generator
Not to be confused with the sitemap.xml file, the Site Map generator creates a real site map that real users can use. Sounds Great!

WP Security Scan
This is a great security, WordPress, hardening tool. Use it to run a site audit and see what needs to be improved. Keep up with new versions, through the new downloader, and you will keep from getting hacked, always an issue using this open source stuff, and an enterprise concern

qTranslate
Just getting into the localization, then try the best of WordPress breed out there. This is qTranslate. I have used it once so far and it did the job. I will mention however, that it is powerful and does require set up. There are these .mo files that need to go on your site in order to assist with the translation character set. So this one may require talking to a tech guy. For latin languages, it goes right to work. Anyway, we are about to try it out again for a new site and we will see if it is up to the Enterprise task.

That’s about it for now. Hopefully we can come to some conclusion on a set of enterprise plugins. The big one, the “Publishing Plugin” is getting close at our company. Somebody will create a real nice one out there and hopefully solve this issue. There are a variety of problems and issues associated with this production plugin, but I think they will be worked out, to the point that we just point and click and it does the job.

Next, Article 3, the WordPress enterprise migration process.

Previous Article 1, WordPress For The Enterprise – Article 1
Next Article 3, Click Here to go to Article 3, Problems During Implementation

Dan

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…