Welcome to The Cookbook

Patty-cake, patty-cake...

Welcome to web development heaven.

If you’re reading the preface to a technical manual, you probably have too much time on your hands. We’re not celebrities, and since the material is what you're after, skip this superfluous section and dive right in.

This material is written for developers at all levels of ability; anyone who enjoys creating robust, maintainable applications quickly and effectively.

In order to understand the content of this document, you're going to need to have a working knowledge of PHP. Some basic familiarity with object-oriented programming will also help, though I suppose the introductory sections of this document could act as a primer of sorts.

There will be content that addresses technology which is technically beyond the scope of this document and not specific to the CakePHP framework. Some of these technologies include:

• AJAX
• JavaScript
• SQL
• Web Server Administration

CakePHP is a free, open-source, rapid development framework for PHP. It’s a foundational structure for programmers to create web applications. Our primary goal is to enable you to work in a structured and rapid manner–without loss of flexibility.

CakePHP takes the monotony out of web development. We provide you with all the tools you need to get started coding what you really need to get done: the logic specific to your application. Instead of reinventing the wheel every time you sit down to a new project, check out a copy of CakePHP and get started with the real guts of your application.

CakePHP has an active developer team and community, bringing great value to the project. In addition to keeping you from wheel-reinventing, using CakePHP means your application’s core is well tested and is being constantly improved.

Here’s a quick list of features you’ll enjoy when using CakePHP:

• Active, friendly community
• Flexible licensing
• Compatible with versions 4 and 5 of PHP
• Integrated CRUD for database interaction
• Application scaffolding
• Code generation
• MVC architecture
• Request dispatcher with clean, custom URLs and routes
• Built-in validation
• Fast and flexible templating (PHP syntax, with helpers)
• View Helpers for AJAX, JavaScript, HTML Forms and more
• Email, Cookie, Security, Session, and Request Handling Components
• Flexible ACL
• Data Sanitization
• Flexible Caching
• Localization
• Works from any web site directory, with little to no Apache configuration involved

The Cookbook

http://book.cakephp.org

You've started in the right place. This manual should probably be the first place you go to get answers. As with many other open source projects, we get new folks regularly. Try your best to answer your questions on your own first. Answers may come slower, but will remain longer–and you'll also be lightening our support load. Both the manual and the API have an online component.

The API

http://api.cakephp.org/1.2

Straight to the point and straight from the core developers, the CakePHP API (Application Programming Interface) is the most comprehensive documentation around for all the nitty gritty details of the internal workings of the framework. Its a straight forward code reference, so bring your propeller hat.

The IRC channel

#cakephp @ irc.freenode.net

If you’re stumped, give us a holler in the CakePHP IRC channel. Someone from the development team is usually there, especially during the daylight hours for North and South America users. We’d love to hear from you, whether you need some help, want to find users in your area, or would like to donate your brand new sports car.

The Bakery

http://bakery.cakephp.org

The CakePHP Bakery is a clearing house for all things CakePHP. Check it out for tutorials, case studies, and code examples. Once you’re acquainted with CakePHP, log on and share your knowledge with the community and gain instant fame and fortune.

CakeForge

http://www.cakeforge.org

CakeForge is another developer resource you can use to host your CakePHP projects to share with others. If you’re looking for (or want to share) a killer component or a praiseworthy plugin, check out CakeForge.

The Official CakePHP website

http://www.cakephp.org

The Official CakePHP website is always a great place to visit. It features links to oft-used developer tools, screencasts, donation opportunities, and downloads.

The Google Group

http://groups.google.com/group/cake-php

CakePHP also has a very active Google Group. It can be a great resource for finding archived answers, frequently asked questions, and getting answers to immediate problems.

CakePHP follows the MVC software design pattern. Programming using MVC separates your application into three main parts:

1. The Model represents the application data
2. The View renders a presentation of model data
3. The Controller handles and routes requests made by the client

Figure 1: A Basic MVC Request

