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.

Magento – A Small Case Study

My client has a small business consisting of 2-3 people, that sell hand made retro clothing. Their whole store contains 78 products – all with simple size and color attributes. Prior to using Magento, the client used oscommerce. Whilst oscommerce may be crap, the store did generate approximately £250.00 per day – which isn’t too bad at all for a small store. However, my client was approached by a web company (I’ll call them “Web Company ABC” going forward) proposing to upgrade their ecommerce platform. Web company ABC did sell them the whole Magento dream, albeit at the hefty price of £5,900.00 +vat. My client said they were impressed with the rich feature set and functionality. Hell, I am as Magento can literally do everything out of the box.

So, 4 months worth of delayed development later and Web company ABC had developed a rather standard looking Magento theme. Skip forward 7 months after the new site had been live on the internet and I was asked to look at doing some improvements due to it failing. Within 7 months, the store had taken ~ £450.00 – not good at all. The reason for this was clear from an SEO point of view – the site in question was total mess within Google. The upshot was that the site averaged 150 visitors per month. I promplty told my client to speak to her current web company about this, as they had paid £6,000.00 for a store and the SEO basics had not been applied. To summarise the main issues, there were lots of querystring based urls within Google and masses of duplicated content. Additionally, the company had allowed search results pages to be indexed (550 pages of them!) and all the customers login/info screens were indexed too. I suggested they install a small plugin for Magento that sets the correct canonical tag for each page.

The response from web company ABC: “Magento is industry leading software, as result we feel it needs no modification”. Industry leading maybe, but from what I saw it was extremely weak on the most basic SEO front. After 7 months, when Google hasn’t even indexed all your pages, something is wrong in my books.

Now, I haven’t looked at default SEO functionality of Magento out of the box, but a few things jumped out to me straight away:

• Far too many duplicated pages with no canonical tag
• No canonical tag for category filter pages resulting in lots of additional pages indexed
• Lots of issues with urls for products being in multiple categories, as discussed in a blog post about multiple categorisation for seo
• Unnecessary links indexed
• Search results pages indexed

Skip forward a few more weeks and the client was now asking me to design and customise some better transactional email templates as they don’t like the default Magento ones at all. They had previously spoken to their current web company (who used Magento to develop the site in question), who said it was not possible. I’m no Magento expert, but it is most definitely possible according to Google.

My client then asked the question that all clients who use Magento always ask – “Can you help me use the admin area, as it’s too complicated”. It’s also very common (as in this example with Web Company ABC), that full training had not been provided on how to use this area. I felt especially sorry for the client when they emailed me saying “I’ve been trying to add a new product for the last hour with no luck and no one has shown me how to do this”. Feeling very sorry for the client and knowing they had forked out close to £6,000.00 for a site I advised them to ask their current web company. The response was shocking in my opinion: “We can’t support your site to this level, there are lots of guides on the Magento official website”.

There are a few standout issues here when a web company has used Magneto as an ecommerce solution. Make sure you are actually Magento experts – know how the core files work, know how to customise core functionality and know more than being able to install a basic plugin. Whilst I agree Magento does have an impressive feature set, even in the community edition, it is inherently complicated and bloated. The latter is not a criticism, just something that naturally happens when a system is built that attempts to cater for a plethora of requirements.

Lots of web companies seem to hide behind the reputation of Magento and base their whole sales pitch around that. For the smaller clients I’ve dealt with they don’t need such a feature rich system – I’d go as far to say Magento is overkill for a lot of sites it’s used on. In my opinion, the whole system is geared towards larger companies and sites with complicated products. It is not geared towards small sized business with simple products. I put together a list of changes for web company ABC that would solve all the issues the client was experiencing, some involved installing small, third party plugins. The web companies response was simply: “we feel Magento works well of the box and doesn’t need any additional plugins”. Fail.

The Infamous Magento Administration Area

