Yes. If you can afford it!

Here’s why:

• Prospects are much more likely to enquire/buy from a local site.  I.e. Americans are much more likely to enquire/buy from a .com site rather than a .au site
• Google will rank your site higher in America if it is on a .com TLD (Top Level Domain), likewise a .au site will rank higher in Australia, etc
• The IP address of your site (while minor) does go someway to affecting your Google search results – so ideally the site would also be hosted in that country
• Content is king – and should be localised to the country you’re targeting.   Content is such a critical aspect of your SEO, and needs to be considered for each country individually
• Credibility – if you can get your hands on a US phone number and address to plaster all over your .com website – all the better – even if diverting to a messaging service
• In-bound links – another critical aspect of SEO is in-bound links.  If your local site gets links from other local sites, you’re also creating much Google love

Some things to consider:

• It can be expensive to build several websites, so try to ensure they’re very similar, and also use a CMS platform that supports multiple sites (I.e. Drupal for websites, Magento for eCommerce) to minimise development and maintenance costs
• Each of these sites requires their own SEO strategy, link building efforts, etc – which can be expensive.  Look to get discounts from your provider for bulk link building
• If you can’t afford all of this, then consider using sub domains or sub directories for country specific “satellite sites” that are optimised for those countries, then send the traffic back to your main site
• There are compromises you can consider – talk to your agency for some advice

Hallelujah! CodeIgniter has finally released version 2.0.0 after a very long and patient wait, as a stable, production ready framework. It was deemed more stable than the 1.7.2 version for quite a while before it was officially released, as all bugs that were fixed in the old version were applied to the dev version at the same time, while making further improvements. So the usual deal of waiting a few months while a new major release goes through it’s teething stage thankfully doesn’t apply here, it’s ready to roll right now.

What do you need to know?

There are a few new items in 2.0 which you can read in more detail about on their website, however the main points to note if you are planning an upgrade are:

• PHP4 support is gone, the lowest version of PHP supported is 5.1
• The validation class (which was deprecated) has been completely removed, the form_validation class has taken over
• Scaffolding has been removed (this was also deprecated)
• Plugins have been removed, Helpers are to be used instead

What do you need to do?

As always, take a full backup before you make any changes so you can rollback.

Download the latest version of CodeIgniter Reactor and extract it somewhere on your computer.

Hopefully you’ve only made changes to the files in the system/application folder. If you’ve made changes to anything else in the system folder, you’ll need to go back and move those changes to where they should be in the system/application folder before you can move forward.

The system/application folder in 2.0 has been moved to the top level, so first thing you need to do is move your system/application folder to sit in the root alongside the system folder.

Now delete the system folder.

Completely.

You’ve now removed the CodeIgniter base, simply swap in the system folder that you downloaded from the CodeIgniter site, add the following additional files from the download into your site, and we’re ready to move on to a few convention changes.

• index.php
• application/config/foreign_chars.php
• application/config/profiler.php

Convention changes

In each of your controllers and models, (unless you’ve created your own base controller to extend, in which case you only need to update your base controller) you are probably doing something like

class user_model extends Model

You’ll need to go through and change this to

class user_model extends CI_Model

The same goes for controllers, whereby instead of extending Controller, you need to now extend CI_Controller

Change your plugins to helpers

If you’ve written or downloaded any plugins to use on your site, you’re going to have to convert them into helpers. It’s a pretty simple change, just move the files in the plugins folder to the helpers folder, rename them from xxx_pi.php to xxx_helper.php. Then update your config.php file to make sure you are autoloading the same files as before but now as helpers. That’s it!

Move over to Form Validation

You can in theory get the old validation.php file from the 1.7.2 version of CodeIgniter and place it in your application/libraries folder and be done with it. However, if you can spare the time it’s more beneficial to use the new Form Validation class as you’ll be able to take advantage of the much neater code and also keep on top of any updates and improvements made over time. When working with user data, keeping on top of security releases can be a pretty important thing. The small amount of effort is worth it.

That’s it.

You’ve just upgraded to a version 2.0 base. Now you need to give everything on your site a thorough test to make sure that everything is in working order.

There are a few more left field items, but for 90% of sites out there using CodeIgniter 1.7.2 this will cover you for making the upgrade pretty painlessly.

