Buddypress Redeux

Sometime in 2011 I was asked to assist a friend in setting up Buddypress. Buddypress was a special plugin that, along with WordPress MU or WPMU would make your WordPress site into a social network.  It was a bit of a dream at the time, to be able to plugin this in and that in and get a basic Facebook.  It was not easy and there was a bit of trouble, because it was actually built on top of WPMU which was really many blogs in one.  So it was very convoluted.

I heard WordPress acquired buddypress a few years ago. Well, the 2011 version of Buddypress did not implement very well.  From what I remember we stumbled into it and found that we needed a developer to do this or do that. Eventually we lost interest in the project, because we were just trying to create a basic social site.

Many Buddypress plugin functions hardly worked, and you were really limited because at the time you had to use a special WordPress template that was Buddypress compatible.  In fact, you had to not only have a special template or create one yourself, you also needed to hire a programmer to get Buddypress to pretty do anything out of the ordinary.  So, what this meant is you ended up with a common looking Social site that was no different than Facebook, so nobody cared.  In fact the template issue was as big a stumbling block as the custom coding issues.

So, fast forward 4 years, and we are now popping the new Buddypress into action. Basically it is a whole different world. I know that WPMU became part of the standard WordPress build.  So, it is not really worth going into, but basically Buddypress can allow you to not only create a social site, it can be combined with BBpress to create a multi-blog site for your users, where every user can have their own blog.  Does not sound too important, but that was the basis of Buddypress in the beginning.

The big improvement, because I have been away from this plugin so long, is that you can pretty much choose any WordPress template to work with Buddypress.  Does not sound too important, but it makes it possible to design your social site anyway you wish if you are designer.  The end result is you can find that killer template, pay a small amount or get it for free, plug this and that new WordPress plugin in and you have a real social site.

I have worked on a bunch of custom social sites, so I know as well as anybody what it takes to build out a real social site.  Obviously you are going to have to sacrifice some level of customization to make Buddypress work for your concept, but if you are not that concerned about custom functions, this is pretty much going to do the job.

So, want your own Facebook or social app, you can configure Buddypress and WordPress and get something special. If you have a WordPress site already and want to figure this all out, let me know.

Dan

dan@startuppop.com

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.

qTranslate WordPress language Plugin

The qTranslate plugin translates your website into multiple languages using WordPress. There are 2 major caveates that I will discuss in this article, which need to be resolved external to the plugin and that is where I have run into a few bugs.

Benefits of qTranslate Plugin:

  • Localize (Translate) your website into many languages.
  • Have your website seen all around the world and get indexed in internal search engines and get more traffic.
  • Using WordPress, makes it is possible to hire third parties to translate for you directly.
  • Automated language translation services are available.
  • Supports additional domains like es.strategicpoints.com if you want to use this method.

Challenges of qTranslate Plugin:

  • qTranslate has been around for many versions, yet we ran into a few bugs.
  • Installation is not as simple as plug and play. You have to make choices and sometimes DNS changes.
  • Support for problems is still not for non programmers. You may need a technical person to help out.
  • Needs to be planned out and may require a dev environment for larger websites.
  • Issues when you run WordPress Upgrade, often qTranslate needs to be upgraded. WATCHOUT FOR THIS ONE!

Unlike other simple plugins, this plugin allows you to create domains like es.strategicpoints.com and de.strategicpoints.com if you choose. The default would be simply strategicpoints.com/es/ and strategicpoints.com/de/, with the language represented by the directory. So you have to decide which format you are using, either a directory method or a domain name method.

The other issue that needs to be resolved is whether or not you are going to use translations that are done by hand or by a “machine”. By machine this means a translation engine has attempted to translate it for you. Apparently this old translation that most on the web used to call Babelfish, because they were an early automatic translator, as well as systran, is still giving it a go. I guess one day it would be ready for primetime.

After our first attempt at the qTranslate WordPress plugin about a year ago on a small website, there was a second attempt at it this past fall, to translate one of our medium sized websites into 3 additional languages. The first time at this had its pitfalls, but the second time around has been a lot better.

First issue that we ran into is what to call the domain names. After deciding to go with the domain name approach, we found that we were restricted to es.strategicpoints.com… This was a bit disappointing, because we had originally wanted to come up with completely different domain names per language. Maybe this will be a feature that will be added.

The next issue we ran into and still have a problem with is, once we turned it on, the wrong default language kept coming up. We wanted it to be English, but it came up German! The only thing we could think of was to set the default site to en.strategicpoints.com (you realize I am just using this site as an example). And we had to use .htaccess to do this. Not good. But of course marketing folks did not like the en. in front of a site, so we were stuck between a rock and hardplace. Have not yet resolved and we may have to hack the site to get it work right.