Figure 1 shows an example of a bare-bones MVC request in CakePHP. To illustrate, assume a client named "Ricardo" just clicked on the “Buy A Custom Cake Now!” link on your application’s home page.

• Ricardo clicks the link pointing to http://www.example.com/cakes/buy, and his browser makes a request to your web server.
• The dispatcher checks the request URL (/cakes/buy), and hands the request to the correct controller.
• The controller performs application specific logic. For example, it may check to see if Ricardo has logged in.
• The controller also uses models to gain access to the application’s data. Models usually represent database tables, but they could also represent LDAP entries, RSS feeds, or files on the system. In this example, the controller uses a model to fetch Ricardo’s last purchases from the database.
• Once the controller has worked its magic on the data, it hands it to a view. The view takes this data and gets it ready for presentation to the client. Views in CakePHP are usually in HTML format, but a view could just as easily be a PDF, XML document, or JSON object depending on your needs.
• Once the view has used the data from the controller to build a fully rendered view, the content of that view is returned to Ricardo’s browser.

Almost every request to your application will follow this basic pattern. We'll add some details later on which are specific to CakePHP, so keep this in mind as we proceed.

Why use MVC? Because it is a tried and true software design pattern that turns an application into a maintainable, modular, rapidly developed package. Crafting application tasks into separate models, views, and controllers makes your application very light on its feet. New features are easily added, and new faces on old features are a snap. The modular and separate design also allows developers and designers to work simultaneously, including the ability to rapidly prototype. Separation also allows developers to make changes in one part of the application without affecting others.

If you've never built an application this way, it takes some getting used to, but we're confident that once you've built your first application using CakePHP, you won't want to do it any other way.

The Start of Becoming a Smart Cookie

CakePHP features Controller, Model, and View classes, but it also features some additional classes and objects that make development in MVC a little quicker and more enjoyable. Components, Behaviors, and Helpers are classes that provide extensibility and reusability to quickly add functionality to the base MVC classes in your applications. Right now we’ll stay at a higher level, so look for the details on how to use these tools later on.

A Component is a class that aids in controller logic. If you have some logic you want to share between controllers (or applications), a component is usually a good fit. As an example, the core EmailComponent class makes creating and sending emails a snap. Rather than writing a controller method in a single controller that performs this logic, you can package the logic so it can be shared.

Controllers are also fitted with callbacks. These callbacks are available for your use, just in case you need to insert some logic between CakePHP’s core operations. Callbacks available include:

• beforeFilter(), executed before any controller action logic
• beforeRender(), executed after controller logic, but before the view is rendered
• afterFilter(), executed after all controller logic, including the view render. There may be no difference between afterRender() and afterFilter() unless you’ve manually made a call to render() in your controller action and have included some logic after that call.

A Helper is a class that aids in view logic. Much like a component used among controllers, helpers allow presentational logic to be accessed and shared between views. One of the core helpers, AjaxHelper, makes Ajax requests within views much easier.

Most applications have pieces of view code that are used repeatedly. CakePHP facilitates view code reuse with layouts and elements. By default, every view rendered by a controller is placed inside a layout. Elements are used when small snippets of content need to be reused in multiple views.

Similarly, Behaviors work as ways to add common functionality between models. For example, if you store user data in a tree structure, you can specify your User model as behaving like a tree, and gain free functionality for removing, adding, and shifting nodes in your underlying tree structure.

Models also are supported by another class called a DataSource. DataSources are an abstraction that enable models to manipulate different types of data consistently. While the main source of data in a CakePHP application is often a database, you might write additional DataSources that allow your models to represent RSS feeds, CSV files, LDAP entries, or iCal events. DataSources allow you to associate records from different sources: rather than being limited to SQL joins, DataSources allow you to tell your LDAP model that it is associated to many iCal events.

Just like controllers, models are featured with callbacks as well:

• beforeFind()
• afterFind()
• beforeValidate()
• beforeSave()
• afterSave()
• beforeDelete()
• afterDelete()

