In this episode we create a user model and focus on securely storing passwords in a database table by using sha256 encryption. We go over the reasons why using MD5 is no longer acceptable and we create a password validation method.
Be sure to watch in HD.
SwiftMailer is a powerful library for sending mail written in PHP5. SwiftMailer supports SMTP, Sendmail, Postfix, or your custom transport implementations. There are many advantages to using SwiftMailer in your application as opposed to simply using PHP's mail() function.
Sparks are small packages that can be quickly installed into your CodeIgniter 2 application.
We have created a swift-mailer spark that enables developers to install swift-mailer with a single command.
php tools/spark install swift-mailer
If you don't have Spark installed into your project you can find instructions here.
You can find more information about our swift-mailer Spark on the official Spark page or on the Github page.
This screencast covers the installation of CodeIgniter 2 and the PHP ActiveRecord model library. We install and use CodeIgniter Sparks to simplify the installation of PHP ActiveRecord and any compatible functionality that we wish to add in the future.
Be sure to watch in HD.
This screencast continues a series with the goal of documenting the development of a functionally complete site using PHP with the CodeIgniter framework and jQuery for JavaScript UI Improvements including AJAX interactions.
This video covers the development of an admin user management system (CRUD) and includes updates to the authentication system including a method that is used allow only admins into specific sections of the site.
This article discusses the reason behind the base_url() method and the creation of a helper file that will assist in managing images, css files, and more.
PHP code is far from the only content necessary for most web applications. Most frequently we need to include images, css files, flash files, and many other types of files. The CodeIgniter framework doesn't contain a built-in methodology for asset management, leaving the developer to their own devices when it comes to deciding where to put this content. Every developer is going to have their own personal preference, and for the most part they're equally valid.
Imagine a scenario where you have developed a site that contains user profiles. Each user profile can have an image. The code in your view that would display the image may look something like this:
<img src="/images/profiles/myface.jpg" alt="" />
This works fine until your cool new site is bought up and now your application rests at http://www.bigcompany.com/mycoolsite. Now, you have to go through all of your code and search/replace "/images with "/mycoolsite/images while hoping that you've found everything and that something small won't be missed until 500 users have seen it.
Instead, we use the base_url() method for creating absolute links. base_url() simply outputs the value of the $config['base_url'] variable that is set in your application/config/config.php file. Your new code would look like this:
<img src="<?=base_url()?>images/profiles/myface.jpg" alt="" />
Now, if you need to change the location of your site you can simply update the $config['base_url'] value in your application/config.php and your code will be updated throughout the site. For this reason it's a good idea to use base_url() anywhere that you would use an absolute or relative url that points to your CodeIgniter site.
<form action="<?=base_url()?>admin/users/edit/72" method="post">
<a href="<?=base_url()?>admin/pages">Manage Pages</a>
We not only have to consider that our application may be moving, we need to consider how we're keeping our static assets mobile, things like images, css files, etc. My method is to create a path_helper that contains a new function, asset_url().
// application/helpers/path_helper.php
if (!function_exists('asset_url'))
{
function asset_url()
{
// the helper function doesn't have access to $this, so we need to get a reference to the
// CodeIgniter instance. We'll store that reference as $CI and use it instead of $this
$CI =& get_instance();
// return the asset_url
return base_url() . $CI->config->item('asset_path');
}
}
Then, in either our config.php or in a new configuration file we would add:
// config.php
$config['asset_path'] = 'system/application/assets/';
Now, we just add the path_helper and the configuration file (if you're not using config.php) to the autoload.php file.
// Note that you omit the _helper.php suffix from the filename when loading helpers, it's automatically added by CodeIgniter.
$autoload['helper'] = array('form', 'url', 'path');
// This line doesn't need to be use if you modified the config.php file, as it's already loaded for you.
// This line configures application/config/site.cfg to be autoloaded on every page load.
$autoload['config'] = array('site');
Now that the helper has been created, the configuration updated, and everything set to autoload we're ready to use the asset_url() method. Here's the new way of writing image source.
<img src="<?=asset_url()?>images/profiles/myface.jpg" alt="" />
Now, the asset root folder can be moved anywhere you'd like and you'll be able to easily move these files around. This can be very useful if users are uploading images to your live site and you wish to view them on your dev site as well. You could simply update your configuration so that instead of use base_url() it uses http://www.mysite.com/ so that asset requests hit your live site instead of the local development site.
Naturally, all programmers prefer to do things differently. Some prefer the asset_url set to './' so that the images/ folder is at the same place as the CodeIgniter system/ folder. I personally prefer to place assets under the application folder as shown below:
system/application/assets/images system/application/assets/js system/application/assets/swf
I am of the opinion that the entirety of a site should be contained within the application/ folder, allowing for the rest of the CodeIgniter structure to be replaced (version upgrade) simply. It's always important to consider the cost of maintaining the site in the future. It doesn't cost any extra time to implement good practices during development but it can be very costly to retrofit a site with similar functionality, especially if there's been personnel changes.
The mark of a professional developer is designing and developing with focus on the lifetime cost of the product.
If you have any questions or suggestions please leave a comment.
This screencast continues a series with the goal of documenting the development of a functionally complete site using PHP with the Code Igniter framework and jQuery for Javascript UI improvements including AJAX interactions.
In this video we utilize the user model that we've created to create a login process for our website. We'll use the code igniter form helper, database library, and session library.
I tried something different and recorded the video in HD. The encoding left the dark background text a bit hard to read, so if I continue to upload HD videos I'll switch to using a white background. Please let me know if you prefer the old resolution or the HD resolution.