Overall it saved us thousands of dollars, and yes we did run into a bug with qTranslate. That said, it still was a big lifesaver and appears to be worth its weight in gold. So, if you have a bit of technical team around and want to local/translate, this is the way to do it in WordPress. In fact I can see sites switching to WordPress for just getting the qTranslate running.

UPDATE

So as an update to the particular bug I ran into using qTranslate, I went through and found out what the real problem was and fixed it manually. Basically the issue was that the program was looking for “de” at the beginning of the domain name. So what was happening is dev.strategicpoints.com was pointing automatically to the German language. That is because “dev” begins with “de”. The qTranslate plugin was just looking at the first two characters of the domain name, and assumed it was de.strategicpoints.com.

How did I fix this?

If you are having this bug, which I doubt, because you would have to have a domain with three parts that begins with either “de”, “es” or “en” or something like that, you could go into the qtranslate_core.php file and correct the problem. That is what I did. I went in and edited the open source code and checked for the full domain name string, “dev.strategicpoints.com” and when it matched I set the language to “en” or english, my base language. Leave me a comment below if you have any additional questions about how I fixed this, though I highly doubt that anybody will have this problem. The biggest issue now that I have solved it, is remembering to not overwrite the old plugin with a new one without fixing the code I placed in there. ..

Google Analytics Intelligence Beta – Article 1

So we all login to google analytics and are noticing this new Beta feature called Intelligence… Looks like the Google Gods have delivered for us again. Sometimes these suddenly new features are amazing, and sometimes they are lackluster. I don’t know about you, but it is feeling a little like Google has turned into the Chocolate Factory in Charlie in the Chocolate Factory. Don’t know the reference…hmmm.

The fact they are free is the amazing part, and to the chagrin of several hundred developers at competitors like WebTrends, Omniture (now Adobe) and Coremetrics it is just one more dink in the armor, especially when these types of enterprise features are considered something you would typically pay for.

Ok, so what it is… Well actually if you don’t have much traffic you won’t notice much when you click it. Since I work for a large corporation and have quite a few small, medium and large Google Analytics accounts for my sites and other clients, I can see the disparity in what you get. For bigger corporate clients there is data showing up.

2 kinds of data.

One is called “Automatic Alerts”, the other are “Customer Alerts”.

Just assume the automatic alerts they decide for you, while you have some control on your own. Weird thing is the actual types of control are very general with a simple low to high sensitivity bar. Without a lot of information about this tool, I am going to take a stab at the relevance and how to use it…

Automatic Alerts (Variance Reporting)

Like I said, if you have some data coming through that is a bit more than just 10 visits a day, you will see something. What I am seeing is any form of data that is above a specific variance curve showing up. If you have had basic statistics. I suffered through it twice in two MBA programs, you have the basic within like 2.5% of the mean at both sides of the bell curve. When I see low medium and high settings, this probably is more like the variance of like 20%, 50% and 70%. You can modify it a bit with that bar.

What does this really mean for analysis?

It pretty much it means they are “Alerting” you to unusual activity in your account. For my corporate accounts I am seeing things out of the ordinary showing up, like traffic from a specific geographic location has increased by greater than 40% or time on site has increased from a specific location by over 88%. You will have to become a hack like me to understand the fact that this stuff is relative. This means that it really can mean very little depending on the situation. You have to dig deeper to see why or how it is a variance.

Time Frame

Trying to get a handle on what time frame means, it appears that if you choose a small time frame at the top of the page, you create a statistically insignificant amount of data to analyze, and you will notice that there is no results. There are two types of time frames involved in this analysis. There is the time of the report you are looking at, at the top of the page, and there is the “Time Frame”, one day, that is in the middle of the page. You can shift this “Time Frame” back and forward (if you are not looking at today). This way you can see if the trend is common each day or just for this day. Does not look like right now that you can switch this from a day to a week or month, but that would be a nice feature. Maybe I am missing something on the screen to switch this. Also, seems like this is going to cost us money at some point, so maybe that is the paid feature? But then, I have not yet gotten to custom intelligence.

Alert Sensitivity Bar & Significance Bar

There is a significance bar on the right side of each metric and dimension. This significance bar is related to the variance discussed earlier. It can be used as a measure of how important, or in my old stat class we called this the Sigma. I actually turned down the Alert Sensitivity bar in the middle right and noticed that a few of the alerts dropped off. This sounds right, if it is straightforward. Obviously you will have less alerts if the Alert Sensitivity bar is lowered.