The names of these methods should be descriptive enough to let you know what they do. Be sure to get the details in the models chapter.

Both controllers, helpers and models have a parent class you can use to define application-wide changes. AppController (located at /app/app_controller.php), AppHelper (located at /app/app_helper.php) and AppModel (located at /app/app_model.php) are great places to put methods you want to share between all controllers, helpers or models.

Although they aren’t a class or file, routes play a role in requests made to CakePHP. Route definitions tell CakePHP how to map URLs to controller actions. The default behavior assumes that the URL “/controller/action/var1/var2” maps to Controller::action($var1, $var2), but you can use routes to customize URLs and how they are interpreted by your application.

Some features in an application merit packaging as a whole. A plugin is a package of models, controllers and views that accomplish a specific purpose that can span multiple applications. A user management system or a simplified blog might be good fits for CakePHP plugins.

Let’s take a look at what CakePHP looks like right out of the box. You know what CakePHP looks like from a basic MVC request standpoint, but you’ll need to know how its files are organized as well.

• app
• cake
• docs
• index.php
• vendors

When you download CakePHP, you will see four main folders. The app folder will be where you work your magic: it’s where your application’s files will be placed. The cake folder is where we’ve worked our magic. Make a personal commitment not to edit files in this folder. We can’t help you if you’ve modified the core. The docs folder is for the quintessential readme, changelog, and licensing information. Finally, the vendors folder is where you’ll place third-party PHP libraries you need to use with your CakePHP applications.

CakePHP’s app folder is where you will do most of your application development. Let’s look a little closer at the folders inside of app.

config

Holds the (few) configuration files CakePHP uses. Database connection details, bootstrapping, core configuration files and more should be stored here.

controllers

Contains your application’s controllers and their components.

locale

Stores string files for internationalization.

models

Contains your application’s models, behaviors, and datasources.

plugins

Contains plugin packages.

tmp

This is where CakePHP stores temporary data. The actual data it stores depends on how you have CakePHP configured, but this folder is usually used to store model descriptions, logs, and sometimes session information.

vendors

Any third-party classes or libraries should be placed here. Doing so makes them easy to access using the vendor() function. Keen observers will note that this seems redundant, as there is also a vendors folder at the top level of our directory structure. We'll get into the differences between the two when we discuss managing multiple applications and more complex system setups.

views

Presentational files are placed here: elements, error pages, helpers, layouts, and view files.

webroot

In a production setup, this folder should serve as the document root for your application. Folders here also serve as holding places for CSS stylesheets, images, and JavaScript files.

We’ve covered the basic ingredients in CakePHP, so let’s look at how each object works together to complete a basic request. Continuing with our original request example, let’s imagine that our friend Ricardo just clicked on the “Buy A Custom Cake Now!” link on a CakePHP application’s landing page.

Figure 2. Typical Cake Request.

Black = required element, Gray = optional element, Blue = callback

1. Ricardo clicks the link pointing to http://www.example.com/cakes/buy, and his browser makes a request to your web server.
2. The Router parses the URL in order to extract the parameters for this request: the controller, action, and any other arguments that will affect the business logic during this request.
3. Using routes, a request URL is mapped to a controller action (a method in a specific controller class). In this case, it’s the buy() method of the CakesController. The controller’s beforeFilter() callback is called before any controller action logic is executed.
4. The controller may use models to gain access to the application’s data. In this example, the controller uses a model to fetch Ricardo’s last purchases from the database. Any applicable model callbacks, behaviors, and DataSources may apply during this operation. While model usage is not required, all CakePHP controllers initially require at least one model.
5. After the model has retrieved the data, it is returned to the controller. Model callbacks may apply.
6. The controller may use components to further refine the data or perform other operations (session manipulation, authentication, or sending emails, for example).
7. Once the controller has used models and components to prepare the data sufficiently, that data is handed to the view using the controller’s set() method. Controller callbacks may be applied before the data is sent. The view logic is performed, which may include the use of elements and/or helpers. By default, the view is rendered inside of a layout.
8. Additional controller callbacks (like afterFilter) may be applied. The complete, rendered view code is sent to Ricardo’s browser.

