Text Size

When Should You Upgrade Your Joomla 1.5 Site

Rails: end of the line

According to W3Techs, as of the beginning of July 2013, 63% of all Joomla sites are running version 1.x. Of these, some 92% are running version 1.5. That works out to a rather large 58% of all Joomla sites running 1.5! The other 5% are mostly version 1.6 and 1.7. [Aside: if your site is one of those 5% please just upgrade now. It's not going to be that painful and you are a sitting duck for hackers. By "now" I mean stop reading this and go upgrade. Seriously.]

So why is the number so high? There are usually a long list of factors, and most of them are valid. Here are the ones I hear regularly:

Read more: When Should You Upgrade Your Joomla 1.5 Site

Optimizing Web Crawlers for Shared Hosts

Spider image copyright Gio Diaz. Used under a CC-SA license.

Recently I've seen some of our shared servers getting bogged down when web crawlers start processing some large sites. What these sites have in common is that they have sections that need longer database queries to compose a page. For example, one of these sites has a large database for a directory.

From the hosting perspective, a slow shared server is a distressing prospect. It's fine if one site with inefficient queries takes longer to load, but it's not fine when that load affects other sites on the same server. It's pretty common for hosting companies (at least those few who monitor this sort of thing) to react by booting the problematic site, usually recommending a dedicated or virtual server in the process. But this can be impractical or grossly unfair. Why should a web site that has accumulated a large database of information but that has low overall traffic be forced into a much more expensive hosting plan just because of the way web crawlers work?

Read more: Optimizing Web Crawlers for Shared Hosts

Joomla Security: Beware the Forgotten Installation

A sphere within a sphere; installations within installations

It's common practice for developers to put test or new development sites in a subdomain. Most hosting control panels, notably cPanel, default the root directory of the subdomain to a subdirectory of the main site, so if I was going to create a "test" subdomain, cPanel will suggest "/home/youracct/public_html/test" as the root directory (youracct is the name of your hosting account). The problem is that these test installations are soon forgotten and can become a major security risk.

Let's say your client — let's call them client.com — finally has the budget to get off the old Joomla 1.5 site you built years ago. You create a subdomain to hold that shiny new web site. Maybe you call it "new.client.com", or being a leading edge kind of person maybe it's "joomla31.client.com" (Joomla 3.1 will be here very shortly). If you use the default directory and don't password protect it, anyone can see the new site by accessing the subdirectory. Entering client.com/joomla31/ exposes the new site to the world. If you used "new" it's an easy guess. There's a also good chance that backups of your main site are also now a lot bigger (you are backing up the site, right?) because they include also include the new version.

You work away on your spanking new Joomla 3.1.0 site and a few weeks later it's ready for launch. If you have the site in a subdirectory, you make a backup there and restore the new site in the web root. Over time you update the new site, applying security updates, fixing a vulnerable extension... everything is running smoothly. Then months later despite thinking you've done everything right, the site is hacked! What happened?

Read more: Joomla Security: Beware the Forgotten Installation

An Argument for Complex User Interfaces

Credit: Flickr user SWF Photography

User Experience (UX) design is an important aspect of almost every software application. Most users benefit from having a simple, easy to understand interface that offers intuitive choices to achieve their goals. Advocates of the simple approach point to surveys that measure how users respond to the design of an application, where simpler interfaces almost always garner a better rating.

The challenge is that not all applications can be reduced to a simple model. The current trend in UX design is to break a complex task down into a set of smaller, simpler interfaces, and then give the user a method of selecting or stepping through each of these interfaces. In some cases where a lot of this input is required, the user is guided through a sequence of simple steps to achieve a complex goal. This doesn't work. It's the opposite of the one-step checkout process that works so well for commerce sites, and we need a better solution.

Read more: An Argument for Complex User Interfaces

Save Time and Money by Using ACP for Joomla Content

Presentation Title Slide

The title of this post is what I should have titled my presentation at the 2012 Joomla World Conference. That's also how I should have structured the presentation. Much the same material, but the benefits first. The marketer's version of "Keep it Simple, Stupid" should be "Present the Benefits First, Idiot". Next time I do this presentation it's going to be organized to do just that. Until then, this will have to do.

The best way to put it is this: ACP is very useful when you have a lot of articles with similar elements and you want the flexibility to change the way all those articles are presented with a single update. If you have something like 300 product brochure pages in your site, or 10 executive profiles, then ACP is worth learning.

Read more: Save Time and Money by Using ACP for Joomla Content