Now comes my major criticism about Magento – it’s insanely mammoth administration system. As a developer I personally like it – lot’s of functionality and settings to play with and lots of general control. For the end user, in my experience, this is the area that makes Magento fail as a platform for me – for a few reasons. For a normal user, there is simply too much functionality, and too many options to make even the most basic tasks extremely difficult. Does an end user really need functionality to control essential system settings for example? I felt really bad after accepting a small admin fee after the client emailed me the following out of pure frustration: “can you please add a discount code to my store as I’ve spent 20 minutes trying to get this to work”. All they wanted tom do was add a voucher code that knocked 20% off orders over £100, but due to the complexity they were unable to do this simple task. I personally liked this area, but can see why a non technical user would get confused.

If companies are going to push Magento as their platform of choice and tout it as the best thing to build your business on, they need to provide training on how to perform basic tasks within the administration area. It doesn’t matter the value of the project – the administration area remains complicated and end users need training. However good an ecommerce platform Magento may be, if end users have difficulty using it something is wrong. Web companies should realise this include training as part of the price.  Leaving a client with the advice of “go and read the Magento docs” (which are quite technical in their own right) is not acceptable and does little to help the client.

Please don’t misunderstand me here. I am not saying Magento is bad ecommerce platform. What I am saying, is that Magento does not have a place for every level of ecommerce store and that users require training. My advice, if you’re considering Magento for you platform, take note of the following:

• Don’t get caught up in the sales speak and try to ignore the shiny default template
• Remeber you’ll need to set aside a great deal of time to learn the administartion area – you may need training here
• Magento is not for every niche/business. The feature set and size of Magento implies you have a high volume of and complicated product variations
• Remember that due to the complexity of Magento, you’ll no doubt pay a premium for updates where a plugin will not suffice

What are your views on this matter?

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:

- CodeIgniter_2.0.3
---- application
---- system
- public_html
---- assets
---- index.php
---- .htaccess

The “public_html” directory will vary from host to host and has many names depending on the hosting setup – it is the files from which the live website is served from. The major benefit now, is the only file directly accessible is index.php. The assets folder is included in all my projects, for things such as images, css files and JavaScript. For additional security, directory browsing is disabled by means of adding the following to the main htaccess file:

Options -Indexes

To complete the move of the core CodeIgniter files there are a couple of other small tweaks:

Open index.php, go to line 59 (CodeIgniter v 2.0.3) and change (several lines of PHP comments have been removed here for readability)

$system_path = 'system';
$application_folder = 'application';

to

$system_path = '../CodeIgniter-2.0.3/system';
$application_folder = '../CodeIgniter-2.0.3application';

The latter change simply tells CodeIgniter to look for those core files in an alternative location. The absolute path to the file could have also been used.

The name of the CI directory has the following format: CodeIgniter-x.x.x, where x.x.x is the CI version. Naming directories this way allows different versions of CodeIgniter to be more easily upgraded, without affecting the current used version. For instance, CI version 2.0.4 would be placed in CodeIgniter-2.0.4 – $system_path and $application_folder would be adjusted accordingly.

The above method can be applied to any website, it doesn;t have to be CodeIgniter or a PHP Framework. For instance, say you had a vanilla PHP site that used a single configuration file and a bootsrap file – both containg lots of important settings and data. Simply place the two files within the webroot and adjust your include paths within you application pages. Another example is with third party caching systems. An application may make use of PEAR Cache Lite to Cache Arrays for example. It would be good practice to set the cache directory directly within the web root, meaning cache files are not directly accessible.

That’s it – within a couple of minutes you’ve just improved the security of your application!

Why backup data?

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):

include 'Cache/Lite/Output.php';

$options = array(
    'cacheDir' => 'pear_cache/',
    'lifeTime' => 3600,
    'automaticSerialization' => true
);

$cache = new Cache_Lite_Output($options);

Secondly, for simplicity, include a function to generate the array to be cached. As previously mentioned, this array would come from some sort of database intensive operation under normal circumstances:

function letters() {
    return range('A', 'Z');
}

Thirdly, check for a cache hit or miss. If there is a cache miss, generate the array and save it to a cache file (line 5). Otherwise, there is a cache hit and the cached data can be used directly (line 2):

if( $data_array = $cache->get('array_of_letters') ) {
    $data =$data_array;
} else {
    $data = letters();
    $cache->save($data);
}

