In August 2009 I had been programming with CodeIgniter a little over 2 years, in that time I learned a lot of things which would have been good to know when I began. I made a list of stuff I considered best practices for programming in CodeIgniter, which I have kept up to date. But as I have since moved on to another framework this is it, the final update was on: March 2nd, 2012
These 2 posts I licensed under MIT so do with it as you please as long as you give proper acknowledgement about the origin.
RT(F)M: Read the User Guide & watch tutorials
Clear and simple, don’t ask questions before you looked into the awesome thing that makes CI stand out among frameworks: The CodeIgniter User Guide. There’s a lot of references in this article to the user guide, but those are highlights for specific topics - the whole thing should be read!
Also to get started you can find some video tutorials on nettuts+ or view the (very dated) video tutorials on the CodeIgniter website. The latter is using an older version but when you take that into consideration it’s still a nice place to start understanding the basics of using CI.
If you don’t know the MVC pattern read up on it! You’ll learn soon the value of putting the data-access in models, the application logic in controllers and the visuals in views. But if you haven’t done programming in such a pattern before it might take a while to sink in, give it the chance to sink in!
A good guideline is to put as little as possible into your controller. Adhere to the DRY principle: Don’t Repeat Yourself. When functionality is needed in more than one place, create a library, helper or model (depending on what kind of functionality it is). You’ll notice that once you start to grasp the MVC basics this will become habitual and you’ll start to reap the benifits that good clean MVC code bring.
Error reporting and debugging
One of the most often made mistakes is to forget to turn off PHP errors or Database errors, both of which are gigantic security riscs. It’s a security risk because you allow an attacker to debug his hacking using the displayed warnings.
Codeigniter offers environment settings to help with this. On any public site error_reporting should be set to 0 (or at most E_ERROR), database setting db_debug should be set to false and just for extra measure I tend to do a ini_set(‘display_errors’, ‘Off’).
At the same time you should debug your application with error_reporting set to -1 (this will show E_ALL and E_STRICT, E_ALL doesn’t include E_STRICT warnings), and solve every notice and warning before making your application public. You tend to spot “invisible” bugs sooner and thus write better code. (more on the error reporting levels on php.net)
One way to make all of this easy has been for me to set the db_debug value (in the application/config/database.php config file) to a constant I declare MP_DB_DEBUG. And add the following code to the top of the main index.php to replace the error_reporting() declaration when the site is live (will disable all errors):
But when in production or testing phase I’d suggest:
For even better error reporting Dan Horrigan ported a great error reporting script to CI which you can find on Github. This must never be switched on in a live-site environment but is a huge help during production and has probably saved me hours already.
Application & System directory placement
An absolute best practice is to put the system & application directories outside the webroot. If your main index.php is in your FTP in a directory like /public_html/ try if you can upload the system directory to the root as /system/. That way no one can access your PHP files except through the index.php.
Don’t forget to change the values $system_folder and $application_folder in the main index.php file. $system_folder should be relative to the index.php file, $application_folder should be relative to the system folder.