Graphing Anomalies (Alert Data)

Another part of this is the cool way you can quickly access graphing. Let’s say you are looking at a specific alert. There is a little graph icon on the left of each alert. Click on it, and you can that specific target data across the page time line, and BAM a pretty powerful way to use this thing… Try it and see what I mean.

Alerts Candlestick Bar Graph

Notice this secondary graph beneath the normal graph. This one is tracking how many alerts per day. If you are just starting out this is set for the automatic alerts only. If you set up custom alerts, it will track them on this chart as well. I am going to set up a few and then report back through this blog and my twitter account @dgudema on how they work.

Group By Metric | Dimension Function

There are 2 ways to Group the Information, by Metric & Dimension. Metric refers to the basic metrics listed on the right side. Dimension appears to be the more deeper secondary level metrics like region, new vs repeat visitor and other more detailed items. Interestingly enough the higher level metric may not show the alert that is in the lower level metric.

I am sure that there is more here that I have missed. I will cover it in my second article coming up soon.

From Regular Website To WordPress Website – Article 1

This article is in a series of articles about migrating from a regular website to a WordPress website…

Like many things on the web, whether you a 100% techie or 100% marketing or somewhere in between the day comes when you have to improve, change or modify your website. I am about 50% techie and 50% marketing, at least that is my perspective. When you are a techie, you build your website (your personal site) once and never touch it again. When you are a marketing guy, you are adding so much to it that it looks like a target ad special. But overall when it is your personal site, like StrategicPoints.com is my personal site, how it works, what it says and what it does, is really important if you want to impress upon your clients, your com-padres or your parents, that you know something about the web.

For techies the concept of using wordpress is sacrilegious, and that is why I am using kid gloves in this first article, explaining why I am switching to StrategicPoints.com to a WordPress site. It has been a long time coming, and I am switching it over in stages. These stages will be discussed in this series of wordpress blog articles that cover the why, the how and the little details in between. Now that we are down the road a bit on this WordPress critical mass that has been occurring, I bet a lot of techie and marketing types out there would like to switch to WordPress, and best of all to be able to do it yourself, and not lose a step along the way.

That is why I am documenting this process. One for those out there who care, and two for myself, to learn. Whenever I teach something I learn, and trust me the migration of a old fashion html website to WordPress is a learning process.

So, before the next article, let’s cover the difference between a regular website and a WordPress site. First off, there are so many answers to what is a regular website, so let’s limit this to two categories, the old fashioned HTML website and the programmed language website. The basic HTML website is a series of tags in a page that you run through a web server and the more advanced programmed website does a bit more with a database, forms, reports, interactive actions and anything imaginable. Now my original strategicpoints.com site was and still is an HTML site (until I finish up this process). By HTML, you can sometimes check this out by seeing index.html or index.htm or directories like /services/ at the end of the URL. This is still somewhat misleading, because in the web world any URL can look like any URL if you use redirection and other techniques… The more advanced “programmatic” site can become a wordpress site, but this gets into the more difficult integration and creation of plugins. We will get into that last, and then it becomes a question or whether or not the wordpress migration is worth it. (It is if you are starting from scratch, but if you have already made an investment in .net, Cold Fusion, python or any of the other languages out there not a freely distributable or not available on all flavors of websites, you may want to hold onto your pocketbook and stay put).

So the final part of this article will try to explain why I think most people would benefit from WordPress instead of their regular sites (unless you don’t want to be found on the web and manage a website, but then you wouldn’t be building a website unless you did not want to be found). Here are the reasons:

1. WordPress is opensource and free.
2. WordPress has many of the nice SEO features you can’t get so easily on your own. SEO means Search Engine Optimization and you needed to know that, this is perfect for you.
3. WordPRess is gaining critical mass and like Microsoft DOS, you don’t want to manage CPM.
4. WordPress has an easy to use CMS, while if you had a regular html site you would not have a CMS. By CMS I mean Content Management System.
5. WordPress has easy to upgrade path and new version every month or 2 if you want new features.
6. Literally thousands of plugins out there on the market and if you need something it will be free or cheap.
7. Tens of Thousands of support articles like this one.
8. WordPress not only can run on any hosting plan on the market from Linux to Windows, but many hosters have it already ready for you.
9. Tons of free and cheap themes out there to choose from and easy to switch theme.
10. Probably a hundred other reasons out there and too many to think of.

So, there you have it… Check back on this article as I go through the process of converting StrategicPoints.com from a regular HTML site to a WordPress site.

Dan

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

SEO in Overdrive :)

Like may things in the web everybody is looking for the edge. You can go and read the JimBoykin.com site and get some interactive agency to do an audit, but often it is the same SEO stuff over and over.

