Opencart theme development, in it’s current state is flawed in my opinion. Opencart is a great platform for any type of ecommerce store, having a plethora of features for users and a low entry point for developers. As a result, Opencart has plenty of themes available for download, just take a look on Themeforest. Occassionally, to test out various things out I’ll install such themes locally. More often than not the theme will break the store completely, or render parts of the site completely broken.
9 times out of 10 the issue will be down to the theme developer not sticking to basic Opencart theming guides – they’re very basic to say the least. The main point to note is that Opencart, like other ecommerce platforms, uses a fallback technique on the “default” theme. So, for example, if Opencart doesn’t find a template for a category listing page, it will fallback to the template from the default theme. If the latter is not adhered to, and it isn’t – look at some of the so called “premium” themes out there, it makes upgrading very, very painful. There are theme developers out there that are copying over a files for the sake of it, when no changes are made. If your theme literally only has changed the color/layout of the footer, apart from the default stylesheet folder, image folder and header template you only need the footer.tpl in your theme folder.
CodeIgniter’s validation library is amazing out of the box and will save any developer an absolute ton of time. However, as CodeIgniter is an MVC framework it’s validation library does encourage data validation directly in controllers – which of course for the “MVC Nazis” out there is against strict MVC principals. So, data validation should strictly happen at the model layer, not in the controller. Moving data validation to the model has a few benefits – it allows your application to follow to coveted “Fat Model, Skinny Controller” pattern and allows you to validate other data types (not just posted data). Again, you can technically keep things neat by saving your validation rules to a config file and keeping validation in the controller, but that still breaks the MVC principals.
There are a plethora of reasons to use a good base model (also called CRUD Model, MY-Model) for all your CRUD operations in a CodeIgniter (or any) application. Amongst many, a base model will boostrap all models it extends, keep your application as “DRY” as possible and speed up general development. Codeigniter has a pretty neat active record implementation, but you do tend to repeat a lot of the boring database stuff when writing models. In my opinion, you’d be insane not to use a good base model. There are many out there, but I use the amazing base model from Jamie Rumblelow (it deserves and SEO Link before you ask!).
It’s been fairly common news for a while now that the age old Yell.com offer web design services, or “Yellsites” as some have coined it. There’s been a lot written about this fact, with some people citing lots of reasons why Yell websites are evil. There also a fairly in depth post that goes on to actually explain why the author dislikes yell.com websites over here. Additionally, there is also a big pool of annoyed people over at the infamous reviewcentre.
Personally, I think their sites will never set the world on fire, but at the end of the day Yell are tapping into a certain and very specific niche where the majority of their clients are very small businesses. It’s truly a case of you get what you pay for (even if a Yell.com website will cost you more overtime, which is what I assume is key Yell’s business model). For me, it’s great really, as seem to have lots of clients who currently have a Yell site, realise their site isn’t performing for them and want to move on – in I (or any other web person) step. Yell are clearly going down the bulk route with their sites being mass produced and based upon templates – at the end of the day they aren’t charging bespoke prices (in the short term anyway). I say fair play to them if they want to go down that route. This post isn’t in any way intended to knock Yell.com websites in the least. Although I’m not a fan of their apparent sales patter I keep hearing about where Yellsites say they have a special partnership with Google” or the “Did you know Yell.com is the most searched UK website” – for the record, both of those statements are frankly lies and total rubbish.
I’ve come across an endless list of IE6 hacks and apparent fixes for the one browser that still causes many issues. This on is my favourite:
<!--[if IE 6]>
<meta http-equiv="refresh" content="0; url=http://www.microsoft.com/windows/internet-explorer/default.aspx" />
/* <![CDATA[ */ window.top.location = 'http://www.microsoft.com/windows/internet-explorer/default.aspx'; /* ]]> */
Drastic, yet very epic and takes seconds to implement. Solves all your IE6 problems
After reading an article about OOCSS (Object Oriented CSS) I was left a little numb and confused to be honest. I’d advise you read the full article before reading what follows.
The idea is fairly simple – write your CSS using a “bottom up” approach, as opposed to a “top down” approach, treating your elements as “objects”, using mainly classes, as opposed to IDs. The idea of this is to make classes more reusable and to encourage a greater css granularity architecture. The overall theory behind OOCSS is something I don’t dispute in the least, if anything it’s simply good practice when writing a CSS file.
For me, the whole article borders on the pedantic to the outright pretentious.
Firstly, I’m not a fan of the name. “OOCSS” implies a link to OOP (Object Orientated Programming), which it is not. I can see why they’ve named it OOCSS as I guess multiple classes could be similar to inheritance, an element on your page as an “object”, classes imply reusability etc. As a web developer, who uses OOP I was instantly put on the defensive, thinking “OOP for CSS, wtf”. I understand the name is simply a paradigm, but it sends out all the wrong signals for me personally.
Apologies if this article turns into a bit of a rant…..
To date this year, I have inherited several Magento stores to perform web updates on. I thought I’d write a small post on my experience and thoughts in using the system and how that system translates to real world, non technical clients.
As a bit of background, I’m by no means a fully fledged Magento developer in the least. After a few hours of experimenting I managed to get a template based upon my design, up and running.
It’s common knowledge that Magento is touted as the best thing since sliced bread – you constantly see companies selling the (what I call), “Magento experience”. Sales based pitches such as “you’ll never need to upgrade again”, “Magento can do everything out of the box” and “Magento will infinitely scale with your business” are very common from web companies. The latter does not apply to all businesses in my experience. To illustrate, I’ll use the example of a client who came to me in despair at their current web company and Magento based website – I won’t be using any real names.
By default, when installing CodeIgniter (CI), all the important files i.e. all files withing the application and systems folders are installed within the main web directory, that is visible to anyone. This is fine to an extent because all folders have a htaccess file that denys all incoming requests. The CodeIgniter developers did this intentionally to make things easy for people trying the framework out.
However, a much more secure method is to store the application and systems folders within the server webroot. This location is not directly accessible and helps with all around application security. Personally, I feel a lot safer knowing core files are not directly accessible. The latter is doubly as important when using a well known PHP framework, as anyone has a starting point to figure out your folder structure, simply by downloading the framework.
Here is how a typical CodeIgniter install looks on a production server:
In previous posts full page, block level caching with pear cache lite have been discussed. Full page level caching is fine under a lot of conditions. However, sometimes it is desirable to cache the contents of an array to a file. PEAR Cache Lite makes this very easy.
The array used in the following example is for illustration only and very basic. On a real site the array may be the result of several database queries, or even a recursive function to display the full category structure on a website E.g. something a lot more database intensive and costly than a simple array!
The setup using PEAR Cache Lite is exactly the same, the only difference is within the constructor. There is an option called ‘automaticSerialization’ (set to false by default) that enables the caching of none string data E.g. arrays. It is possible to achieve what following by using PHP’s serialize and unserialze functions, but it’s preferable and neater to use what functionality the author of the PEAR Cache Lite class has provided. The code is very simple.
Firstly, include the PEAR Cache Lite class and pass the associative array of options (including the automaticSerialization key) to the class constructor (line highlighted):
Read more …
Sometimes, you have small experiences that really make you appreciate your chosen web host. They leave you glad you spent the time doing your homework, testing out their support, features and generally ensuring everything is easy as possible with them. If it isn’t easy, then your job will be made all that much harder, unnecessarily.
I experienced such a feeling last week with a client who wanted to use their own web hosting. I had updated a small website to include a blog and gallery, both updateable by the client. This wouldn’t usually be an issue at all if using my own hosting – simply upload the files, add in my custom htaccess file for some mod rewriting goodness and away we go.
However, the host in question was 1and1.co.uk. Now, I’ve read some absolute horror stories about this company in the past – all such experiences seem very typical of a very large company, with their support teams based offshore.
So, back onto uploading the updated site in question. I had expressed initial concerns about the clients current 1and1 hosting package, noting that they’d most likely need to upgrade with 1and1, even though they were on an intermediate hosting package entitled the “1and1 Standard package”. I had also personally been forced to use their support about a year ago, which was hard work to say the least. Moving forward, I carried on and uploaded the site to 1and1′s servers and then visited site. Instant internal server error 500. Straight away I knew this was the hosting as I had previously given the client a link to a staging area on my preferred web host, that worked flawlessly. I’m aware 1and1 have some restrictive hosting on their basic packages (which seems to be inherant of such a large company, with thousands of customers in my experience), so I immediately headed towards to the .htaccess file (it’s essentially a variation of the HTML5 Bolierplate template with some of my own magic included, nothing out of the ordinary though) and renamed the htaccess file. Whallah – the site loaded, thus isolating the issue straight away. Great, I can inform 1and1 and find out what htaccess directives are allowed, it should be a run of the mill support request for any support department.