creating a microsite manager with codeigniter

Thomas Myer

Creating a Microsite Manager with CodeIgniter®

Updates, source code, and Wrox technical support at www.wrox.com

Wiley Publishing, Inc.

Contents

Introducing CodeIgniter 2What’s Model-View-Controller? 3Why Bother with MVC? 4

Installing and Configuring CodeIgniter 5The Root Folder 6The system/ Folder 6The system/application Folder 7Tweaking the Configuration 8

Getting Started 10The Login Area 11Creating the Template View 12Creating the Login Form 14Reworking the index() Function 15Creating the MAdmins Model 16Creating the verifyUser() Function 17Autoloading the MAdmins Model 17A Small Note about Creating Your First User 18

Creating the Admin Dashboard 18Creating the Dashboard Controller 19Building the Admin Area 22Setting up the Site Builder 35

Conclusion 39About Thomas Myer 40

Wrox Blox0 Creating a Microsite Manager with CodeIgniter By Myer - ISBN0 97804704133711 Prepared for CHRISTOPHER RINGWALD/email0 [email protected] Order number0 40397143 Copyright 2009/ Wiley Publishing Inc. This PDF is exclusively for your use inaccordance with the WroxBlox Terms of Service. No part of it may be reproduced or transmitted in any form by any means without priorwritten permission from the publisher. Redistribution or other use that violates the Wrox Blox Terms of Service or otherwise violates theU.S. copyright laws is strictly prohibited.


A recent trend in online marketing has been the increased use of targeted microsites to deliver information to prospects and customers. If you’re not familiar with the term, a microsite is a small web site that is focused on a very narrow range of topics or that has a single goal (like introducing prospects to a product line or gathering leads).

Most of the time, microsites are static sites with only a handful of pages and a few forms. They may or may not include rich media like Flash and video. Just because they’re usually small and tightly focused doesn’t mean that they’re one-shot deals. My experience has been that once a marketing team strikes on the idea of building a microsite, they usually iterate over the content and structure many times, because they have that freedom.

These iterative cycles can cause the seemingly simple goal of creating a microsite (after all, you’re only talking about a few pages, right?) to disappear and instead be replaced by a confusing process without any centralized control or logical workflow. Anyone who has seen a team of developers, writers, designers, and subject matter experts (SMEs) trying to hammer out messaging for a product rollout, while at the same time debating structure and trying to maintain publishing control, knows that even the best intentions can be made into a hash in no time.

A good approach to the problem is to build some kind of microsite management tool that would allow a team of marketers, writers, and developers to create a microsite and then publish the files to a web server. In this Wrox Blox, I show you how to do just that.

You’re going to build a microsite manager using CodeIgniter, a PHP Model-View-Controller (MVC) framework. Before getting into any of the details of MVC and CodeIgniter, let’s consider the microsite manager itself. From a requirements perspective, the microsite manager should:

Allow users to log in to a secure area.

Allow users to organize content into folders or categories.

❑

❑



�

Allow users to create pages.

Allow users to upload files and other media.

These requirements address the what (or the content) in the microsite, but eventually, the microsite needs to be published to a target location. The developers may have little or no control over the target environment. They may or may not, for example, be able to specify a type of database or even PHP support. In fact, they may be publishing to an ASP or ColdFusion server, or to a server that only supports basic HTML.

For these reasons, the microsite manager you build needs a publication function that extracts information from the microsite database tables, applies templates to it, and then publishes the material to a designated target, all as flat HTML. Once you have all of the material in HTML (with supporting assets and media files, of course), you’re free to place that information on any web server you choose.

Introducing CodeIgniterCodeIgniter was created by EllisLab, Inc. It is a Model-View-Controller (MVC) framework with a very small footprint. In form and function, it is very similar to other MVC frameworks, like Ruby on Rails. Like Ruby on Rails, it requires very little configuration to get started. I’ve been able to create prototype applications within hours of talking to a client, and then refined the prototypes over the course of a few days.

It’s this kind of prototyping power and flexibility, by the way, that will transform the way you work with clients — but more on that later.

Unlike Ruby on Rails, CodeIgniter doesn’t require you to adhere to a strict set of coding rules. For example, you don’t have to name your database tables a certain way and your models another. You don’t even have to have strictly formatted table fields — which makes CodeIgniter an excellent platform for recoding legacy applications.

Below are a few more great things about CodeIgniter:

There is a growing toolbox of helpers and libraries that help you do your job quickly.

You don’t have to learn a complex templating language.

You don’t need to work with large-scale monolithic libraries.

You can run your applications in PHP 4 or PHP 5 without too much hassle.

CodeIgniter applications run with exceptional performance.

I won’t get into too many more details right now. You’ll start seeing the difference once you start coding. For now, though, it might be useful to talk a little bit about MVC, and why it’s important. Then you can get to work.

❑

❑

❑

❑

❑

❑

❑



�

What’s Model-View-Controller?Model-View-Controller is a design pattern that allows developers to separate their code cleanly into three categories:

Models help you maintain data.

Views display data from the model and user interface elements.

Controllers handle user events that interact with models and views.

The important thing to remember is that MVC takes the user into account — it begins with them. It’s the user who clicks a link, moves the mouse, or submits a form. It’s the controller that monitors this activity and takes the appropriate action (such as manipulating the model and updating the view).

Because of MVC’s three-part separation, developers can create multiple views and controllers for any given model without forcing changes in the model design. Similarly, multiple controllers can make use of any model. This separation allows for easily maintained, portable, and organized applications.

For example, think about an MVC application that allows you to track eCommerce items in an online store:

You would have a model for product information.

You would have multiple views to show single products, products in a list, products in search results, and so on.

You would have at least one controller that would organize those views into destinations, such as index() (for home page), product_detail(), and search_results().

Drilling down further, an MVC eCommerce application might involve the following flow of events:

1. The user visits the store’s home page.

�. This simple event requires a controller action for the home page, which makes a quick call to the model to retrieve the 10 most popular products based on recent sales.

�. The model’s data is then transmitted to the view for the home page.

4. The view (including the data retrieved by the model) is what the user sees in the browser.

5. The user clicks on a link to see details on a particular product.

6. The underlying controller captures this user input (clicking the link), uses the model to retrieve the product in question from the database, and then loads the appropriate view.

7. The cycle begins anew when the user takes another action, such as running a search or clicking on a link.

❑

❑

❑

❑

❑

❑



4

This three-part analogy is a much simpler way of looking at things. Some might argue that the approach is much too simple. After all, it’s possible, some might argue, to create an MVC application without a model, or to gang-press view code into the controller. It’s not a good idea, but it can be done. For right now, our simple analogy will hold.

Why Bother with MVC?Although at first glance the MVC approach seems like a lot of work, it really isn’t. When the developer of the hypothetical MVC eCommerce application wants to change something about the home page, she asks herself about the nature of the change. Doing so allows her to zero in on the part of the application on which she needs to work.

displayed for interacts with

updates manipulates

user

controllerview

model

Figure 1: The Model-View-Controller framework in action.

Another way of thinking about this breakdown of roles is to map it as follows (see Figure 1):

User Input and Traffic Control = Controller.

Data Interaction and Processing = Model.

Output = View.

❑

❑

❑



5

If she wants to change the number of products that get retrieved (or even the order in which the products are displayed), she updates the model.

If she wants to change the way the home page looks, she updates the view.

If she wants to add a new page to the application, she first adds a method to the controller and then builds out any supporting views (to display content in the browser) and models (to gather data from a database).

The beauty of the entire system lies in the fact that none of those hypothetical actions on any given part of the MVC triumvirate affects the others. It’s true that changing the model in some way (retrieving 15 products instead of 10) will change the view, but the developer didn’t have to dig through her view (or controller) to make that change, then later discover another SQL call embedded in other files that did the same thing. Theoretically, on large projects, you could have developers who focus only on views, controllers, or models, thus keeping clean lines of sight on deliverables and responsibilities.

Installing and Configuring CodeIgniterTo get your hands on CodeIgniter, point your browser to www.codeigniter.com and click the Download CodeIgniter button, shown in Figure 2.

❑

❑

❑

Figure �: CodeIgniter.com.


www.codeigniter.com


6

Once you’ve downloaded the Zip archive, double-click it to open it and place the contents of the archive in your favorite work area. Once you’ve done that, take a moment to tour CodeIgniter.

As you see, CodeIgniter has a folder structure that looks a bit daunting at first, but believe me, you’ll become very familiar with it. See Figure 3.

Figure �: CodeIgniter’s folder structure.

The Root FolderThe root folder contains an index.php file (called the front controller — it basically routes traffic into the rest of the application), a system/ folder, and a user_guide/ folder. I won’t cover the user_guide/ folder, as it is merely a local copy of the online user guide found at www.codeigniter.com/user_guide/. If you want to explore the documentation, you can do so at your leisure.

The system/ FolderThe system/ folder is where all the action happens. This folder contains all the CodeIgniter code of consequence, organized into various folders:

application — This folder contains the application you’re building. Basically, this folder contains your models, views, controllers, and other code (like helpers and class extensions). In other words, this folder is where you’ll do 99 percent of your work.

cache — This folder contains all cached pages for your application.

codeigniter — This is where CodeIgniter’s core classes live. You have almost no reason to go in here. All of your work will occur in the application folder.

database — This folder contains core database drivers and other database utilities. Again, there’s no good reason for you to be in this folder.

❑

❑

❑

❑


www.codeigniter.com/user_guide/


7

fonts — This folder contains font-related information and utilities. Again, there’s no reason to spend any time here.

helpers — This folder contains standard CodeIgniter helpers (such as Date, Cookie, and URL helpers). You’ll make frequent use of helpers in your CodeIgniter career, and can even extend helpers thanks to improvements introduced in CodeIgniter version 1.6.

language — This folder contains language files. You can ignore it for now.

libraries — This folder contains standard CodeIgniter libraries (to help you with e-mail, calendars, file uploads, and more). You can create your own libraries or extend (and even replace) standard libraries, but those will be saved in the application/libraries directory to keep them separate from the standard CodeIgniter libraries.

logs — This is the folder to which CodeIgniter writes error and other logs.

plugins — This folder contains plug-ins. Plug-ins and helpers are very similar, in that they both allow developers to address an issue or create content (like forms, links, etc.) quickly. The main difference between them is that plug-ins usually consist of one function, while helpers often have many functions bundled inside them.

The system/application FolderThe most important folder, the one that deserves most of your attention, is the /system/application folder (and all of its subfolders). Ninety-nine percent of your work will be done right in this folder, so it deserves your attention. Learning what goes where now will reduce confusion later.

The system/application folder is broken down into several folders:

config — This folder contains several important files that control your configuration options. There are files that manage your database setup and other variables that CodeIgniter needs to know (such as the base URL, which libraries and helpers to autoload, etc.).

controllers — This folder contains the controllers you create for your application.

errors — This folder comes with standard CodeIgniter error templates for 404 pages, PHP errors, and others. You are free to modify these templates to make them fit the look and feel of your application.

hooks — This folder contains any hooks you create for your application. Hooks, as mentioned above, are the best way to extend the CodeIgniter core safely.

libraries — This folder contains custom libraries you create for your application.

models — This folder contains the models you create for your application.

views — This folder contains the views you create for your application.

In other words, the most important folders in /system/application are: controllers/, models/, and views/. If you’ll spend 99 percent of your time inside this folder, you’ll spend 99 percent of that time with models, views, and controllers that you build.

❑

❑

❑

❑

❑

❑

❑

❑

❑

❑

❑

❑

❑



�

The other very important folder is config/, which contains various important configuration files. You’ll want to open them in an editor for tweaking before starting any project. Most of the time, when you start a new CodeIgniter project, you’ll start with the config/ folder.

Tweaking the ConfigurationThe two most important files in the /system/application/config folder are config.php and database.php. Whenever you start a new CodeIgniter project, the first two files you’ll want to work with are these.

config.phpThe config.php file contains a series of configuration options (all of them stored in a PHP array called, appropriately enough, $config) that CodeIgniter uses to keep track of your application’s information and settings.