If you do get stuck, remember there’s a very active userbase on the CodeIgniter forums only too happy to help out.

There comes a time when you need to bite the bullet and upgrade your site from the old to the new. Not only are you leaving yourself open to security vulnerabilities as older versions are no longer supported so new security holes found are left open, but future work will also be more complex as extensions are no longer being made for your sites outdated framework.

This can only spell disaster, maybe not in the immediate future (hopefully never), but you’re doing yourself and your sites users a disservice by leaving it outdated and vulnerable. It’s also a perfect time to give the site a facelift, but that’s fuel for another post.

Of course this is easier said than done, particularly if you’ve let your site age quite a bit. Fortunately for the most part, the upgrade process for Joomla is relatively straight forward, the downside though is any third party or custom extensions that your site has will not gracefully be moved over in the upgrade process.

So if you have a basic, content only site, you’re in luck. If not, some planning needs to happen to make the transition as smooth and painless as possible.

There’s no path at this stage (and nothing has been announced) to migrate directly from 1.0.x to 1.6.x, so this article will cover both migrating from 1.0.x to 1.5.x, then from 1.5.x to 1.6.x.

Migrating from 1.0.x to 1.5.x

This step is the easiest of the whole process, and is well documented on the Joomla wiki http://docs.joomla.org/Migrating_from_1.0.x_to_1.5_Stable

It basically involves installing a component on your existing 1.0.x site to create a file that will be used when installing a fresh Joomla 1.5.x site.

Note that we said ‘migrating’ instead of ‘upgrading’, this is because you actually need to download Joomla 1.5.x from the Joomla site and do a completely fresh install on your development machine, rather than edit any existing files.

Nearing the completion of the the installation process of the Joomla 1.5 site there will be a screen that will allow you to kick off a migration process, simply upload the file that was created earlier from your old site and it will import with a good amount of success the following:

• content
• core modules
• custom html modules
• menus
• data from core components

What it will not import though are (among others)

• 3rd party plugins / components / modules
• custom plugins / components / modules
• templates (as these are file based)

If you are making the move all the way to Joomla 1.6.x, then this is all you need to do with the Joomla 1.5.x migration, move on to ‘Migrating from 1.5.x to 1.6.x’

Why? Joomla 1.5.x allowed plugins, modules and components to run in what was called ‘legacy mode’, which meant that it allowed code that was built for Joomla 1.0.x to run in a Joomla 1.5.x site.

This backwards compatibility is non existent in Joomla 1.6.x as the core of the site has been modified too much to efficiently be able to allow for older code to be supported. While initially it may seem like a pain, looking forward this is a good move as it will force extensions to be well written and closely follow the Joomla conventions, making it much easier for developers to make their own extensions or work on existing code.

If you are planning to stay at Joomla 1.5.x for now, then you will now need to start the process of reinstalling all of the components, modules and plugins that you had on your 1.0.x site and switch on the Legace Mode plugin to allow them all to run smoothly.

You will also need to make a few modifications to your template file as the syntax for displaying Joomla elements has changed somewhat. Details on upgrading a template from Joomla 1.0.x to 1.5.x can be found here: http://docs.joomla.org/Tutorial:Upgrading_a_Joomla!_1.0.x_template

Migrating from 1.5.x to 1.6.x

Thankfully a component has been created to help out with this move, at the time of writing though there were a few issues we found which we’ll outline shortly, but first, how to use it.

The component is named jUpgrade and can be found here: http://extensions.joomla.org/extensions/migration-a-conversion/joomla-migration/11658

This step doesn’t require you to download and install a fresh Joomla 1.6.x site, this component when run will actually download the latest stable package for you, install the files in a new folder that is creates called jupgrade, and will create all the tables it needs to run in the main database but with j16 as the prefix instead of the default jos prefix. This allows you to run the two sites side by side until your migration is complete.

The installation process is pretty impressive to watch, however as noted earlier, there were a few issues that we found with this upgrade (at the time of writing the latest stable version of Joomla was 1.6.0 and the latest stable version of jUpgrade was 0.5.3, while our experience was with 0.5.1, some bugs are noted to be fixed and will be marked as such)