A couple of years ago, at the beginning of SEO, Search Engine Optimization, around 2001, I was tasked with getting this startup speed dating site as high up in the search engines as possible, because as you can imagine, it is always less expensive to be found naturally, than to be found through PPC, Pay Per Click. Lots of stuff out there and lots of the same stuff where ever you look, so much so, for interactive firms these have become a standard.

Surprisingly, like 90% of sites have yet to meet these standards. These are pretty much the same as when we started SEO around the early 2000’s, plus all the new media stuff like blogging, plus now webmaster tools from Google, Yahoo and Bing like sitemaps.xml files.

There there are some additional small details that you would not think of to round this off. This is what I call SEO in Overdrive. Recently I gave a short talk on what are critical technical issues in getting a site nicely found on Google. So here is my SEO in Overdrive list below. I will probably miss a few things here and there.

1. Choose either www or no www URL.
Choose either www.strategicpoints.com or strategicpoints.com. Having both URLs working on your site will cause Google to count your rankings for pagerank separately. Together, as one domain, this will increase your site pagerank, because these two URL’s pagerank power is diluted. How to do this? If you have a linux server, the .htaccess file can be used. I am pointing to a good refernce to figure this out. If you are using WordPress, then do it for you automagically, and will switch you over to either one or the other based on the choice. If you are using windows…well I am sure there is an answer out there.

2. Localize or specialize each page of a site.
The old days of one title for all 100 pages of a site are like 1999. The top areas are title and Meta Description. As I have found out recently, if you mess up your title, the listing on Google will reflect this. So make sure the title is accurate and contains the key words you want to be found by, first… The Meta Description (if you don’t have top content) will be used by Google to show the descriptive text underneath the title on a Google result page. Take for instance a situation recently where we migrated a site, and the Meta Description was removed from a page. Without the little description beneath the title on the Google Results page, the link looked like an ad, especially since it was showing up first in the rankings. We learn from our dumb mistakes. We put the Meta Description back, and wholla, the link reappeared and so did our traffic.

3. Healthly, always changing content…
The search engines love content, no matter where it exists on your site. This is why having a forum, blog or other interactive parts of your site are so critical. This content is always changing, and this is always freshly indexed on the search engines. The introduction of the blog, and WordPress, which I favor, has really given us an ability to SEO in Overdrive, because it pings out to the rpc servers that update the search engines within 24 hours. This means not waiting for crawlers to come out to your site, but telling the search engines when and where to look for new content.

4. Text Links…
Who knew they would be so important. For sites that do not provide text links on the home page, they are missing out on the ability for both crawlers to go deeper, and the ability to make these links important part of search criteria for your site. Ever notice a group of links below your search results on Google… They determine these for you initially. These are considered the top internal links from your homepage on your site. The calculate it for you if you don’t do it yourself as sitelinks, through Google Webmaster Tools. You can remove these, but you can’t add these I believe… Only having images links is a downer…, and can be a negative impact on your sites. Top sites that want to continue with image links often put <div> based text that is not visible behind the image, that state the link in real text as a way to solve this issue. Either way, always take your links seriously.

5. Images, Site Elements and alt tags.
One of the tricks we used years ago to get to the top of the search engines without violating any code of ethics with Google was a technique I call snow balling. We decided on our top search content words, which were “speed dating”. Then we renamed the /images/ directory to /speed-dating-images/. Then we proceeded to add alt tags to each image, that said the image name with “speed dating” after the name, like “party photo – speed dating”. Then we went on to include alt tags in the links with the name of the link “event xyz – speed dating”.

6. Directories and Virtual Directories.
A newer technique is to create directories or virtual directories with tons of additional terms. No need to create these real directories anymore, unless you are on a windows server. I only know the Linux apache version of .htaccess and this can be used to create virtual directories for SEO. In our case it would have been /speed-dating/, /speed-dating-parties/, /speed-daters/, etc., etc. These so called directory and sub directory structures are really the cutting edge of the web today in terms of getting found on the search engines. No need to work hard and create these directories and subdirectores anymore or even a super .htaccess file. This is why I am lovin WordPress. If you have WordPress, all this is done for you and no need to work about it. WordPress not only can create these for you with real directories, but the redirection program I mention in my enterprise wordpress discussions on earlier blog entries gets into how it works, and why to use it.

That’s it for now. I am going to add some more to this list soon, and as you know there are a hundred other blogs out there with a lot of the same information. Good luck putting your SEO in overdrive. Contact me if you have any questions about the stuff I mention today at dgudema AT StrategicPoints DOT com.

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.