We’re a big fan of convention over configuration. While it takes a bit of time to learn CakePHP’s conventions, you save time in the long run: by following convention, you get free functionality, and you free yourself from the maintenance nightmare of tracking config files. Convention also makes for a very uniform system development, allowing other developers to jump in and help more easily.

CakePHP’s conventions have been distilled out of years of web development experience and best practices. While we suggest you use these conventions while developing with CakePHP, we should mention that many of these tenets are easily overridden–something that is especially handy when working with legacy systems.

In general, filenames are underscored, while classnames are CamelCased. The class KissesAndHugsController can be found in the file kisses_and_hugs_controller.php, for example.

The name of the class a file holds may not necessarily be found in the filename, however. The class EmailComponent is found in a file named email.php, and the class HtmlHelper is found in a file named html.php.

Model classnames are singular and CamelCased. Person, BigPerson, and ReallyBigPerson are all examples of conventional model names.

Table names corresponding to CakePHP models are plural and underscored. The underlying tables for the above mentioned models would be people, big_people, and really_big_people, respectively.

Foreign keys in hasMany, belongsTo or hasOne relationships are recognized by default as the (singular) name of the related model followed by _id. So if a baker hasMany cakes, the cakes table will refer to the baker in the bakers table via a baker_id foreign key.

Join tables, used in hasAndBelongsToMany (HABTM) relationships between models should be named after the model tables they will join in alphabetical order (apples_zebras rather than zebras_apples).

All tables CakePHP models interact with (with the exception of join tables), require a singular primary key to uniquely identify each row. If you wish to model a table which does not have a single-field primary key, such as the rows of your posts_tags join table, CakePHP's convention is that a single-field primary key is added to the table.

Controller classnames are plural, CamelCased, and end in ‘Controller.’ PeopleController, BigPeopleController, and ReallyBigPeopleController are all examples of conventional controller names.

The first function you write for a controller might be the index() function. When a request specifies a controller but not an action, the default CakePHP behavior is to render the index() function of that controller. For example, a request to http://www.example.com/apples/ maps to a call on the index() function of the ApplesController, where as http://www.example.com/apples/view maps to a call on the view() function of the ApplesController.

You can also change the visibility of controller functions in CakePHP by prepending controller function names with underscores. If a controller function has been prepended with an underscore, the function will not be web-viewable through the dispatcher, but is available for internal use.

View template files are named after the controller functions they display, in an underscored form. The getReady() function of the PeopleController class will look for a view template in /app/views/people/get_ready.ctp.

The basic pattern is /app/views/controller/underscored_function_name.ctp.

By naming the pieces of your application using CakePHP conventions, you gain functionality without the hassle and maintenance tethers of configuration. Here’s a final example that ties the conventions

• Database table: ‘people’
• Model class: ‘Person’, found at /app/models/person.php
• Controller class: ‘PeopleController’, found at /app/controllers/people_controller.php
• View template, found at /app/views/people/index.ctp

Using these conventions, CakePHP knows that a request to http://example.com/people/ maps to a call on the index() function of the PeopleController, where the Person model is automatically available (and automatically tied to the ‘people’ table in the database), and renders to a file. None of these relationships have been configured by any means other than by creating classes and files that you’d need to create anyway.

Now that you’ve been introduced to CakePHP’s fundamentals, you might try a run through the CakePHP Blog Tutorial, an appendix at the end of this manual.

Now you’re cooking.

• HTTP Server. Apache with mod_rewrite is preferred, but by no means required.
• PHP 4.3.2 or greater. Yes, CakePHP works great on PHP 4 and 5.

Technically a database engine isn’t required, but we imagine that most applications will utilize one. CakePHP supports a variety of database storage engines:

• MySQL (4 or greater)
• PostgreSQL
• Firebird DB2
• Microsoft SQL Server
• Oracle
• SQLite
• ODBC
• ADOdb