• Placeholder / separator menu items were not moved over (possibly fixed in v0.5.2)
• Many menu items were pointing to the wrong article (possibly fixed in 0.5.2)
• Multiple menu items were marked as the default (possible fixed in 0.5.2)
• Creating new menu items throws an error if an alias is not explicitly set, however the menu item is still created (this may be a Joomla bug, not the jupgrade)
• Content of custom HTML modules were lost in the move and needed to be manually re-entered
• At first attempt trying to view a category listing (from a newly created menu item) the site throws a 404. The quick manual fix was to move the category to be a child of another category, then move it back. It seemed to work fine after that, but obviously that’s a pretty poor workaround. Hopefully this has been fixed in a later release of jUpgrade.

A few extra notes for 1.6.x first timers:

A new feature for ‘discovery’ is available in the extenuation manager which allows you to simply add your files to the site and have Joomla discover them and present them to you in a list of items that are available for installation rather than have you need to package them and upload them as an installable package.

• There’s been a change in the required XML format for your extensions, which you can see here: http://www.finishjoomla.com/blog/22/joomla-16-vs-joomla-15-templatedetailsxml/
• When installing a module, while the installation will be successful, it won’t show up in your list of modules straight away as you are used to. You need to create a ‘new’ module, the module you installed will show up in the list of modules you can choose for the module you are creating.

Our rates are so high because *this* guy goes through bananas like you wouldn’t believe!!

There is an old adage that goes something like “if you pay peanuts, you get monkeys”… and this one … “You get what you pay for!”.  Ah, the cliches are endless.

Seriously though, we get this question a lot.  There are a lot of ways to answer the question, and a lot of theories around what a website is worth. After being in the industry for about 12 years now, I believe you get what you pay for (well that’s not true if you deal with a really big over-priced agency that can demand any price they like) … AND also believe that some businesses don’t need to spend a fortune on their website!

If your business is very small, doesn’t have a huge marketing budget, or doesn’t see the web as a strategic part of the business growth, and is a strong offline business (accounting firms are a good example of this), then it’s not likely you need to invest heavily in a web presence, and can get away with having it built by a freelancer or a small agency, however be warned…

I’ve compared digital agencies and freelancers in another post.

As the owner of a mid-tier agency, I can tell you categorically that we charge what we do, to survive.  If we charged less, we’d have to provide a less superior service (and compete with the commodity end of the market), or disappear.  Here is why:

1. Experience - what a surprise huh? Building websites isn’t just about slapping together a design and crunching out a few pages of code.  Anyone that’s had a bad website built knows that there are endless amounts of pain associated with a site that has been built poorly: It doesn’t render properly in the browsers it should; hosted in an unreliable environment; CMS wasn’t setup correctly so you can’t edit all the things you should be able to; the site doesn’t appear in the search engines; it looks unprofessional; usability is poor!  We’ve learnt all these lessons the only way – the hard way!

2. Staff – you’re buying a service, not a product.  The quality of the service you receive depends solely on the quality of the staff that are providing the service.  It’s all about the people you’re dealing with.  The larger, and more professional the agency, the more talented and expensive their staff will be.  There’s a reason more experienced staff are more expensive!  It’s like choosing an accountant – if you go to an inexperienced accountant straight out of school, they’ll be cheaper, and you’ll most likely get poorer advice than from an Accountant that has been working in the field for years.  Probably not a great idea considering the difference that could make to your tax return – why make the same mistake on your website?

3. Infrastructure – Salsa has a dedicated Program Manager who’s sole responsibility is to ensure projects are run to schedule, and to the highest standards.  Our support team is dedicated purely to helping customers maintain their sites after they go live (as opposed to trying to get our developers to support client sites while they’re busy on building new ones). We also ensure the staff are well looked after – we have someone that manages the office, the beer fridge is stocked, the coffee machine is ready for our next client meeting, organises team events, & client xmas parties.  Happy staff make great websites, which makes happy customers.

4. Quality assurance – about 3 years ago we heard a story from a client of ours that had a website built by another agency, which was lost about 90% way through the build cycle.  They had a server problem, and the site that had been worked on for 3 months, disappeared over night – no backup, no copy on a local machine. Nothing. They had to start from scratch.  More professional agencies have backup systems, version control mechanisms, project management tools, development-production synchronisation processes, testing infrastructures… the list goes on.