The first configuration option you need to set inside of config.php is the base URL of your application. You do that by setting the absolute URL (including the http:// part) for $config[‘base_url’], like so:

$config[‘base_url’] = “http://www.example.com/test/”;

Once you’ve set this configuration option, you can recall it whenever you want using the CodeIgniter base_url() function (a very handy thing to know). This one feature keeps you from having to rewrite hard-coded URLs in your application when you migrate from development to test or from test to production.

The second thing you need to do is set a value for your home page by editing the $config[‘index_page’] configuration option. CodeIgniter ships with a value of index.php for this option, which means that index.php will appear in all of your URLs. Many CodeIgniter developers prefer to keep this value blank.

$config[‘index_page’] = ‘’;

To make this work, you need to include an .htaccess file to the CodeIgniter root directory. For now, keep the value as index.php.

After you’ve set this option value, there’s very little to do. For now, leave all the other values at their default settings.

$config[‘uri_protocol’] = “AUTO”;$config[‘url_suffix’] = “”;$config[‘language’] = “english”;$config[‘charset’] = “UTF-8”;$config[‘enable_hooks’] = FALSE; $config[‘subclass_prefix’] = ‘MY_’;$config[‘permitted_uri_chars’] = ‘a-z 0-9~%.:_-’;$config[‘enable_query_strings’] = FALSE;$config[‘controller_trigger’] = ‘c’;$config[‘function_trigger’] = ‘m’;$config[‘log_threshold’] = 0;$config[‘log_path’] = ‘’;$config[‘log_date_format’] = ‘Y-m-d H:i:s’;



�

$config[‘cache_path’] = ‘’;$config[‘encryption_key’] = “enter_a_32_character_string_here”;$config[‘sess_cookie_name’] = ‘ci_session’;$config[‘sess_expiration’] = 7200;$config[‘sess_encrypt_cookie’] = TRUE;$config[‘sess_use_database’] = FALSE;$config[‘sess_table_name’] = ‘ci_sessions’;$config[‘sess_match_ip’] = FALSE;$config[‘sess_match_useragent’] = TRUE;$config[‘cookie_prefix’] = “”;$config[‘cookie_domain’] = “”;$config[‘cookie_path’] = “/”;$config[‘global_xss_filtering’] = TRUE;$config[‘compress_output’] = FALSE;$config[‘time_reference’] = ‘local’;$config[‘rewrite_short_tags’] = FALSE

For more details on each of these configuration options, simply read the comments embedded in /system/application/config/config.php. As you progress through the installation, there will be some opportunities to talk about configuration options, and I’ll bring up some points if it’s appropriate.

database.phpThe database.php file contains all the information required to connect to a database. Currently, CodeIgniter supports mysql, mysqli, postgres, odbc, and mssql connections. To connect to your database, simply enter valid information for your hostname, username, password, database name, and database driver.

Each of these is stored in the $db array under the “default” group, which means you could have numerous connection groups, each with it own unique name. For example, you could have one set of connection variables for your development environment and another for your production environment. As long as you’ve set the $active_group variable correctly, your application will stay connected.

$active_record = TRUE;$active_group = “default”; $db[‘default’][‘hostname’] = “your-host-name”;$db[‘default’][‘username’] = “your-db_username”;$db[‘default’][‘password’] = “your-db_password”;$db[‘default’][‘database’] = “your-db_name”;$db[‘default’][‘dbdriver’] = “mysql”;$db[‘default’][‘dbprefix’] = “”;$db[‘default’][‘pconnect’] = TRUE;$db[‘default’][‘db_debug’] = TRUE;$db[‘default’][‘cache_on’] = FALSE;$db[‘default’][‘cachedir’] = “”;$db[‘default’][‘char_set’] = “utf8”;$db[‘default’][‘dbcollat’] = “utf8_general_ci”;



10

Other FilesThere are other important files in the config/ directory, namely, routes.php and autoload.php. You don’t need to know anything about routes.php right now, but you will want to autoload a few helpers and libraries before you get started.

You’ll want to autoload the database and session libraries, so that you don’t have to call those libraries every time you want to query the database or work with CodeIgniter sessions. On the helpers side, you’ll be using the URL, Form, and Text helpers constantly, so they might as well be loaded.

$autoload[‘libraries’] = array(‘database’,’session’);$autoload[‘helper’] = array(‘url’,’form’,’text’);

There is one more task to be done before leaving the autoload file. I am talking about autoloading models. In the days prior to CodeIgniter 1.6, you had to load a model manually every time you used it in your controller. Not any more — you can autoload them and use the model functions at any point.

Although you don’t have any models built yet, at various points in this application, you’ll be building models and then immediately autoloading them in the autoload.php file.

Getting Star tedNow that CodeIgniter is installed and configured, you’re ready to begin. Take a quick look at the requirements list before you get too deep:

Allow users to log in to a secure area.

Allow users to organize content into folders or categories.

Allow users to create pages.

Allow users to upload files and other media.

Allow users to publish flat HTML to a designated target.

You will translate these requirements into CodeIgniter terms. Ninety-nine percent of this application will be some kind of administrative dashboard that will be password-protected. The other one percent will be a combination of a login screen and whatever the system outputs to the target destination. Ironically, it is this very last part, the output HTML, that everyone will think of as the application, but it is really only exported data.

You need to build two sets of controllers for CodeIgniter. The first set of controllers, which you will call Welcome, contains a single view, the login screen. The second group contains multiple controllers, one for the main dashboard and the others for pages, uploads, categories/folders, and users.

This second set of controllers will be organized under a folder called admin/ within your controllers directory. There is more about this below in this Wrox Blox, but for now, just know that you can organize your files into convenient folders.

❑

❑

❑

❑

❑



11

You need one model for each database table. Since you need to track users, pages, categories/folders, and uploads, you need a model for each of those. For the time being, you also need database tables for each of these models. You will build those database tables as you go.

You will also have a few dozen views. Most of them will be for our administrative views, but a few will be used by our export feature, when you pour data from the models into those views to create flat HTML. There is more on this below.

Now that you have all of that roughed in, try creating the first controller.

The Login AreaThe first thing you’re going to build is the login area. This is where users will go when they want to log in to the microsite manager and start working with files, pages, and categories. All you want is a very simple page with a simple login form.

Our first step is to create the controller. Simply create a welcome.php file in /system/applications/controllers/ and put the following basic information in it:

<?php class Welcome extends Controller { function Welcome(){ parent::Controller(); session_start(); } }//end controller class ?>

Please note that when you create a controller, you have to follow a few basic rules. The name of the class is always capitalized, and it must match the name of the file. Therefore, you have class Welcome in the welcome.php file. Furthermore, you need a constructor of the same name inside your class. The example above is PHP 4.I. If you were working in PHP 5, your constructor would look as follows:

<?php class Welcome extends Controller { function __construct(){ parent::Controller(); session_start(); } }//end controller class ?>

Notice that in both examples, I’m initializing PHP Sessions with session_start(). You’ll see why I’m using PHP Sessions, as you continue working with the application. CodeIgniter comes with its own



1�

Sessions, but those are cookie-based and therefore accessible to the client. They can be encrypted, of course, but we can’t completely trust them.

Once you have your constructor in place, all you have to do is add some functions. You need functions for every single destination in the controller. In this case, you will need a destination for the home page, traditionally handled by an index() function.

Your index() function is very basic — it just needs to display a form. The form itself is not placed in the controller function, but is instead handled in a view, which you’ll get to shortly.

function index(){ $data[‘title’] = “Welcome to the MicroSite Manager”; $data[‘main’] = ‘login’; $this->load->vars($data); $this->load->view(‘template’);}

Notice that you are saving information in a $data array (like the variables title and main), and then loading that array with $this->load->vars($data). All you’re doing here is making the $data array available to a view called template.

The template array (which will be saved in the /system/application/views folder as the template.php file) is going to be a generic template that you can use throughout the administrative dashboard. The template will contain a hole in the center of it (a PHP doughnut, if you will) in which you can include whatever other template you want. In this case, whatever value is saved in $data[‘main’] will be used to call up the template that fills that hole.

In the case of our first very simple index() function of the Welcome controller, the login template will contain a very simple form.

Creating the Template ViewBefore building that form, let’s create the template.php file:

<!DOCTYPE html PUBLIC “-//W3C//DTD XHTML 1.0 Strict//EN” “http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd”><html xmlns=”http://www.w3.org/1999/xhtml” xml:lang=”en” lang=”en”><head> <meta http-equiv=”content-type” content=”text/html; charset=utf-8” /> <title><?php echo $title; ?></title><link href=”<?= base_url();?>includes/css/admin.css” rel=”stylesheet” type=”text/css” /><script type=”text/javascript”>//<![CDATA[base_url = ‘<?php echo base_url();?>’;//]]></script><script type=”text/javascript” src=”<?php echo base_url();?>includes/js/prototype.js”></script><script type=”text/javascript” src=”<?php echo base_url();?>includes/js/scriptaculous.js” ></script>



1�

<script type=”text/javascript” src=”<?php echo base_url();?>includes/js/customtools.js” ></script></head><body><div id=”wrapper”> <div id=”header”> <?php $this->load->view(‘nav’);?> </div> <div id=”main”> <?php $this->load->view($main);?> </div> <div id=”footer”> Copyright 2008 Your-Company-Here </div></div></body></html>

Remember to save this file in the /system/application/views/ folder!

This template.php file is very simple, but you need to look at a few things before you go any further. First, please notice that it refers to a series of CSS and JavaScript files that all live under an includes/ folder and various subdirectories under that. CodeIgniter doesn’t come with a designated storage place for all the images, CSS files, JavaScript files, and other goodies that you need to build a web application. The best thing to do with these assets is to create a folder off the root (at the same level as the system/ folder) and store everything in there, out of the way.

All of the files you will need, by the way, are included in the Zip archive. This includes all the files referred to under the top-level includes/ folder.

The other thing you should notice is the sections marked $this->load->view(). They are reprinted in the following example:

<div id=”wrapper”> <div id=”header”> <?php $this->load->view(‘nav’);?> </div>

<div id=”main”> <?php $this->load->view($main);?> </div> <div id=”footer”> Copyright 2008 Your-Company-Here </div></div>

You can nest your views using the $this->load->view() command, as long as you feed it the name of a view in your application. Sometimes you manually set the name of a view (as you did with nav), and at other times, you can dynamically load a view with a PHP variable. Notice that you’re doing just that by feeding in the variable $main in the second instance.



14

Why $main? Wasn’t the variable called $data[’main’] in the controller? Yes, but once $data is loaded into the view, you access the values by using the keys of that array. This makes it pretty handy when you’re trying to remember what to access. It also makes it possible to pass all manner of data arrays into a view without any trouble at all.

In our case, the $main stands for “main content.” You could use another semantically valid name, like $content or $fill_in_the_donut_hole, but you get the idea. You now have a template you can use for any non-logged-in view you may need.

Creating the Login FormTurn your attention to the login form. Create a file called login.php in the /system/application/views/ folder and put the following code in it:

<h2>Please login to Access the Dashboard</h2> <?phpecho form_open(“welcome/index”);echo form_label(“username”,”u”);$udata = array(‘name’=>’username’,’id’=>’u’,’size’=>15);echo form_input($udata) . “</p>”; echo form_label(“password”,”p”);$pdata = array(‘name’=>’password’,’id’=>’p’,’size’=>15);echo form_password($pdata) . “</p>”; echo form_submit(‘submit’,’login’);echo form_close();?>

You’ll notice that I’m not using the standard HTML form markup here. Instead, I’m using CodeIgniter’s built-in Form helper. This helper contains various shorthand functions that do a lot of heavy lifting for you.

To open a form, use form_open() and pass in the URI to which the form posts. This is equivalent to the action attribute of a form. In your case, you want this simple form to post to welcome/index, which means you will need to modify your controller function a bit.

Notice that you then use form_input() and form_password() to create a text field followed by a password field. Also, notice that each of these has a short array containing necessary values (like the field name, DOM ID, and size) that gets passed to that field. Also notice the use of form_label(), a handy shortcut for your labels (which are good to have on your forms from an accessibility perspective).

Finally, you create a submit button with form_submit() and close the form with form_close(). Although you may now be wondering why you would go to all this trouble, after only a short while, you’ll wonder how you got along without this helper.



15

Reworking the index() FunctionAt this point, you have a login form that posts back to welcome/index, which means that your index() function must be rewritten to handle incoming POST data. If there aren’t any POST data, then you just show the login form. If there are POST data, you will need to take the values from the form, encrypt the password using some simple method, and then check to see whether there are any users in the database that match the values from the form. The encrypting and checking can be done inside the model to keep things simple.

Here’s a complete version of that new index() controller:

function index(){ $this->load->library(‘encrypt’); if ($this->input->post(‘username’)){ $u = $this->input->post(‘username’); $pw = $this->input->post(‘password’); $row = $this->MAdmins->verifyUser($u,$pw); if (count($row)){ $_SESSION[‘userid’] = $row[‘id’]; redirect(‘admin/dashboard’,’refresh’); }else{ redirect(‘welcome/index’,’refresh’); } }else{ $data[‘title’] = “Welcome to the MicroSite Manager”; $data[‘main’] = ‘login’; $this->load->vars($data); $this->load->view(‘template’); }}

The first thing you do now is load the encrypt library. This library is only used during login, so there is no need to autoload it. Once loaded, it will be used by the model you’re going to create to communicate with the database table that will store administrative users.

The second thing you do is use $this->input->post() to check to see whether there is a value in a field called username. If there is a value, then you grab the username and password values and hand this information off to the MAdmins model (which you haven’t built yet) and, specifically, the verifyUser() function of that model.

What you need to receive is an array of data. If you do get back an array, you can populate a PHP session variable called userid, and then redirect the user to the admin/dashboard controller (you’ll be building that shortly, as well). If you don’t get back a data array, you simply redirect the user to the login form so that they can try to log in again.

So here’s what you need to do before you’re done with the login area:

1. Create the MAdmins model.

�. Create the verifyUser() function inside that model.

�. Autoload the MAdmins model for future ease of use.



16

Creating the MAdmins ModelThe MAdmins model doesn’t need to be incredibly complex, at least not at first. All models follow the same set of rules:

1. They must have a name that doesn’t conflict with a controller.

�. The name of the class is usually capitalized and matches the file name.

�. They live in the /system/application/models/ directory.

Here is a basic, bare-bones model for MAdmins, stored in madmins.php:

<?php class MAdmins extends Model{ function MAdmins(){ parent::Model();}}//end class?>

I tend to call my models MSomething because the M stands for “model.” You may choose whatever naming convention works for you.

While you’re at it, you need to create the database table that goes with this model. If this were Ruby on Rails or another MVC framework, you would need to name your model after your table, but with CodeIgniter there is no such restriction. Create a table called ms_admins with the following schema:

CREATE TABLE ‘ms_admins’ ( ‘id’ int(11) NOT NULL auto_increment, ‘username’ varchar(16) NOT NULL default ‘’, ‘email’ varchar(255) NOT NULL default ‘’, ‘status’ enum(‘active’,’inactive’) NOT NULL default ‘active’, ‘password’ varchar(128) NOT NULL default ‘’, PRIMARY KEY (‘id’), UNIQUE KEY ‘username’ (‘username’,’email’)) ENGINE=MyISAM DEFAULT CHARSET=utf8;

If you’re used to creating database tables in MySQL, then nothing about this should surprise you. The table’s fields allow you to store a username, e-mail, status, and password, and has an auto-incremented key field called ID.



17

Creating the verifyUser() FunctionNow that you have the basic MAdmins model in place, you need to create the verifyUser() function. This function will receive two arguments, a username and a password. It needs to encrypt the password before running the query (as you’re only going to save encrypted passwords in the system). It then returns an array of data (whether empty or not) to the calling controller:

function verifyUser($u,$pw){ $this->db->select(‘id’); $this->db->where(‘username’,$u); $this->db->where(‘password’, md5($pw)); $this->db->where(‘status’, ‘active’); $this->db->limit(1); $Q = $this->db->get(‘ms_admins’); if ($Q->num_rows() > 0){ $row = $Q->row_array(); return $row; }else{ return array(); }}

Notice that you’re not exactly using standard SQL queries here to extract the data you want. Although CodeIgniter allows you to use SQL queries, most experienced CodeIgniter developers use the built-in Active Record class and its helper functions.

For example, $this->db->select() accepts a list of comma-separated fields, which gets placed in the SELECT part of the query. $this->db->where() accepts two arguments (a field name and a value) that get put into the WHERE part of the query. You are allowed to add as many calls to $this->db->where() as you want, as they are concatenated with AND [you can change this behavior by using $this->db->or_where()].

You can limit how many records are retrieved by using $this->db->limit(), telling it to run a query with $this->db->get(), and passing in a table name. Then, all you have to do is check whether you get anything back using num_rows(). Finally, return the row with the row_array() command. If you don’t get anything, you return an empty array.

If you recall, the controller index() function that is calling verifyUser() is expecting a row containing an ID, so that it can set a PHP Session value. It will accept an empty array, but that will cause the controller to redirect back to the login page.

Autoloading the MAdmins ModelTo autoload your new model, simply open /system/application/config/autoload.php in your favorite text editor, and modify the following line:

$autoload[‘model’] = array(‘MAdmins’);

From now on, you can access the model and its functions without manually loading it.



1�

A Small Note about Creating Your First UserYou’ll notice that you’re only storing encrypted passwords in the database table. Later, you’ll be asked to log in before you can see the admin dashboard, which you won’t be able to do because there is no user in the system!

To get around that little problem, generate your first user by hand, using phpMyAdmin or some other database admin tool. To generate a proper password, use PHP to echo a string wrapped with md5(), then store that string in your database.

For example,

<?php echo md5(‘password’);?>

This should generate an md5 hash of the string password, which, once stored in the database, will allow you to log in with that password.

Creating the Admin DashboardNow that the login area is fully created, you have been introduced to controllers, models, and views, and can easily create the rest of the application. The rest of the application will involve building out the administrative dashboard, with separate controllers for categories, pages, files, and users. (Remember, you need to manage those as well!)

To keep things organized, you’re going to create a folder called admin/ inside the /system/application/controllers/ folder, and you’ll store all your controllers in there. You will need to build the following controllers:

dashboard — This will be the “home area” for your administrative area and will include all publication functions.

pages — To manage pages.

categories — To manage folders or categories in the site.

uploads — To manage uploaded media files.

admins — To manage admin users.

Along the way, you’ll create models (and in one case, you’ll expand what you’ve done with the MAdmins model) and views to support what you need. Because of time and space constraints, I don’t go into extraordinary detail on each part of the application, but you will have enough information that you can easily duplicate the finished application. You’ll also have access to all the code in order to create your own microsite manager.

Please note that there is no way I can take you through every nook and cranny of this application in the short space allowed. I will give you a detailed view of a few areas and then gloss over the other areas where repeating won’t help comprehension. Rest assured that once you’ve built one set of models, views, and controllers in an administrative dashboard, it’s very easy to repeat the process whenever you need more screens.

❑

❑

❑

❑

❑



1�

Creating the Dashboard ControllerThe Dashboard controller needs three very simple functions: index(), build_site(), and logout(). The index() function contains all the code you need to display the home page of the admin dashboard. The logout() function allows users to log out. Finally, the build_site() function does the complicated bit of pulling all the data out of the database and making a static site from it. I leave that discussion for below in this Wrox Blox.

Here’s what the top of our Dashboard controller looks like (remember, it is stored in the /system/application/controllers/admin folder):

<?php class Dashboard extends Controller { function Dashboard(){ parent::Controller(); session_start(); if ($_SESSION[‘userid’] < 1){ redirect(‘welcome/index’,’refresh’); } } }//end class

The controller starts typically enough, with the right naming conventions, and includes a very short check to make sure that the Session variable called userid has been set. If it has a value less than 1, then the user is redirected to the Welcome controller, and specifically to the login form. You’re going to add this little bit of code to every single controller in the admin/ folder to keep out any unauthorized users.

Once that little bit of business is done, you can build the index() function:

function index(){ $data[‘title’] = “Dashboard Home”; $data[‘main’] = ‘admin_home’; $data[‘tinymce’] = ‘’; $this->load->vars($data); $this->load->view(‘dashboard’);}

You’re doing essentially the same thing you did before, on the login screen, except for two tiny variants:

You’re setting a blank value for tinymce (this is a WYSIWYG editor — you’ll talk about that when you build the pages controller).

You’re loading a dashboard view instead of the template view.

❑

❑



�0

The dashboard view is very simple and looks like this:

<!DOCTYPE html PUBLIC “-//W3C//DTD XHTML 1.0 Strict//EN” “http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd”><html xmlns=”http://www.w3.org/1999/xhtml” xml:lang=”en” lang=”en”><head> <meta http-equiv=”content-type” content=”text/html; charset=utf-8” /> <title><?php echo $title; ?></title><link href=”<?= base_url();?>includes/css/admin.css” rel=”stylesheet” type=”text/css” /><script type=”text/javascript”>//<![CDATA[base_url = ‘<?= base_url();?>’;//]]></script><script type=”text/javascript” src=”<?php echo base_url();?>includes/js/prototype.js”></script><script type=”text/javascript” src=”<?php echo base_url();?>includes/js/scriptaculous.js” ></script><script type=”text/javascript” src=”<?php echo base_url();?>includes/js/customtools.js” ></script> <?php echo $tinymce;?> </head><body><div id=”wrapper”> <div id=”header”> <?php $this->load->view(‘admin_header’);?> </div> <div id=”main”> <?php $this->load->view($main);?> </div> <div id=”footer”> <?php $this->load->view(‘admin_footer’);?> </div></div></body></html>

This dashboard template, in turn, loads an admin_header, an admin_footer, and whatever value has been loaded into $data[’main’] from the controller (in this case, admin_home).

Here is the admin_header view:

<div id=’globalnav’><ul><li><?php echo anchor(“admin/dashboard/index”,”home”);?></li><li><?php echo anchor(“admin/categories/”,”categories”);?></li><li><?php echo anchor(“admin/pages/”, “pages”);?></li><li><?php echo anchor(“admin/uploads/”, “files”);?></li>



�1

<li><?php echo anchor(“admin/admins/”, “users”);?></li><li><?php echo anchor(“admin/dashboard/logout/”, “logout”);?></li></ul></div>

Essentially, this is the main navigation that will go across the top of the admin dashboard. Once you’ve built all the necessary controllers and views, all of this will start working like a charm. For now, take a look at the use of the anchor() shortcut function. This function is part of the URL helper. It builds links for you and accepts two arguments, the link destination and the link text.

What’s so great about the anchor() function? It automatically adds the base URL to any internal links so you don’t have to keep track of it. This one little benefit will keep you coming back to the anchor() tag over and over again.

Here’s the admin_footer view:

Copyright © <?php echo date(“Y”); ?> Your Company Name

This one line of HTML and PHP will put a copyright notice on the bottom of each page.

Finally, here’s the admin_home view:

<ul><li><b><?php echo anchor(“admin/categories/”,”Manage Categories”);?>.</b></li><li><b><?php echo anchor(“admin/pages/”,”Manage Pages”);?>.</b></li><li><b><?php echo anchor(“admin/uploads/”,”Manage Files”);?>.</b></li><li><b><?php echo anchor(“admin/admins/”,”Manage Users”);?>.</b></li> <li><b><?php echo anchor(“admin/dashboard/logout/”,”Logout”);?>.</b></li></ul><?php echo form_open(‘admin/dashboard/build_site’); echo form_submit(‘submit’, ‘build site now!’); echo form_close();?>

It is basically the same list of links seen in the main navigation, but with a form added to the end. The form is very basic, consisting of a single button that says, “build site now!” The form posts to the build_site() function of the Dashboard controller.

Before you move on to the other controllers, finish the Dashboard controller. You still need the logout() and build_site() functions. Here’s the logout() function, which basically unsets the PHP Session variable userid and redirects the user to the login screen:

function logout(){ unset($_SESSION[‘userid’]); redirect(‘welcome/index’,’refresh’); }



��

For right now, stub out the build_site() function by having it say, “Ready to go!” You will fill in all the necessary code after you’ve built out the rest of the controllers, models, and views that you need:

function build_site(){ echo ‘Ready to go!’;}

Now that you’ve got the dashboard figured out, create the other controllers you need, starting with the Admin area first.

Building the Admin AreaThe admin area already has a model (MAdmins), so all you have to do is create a controller that will refer to it, add any other functions you may need, and then build your views.

Creating the Admins ControllerGenerally speaking, you need just four main functions within any given admin-type controller to make things work smoothly:

An index() function allows users to see data within the database table at a glance.

A create() function allows users to create new data in the table.

An edit() function allows users to edit existing data in a table.

A delete() function allows users to remove (or deactivate) data in a table.

All of our administrative controllers will follow this basic pattern. Following is the Admins controller, with each section above inserted into the code. The first part is the header, which should look extremely familiar to you by now:

<?phpclass Admins extends Controller { function Admins(){ parent::Controller(); session_start(); if ($_SESSION[‘userid’] < 1){ redirect(‘welcome/index’,’refresh’); } }

The index() function loads the admin_admins_home view, and will require the creation of a model function called getAllUsers(). As you can guess, this function will retrieve all users from the database:

function index(){ $data[‘title’] = “Manage Users”; $data[‘main’] = ‘admin_admins_home’; $data[‘admins’] = $this->MAdmins->getAllUsers(); $data[‘tinymce’] = ‘’; $this->load->vars($data); $this->load->view(‘dashboard’); }

❑

❑

❑

❑



��

The create() function is very simple. You want to create a dual-purpose function here, similar to your login screen. If there are POST data, run a function called addUser() and redirect the user to the index() function. If not, show the admin_admins_create view.

function create(){ $this->load->library(‘encrypt’); if ($this->input->post(‘username’)){ $this->MAdmins->addUser(); redirect(‘admin/admins/index’,’refresh’); }else{ $data[‘title’] = “Create User”; $data[‘main’] = ‘admin_admins_create’; $data[‘tinymce’] = ‘’; $this->load->vars($data); $this->load->view(‘dashboard’); } }

Similarly, the edit() function also looks for POST data. If it finds any, it runs the updateUser() function and redirects the user to the index() function. If it doesn’t, it loads the admin_admins_edit view. Notice that it also runs the getUser() model function, which you’ll use to populate the form fields.

function edit($id=0){ $this->load->library(‘encrypt’); if ($this->input->post(‘username’)){ $this->MAdmins->updateUser(); redirect(‘admin/admins/index’,’refresh’); }else{ $data[‘title’] = “Edit User”; $data[‘main’] = ‘admin_admins_edit’; $data[‘admin’] = $this->MAdmins->getUser($id); $data[‘tinymce’] = ‘’; $this->load->vars($data); $this->load->view(‘dashboard’); } }

Finally, there’s the delete() function, which will pass in a user ID via a link and run the deleteUser() model function:

function delete($id){ $this->MAdmins->deleteUser($id); redirect(‘admin/admins/index’,’refresh’); }}?>

Expanding the MAdmins ModelYou now have to add various functions to the MAdmins model: getAllUsers(), getUser(), addUser(), updateUser(), and deleteUser(). It’s probably a good idea to work on them now, before you start doing anything with the views, which will be simple enough.



�4

The easiest function to understand is getUser(). All you have to do is feed the function an ID, and it will return all the data associated with the record:

function getUser($id){ $data = array(); $this->db->where(‘id’,$id); $this->db->limit(1); $Q = $this->db->get(‘ms_admins’); if ($Q->num_rows() > 0){ $data = $Q->row_array(); } $Q->free_result(); return $data; }

The getAllUsers() function is similarly easy to understand. It returns all rows in the designated table (in this case, ms_admins).

function getAllUsers(){ $data = array(); $Q = $this->db->get(‘ms_admins’); if ($Q->num_rows() > 0){ foreach ($Q->result_array() as $row){ $data[] = $row; } } $Q->free_result(); return $data; }

The addUser() function accepts an incoming array of POST data, and then uses $this->db->insert() to place those data in the right table:

function addUser(){ $data = array(‘username’ => $_POST[‘username’], ‘email’ => $_POST[‘email’], ‘status’ => $_POST[‘status’], ‘password’ => md5($_POST[‘password’]) ); $this->db->insert(‘ms_admins’,$data);}

The updateUser() function also accepts an incoming array of POST data, and then updates the table using $this->db->update(). Notice that tucked away inside the POST data is some kind of ID field. You should make sure to put that inside the view to keep things working properly.

function updateUser(){ $data = array(‘username’ => $_POST[‘username’], ‘email’ => $_POST[‘email’], ‘status’ => $_POST[‘status’],



�5

‘password’ => md5($_POST[‘password’]) ); $this->db->where(‘id’,$_POST[‘id’]); $this->db->update(‘ms_admins’,$data);}

The deleteUser() function accepts an ID, and then sets the status of that record to inactive. I’m not a big believer in actually deleting items from the database, which is why I’ve opted for a deactivation instead of deletion. Because of that, you’re using $this->db->update() instead of $this->db->delete().

function deleteUser($id){ $data = array(‘status’ => ‘inactive’); $this->db->where(‘id’, $id); $this->db->update(‘ms_admins’, $data);}

Creating the ViewsNow that the controller and model functions are in place, all you need to build are the views. You need three views: a Main Index view, a Create form, and an Edit form. Once you have all three in place, you can tie them all together with the rest of the application to make things work correctly.

The admin_admins_home view is just a simple table that displays all the available records from the database table. Remember that the controller calls the model function getAllUsers(), and that function returns an array and saves it in $data[‘admins’]. Therefore, you will need to loop through $admins in the view:

<h1><?php echo $title;?></h1><p><?php echo anchor(“admin/admins/create”, “Create new user”);?> if (count($admins)){echo “<table border=’1’ cellspacing=’0’ cellpadding=’3’ width=’400’>\n”;echo “<tr valign=’top’>\n”;echo “<th>ID</th>\n<th>Username</th><th>Status</th><th>Actions</th>\n”;echo “</tr>\n”;foreach ($admins as $key => $list){ echo “<tr valign=’top’>\n”; echo “<td>”.$list[‘id’].”</td>\n”; echo “<td>”.$list[‘username’].”</td>\n”; echo “<td align=’center’>”.$list[‘status’].”</td>\n”; echo “<td align=’center’>”; echo anchor(‘admin/admins/edit/’.$list[‘id’],’edit’); echo “ | “; echo anchor(‘admin/admins/delete/’.$list[‘id’],’delete’); echo “</td>\n”; echo “</tr>\n”; } echo “</table>”;}?>



�6

Notice that you can easily create a new user with the link along the top, and edit or delete any existing record once they load up in the table. When you’re done, your user area will look a little like the illustration in Figure 4.

Figure 4: User home page.

The admin_admins_create view is just a simple form. It should allow the user to enter a username, password, and other information.

<h1><?php echo $title;?></h1> <?phpecho form_open(‘admin/admins/create’);echo form_label(“username”,”u”);$data = array(‘name’=>’username’,’id’=>’uname’,’size’=>25);echo form_input($data) .”</p>”; echo form_label(“email”,”email”);$data = array(‘name’=>’email’,’id’=>’email’,’size’=>50);echo form_input($data) .”</p>”; echo form_label(“password”,”pw”);$data = array(‘name’=>’password’,’id’=>’pw’,’size’=>25);echo form_password($data) .”</p>”; echo form_label(“status”,”status”);$options = array(‘active’ => ‘active’, ‘inactive’ => ‘inactive’);echo form_dropdown(‘status’,$options) .”</p>”; echo form_submit(‘submit’,’create admin’);echo form_close();?>

Notice that you’ve introduced another element here called form_dropdown(), a handy shortcut that allows the easy creation of dropdowns. All you have to do is create an array of options, and then pass it in to form_dropdown() to create your values. This array can be manually set, or it can be generated from a query.

For all intents and purposes, the admin_admins_edit view contains the same exact form, except you’re loading values into each field. Remember that the controller function edit() has run the getUser()



�7

model function to pull in the corresponding record for a given user ID. Those data were stored in $data[‘admin’], and therefore can be accessed via $admin:

<h1><?php echo $title;?></h1> <?phpecho form_open(‘admin/admins/create’);echo form_label(“username”,”u”);$data = array(‘name’=>’username’,’id’=>’uname’,’size’=>25, ‘value’=>$admin[‘username’]);echo form_input($data) .”</p>”; echo form_label(“email”,”email”);$data = array(‘name’=>’email’,’id’=>’email’,’size’=>50, ‘value’=>$admin[‘email’]);echo form_input($data) .”</p>”; echo form_label(“password”,”pw”);$data = array(‘name’=>’password’,’id’=>’pw’,’size’=>25, ‘value’=>’’);echo form_password($data) .”</p>”; echo form_label(“status”,”status”);$options = array(‘active’ => ‘active’, ‘inactive’ => ‘inactive’);echo form_dropdown(‘status’,$options,$admin[‘status’]) .”</p>”; echo form_submit(‘submit’,’update admin’);echo form_close();?>

Creating the Rest of the Admin FunctionsNow that the Admins controller is in place, it’s time to create models, views, and controllers for categories, pages, and uploads. Since each of these controllers follows the exact same pattern you’ve seen with the Admins area, I won’t spend a lot of time on each section. I especially won’t spend a lot of time on the views, as you can inspect them easily enough when you look at the companion code for this Wrox Blox.

CategoriesFirst, let’s talk about categories. Categories, for the purposes of this application, are defined as generic containers (like folders) that can hold pages. When you create the site building function for the Dashboard controller, you’ll organize all the output into their proper categories, using the category names as folder names.

The categories area has a very simple controller. Looking at it, you will notice that almost the same thing is going on in this controller as went on in the Admins controller. The only difference is that you’re calling different views.



��

Here’s the Categories controller:

<?phpclass Categories extends Controller { function Categories(){ parent::Controller(); session_start(); if ($_SESSION[‘userid’] < 1){ redirect(‘welcome/index’,’refresh’); } } function index(){ $data[‘title’] = “Manage Categories”; $data[‘main’] = ‘admin_cat_home’; $data[‘categories’] = $this->MCats->getAllCategories(); $data[‘tinymce’] = ‘’; $this->load->vars($data); $this->load->view(‘dashboard’); } function create(){ if ($this->input->post(‘name’)){ $this->MCats->addCategory(); redirect(‘admin/categories/index’,’refresh’); }else{ $data[‘title’] = “Create Category”; $data[‘main’] = ‘admin_cat_create’; $data[‘categories’] = $this->MCats->getTopCategories(); $data[‘tinymce’] = ‘’; $this->load->vars($data); $this->load->view(‘dashboard’); } } function edit($id=0){ if ($this->input->post(‘name’)){ $this->MCats->updateCategory(); redirect(‘admin/categories/index’,’refresh’); }else{ $data[‘title’] = “Edit Category”; $data[‘main’] = ‘admin_cat_edit’; $data[‘category’] = $this->MCats->getCategory($id); $data[‘categories’] = $this->MCats->getTopCategories(); $data[‘tinymce’] = ‘’; $this->load->vars($data); $this->load->view(‘dashboard’); } } function delete($id){



��

$this->MCats->deleteCategory($id); redirect(‘admin/categories/index’,’refresh’); }}//end class?>

As you can see, the same patterns emerge. The controller calls model functions, sets variables, and loads those variables into a particular view. In your case, you’re building administrative panels, so the view won’t vary much. They’ll either be a listing of available records, or a form that allows you to create new records or edit existing records.

Here’s the model for categories, called MCats:

<?phpclass MCats extends Model{ function MCats(){ parent::Model(); } function getCategory($id){ $data = array(); $options = array(‘id’ => $id); $Q = $this->db->getwhere(‘ms_categories’,$options,1); if ($Q->num_rows() > 0){ $data = $Q->row_array(); } $Q->free_result(); return $data; } function getAllCategories(){ $data = array(); $Q = $this->db->get(‘ms_categories’); if ($Q->num_rows() > 0){ foreach ($Q->result_array() as $row){ $data[] = $row; } } $Q->free_result(); return $data; } function addCategory(){ $data = array( ‘name’ => str_replace(“ “, “_”,$_POST[‘name’]), ‘shortdesc’ => $_POST[‘shortdesc’], ‘longdesc’ => $_POST[‘longdesc’], ‘status’ => $_POST[‘status’], ‘sortorder’ => $_POST[‘sortorder’],



�0

‘parentid’ => $_POST[‘parentid’] ); $this->db->insert(‘ms_categories’, $data); } function updateCategory(){ $data = array( ‘name’ => str_replace(“ “, “_”,$_POST[‘name’]), ‘shortdesc’ => $_POST[‘shortdesc’], ‘longdesc’ => $_POST[‘longdesc’], ‘status’ => $_POST[‘status’], ‘sortorder’ => $_POST[‘sortorder’], ‘parentid’ => $_POST[‘parentid’] ); $this->db->where(‘id’, $_POST[‘id’]); $this->db->update(‘ms_categories’, $data); } function deleteCategory($id){ $data = array(‘status’ => ‘inactive’); $this->db->where(‘id’, $id); $this->db->update(‘ms_categories’, $data); }} function getTopCategories(){ $data[0] = ‘root’; $this->db->where(‘parentid’,0); $Q = $this->db->get(‘ms_categories’); if ($Q->num_rows() > 0){ foreach ($Q->result_array() as $row){ $data[$row[‘id’]] = $row[‘name’]; } } $Q->free_result(); return $data; } ?>

By the way, here’s the schema for the ms_categories table:

CREATE TABLE ‘ms_categories’ ( ‘id’ int(11) NOT NULL auto_increment, ‘name’ varchar(255) NOT NULL default ‘’, ‘shortdesc’ varchar(255) NOT NULL default ‘’, ‘longdesc’ text NOT NULL, ‘status’ enum(‘active’,’inactive’) NOT NULL default ‘active’, ‘sortorder’ int(3) NOT NULL default ‘0’, ‘parentid’ int(11) NOT NULL default ‘0’, PRIMARY KEY (‘id’)) ENGINE=MyISAM DEFAULT CHARSET=utf8 ;


�1

One last note before you move on: Don’t forget to add MCats to the autoloaded model list in the /system/application/config/autoload.php file!

PagesThe Pages controller and model (MPages) are essentially identical to Categories, except that the schema related to pages has a few more fields. I won’t go into all the detail of the controller and model (as you can investigate yourself using the code), but here’s the schema for ms_pages:

CREATE TABLE ‘ms_pages’ ( ‘id’ int(11) NOT NULL auto_increment, ‘category_id’ int(11) NOT NULL default ‘0’, ‘name’ varchar(255) NOT NULL default ‘’, ‘localname’ varchar(255) NOT NULL default ‘’, ‘title’ varchar(255) NOT NULL, ‘keywords’ varchar(255) NOT NULL default ‘’, ‘description’ varchar(255) NOT NULL default ‘’, ‘path’ varchar(255) NOT NULL default ‘’, ‘content’ text character set utf8 collate utf8_unicode_ci NOT NULL, ‘sidebar’ text character set utf8 collate utf8_unicode_ci NOT NULL, ‘shownav’ enum(‘yes’,’no’) NOT NULL default ‘yes’, ‘pageorder’ int(3) NOT NULL default ‘0’, ‘status’ enum(‘active’,’inactive’) NOT NULL default ‘active’, PRIMARY KEY (‘id’)) ENGINE=MyISAM DEFAULT CHARSET=uft8;

Notice that there are fields for the page name, title, keywords, description, and content, which you would expect, but also other fields. For example, the localname field allows you to put in an alternative name that shows up in navigation. I’ve used it to good effect when I had to create translations or show navigation links in other languages. The shownav field tells the application whether to show this page in the navigation at all. The sidebar field can hold HTML content for a sidebar area.

One other thing you should note about the Pages area is that you will want to install a WYSIWYG editor. In the code, you’ll see that I’ve installed TinyMCE, then placed the configuration options for it inside my Pages controller so that I can pass it all into my views.

class Pages extends Controller { function Pages(){ parent::Controller(); session_start(); if ($_SESSION[‘userid’] < 1){ redirect(‘welcome/index’,’refresh’); } $this->tinyMce = ‘  <script type=”text/javascript” src=”’ . base_url().’includes/tiny_mce/tiny_mce.js”></script> <script type=”text/javascript”> tinyMCE.init({


��

// General options mode : “textareas”, theme : “advanced”, plugins : //snipped here, as configuration goes on for pages and pages! ‘; } }//end class

Because you pass this value into the appropriate functions [in this case, the create() and edit() functions of the Pages controller], you end up with WYSIWYG editors where you want them (i.e., the text areas devoted to content and sidebar data).

function create(){ if ($this->input->post(‘name’)){ $this->MPages->addPage(); redirect(‘admin/pages/index’,’refresh’); }else{ $data[‘title’] = “Create Page”; $data[‘main’] = ‘admin_pages_create’; $data[‘tinymce’] = $this->tinyMce; $cats = $this->MCats->getCategoriesNav(); $data[‘categories’] = $this->_flatten_cats($cats); $this->load->vars($data); $this->load->view(‘dashboard’); } } function edit($id=0){ if ($this->input->post(‘name’)){ $this->MPages->updatePage(); redirect(‘admin/pages/index’,’refresh’); }else{ $data[‘title’] = “Edit Page”; $data[‘main’] = ‘admin_pages_edit’; $data[‘page’] = $this->MPages->getPage($id); $data[‘tinymce’] = $this->tinyMce; $cats = $this->MCats->getCategoriesNav(); $data[‘categories’] = $this->_flatten_cats($cats); $this->load->vars($data); $this->load->view(‘dashboard’); }}

Did you notice the use of a special function called $this->_flatten_cats()? In CodeIgniter, any controller function that begins with an underscore (_) is automatically treated as a private function. A user can’t enter the name of that function as a destination.

In this special case, the _flatten_cats() function accepts a list of categories, and then flattens it into a more human-readable format. Specifically, it makes a list of categories look like a directory tree. This will be used in any category dropdowns on page create/edit forms, making it that much easier to associate a page with a category.



��

function _flatten_cats($cats){ $F = array(); $F[0] = ‘/’; foreach ($cats as $root => $list){ foreach ($list as $key => $cat){ $F[$key] = “/”.$cat[‘name’]; if (isset($cat[‘children’])){ foreach ($cat[‘children’] as $k => $v){ $F[$k] = “/”.$cat[‘name’] .”/”.$v; } } } } return $F;}

UploadsThe uploads area is very similar to the pages and categories. Before I talk about where this controller differs (e.g., how you upload a file with CodeIgniter), I want to show you the schema for the ms_files database table:

CREATE TABLE ‘ms_files’ ( ‘id’ int(11) NOT NULL auto_increment, ‘name’ varchar(255) NOT NULL default ‘’, ‘keywords’ varchar(255) NOT NULL default ‘’, ‘path’ varchar(255) NOT NULL default ‘’, ‘status’ enum(‘active’,’inactive’) NOT NULL default ‘active’, PRIMARY KEY (‘id’)) ENGINE=MyISAM DEFAULT CHARSET=utf8;

The goal is to be able to upload individual files and store some information about them in the ms_files table, but then to store the files in a specific area of the site. At this point, I’ve set aside the /includes/uploads/ folder as my repository for any uploaded files. In the next section, I talk about the site-building function and all the things you’ll have to do to make the publication process work.

CodeIgniter makes file uploads work seamlessly. Let’s walk through the file creation process, starting with the view, then working our way through to the controller, and then the model.

Our file creation view is called admin_uploads_create, and it’s just a simple form:

<h1><?php echo $title;?></h1> <?phpecho form_open_multipart(‘admin/uploads/create’); echo form_label(“file name”,”fname”);$data = array(‘name’=>’name’,’id’=>’fname’,’size’=>25);echo form_input($data) .”</p>”; echo form_label(“keywords”,”short”);$data = array(‘name’=>’keywords’,’id’=>’short’,’size’=>40);



�4

echo form_input($data) .”</p>”; echo form_label(“upload file”,”upload”);$data = array(‘name’=>’myfile’,’id’=>’upload’);echo form_upload($data) .”</p>”;

echo form_label(“status”,”status”);$options = array(‘active’ => ‘active’, ‘inactive’ => ‘inactive’);echo form_dropdown(‘status’,$options) .”</p>”;

echo form_submit(‘submit’,’upload file’);echo form_close();

?>

It’s important to note that you’re using form_open_multipart() to open the form; that way, the form is ready to accept file uploads. Also notice that you’ve used the form_upload() shortcut to create the file upload widget in the form.

Here’s the specific controller function that deals with file uploads:

function create(){ if ($this->input->post(‘name’)){ $this->MUploads->addFile(); redirect(‘admin/uploads/index’,’refresh’); }else{ $data[‘title’] = “Upoad File”; $data[‘main’] = ‘admin_uploads_create’; $data[‘tinymce’] = ‘’; $this->load->vars($data); $this->load->view(‘dashboard’); } }

So far, nothing surprising, right? Take a look at that addFile() function in the MUploads model. The first thing you do is prepare the $data array, as you normally would:

function addFile(){ $data = array( ‘name’ => $_POST[‘name’], ‘keywords’ => $_POST[‘keywords’], ‘status’ => $_POST[‘status’] );

Next, check for a value in $_FILES, which is the superglobal associated with file uploads. If there is a value associated with $_FILES[’myfile’], then set the CodeIgniter $config parameters. These parameters allow you to control the path, allowed file types, maximum upload size, and more.



�5

if ($_FILES[‘myfile’]){ $config[‘upload_path’] = ‘./includes/uploads/’; $config[‘allowed_types’] = ‘gif|jpg|png|pdf|doc|xls|zip|swf|txt|html’; $config[‘max_size’] = ‘0’; $config[‘remove_spaces’] = true; $config[‘overwrite’] = true; $config[‘max_width’] = ‘0’; $config[‘max_height’] = ‘0’;

Once you have the $config array squared away, load the upload directory using the $config array as the second argument:

$this->load->library(‘upload’, $config);

Run the do_upload() command, checking for errors as you go (and exiting immediately if you run into problems):

if(!$this->upload->do_upload(‘myfile’)){ echo $this->upload->display_errors(); exit(); } $U = $this->upload->data();

If the upload is successful, you will end up with a file_name key in your upload array. If you find that, just make sure your $data[‘path’] value is set to that, as that will be written to your database upon insertion. You’re done!

if ($U[‘file_name’]){ $data[‘path’] = $U[‘file_name’]; } } $this->db->insert(‘ms_files’, $data);}

Make sure that your target directory (in this case, /includes/uploads) is writable.

Setting up the Site BuilderNow that all the admin portions have been built and users are able to log in and create categories, pages, and media assets on the site, it’s time to think about the site builder.

To make a site builder work, you will need a few tools:

1. Some way to extract all the information from the database in an orderly fashion (e.g., grouped by category).

�. A set of rules that will transform page records into flat HTML files.



�6

�. Some kind of script that will transfer uploaded files into the completed site.

4. A set of templates that will apply look and feel to any HTML pages.

5. A folder that will hold all the other assets you’ll need for the completed site, like CSS files, JavaScript files, images, and more. (These assets are different from the previous assets you set up, because these will be used on your destination microsite, not the manager.)

6. A URL helper extension that will allow you to add some custom helper functions.

First, set up a folder called stage_assets/ in the includes/ folder. You can place any assets for the microsite in there. For example, in many projects, there is an images/ folder and some CSS files. All of those go into the stage_assets/ folder.

Next, create a series of template views (I’ve called mine public_home, public_inner, etc.) that you store in the /system/application/views/ folder. These views represent the look and feel of your completed site design. Again, these have nothing to do with your manager views. They should include places for keywords, title, content, and sidebar (all the fields you designated in your ms_pages table).

Next, you can create a file called MY_url_helper.php in the /system/application/helpers/ folder. By creating a file with this name, CodeIgniter will know that you are seeking to extend the default URL helper. What you want to do is create various functions that will help you keep track of paths. You’ll use these functions in the site-building function.

Here’s what you can put in your helper extension file:

<?phpfunction prepend_url(){return “/”;} function cms_prep(){return “/var/www/html/whatever/”;} function target_prep(){return “/var/www/html/target/”;} function target_url(){ return “http://www.example.com/target-whatever/”;}?>

Finally, let’s consider the build_site() function in the Dashboard controller. It’s a bit complicated, but once you go through it step-by-step, you’ll see that it’s very straightforward.



�7

The first step is to load the File helper, which will give you some shortcuts for physically creating and working with files. At the same time, you want to grab all categories, files, and pages that are ready for publication with specially prepared model functions:

function build_site(){ $this->load->helper(‘file’); $cats = $this->MCats->getPublishCats(); $pages = $this->MPages->getPublishPages(); $indexpages = $this->MPages->getIndexPages(); $files = $this->MUploads->getAllFiles(); $localnav = array();

Next, you make sure that you have items in the $pages and $cats arrays and start processing the stack. The first step is to delete everything in the target area (don’t worry, this will more than likely be a staging server!) to make sure that anything you deactivate in the manager doesn’t keep showing up over on the target area. Next, rsync everything from your stage_assets/ folder to the target area:

if (count($pages) && count($cats)){ unset($cats[0]); //DELETE TARGET AREA shell_exec(‘rm -rf ‘. target_prep().’*’); //COPY OVER ASSETS shell_exec(‘rsync -avz ‘.cms_prep().’includes/stage_assets/ ‘ . target_prep());

Next you loop through all the categories, creating a folder for each one. If you have a category called contact_us, this process will create a folder with that name. At the same time, create a folder named files to hold the uploaded files:

//NOW YOU MAY CREATE NEW CATS! foreach ($cats as $id => $path){ @mkdir(staging_prep().$path); } @mkdir(target_prep().”files”);

Next, loop through all the pages, making sure that you add .html to any page name that doesn’t already have it on the end:

foreach ($pages as $page){ if (!preg_match(“/\.html$/”,$page[‘path’])){ $page[‘path’] .= “.html”; }

Figure out which template you need to use (either public_home or public_inner). The project, with which I was involved, had radically different designs for these two types of pages, and indeed, with your project, you might have very different designs for each category (e.g., a different look for contact pages vs. products pages).



��

Once you know what view to use, load the view by passing in $page and setting the third parameter to TRUE. This will keep CodeIgniter from echoing results to the page, and instead, saving everything that results into the $final variable.

if ($page[‘category_id’] == 0 && $page[‘path’] == “index.html”){ $TEMPLATE = “public_home”; }else{ $TEMPLATE = “public_inner”; } $final = $this->load->view($TEMPLATE,$page,true);

Once you know what $final looks like, you need to figure out where it belongs in the site hierarchy. Essentially, any page with a category_id of 0 belongs in the site root; otherwise, it really belongs in some other folder.

//2. determine path! if ($page[‘category_id’] == 0){ $finalpath = target_prep().$page[‘path’]; }else{ $finalpath = target_prep(). $cats[$page[‘category_id’]] . “/” . $page[‘path’]; }

Once you figure out where it goes, use the write_file() function to write the file to the right directory. The write_file() function comes to us by way of the File helper and simplifies the task of writing a file to the filesystem:

//3. write to staging folder if (!write_file($finalpath,$final)){ die(“can’t write to $finalpath!”); } }

Once you’re done looping through all the pages, loop through the files array and copy them over to the files/ folder you created earlier. Finally, redirect the user to the Admin dashboard after setting a quick Session variable to indicate that files are now ready for viewing:

//don’t forget uploaded files! if (count($files)){ foreach ($files as $F){ $file = $F[‘path’]; @copy(cms_prep().”includes/uploads/$file”, target_prep().”files/$file”); } } $_SESSION[‘target_ready’] = true; redirect(“admin/dashboard”,’refresh’); }else{ redirect(“admin/dashboard”,’refresh’); }}



��

Now it’s time to make a quick change on the admin_home view. Simply add a check to see whether the Session variable called target_ready is set to TRUE, and, if so, show a link to the target site:

if (isset($_SESSION[‘target_ready’]) && $_SESSION[‘target_ready’] == true){ echo ‘<a href=’.target_url().’ target=”_blank”>see site</a>’;}

ConclusionOnce the process runs, you’ll see several folders and files copied into your target directory. In Figure 5, my target directory is the microsite_stage directory off the server root. There’s a folder for every category, an images folder, a CSS file, and various other HTML files present.

Figure 5: Results of the process.

By now, what you have is a compact, portable microsite manager that exports all of your database data (and associated files) as static pages and folders in a designated spot. This designated area can be a staging server with files that can later be transferred, via FTP or rsync, to a live server.

This arrangement gives your marketing team a lot of flexibility. They can create content for their microsite, design views, upload files, and organize content into virtual folders; then, when they’re ready, they can build a site and see what everything looks like. If they need to fix something, they can do that quickly and easily, and then build their site again.


40

About Thomas MyerThomas Myer is a technical book author, consultant, and web developer. In 2001, he founded Triple Dog Dare Media in Austin, Texas. Triple Dog Dare Media focuses its attention on helping companies create CodeIgniter-based applications like content management, portals, and eCommerce systems.

Thomas Myer is the author of No Nonsense XML Web Development with PHP (Sitepoint, 2004) and Lead Generation on the Web (O’Reilly, 2007). His new book, Professional CodeIgniter from WROX, hits the bookstores July 2008. He has also authored dozens of technical and business articles for IBM DeveloperWorks, Amazon Web Services, AOL, Darwin Magazine, and others.



Creating a Microsite Manager with CodeIgniter®Published byWiley Publishing, Inc.10475 Crosspoint BoulevardIndianapolis, IN 46256www.wiley.com

Copyright © 2008 by Wiley Publishing, Inc., Indianapolis, Indiana

ISBN: 978-0-470-41337-1

No part of this publication may be reproduced, stored in a retrieval system or transmitted in any form or by any means, electronic, mechanical, photocopying, recording, scanning or otherwise, except as permitted under Sections 107 or 108 of the 1976 United States Copyright Act, without either the prior written permission of the Publisher, or authorization through payment of the appropriate per-copy fee to the Copyright Clearance Center, 222 Rosewood Drive, Danvers, MA 01923, (978) 750-8400, fax (978) 646-8600. Requests to the Publisher for permission should be addressed to the Legal Department, Wiley Publishing, Inc., 10475 Crosspoint Blvd., Indianapolis, IN 46256, (317) 572-3447, fax (317) 572-4355, or online at http://www.wiley.com/go/permissions.

Limit of Liability/Disclaimer of Warranty: The publisher and the author make no representations or warranties with respect to the accuracy or completeness of the contents of this work and specifically disclaim all warranties, including without limitation warranties of fitness for a particular purpose. No warranty may be created or extended by sales or promotional materials. The advice and strategies contained herein may not be suitable for every situation. This work is sold with the understanding that the publisher is not engaged in rendering legal, accounting, or other professional services. If professional assistance is required, the services of a competent professional person should be sought. Neither the publisher nor the author shall be liable for damages arising herefrom. The fact that an organization or Website is referred to in this work as a citation and/or a potential source of further information does not mean that the author or the publisher endorses the information the organization or Website may provide or recommendations it may make. Further, readers should be aware that Internet Websites listed in this work may have changed or disappeared between when this work was written and when it is read.

For general information on our other products and services please contact our Customer Care Department within the United States at (800) 762-2974, outside the United States at (317) 572-3993 or fax (317) 572-4002.

Trademarks: Wiley, the Wiley logo, Wrox, the Wrox logo, Programmer to Programmer, and related trade dress are trademarks or registered trademarks of John Wiley & Sons, Inc. and/or its affiliates, in the United States and other countries, and may not be used without written permission. All other trademarks are the property of their respective owners. Wiley Publishing, Inc., is not associated with any product or vendor mentioned in this Wrox Blox.

This PDF should be viewed with Acrobat Reader 6.0 and later, Acrobat Professional 6.0 and later, or Adobe Digital Editions.

Usage Rights for Wiley Wrox Blox. Any Wiley Wrox Blox you purchase from this site will come with certain restrictions that allow Wiley to protect the copyrights of its products. After you purchase and download this title, you:

• Are entitled to three downloads • Are entitled to make a backup copy of the file for your own use • Are entitled to print the Wrox Blox for your own use• Are entitled to make annotations and comments in the Wrox Blox file for your own use• May not lend, sell or give the Wrox Blox to another user • May not place the Wrox Blox file on a network or any file sharing service for use by anyone other than yourself or

allow anyone other than yourself to access it• May not copy the Wrox Blox file other than as allowed above• May not copy, redistribute, or modify any portion of the Wrox Blox contents in any way without prior permission

from Wiley

If you have any questions about these restrictions, you may contact Customer Care at (877) 762-2974 (8 a.m.–5 p.m. EST, Monday–Friday). If you have any issues related to Technical Support, please contact us at 800-762-2974 (United States only) or 317-572-3994 (International) 8 a.m.–8 p.m. EST, Monday–Friday).

Acquisitions EditorJenny WatsonDevelopment EditorChristopher J. RiveraTechnical EditorEd FinklerProduction EditorDebra Banninger

Copy EditorCate CaffreyEditorial ManagerMary Beth Wakefield Production ManagerTim Tate

Vice President and Executive Group PublisherRichard SwadleyVice President and Executive PublisherJoseph B. WikertProofreaderNancy Carrasco


Ready for more?Build onto the knowledge that you just gained from this Wrox Blox.

Visit us at www.wrox.com

Professional CodeIgnitertBy THOMAS MYER

978-0-470-28245-8 • Paper • 304 pages

C odeIgniter is lighting up the PHP developmentspace, and this book shows programmers how to

join the action

• CodeIgniter is an MVC (model-view-controller)framework for PHP that is generating a lot of buzz,because it allows developers to save time by reusingexisting code instead of writing it from scratch; althoughsimilar to Ruby on Rails, CodeIgniter is popular as a wayto build Rails-like code without learning a newprogramming language

• Walks readers through the steps of building severaltypes of applications with CodeIgniter, including blogs,forums, and content management; also providesproblem-solving techniques and tips on everyday issuesnot typically covered in reference manuals forprogrammers

• Covers a range of topics helpful to developers of allstripes, from novice programmers to code gurus; topicsinclude an overview of agile methodologies andapproaches, the MVC approach, helpers and libraries,model and schema for products, and Ajax andScriptaculous.

Professional CodeIgniter is available now!


creating a microsite manager with codeigniter

Documents

microsite manager

madmins model

php modelview

whats modelview

wrox blox0

dashboard controller

publishing control

wrox blox terms of service