There are two main ways to get a fresh copy of CakePHP. First, you can download an archive (zip/tar.gz/tar.bz2), or you can check out a code from our repository (SVN).

To get a fresh archive, visit our web site at http://www.cakephp.org. Follow the huge “Download Now!” link to paradise. CakePHP downloads are hosted at CakeForge, and you can also visit the project web site at http://cakeforge.org/projects/cakephp.

If you want to live on the edge, check out our nightly downloads at http://cakephp.org/downloads/index/nightly. CakePHP nightlies are stable, and include fixes between releases.

To grab a fresh copy from our SVN repository, connect to https://svn.cakephp.org/repo/branches/1.2.x.x .

CakePHP uses the /app/tmp directory for a number of different operations. Model descriptions, cached views, and session information are just a few examples.

As such, make sure the /app/tmp directory in your cake installation is writable by the web server user.

Installing CakePHP can be as simple as slapping it in your web server’s document root, or as complex and flexible as you wish. This section will cover the three main installation types for CakePHP: development, production, and advanced.

• Development: easy to get going, URLs for the application include the CakePHP installation directory name, and less secure.
• Production: Requires the ability to configure the web server’s document root, clean URLs, very secure.
• Advanced: With some configuration, allows you to place key CakePHP directories in different parts of the filesystem, possibly sharing a single CakePHP core library folder amongst many CakePHP applications.

Just place your cake install inside your web server’s document root. For example, assuming your web server’s document root is /var/www/html, a development setup would look like this on the filesystem:

• /var/www/html
  • /cake_1_2
    • /app
    • /cake
    • /docs
    • /index.php
    • /vendors

To see your CakePHP application, point your web browser to http://www.example.com/cake_1_2/

In order to utilize a production setup, you will need to have the rights to change the document root for your web server. Choosing the production setup means the whole domain acts as a single CakePHP application.

The production setup uses the following layout:

• /path_to_cake_install/
• /app
  • /webroot (this directory is set as the document root for the web server)
• /cake
• /docs
• /index.php
• /vendors

If this application was going to be hosted on Apache, the DocumentRoot directive for the domain would look something like:

DocumentRoot /path_to_cake_install/app/webroot

1. DocumentRoot /path_to_cake_install/app/webroot

To see your CakePHP application, point your web browser to http://www.example.com.

There may be some situations where you wish to place CakePHP's directories on different places on the filesystem. This may be due to a shared host restriction, or maybe you just want a few of your apps to share the same Cake libraries. This section describes how to spread your CakePHP directories across a filesystem.

First, realize that there are three main parts to a Cake application:

1. The core CakePHP libraries, in /cake.
2. Your application code, in /app.
3. The application’s webroot, usually in /app/webroot.

Each of these directories can be located anywhere on your file system, with the exception of the webroot, which needs to be accessible by your web server. You can even move the webroot folder out of the app folder as long as you tell Cake where you've put it.

To configure your Cake installation, you'll need to make some changes to /app/webroot/index.php. There are three constants that you'll need to edit: ROOT, APP_DIR, and CAKE_CORE_INCLUDE_PATH.

• ROOT should be set to the path of the directory that contains your app folder.
• APP_DIR should be set to the path of your app folder.
• CAKE_CORE_INCLUDE_PATH should be set to the path of your CakePHP libraries folder.

Let’s run through an example so you can see what an advanced installation might look like in practice. Imagine that I wanted to set up CakePHP to work as follows:

• The CakePHP core libraries will be placed in /usr/lib/cake.
• My application’s webroot directory will be /var/www/mysite/.
• My application’s app directory will be stored in /home/me/mysite.

Given this type of setup, I would need to edit my webroot/index.php file (which will end up at /var/www/mysite/index.php, in this example) to look like the following:

// /app/webroot/index.php (partial, comments removed) 

if (!defined('ROOT')) {
    define('ROOT', DS.'home'.DS.'me');
}