5. ROI – a site that doesn’t return any customers isn’t a lot of value.  There is a LOT to learn about creating websites that work.  From design (read Blog posts from our Creative Director to appreciate how important good design is – yet another example of amazing staff) to prominence in the search engines, to integration with back-end sales systems – they’re all important aspects of creating websites that work.  It’s not too hard to do the math on what a good website will return for you when compared with other marketing medium, but it’s futile if the site isn’t built with ROI in mind.

6. Your professionalism online – this may sound pretentious, but have you ever driven a BMW, then gotten into a Hyundai?  Not that Hyundai’s are bad cars – I actually think they’re exceptional value for money, but you’d obviously notice the difference in quality and experience if you had the M3?.   If your potential clients look at your Hyundai website, and your competitors BMW website, who do you think they’ll choose?  We’ve found that making a BMW quality website, while more expensive, ends up returning far more to customers in leads, inquiries and sales, and so we focus on delivering quality websites that sell.

BUT I JUST WANT A WEBSITE – WHAT’S THE DIFFERENCE?!

Here is how you can decide – checkout the portfolio of the providers. Are they of the quality you would like?  Are they BMW’s or Hyundai’s?  Are their customers of a similar size/level of professionalism to you?  Maybe even call a couple of the customers – get some honest feedback.

Bottom line, if you get a price that is considerably lower, you should expect a compromise on some or all of the above.  That doesn’t mean you can’t get a cheaper website, but (wait for the Cleche) “You get what you pay for!”.  When ever we compete against agencies of a similar size to us, the prices are always comparable.

When we compete against smaller agencies, they’re always cheaper.  The clients that understand the difference, are the ones that we love to work with.

I have this conversation at least once a week with clients.  About 20% of our new customers come to us to have an existing site re-built from a proprietary CMS, into an open source CMS such as Joomla, Drupal or WordPress; or Magento or OSCommerce for eCommerce sites.  They feel locked into their CMS, and their provider.  We’re exclusively an open source house, so I am biased, but strongly believe that there is very little advantage in using a proprietary CMS to build any website.

Effort

The amount of work required to build a site in a proprietary or open source CMS is generally the same.    It could be argued that a proprietary system is intimately understood by the developer, and as such the site can be built faster;  however many development houses have built up just as much knowledge in Open Source systems, and so this isn’t a challenge – as long as you choose an agency that specialises in your chosen open source CMS.

Initial Costs

When building a site using a proprietary system, the client is usually paying to help cover the costs of development of the software development exercise.  This means setup costs are in fact higher, even though the effort required is similar.

Ongoing Costs

Most proprietary CMS systems have licensing costs attached to them to cover the cost of maintaining the software.  Also, for any additional components that need to be added to the site, these typically also attract their own maintenance costs.  We’ve recently re-built a website for the same cost as the annual licensing fees the client was paying – and this was a substantial site (tens of thousands of $).  What’s more, the new site is far better!

Flexibility

Open source code can be edited by anyone; anyone that has the right skills of course.  You can take your site to anyone that is skilled in your particular system, or language, and have them make changes for you.  Alternatively, if you run a proprietary system, edits can usually only be done by the provider.  This of course means less access to appropriate developers, and typically higher prices.  Also many proprietary systems will only implement changes that can be rolled out to their entire customer base, so that they don’t have to maintain too  many different versions of the software; so getting customisations can be difficult.

Intellectual Property (IP) Ownership

