Do You Really Need WordPress?

Probably not.

Before I get started, I want to disclaim two things:

  1. This site uses WordPress
  2. The OCS Solutions website uses WordPress

So why do I say you probably don’t need it?  Well, the answer is both simple and complicated so I’ll start with the simplest explanation for my recommendation: unless you intend on running a blog (as your primary site) or an online magazine, you don’t need WordPress.

This site is a blog, so WordPress is a perfect fit.  The OCS Solutions website is updated frequently and has some behind-the-scenes features that our staff use that made WordPress a good fit.  But those examples are quite limited in scope and its likely that the vast majority of non-blog or magazine sites need the features and maintenance requirements that WordPress delivers.

WordPress is an amazing piece of software and has certainly opened up online publishing to the masses.  I highly recommend it for blogs or magazines.  But for personal pages, company websites, and sites with mostly static content, it adds needless complexity and security risks to your site.

Since so many sites use WordPress it is a prime target for hackers.  If your WordPress installation isn’t kept up to date (including all plugins and themes) then you will almost certainly be hacked.  This can potentially be a nightmare to recover from and will certainly ruin a holiday or weekend. If your website content rarely (or never) changes, you probably want a set-and-forget solution, and WordPress, at least that this point in time, does not fit that description.

Regular HTML files can be easily edited in any text editor, including the powerful WYSIWYG Adobe Dreamweaver, so editing your site can still be easy.  If you use Dreamweaver templates or PHP includes then you can make your site even more flexible.  HTML and basic PHP websites are significantly faster than WordPress (unless you use caching, and that can be tricky) as they don’t the database.

If you still need a blog, installing a blog on is always possible – using WordPress there and having your main website content be regular HTML.  With that technique you can have your cake and eat it too!

Linux for Web Developers

If you are a web developer, you’ll no doubt need access to the myriad of command line tools that now power modern web design.  It seems that, for better or worse, the Node Package Manager (NPM) is standard equipment in a web developer’s tool chest. If you’re not a native Linux user, this can present a challenge, both on Windows and Mac.

This article will focus on providing a high-level overview of setting up a Linux development environment for Windows users.  It’s a bit easier to get a command line web development tool set going on Mac but I’ve always preferred to pick my own hardware and not pay a fortune for it.  I also can’t stand the Mac file system layout, UI navigation, and proprietary smugness of the operating system.  That will be the end of my Mac bashing for the remainder of this article.

I’m currently using Windows 10 on both my desktop and laptop, and while its far from perfect (you should turn off as much of the privacy-violating stuff as you can), it does a great job of providing the underpinning to my setup.  I would  use Linux full time if I could, but my gaming and Adobe addictions make that a difficult challenge.  Instead, I use Windows and run Linux in a virtual machine.

I’ve always been a fan of VirtualBox.  It’s open-source, free, and runs very well.  Out of the many Linux distributions I’ve tried in a virtualized environment I’ve found Linux Mint or Ubuntu to run the best.  I’d prefer Debian or Arch, but I’ve found that both Mint and Ubuntu have the best long term support (as long as you pick the LTS releases) and virtualization support right out of the box.  CentOS makes a great choice on the server but with little out of the box support for many of the web development tools you’ll need it just doesn’t make sense on a workstation.

Installing the various web development command line tools in Linux is extremely straightforward and requires little instruction.  If you go to each of the respective web pages for each software package you’ll find easy instructions tailored for your distribution.  Within just a few minutes after install you’ll be ready to go.  Since I do most of my work in Vim I skip fancy IDEs, but if they are your preference its easy to install Eclipse and others via the software package manager in Mint or Ubuntu.

The tricky part comes with sharing data with your host machine. VirtualBox includes shared folder support – allowing you to mount a Windows folder in Linux.  While that does work, I prefer simply sharing the folder natively in Windows then mounting it in Linux.  This avoids using custom kernel plugins that can change over time and allows you to access these folders on other machines as well.

You can also keep all of your work in Dropbox and install the Dropbox client inside your virtualized Linux environment.  This solution works well enough and provides an extra layer of backup for your work, but if you have a lot of data in your Dropbox account its strongly advisable to select only your work folders to be accessible inside your Linux system else you’ll end up duplicating your entire Dropbox folder structure which could be a problem if you’re on a smaller solid-state drive.

If you use Windows Backup or Acronis to do a bare-metal back up your Windows installation, you’ll also be backing up your Linux work environment as well – something that will greatly simply your backup strategy.  If you choose to throw Dropbox in the mix then you dramatically increase your protection against data loss and hardware failure.

I hope this post has given you a good overview of web development with Linux on Windows.  For now I wanted to share my overall thoughts and methodologies, but in future articles I’ll be digging into the specifics of installing a virtualized Linux environment, setting up specific tools, and optimizing the web development workflow.

This may be my last post before Christmas so best wishes for you and your family.  I hope you have a wonderful holiday!


The www Saga – Should Your Domain Be Naked?

Long ago, near the dawn of the UNIX epoch, servers were generally single-task in nature.  To have one server machine fill multiple roles was unusual.  This was because CPU cycles, RAM, and disk space were hard to find and what resources a machine did have needed to be available for the task at hand.

This situation gave rise to the Internet-naming scheme of putting www before a website address.  The reason for this was that there was literally a machine named www that served the website for that domain.  In today’s era of virtualization, this is no longer the case.  A single server can host thousands of websites and the www prefix is slowly falling out of favor.

There is a debate among webmasters about using the www prefix before your domain name.  To not use it is referred to as a naked domain, that is, typing into the browser to reach your site without the www before it.  In the past websites have generally accepted both but redirected to the www version.  Now it is increasingly common to see sites use the non-www variety and redirect to the reverse.

Google understands the difference and will not penalize you for duplicate content if you serve from both versions. It really doesn’t matter what you choose but whatever you do it is strongly advised to be consistent.  If you want to use www in front of your domain, then always use it.  If you don’t want to, don’t link to it with www in front of the domain.  Here are some ways to accomplish that:


If you use WordPress, this is a fairly simple situation to solve.  In the General page under Settings, simply specify the version you’d like to use. In this case for our site we use the www version because our site has been around since 1997 and we have a lot of links to that variation.  Specifying this here will redirect non-www requests to the proper URL.


Other Linux-based Sites (Static HTML, PHP, etc.)

If you’re not using WordPress, you can use an .htaccess rule to address this situation.  For example, this rule:

RewriteCond %{HTTP_HOST} ^[^.]+\.[^.]+$
RewriteCond %{HTTPS}s ^on(s)|
RewriteRule ^ http%1://www.%{HTTP_HOST}%{REQUEST_URI} [L,R=301]

This will redirect all traffic to the www version of your site and respect the use of SSL.  You can remove the www. from the last line above to do the opposite.  Do not use this solution if you are using WordPress – the two rules can conflict or, at best, unnecessarily duplicate each other.

Microsoft IIS

For .NET websites, you can use the web.config solution here to handle www redirection.