if (!defined('APP_DIR')) {
    define ('APP_DIR', 'mysite');
}

if (!defined('CAKE_CORE_INCLUDE_PATH')) {
    define('CAKE_CORE_INCLUDE_PATH', DS.'usr'.DS.'lib'.DS.'cake');
}

1. // /app/webroot/index.php (partial, comments removed)
2. if (!defined('ROOT')) {
3. define('ROOT', DS.'home'.DS.'me');
4. }
5. if (!defined('APP_DIR')) {
6. define ('APP_DIR', 'mysite');
7. }
8. if (!defined('CAKE_CORE_INCLUDE_PATH')) {
9. define('CAKE_CORE_INCLUDE_PATH', DS.'usr'.DS.'lib'.DS.'cake');
10. }

It is recommended to use the DS constant rather than slashes to delimit file paths. This prevents any missing file errors you might get as a result of using the wrong delimiter, and it makes your code more portable.

It’s occasionally useful to be able to share MVC classes between applications on the same system. If you want the same controller in both applications, you can use CakePHP’s bootstrap.php to bring these additional classes into view.

In bootstrap.php, define some specially-named variables to make CakePHP aware of other places to look for MVC classes:

$viewPaths        = array();
$controllerPaths  = array();
$modelPaths       = array();
$helperPaths      = array();
$componentPaths   = array();
$behaviorPaths    = array();

1. $viewPaths = array();
2. $controllerPaths = array();
3. $modelPaths = array();
4. $helperPaths = array();
5. $componentPaths = array();
6. $behaviorPaths = array();

Each of these special variables can be set to an array of absolute filesystem paths where extra classes can be found when requested. Make sure that each path specified includes a trailing slash.

While CakePHP is built to work with mod_rewrite out of the box–and usually does–we've noticed that a few users struggle with getting everything to play nicely on their systems. Here are a few things you might try to get it running correctly:

• Make sure that an .htaccess override is allowed. In your httpd.conf, you should have a section that defines your Directory on the server. Make sure the AllowOverride is set to All for the correct DocumentRoot.
• Make sure you are editing the system httpd.conf rather than a user- or site-specific httpd.conf.
• Is CakePHP missing its needed .htaccess files? This sometimes happens during copying or moving because some operating systems treat files that start with '.' as hidden. Make sure your copy of CakePHP is from the downloads section of the site or our SVN repository, and has been unpacked correctly.
• Make sure you are loading up mod_rewrite correctly. You should see something like LoadModule rewrite_module libexec/httpd/mod_rewrite.so and AddModule mod_rewrite.c in your httpd.conf.
• If you are installing CakePHP into a user directory (http://example.com/~username), you'll need to modify the .htaccess file in the base directory of your CakePHP installation. Just add the line "RewriteBase /~myusername/".

Alright, let's see CakePHP in action. Depending on which setup you used, you should point your browser to http://example.com/ or http://example.com/cake_install/. At this point, you'll be presented with CakePHP's default home, and a message that tells you the status of your current database connection.

Congratulations! You are ready to create your first CakePHP application.

CakePHP expects database configuration details to be in a file at app/config/database.php. An example database configuration file can be found at app/config/database.php.default. A finished configuration should look something like this.

var $default = array('driver'      => 'mysql',
                     'persistent'  => false,
                     'host'        => 'localhost',
                     'login'       => 'cakephpuser',
                     'password'    => 'c4k3roxx!',
                     'database'    => 'my_cakephp_project',
                     'prefix'      => '');

1. var $default = array('driver' => 'mysql',
2. 'persistent' => false,
3. 'host' => 'localhost',
4. 'login' => 'cakephpuser',
5. 'password' => 'c4k3roxx!',
6. 'database' => 'my_cakephp_project',
7. 'prefix' => '');

The $default connection array is used unless another connection is specified by the $useDbConfig property in a model. For example, if my application has an additional legacy database in addition to the default one, I could use it in my models by creating a new $legacy database connection array similar to the $default array, and by setting var $useDbConfig = ‘legacy’; in the appropriate models.

Fill out the key/value pairs in the configuration array to best suit your needs.

Note that the prefix setting is for tables, not models. For example, if you create a join table for your Apple and Flavor models, you name it prefix_apples_flavors (not prefix_apples_prefix_flavors), and set your prefix setting to ‘prefix_’.

At this point, you might want to take a look at the CakePHP Conventions, listed in an appendix to this manual. The correct naming for your tables (and the addition of some columns) can score you some free functionality and help you avoid configuration.

Application configuration in CakePHP is found in /app/config/core.php. This file is a collection of Configure class variable definitions and constant definitions that determine how your application behaves. Before we dive into those particular variables, you’ll need to be familiar with Configure, CakePHP’s configuration registry class.

Despite few things needing to be configured in CakePHP, it’s sometimes useful to have your own configuration rules for your application. In the past you may have defined custom configuration values by defining variable or constants in some files. Doing so forces you to include that configuration file every time you needed to use those values.

CakePHP’s new Configure class can be used to store and retrieve application or runtime specific values. Be careful, this class allows you to store anything in it, then use it in any other part of your code: a sure temptation to break the MVC pattern CakePHP was designed for. The main goal of Configure class is to keep centralized variables that can be shared between many objects. Remember to try to live by "convention over configuration" and you wont end up breaking the MVC structure we’ve set in place.

This class acts as a singleton and its methods can be called from anywhere within your application, in a static context.

<?php Configure::read('debug'); ?>

1. <?php Configure::read('debug'); ?>

write(string $key, mixed $value)

1. write(string $key, mixed $value)

Use write() to store data in the application’s configuration.

Configure::write('Company.name','Pizza, Inc.');
Configure::write('Company.slogan','Pizza for your body and soul');

1. Configure::write('Company.name','Pizza, Inc.');
2. Configure::write('Company.slogan','Pizza for your body and soul');

Note the usage of dot notation in the $key parameter. You can use this notation to organize your configuration into logical groups.

The above example could also be written in a single call:

Configure::write(
    'Company',array('name'=>'Pizza, Inc.','slogan'=>'Pizza for your body and soul')
);

1. Configure::write(
2. 'Company',array('name'=>'Pizza, Inc.','slogan'=>'Pizza for your body and soul')
3. );

You can use Configure::write(‘debug’, $int) to switch between debug and production modes on the fly. This is especially handy for AMF or SOAP interactions where debugging information can cause parsing problems.

read(string $key = 'debug')

1. read(string $key = 'debug')

Used to read configuration data from the application. Defaults to CakePHP’s important debug value. If a key is supplied, the data is returned. Using our examples from write() above, we can read that data back:

Configure::read('Company.name');    //yields: 'Pizza, Inc.'
Configure::read('Company.slogan');  //yields: 'Pizza for your body and soul'
 
Configure::read('Company');
 
//yields: 
array('name' => 'Pizza, Inc.', 'slogan' => 'Pizza for your body and soul');

1. Configure::read('Company.name'); //yields: 'Pizza, Inc.'
2. Configure::read('Company.slogan'); //yields: 'Pizza for your body and soul'
4. Configure::read('Company');
6. //yields:
7. array('name' => 'Pizza, Inc.', 'slogan' => 'Pizza for your body and soul');

delete(string $key)

1. delete(string $key)

Used to delete information from the application’s configuration.

Configure::delete('Company.name');

1. Configure::delete('Company.name');

load(string $path)

1. load(string $path)

Use this method to load configuration information from a specific file.

// /app/config/messages.php:
<?php
$config['Company']['name'] = 'Pizza, Inc.';
$config['Company']['slogan'] = 'Pizza for your body and soul';
$config['Company']['phone'] = '555-55-55';
?>
 
<?php
Configure::load('messages');
Configure::read('Company.name');
?>

1. // /app/config/messages.php:
2. <?php
3. $config['Company']['name'] = 'Pizza, Inc.';