Most open systems are covered by the GNU General Public License (http://www.gnu.org/licenses/gpl.html), which basically means you have the rights to do whatever you please with the code, and any customisations that are applied under contract.  On the contrary, most proprietary systems are owned solely by the developer.

Portability

Mentioned already in flexibility, open source sites are able to be picked up and shifted to just about any other hosting/support provider.  Proprietary systems can often only be run on the developers environment, as they like to maintain ownership of the IP.

It has been reported that Joomla alone, which is the most popular of the open source CMS tools, is responsible for 1.5-2 million websites (out of about 16 million active CMS driven sites).  WordPress is probably responsible for even more!  So these open source tools are also very, very widely used, being used for some of the most high profile sites on the internet.

WordPress and Joomla are by far the most popular open source CMS tools available – we’ve built hundreds of sites using these technologies, and so are intimately familiar with their structure, limitations, pro’s & con’s.  Until about 2 years ago, most clients didn’t really care what CMS was used, most didn’t know what a CMS was, but these days people are coming to us with some idea of their options, and often need a little guidance to ensure they make the right choice.

1. Content structure

If the site is just a simple brochure site, with a straight forward menu system (top/side menu), simple content pages, for example, use WordPress.  Similarly, if it’s just a Blog – use WordPress.   This site, for example, is built in WordPress.

If you’re looking to build a larger, more complex site, with a more sophisticated content structure (multiple levels of content), more than 1 menu system, more modular content (in left/right columns for example), and would like more control over what menu appears where, then use Joomla.

2. Community/larger more complex site

If you want to build a community site, including member login functionality that provides users with members only content, or create a feature rich website including user polling, banner advertising, user profiling, etc – then use Joomla.  Likewise if you want a corporate site that is more feature rich, including categorised content for case studies, or whitepaper download capabilities with integration into a 3rd party CRM database, use Joomla.

3. Administrator technical capability

If the website administrators are less savvy, use WordPress, if you can get away with it.  Joomla, while not hard to use, is hard-er to use than WordPress, which is just a bi-product of it being so much more sophisticated.

Wordpress admin - simply about managing content

Joomla admin panel - lots of options and functionality (although most only ever use about 20% of it)

4. Design

The design of a site can also lend itself better to either technology.  Simpler designs, using more traditional content structures (limited number of pages, less modular content, little interaction) are better suited to WordPress.  Either CMS is incredibly flexible in terms of being able to conform to just about any design, so that’s not really a consideration.

5. Future development possibilities

It’s painful to swap over (need to build from scratch – there is no “upgrade”, so make sure you consider the above points for future development also – if your needs are simple now, but they will grow later, you’re better off choosing Joomla right off the bat – it may cost a little more (5-10%), but worth it in my opinion.

6. SEO

You’ll read a LOT about which tool is better for SEO.  In our experience, the technology is only a very small part of the SEO story.  Both CMS’ offer the necessary infrastructure to effectively optimise a site, including (albeit with a free additional module or 2):

• Search engine friendly URL’s
• Ability to control meta data for each page
• CSS styling to support H1, H2, tags, etc
• And many more…

There are a bunch of other factors that weight into how well your site performs in the search engines (content, back-links, internal menu structures, etc) – so don’t let this affect your decision.  You can build the same site in either CMS and achieve the same SEO result.

The takeout – if your needs are simple, use WordPress, which is more geared toward Blog or simple brochure-ware sites.  Otherwise, use Joomla.

We find that clients these days are not just after a website.  The web is often such a crucial part of their strategy, that they can’t afford to just hire in the skills once-off; they actually need to partner with a company and group of people that can join them on their business journey, for the long term.  It’s about building a relationship, and then maintaining it.  And like all relationships, it needs to be built on trust and strong fundamentals.  Here are 4 things to consider:

1. Ensure you’re confident in their abilities

Obviously, you need to check out their portfolio.  Often they won’t have clients in your specific industry, which is no big deal – you just need to make sure they design beautiful work, are familiar with the technology they’re using, and the sites they build are well presented and work well!  You should also speak to a couple of their key clients (3 or 4 if you can).  It’s helpful if they at least deal with businesses of a similar size to yours also.

Dodgy website salesmen also sell 2nd hand cars & stereos from white vans

Companies that have been around for a few years are more likely to be around for a few more.  The web industry is famous for having low barriers to entry – so many small businesses, or sole operators go out of business, creating huge problems for their clients  (For the record, about 20% of our new customers have come to us from this exact predicament!).  Do they have a solid team of professional staff members?  Decent office?  Do they charge enough?

3. Do you have a realistic price quote

If you get a quote that is considerably lower than the others it may be a sign of inexperience (they aren’t familiar with what it takes to get a good site built, and so under quote). The project may then become contentious later, when the developer invests more time than budgeted, and are very hesitant to cater for any alterations – could also become expensive for you.   You should look to get a fixed price quote if you can, and ensure your proposal covers the important items you need.

4. Do you like them?

You need to be able to get along! Like any relationship, you need to understand each other, trust each other, and be able to rely on each other.  Do they respond when you email or call them? Do you enjoy dealing with them?  Can you get easy access to the company stakeholders or key staff members when you need to?  I know whenever I choose a supplier I often rely on my gut (it’s not always right, but has served me fairly well over the years!)

We see a number of clients that are looking to start a brand new business online, and have come across the same issue many, many times – they have a long list of “wishlist” items, but a budget that doesn’t quite match.

One approach is to seek a low cost developer to help get the site done cheaply; unfortunately this often also results in a low quality application, poor design, and little strategic input into the business once launched (I have another Blog post coming on this topic).

The better alternative, is to stage the functionality; release a version of the site that includes some of the core functionality, the things you can’t live without, including the items that actually make you money, and then release additional functionality later.  What we’ve found is that, almost every time, the second and third round of functionality is different to first anticipated.  Inevitably, once the site goes live, and users start putting it through its paces, they tell the business owner what they like/don’t like, and what they would like to see in the site, which usually dictates future releases.

It often comes as a surprise to the business owner that their clients expectations are different to theirs, but to be honest it’s pretty rare that we see a business owner that knows their audience intimately enough to know exactly what they want and need from their site.  They have some idea, and using best practice, we can build a site that works really well, but until it’s live, we don’t really know exactly what the site needs to function successfully.

The trick often is finding a system to choose what functionality should in fact be included in each release.  We recommend using a structured approach which allows you evaluate the business benefit and technical complexity of each of the items on the “wishlist”, which factors heavily in the decision making process.  So for example, if an item has high business benefit, and low technical complexity, then it is a great candidate for a first phase release.  If the business benefit is low, and technical complexity high, perhaps it’s best to leave it till the next phase.

There are various ways to implement this process, but as a start, just try writing them all down, and score them from 1-5 on business benefit (bb) and technical complexity (tc), then make your decisions from there.  Let me know if you need a more detailed approach.

Or, ask your web developer to help you prioritise them based on their experience on what works.

Bye for now.

The raw base

To start off with, we’re going to at least need some sort of menu structure to get us going. For this, the best way to structure the menu is using an unordered list (ul), nesting your submenus as you go. Below is the example we’re going to use in this demo it its raw unstyled format.

(The running demo is here – http://lazarus.salsainternet.com.au/demos/css_jquery_dropdown.html)

Menu item 1

Submenu item 1
Submenu item 1


Menu item 2
Menu item 3
Menu item 4

Submenu item 4.1
Submenu item 4.2


Menu item 5

Opening that in a browser is going to be pretty plain, something like this:

A little css

For the sake of this tutorial we’re only going to give the menu a basic look and not get too fancy. So we’ll just create a nice green and black menu.

The nav we are going to create is going to be a left to right manu, with the second level popping out below its parent, so we first need to order the items left to right and get the submenu it the right position. (To keep it simple, the style is going to be added to the same file and not extracted into a saperate stylesheet)

Hiding the submenu

Now that the menu is working and displaying as we want it to, now we need to hide the submenu by default and setup the style for the hover state.

Change the left value for the “#mainmenu ul li ul” class to be off the screen somewhere (we’re using -12000px here) and add a new hover class for the list item, which moves the ul back to where we just had it when the user hovers over the main menu item.

				#mainmenu ul li ul{
					width: 170px;
					position: absolute;
					left: -12000px;
					float: left;
					clear: left;
				}

					#mainmenu ul li.hover ul{
						left: 0px;
					}

Adding the jQuery event… the fun part

Up to this point, the file could run as a standalone HTML file, and with a little extra CSS could actually work in a lot of browsers, but there are many out there that don’t support using the “:hover” on list items, so we need to make use of some javascript to tell the browser to react when the user hovers over the main menu items. So first step here is to actually load the jQuery javascript:

(The no conflict line has been added in cases where people may already be calling a javascript file that makes use of $, it prevents us from running into any javascript code conflicts)

And now here is where the magic happens, using jQuery you can ‘chain’ function calls one after the other without having to do each function call on an element on its own line which cuts down the file size and keeps things neat and together.

Finally, just to top things off we need to add some hover colors to the menu items.

				#mainmenu ul li.hover a{
					background-color: #3c3;
				}
				#mainmenu ul li ul li.hover a{
					background-color: #333;
				}		

And that’s it, a fully functional CSS dropdown using jQuery. In a later article, I’ll cover adding a slight animation and also adding multiple levels of dropdowns.

Demo and full code

Here’s the running demo – http://lazarus.salsainternet.com.au/demos/css_jquery_dropdown.html

Happy coding!

Chris