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!).
Category: PHP
Magento as an ECommerce Platform – A Case Study
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.
Continue reading Magento as an ECommerce Platform – A Case Study
How to Install CodeIgniter Within the Web Root
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:
Continue reading How to Install CodeIgniter Within the Web Root
PHP Array Caching with PEAR Cache Lite
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):
Appreciating Your Chosen Web Host
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.
Enchaning an Invoicing System for Reporting
At the start of the year I wrote a custom invoicing system for a client, using PHP and Smarty (hope to convert to use Twig at some point). The client has since come back to me to built in extra functionality – namely a reporting section. I thought I’d share my solution to the issue I was faced with.
The client required some fairly involved reporting facilities, here is a sample of some of the requirements from the client:
- Aggregated report, split between two dates of our choosing, with totals split by either month, day or week (we want to choose)
- A list of invoices for a day of our choosing with aggregated totals of for the day selected
- Annual invoicing report – we want to show a summary of the total for the items sold, the total vat charged and summaries for average invoice values
- Invoices totals grouped by customer
There were several more, but they were all similar to the above.
Firstly, I’ll explain the database setup, for the invoicing, of the current system I built. It was basically two tables – one for the invoivce header and one table for the invoices items – nothing un typical there at all.
Continue reading Enchaning an Invoicing System for Reporting
SEO URL Correction
The use of mod_rewrite to create SEO friendly URLs is common place now. However, if an application is not coded correctly they can have potentially negative effects.
Take the fowllowing URL, this is the URL the developer intended – the news story is fetched from the ID in the querystring:
http://www.site.com/news/23/some-breaking-story.html
Store an AJAX Response into a Variable using JQuery
Sometimes, it’s very useful and a lot cleaner to store the result of an AJAX request into a variable – that can used in your script. For instance, say you’re using some sort of calander plugin that takes an array of exluded dates. It is highly likely that these dates will come from an database. You could echo them out manually by mixing PHP, HTML and JQuery, but this is very messy.
Instead, you could create an AJAX request that queries a database for the dates and stores them in a variable. This is fairly simply when using JQuery:
Continue reading Store an AJAX Response into a Variable using JQuery
Best Practices With PEAR Cache Lite
Caching a website using PEAR Cache Lite has many benefits – it will speed up your site and is very simple to implement. However, there are several common pitfalls they could cause potential issues on a website. Basically, you can’t approach caching from a single angle, as the type of caching used is always project/problem specific.
Full File Level Caching
Full file caching is the simplist method and essentially takes an image of the page at a particular time. This method is very fast to implement but does have it’s downsides. As you are storing a static file of the page you’ll instantly notice the following issues (I’ve included some typical examples you’ll run into):
- Any elements of your page that require session data will fail to work (you’ve essentially cached the session id too!)
- If the page needs to be served using a particular header you’ll be out of luck, as a statiuc file will always be served using a plain text header (E.g. a cached rss feed won’t validate as the header has changed)
- Clearing the cache becomes very clumsey as the whole cache requires cleaning when even a small change is made (E.g. say a new article is added by the admin)
- User logins that make use of session data
- E-Commerce sites and a shopping basket summary
- Search results pages
With full file caching dynamic content will always be a issue. However, full file caching CAN help high traffic sites, even when a short cache lifetime is set – use with caution!
Continue reading Best Practices With PEAR Cache Lite
PHP Image Uploads – Better File Type Checking
When working on a project I came across a neat snippet of code that will uses PHP’s image manipulation functions to check the uploaded image type. The majority of the time the filetype is checked using PHP’s string functions on the file name, as a string E.g.
$myFile = $_FILES['myFile']['name'];
$allowed_filetypes = array('.gif', '.JPEG');
$ext = substr($myFile, strpos($myFile,'.'), strlen($myFile)-1);
This is fine, but the contents of $myFile can be faked. A much better check for allowing only image file uploads would be to do the following – I thought this was quite neat:
if (!$img = @imagecreatefromgif($path_to_image)) {
/* NOT a .GIF image */
}
imagecreatefromgif will return false if the image is not a GIF. A similar thing can be done for checking PNGs (see imagecreatefrompng) and JPEGs (see imagecreatefromjpeg).