On September 21st, 2011 we held the kick-off meeting for the new Ottawa WordPress Group.  R-Cubed is one of the group sponsors and Rick Radko is a co-organizer.

We hope to create a user group that will support leaning and promote WordPress in Ottawa.  The group is to address the needs of all levels of WordPress user from beginner to expert.  All types of users are expected form bloggers to plugin developers.

“The Ottawa WordPress Group is all about learning WordPress, for beginners and experts alike!

Do you want to learn about WordPress?  Do you have a WordPress blog or site, or use WordPress at work? Would you like to talk to others about WordPress?  Do you need to know more about how to run your site?

Attend our next meeting and meet other WordPress users, learn more about WordPress, learn best practices, share ideas, projects and other information.” – The Ottawa WordPress Group

You can join the group by joining our meetup group, additional resources can also be found at our website wpottawa.org.

Hope to see you at our next meeting.

Recently I needed to put a sub-domain on different host than the main domain.  (the main domain was IIS and we needed an apache server)   You may not be able to do this with all hosting companies, so check with them first.  In this case, the servers were with 2 different hosting companies.   With shared hosting you will need to get a dedicated IP address ($12-36 a year) for the domain where you will host the sub-domain or there is no address to point the DNS record at for the sub-domain.  Then you will likely need to call you primary hosting company to set up the a-record for the sub-domain as most shared hosting set-ups don’t give you access to the DNS records you need to point a sub-domain to an IP address.

Remember to redirect all your domains to a common one (see www or not, just make sure you canonicalize it).  Once the DNS records are set-up you can use .htaccess to direct the incoming sub-domain to the location of the files for that sub-domain.

You’ll need something like this in your root .htaccess file.

RewriteCond %{HTTP_HOST} ^sub\.domain\.com$
RewriteCond %{REQUEST_URI} !^/location
RewriteRule ^(.*)$ location/$1 [L]

Where to put your blog?  How about blog.domain.com?  Putting your blog on a sub-domain makes it easy to keep all the files for your blog organized and separate from your other website files, you know, the CMS, the forum and the wiki you have jumbled on the site too.  The sub-domain keeps all the links easy to manage too.  But, with blog.domain.com, you may have an impact to you site ranking as Google sees a sub-domain as a separate site (as discussed in www or not, just make sure you canonicalize it).  If you are worried about Google rankings, go with something like domain.com/blog.

Even without a sub-domain, you can keep things tidy. I usually structure my sites with a hierarchy of folders. I put all my web applications in individual folders at the same level to keep everything separate so you can blow away an application and replace it without messing up the others.   If you install an application at the root you will have other installed application folders mixed in at it becomes much more of a challenge to upgrade/patch.   With everything in a folder you can even install major upgrades in parallel with your existing site, do testing in parallel and simple rename folders when you are ready to switch.

There are many opinions on the choice of using www.domain.com or just domain.com for you sites, which is better?  I’m now tending towards domain.com simply because it shorter and the www doesn’t add any value.

Regardless of the www or not decision, of more importance is URL canonicalization.  Say what?   How about a Wikipedia definition:  `In computer science, canonicalization is a process for converting data that has more than one possible representation into a “standard” canonical representation.’

So what does this mean for our web site?  As seen above we can choose domain.com or www.domain.com for our site.  Well how about those sites with blogs or CMS’s, they often have default pages at domain.com/index.php or www.domain.com/index.php.  So who cares?  We as human users we don’t really care as we equate all those URL’s as we are used to seeing them arrive at the same content, but search engines don’t see them as the same.  If you consider Google ranking, and you have not taken care to canonicalize your URL’s, your link popularity gets divided among these the URLs reducing your maximum possible pagerank.

To help avoid this issue redirect one of your URL’s to the other with a permanent (301) redirect.  This is easily done on apache servers by adding one of the groups of lines below to your root .htaccess (with the domain replaced of course):

RewriteEngine on

# no www to www version
RewriteCond %{HTTP_HOST} ^domain\.com$
RewriteRule ^(.*)$ “http\:\/\/www\.domain\.com/$1” [R=301,L]

OR

RewriteEngine on

# www to no www version
RewriteCond %{HTTP_HOST} ^www.domain\.com$
RewriteRule ^(.*)$ “http\:\/\/domain\.com/$1”  [R=301,L]

or, on many hosts you can use set-up redirects using cPanel which modifies the .htaccess for you.

NOTE: there is a program called isapi_rewrite available for IIS servers to do the same things as .htaccess.

Google webmaster tools has an option to select a canonical URL for your site which will help your page rank issues, but still does not avoid the issue of having two addresses for your site, which can trip up things like locally installed versions of WordPress which have the URL coded in the settings.

For many, open source means customizing the code.  Custom is great, you make the program do exactly what you want.

But custom comes with a down side: maintenance.  Once you customize an open source project, it’s yours!  When an update/patch is released for the package, you now need to redo all the changes you made.  On a small plugin, that may not be a big deal, but on a large code base like it can be a major time investment.  When you consider that most of the major open source projects release new versions and or security patches 4-8 times a year, redo can become unmanageable.

My thought is that open source should be thought of as open for developers, closed for users (consumers) of published packages, like Joomla and WordPress, which are usually just installed and used.  Sometimes a rethink on usage is in order.  Many customizations I have been asked to do could be avoided by changing processes, requirements, or specs that don’t really impact the end result.  Rememeber, just because you can, doesn’t mean you should!

While it can make the initial customization more difficult, make sure that any custom work is done as a plugin/extension if you can’t change the specs.  That way it is likely that all except major upgrades will be painless.