Lastly, use the array within your application normal (the following example simply outputs each letter with a semi colon after each item):

$count = count($data);

for ( $i=0; $i    echo $data[$i];
    echo ($i != ($count-1)) ? ' : ' : null;
}

Looking at the actual cache file (open it using your PHP editor or Wordpad as it has no file extension), you can see the cached array has indeed been serialized (the letters at the beginning of the file are a timestamp and not part of your cached array):

715704231a:26{i:0;s:1:"A";i:1;s:1:"B";i:2;s:1:"C";i:3;s:1:"D"; ... [removed for usability] ...   s:1:"Z";}

That’s it! For reference, the full code can viewed below:

include 'Cache/Lite/Output.php';

$options = array(
    'cacheDir' => 'pear_cache/',
    'lifeTime' => 3600,
    'pearErrorMode' => CACHE_LITE_ERROR_DIE,
    'automaticSerialization' => true
);

$cache = new Cache_Lite_Output($options);

function letters() {
    return range('A', 'Z');
}

if( $data_array = $cache->get('array_of_letters') ) {
    $data =$data_array;
} else {
    $data = letters();
    $cache->save($data);
}

$count = count($data);

for ( $i=0; $i    echo $data[$i];
    echo ($i != ($count-1)) ? ' : ' : null;
}

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.

However, such a request to 1and1′s support department wasn’t easy in the least, in fact it was very challenging. After being on hold for roughly 10 minutes I was answered by one of their offshore support staff, who was quite difficult to understand, yet very polite. All I wanted to know was what, if any, features they support on custom htaccess files, on the clients current hosting package. Simple right?

This is the point things got a little messy unfortunately (yes, so early on in the telephone call). After putting me on hold for a further 5 minutes, the lady came back to telephone to tell me to “check my htaccess file for misconfigurations”. I  reiterated my previous statement (as there are no errors) and she told me to “please hold so she could check more things”, after saying it is easy to leave typos in htaccess access files (I guess that’s true, but it wasn’t the case here). After a further 5 minutes was told to go to a PHP script she had uploaded on the site, that displayed the output of a phpinfo call, that I should “check”.

Let’s take a step back here. I have isolated the error down to a server restriction on the 1and1 end. Their response has been to check my perfectly working htaccess file and to look at the output of a phpinfo call. It should be obvious to a person working on a technical support line that if I’m not getting an internal server error after removing a htaccess file, then the issue lies with the custom  htaccess file – it’s error isolation 101, surely? I explained this yet again to the operator who then suggested I “remove the htaccess file to prevent misconfigurations”. At this point I was getting a little impatient, decided to make my excuses and end the call – as we were getting no where. Granted, the lady was very polite on the phone, but my issue was not getting dealt with at all.

So after a 35 minute phone call, I was still left with a site, through no fault of my own, that wasn’t working. Not good for me, the client or my general sanity. I decided to call again, in order to get this resolved. I sometimes do this in the hope of speaking to a different, more informed member of staff. Sometimes I get lucky, others I don’t.

The second time I called I believe I spoke to someone a little more experienced, still in an offshore location though. I had to re explain my issue again (there were no recent calls logged, quite annoying …), I got equally as illogical replies as before. I was told one “solution” (said in the loosest sense here) was to go through each line of the htaccess one by one and keep commenting out lines until I tracked down the issue. The file is over 250 lines long – no thanks! That is not a solution at all in my books. At this point I gave up and decided to report back to client.

What was a little odd related to the emails that got sent the my client, about 20 minutes after my first call – my client forwarded these onto me. Here is a copy of paste (the gramatical errors are definately not mine!!!) of the email:

This is an update regarding your previous call, abou your site “**********” that is showing error 500. When there is an error with a .htaccess file, all pages of the website will display a 500 error indefinitely until the .htaccess file is corrected or removed. As little as a simple spelling mistake or syntax error will cause a 500 error. If the .htaccess file has been edited recently, replace the file with a backup. If no backup is available, try to undo the changes to the file if you can remember what has been altered. If those options are not feasible, you can try commenting lines one by one by placing a pound sign(#) at the beginning of the line to comment it out. Then try to access a page of the site. Continue to add the pound sign to more lines until the 500 error stops which should help you pinpoint which line needs to be corrected.

(email sent 14 October 2011 15:51:36 GMT, from support@1and1.co.uk)

I then got the following email from them re the second call:

This is an update regarding your call awhile ago, please refer to our FAQ link below for you to check the php settings on the server. You will need to create a phpinfo.php file using notepad and copy the code then paste it in your phpinfo.php file: How can I check the PHP settings on the server? http://faq.oneandone.co.uk/server/managed/8.html

(email sent 14 October 2011 16:42:00 GMT, from support@1and1.co.uk)

A little later, the following email came through, again a copy and paste:

Please upload the phpinfo file for you to get hold of the list of all settings allowed on our servers. With regard to the .htaccess file, sometimes the problem is with the syntax you encoded. In this regard, we highly advise that you make sure you key in the correct directives in order to prevent further issues.

(email sent 15 October 2011 06:23:00 GMT, from support@1and1.co.uk)

Great, yet more generic statements that don’t help. We have established several times now that the htaccess file was working correctly on the 1and1 hosting, that the issue was due to the 1and1 servers and that all I wanted to know was what, if any, htaccess directives are allowed/disallowed.

These emails are not helpful to anyone and needless to say, I won’t be chasing 1and1 up any further about this – it’s far too time consuming. Instead (and for the sake of my own sanity) I advised my client to transfer her site.

What is most concerning, apart from the fact 1and1 support have drastically failed to understand my rather basic issue, is that the replies are clearly written without appreciation for none technical people – everyone doesn’t know (read: probably doesn’t want to know) about the technical aspects of PHP settings and htaccess files.

I digres, all that is done now and the site has been uploaded to some quality web hosting where I can use a htaccess file. When I compare the poor level of customer service, the poor technical knowledge they demonstrated and the fact that a simple issue went on for much longer than it should have, to my current web host, the difference is night and day. With my preferred host, everything is so easy, if I need support I can get answered within a few minutes maximum.

At times like these and as a web developer, you really appreciate a good web host and things “just working”. However, the major difference between webhosts in my opinion, is flexibility and basic reason in my experience. Support teams/staff who take the time to understand your issue and have flexibility in solving your issue are easier to deal with. For instance, on my preferred hosts I was having a small issue with a php hashing framework, casuing my site to not work correctly. All that was required was quick email stating the problem and a response saying that they have added in a few commands to a custom php.ini file – the issue was essentially turned into a none issue – all sorted within 10 minutes (even though this issue was potentially more complicated than my little htaccess problem).

No drama, no drawn out telephone conversations to offshore locations – just my issue being solved within good time (thanks to Darren from tsohost for this by the way!). Another big benefit highlighted here is having knowledgeable people – when I stated my issue, they clearly know what they are talking about and clearly are not reading from prompt sheets – this alone, speeds up support requests significantly. I have personally come to the conclusion that the staff I was speaking to were using prompt sheets – purely due to the level of answer (or lack of answer) I was provided with.

Honestly, before you ever choose a webhost do yourself a huge favour. Do not look for the cheapest price. Do your research and test out your potential host first. Pay particular attention to quality and speed of support you receive. I couldn’t go through the above every time I needed a basic support question answering.

The above represent’s my own, personal opinion and is in accordance with my blog disclaimer. It does not represent any company I have ever or currently work for.

LATE NIGHT UPDATE! I was just about to go to bed and the following email came through, very unhelpful (although very polite) – I’m not sure why this issue is such a huge deal? How is a server error out of the scope of a technical support department????? Anyway: the email (copy and pasted again):

We deeply apologize for this inconvenience. Error 500 is misconfiguration of script in the .htaccess file. Please check it and we are no longer able to extend our help as this is already out of our scope of support. Again, we understand your frustration and we deeply apologize for the inconvenience.

(email sent 15 October 2011 21:14:00 GMT, from support@1and1.co.uk)

If anyone is interested, I can post by email response to the latter email. But as you’d imagine, I was less than pleased at the exceptionally poor level of service from 1and1

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.

My first point of call to integrate the reporting was to use what I had already. This proved qwuite complicated as it involved fecthing large sets of data to calculate the totals required by the reports – this was also pretty slow when running the more intensive reports over a longer date range. It would get even more complicated and database intensive when I wanted totals for the other reports.

After some consideration, my solution to this was simple. I decided to add a few new columns to my invoice header table – “invoice_total”, “invoice_sub_total”, “invoice_vat” and “total_invoice_items”. For the reporting side of things, this made the whole process much easier. For example:

To get an aggreate total figure invoiced between two dates, I required a single sql statement, that required no joins, or loops in PHP:

SELECT SUM(`invoice_total`) As total_invoiced FROM `invoice_header` WHERE (`invoice_issue_date` >= :myDate AND `invoice_issue_date`

Equally as simple, to get a monthly total between two dates, grouped by month, the sql statement was just as simple:

 SELECT SUM(`invoice_total`) As total_invoiced FROM `invoice_header` WHERE (`invoice_issue_date` >= :myDate AND `invoice_issue_date`

Getting average invoice sub total between two dates:

 SELECT AVG(`invoice_sub_total`) As average_invoice_subtotal FROM `invoice_header` WHERE (`invoice_issue_date` >= :myDate AND `invoice_issue_date` 

The latter made the actual PHP code required to produce the required reports very straightforward – before I would have required joins to caluclate the totals and multiple sql queries – that could have got quite messy. I also gained a few added benefits of storing the totals within my header table:

• On the print invoice screen, there was need to calculate anything, as I simply read the totals from the datbase
• On the invoice listing screens, I could now display an invoice total in a seperate column, as this was again, simply a database value – before I would have needed to calculate this total via the invoice items table

However, this simplicity in one area, came at a cost … unfortunately. As all report data was now based from totals in the invoice header table, this figure needed to be correct at all times. I needed to amend the add and edit invoice functions. When adding an invoice, I needed another loop to calculate the aggregate totals to insert into the database. When editing the invoice, I needed to recalculate these totals each time the invoice was edited (in case a row was deleted for example). Whilst the latter added a little more work when adding/editing invoices, I feel that this is well worth it due to simplicity when dealing with the reporting side.

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

However, if the application is coded badly the following URLs may also exist in order to reach the same content:

http://www.site.com/news/23/ANYTEXTHERE-some-breaking-story.html

http://www.site.com/news/23/some-breaking-story.php

http://www.site.com/news/23

The latter can have potential issues for your SEO rankings. If search engines pickup on the fact that muliple URLs all goto the same duplicate content then your site send out bad signals to search engines – this should be avoided. There si recent talk that duplicate content is simply ignored by search engines and now a none issue. However, even ignoring direct penalties imposed on your site, having the same content divided over multiple URLs can reduce your rankings simply by diluting content.

The answer is URL correction and correct use of headers. A single URL for a single page is the goal. This is fairly easy toachieve by following the below methodology in your scripts:

• Make your mod_rewrite rules specific (E.g. don’t use lots of ([^/]*) flags as that will match anything!)
• Create a standard base URL for the content
• When the page loads, check that the base URL (or expected URL) matches the page requested by the visitor
• If there is a mismatch, set the correct HTTP headers and redirect to the correct, expected URL

Firstly, adjust your rewrite rule to be more specific:

RewriteRule ^news/([0-9]+)/(-a-zA-Z)\.html$ news.php?TITLE=$2&NEWSID=$1 [L]

This now looks for the following pattern: a number, letters and then a .html extension.

You can also adject your application logic to add in the following:

/* At this point, query your database to retreive information
The variables $title and $id would come from the database */
$actual_url = myClass:getCurrentRequestedURL();
$expected_url = LinkFactory::NewsItem($title, $id);

ob_start();

if ($expected_url != $actual_url) {
ob_clean();
header('HTTP/1.1 31 Moved Permanently'); //Send 301 status code
header('Location: ' . $expected_url); //redirect to expected url
ob_flush();
}

Depending on your url rewriting structure, you’ll notice that WordPress does a very similar thing.

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:

$(document).ready(function() {

    var myAJAXVariable = (function () {
        var myAjaxValue = null;
        $.ajax({
            'async': false,
            'global': false,
            'url': 'ajax.php',
            beforeSend: function () {
                $('h1').css('background-image', 'url(ajax.gif)');
            },
            success: function (returnedData) {
                $('h1').css('background-image', 'none').html(returnedData);

            }
        });
        return myAjaxValue;
    })();

});

The ajax.php file simply returns a list of comma seperated numbers from a loop – in reality this woulod be actual output from your database. The contents of ajax.php:

$values = array();
for ($i = 1; $i<11; $i++) {
    $values[] = rand($i, $i*23);
}
$data = implode(", ", $values);
sleep(3);
echo $data;

There is a delay of 3 seconds to simulate an intensive script – so the example doesn’t load instantly. The HTML is very basic, it only requires a single, empty h1 tag (as I’ll be loading the contents of AJAX result into it).

That’s it, the final result can be seen here and you can download the source files from here.

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!

Block Level or Partial File Caching

Block level caching is likely to be a much longer term caching solution. It is more likely that you’ll have certain sections of a site that do not require an up to date minute. For example, say we have an ecommerce store with dropdown menu that list our full category structure from a database – this is likely to be highly database intensive and may use recursion. This output can be cached to a flat file as follows:

$options = array(
    'cacheDir' => '/cached/',
    'lifeTime' => 1000
);

$cache = new Cache_Lite_Output($options);

if (!$cache->start('left_category_structure')) {
   $store->list_full_category_structure();
   $cache->end();
}

This is much better than full file caching for several reasons:

• The page in question can remain dynamic dynamic elements such as the user’s login status on another part of the page
• If a change is made to the category structure I can delete that particular section of the cache only (the rest of the cache does not require regenerating!)
• The cache lifetime can be set on a per block basis – useful for different types of content
• Even if the category structure doesn’t change often, the block could still be cache forever (set cacheLifeTime to null in the options array) and cleaned when a change is made

Taking Partial Caching Further

PEAR Cache_LIte is also fairly flexible and you can make it fit your needs. For example, say we wanted to cache 10 random articles on a website – which consists of a database query that fetches 10 random articles from a database. The idea here is to still cache the content in a block as above. However, for this our system would create a number of cache blocks and then service those cached blocks to the user. The solution is a simple one, building on the example from above:

$options = array(
    'cacheDir' => '/cached/',
    'lifeTime' => 1000
);

$cache = new Cache_Lite_Output($options);

if (!$cache->start( 'left_category_structure . rand(1,5))) {
   $store->list_full_category_structure();
   $cache->end();
}

When the user requests a page, 5 different cache blocks will be checked – we are essentially creating 5 different versions of the random cached content.

$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).

Ok, easy job – or so I thought. If the previous developer hadn’t been a total mong this simple update would have taken a minute or so – simply update a common function, database or global array to repopulate the drop down list options. No luck in the least – the developer had hard coded each drop down into every page, using HTML – **** great! So I just spent close to 40 minutes wading through include files and HTML to make my changes – so unecessary.

So, what follows is a very simple method to have a common drop down list that will be included on any page you want, with the data stored in a global array (could be a database, but a global array is quickest:

The include, model or config file – simple an associative array that will be accessible throughout your application (lets call this file includes.php):

global $customer_types;
$customer_types = array("1"=>"Normal", "2"=>"Debtor", "3"=>"Dispute", "4"=>"Premium");

The page or view – simply loop through the associative array (as we defined it as a global variable earlier) using the key/value style:

include 'includes.php';
echo '<select name="myTypes">';

foreach ($customer_types as $key=>$value) {
    echo '<option value="'.$key.'">'.$value.'</option>';
}

echo '</select>';

… and there you have it, in a couple of lines code you have an select box that can be maintained from a single file and used on as many pages as required.

/slaps previous developer for making me waste 40 minutes unecessarily