Configuration is generally stored in either PHP or INI files, and loaded during
the application bootstrap. CakePHP comes with one configuration file by default,
but if required you can add additional configuration files and load them in
your application’s bootstrap code. Cake\Core\Configure is used
for global configuration, and classes like Cache provide config()
methods to make configuration simple and transparent.

If your application has many configuration options it can be helpful to split
configuration into multiple files. After creating each of the files in your
config/ directory you can load them in bootstrap.php:

You can also use additional configuration files to provide environment specific
overrides. Each file loaded after app.php can redefine previously declared
values allowing you to customize configuration for development or staging
environments.

When changing the namespace in your configuration, you will also
need to update your composer.json file to use this namespace
as well. Additionally, create a new autoloader by running
phpcomposer.phardumpautoload.

App.baseUrl

Un-comment this definition if you don’t plan to use Apache’s
mod_rewrite with CakePHP. Don’t forget to remove your .htaccess
files too.

App.base

The base directory the app resides in. If false this
will be auto detected. If not false, ensure your string starts
with a / and does NOT end with a /. E.g., /basedir is a valid
App.base. Otherwise, the AuthComponent will not work properly.

App.encoding

Define what encoding your application uses. This encoding
is used to generate the charset in the layout, and encode entities.
It should match the encoding values specified for your database.

App.webroot

The webroot directory.

App.wwwRoot

The file path to webroot.

App.fullBaseUrl

The fully qualified domain name (including protocol) to your application’s
root. This is used when generating absolute URLs. By default this value
is generated using the $_SERVER environment. However, you should define it
manually to optimize performance or if you are concerned about people
manipulating the Host header.
In a CLI context (from shells) the fullBaseUrl cannot be read from $_SERVER,
as there is no webserver involved. You do need to specify it yourself if
you do need to generate URLs from a shell (e.g. when sending emails).

App.imageBaseUrl

Web path to the public images directory under webroot. If you are using
a CDN you should set this value to the CDN’s location.

App.cssBaseUrl

Web path to the public css directory under webroot. If you are using
a CDN you should set this value to the CDN’s location.

App.jsBaseUrl

Web path to the public js directory under webroot. If you are using
a CDN you should set this value to the CDN’s location.

Additional class paths are setup through the autoloaders your application uses.
When using composer to generate your autoloader, you could do the following,
to provide fallback paths for controllers in your application:

The above would setup paths for both the App and App\Controller
namespace. The first key will be searched, and if that path does not contain the
class/file the second key will be searched. You can also map a single namespace
to multiple directories with the following:

Since plugins, view templates and locales are not classes, they cannot have an
autoloader configured. CakePHP provides three Configure variables to setup additional
paths for these resources. In your config/app.php you can set these variables:

return[// More configuration'App'=>['paths'=>['plugins'=>[ROOT.DS.'plugins'.DS,'/path/to/other/plugins/'],'templates'=>[APP.'Template'.DS,APP.'Template2'.DS],'locales'=>[APP.'Locale'.DS]]]];

Paths should end with a directory separator, or they will not work properly.

Many modern cloud providers, like Heroku, let you define environment
variables for configuration data. You can configure your CakePHP through
environment variables in the 12factor app style.
Environment variables allow your application to require less state making your
application easier to manage when it is deployed across a number of
environments.

As you can see in your app.php, the env() function is used to read
configuration from the environment, and build the application configuration.
CakePHP uses DSN strings for databases, logs, email transports and cache
configurations allowing you to easily vary these libraries in each environment.

For local development, CakePHP leverages dotenv to allow easy local development using
environment variables. You will see a config/.env.default in your
application. By copying this file into config/.env and customizing the
values you can configure your application.

You should avoid committing the config/.env file to your repository and
instead use the config/.env.default as a template with placeholder values so
everyone on your team knows what environment variables are in use and what
should go in each one.

Once your environment variables have been set, you can use env() to read
data from the environment:

$debug=env('APP_DEBUG',false);

The second value passed to the env function is the default value. This value
will be used if no environment variable exists for the given key.

Changed in version 3.5.0: dotenv library support was added to the application skeleton.

CakePHP’s 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
won’t end up breaking the MVC structure CakePHP provides.

You can use Configure::write('debug',$bool) to switch between debug and
production modes on the fly. This is especially handy for JSON interactions
where debugging information can cause parsing problems.

CakePHP comes with two built-in configuration file engines.
Cake\Core\Configure\Engine\PhpConfig is able to read PHP config
files, in the same format that Configure has historically read.
Cake\Core\Configure\Engine\IniConfig is able to read ini config
files. See the PHP documentation for more
information on the specifics of ini files. To use a core config engine, you’ll
need to attach it to Configure using Configure::config():

You can have multiple engines attached to Configure, each reading different
kinds or sources of configuration files. You can interact with attached engines
using a few other methods on Configure. To check which engine aliases are
attached you can use Configure::configured():

// Get the array of aliases for attached engines.Configure::configured();// Check if a specific engine is attachedConfigure::configured('default');

Loaded configuration files merge their data with the existing runtime
configuration in Configure. This allows you to overwrite and add new values into
the existing runtime configuration. By setting $merge to true, values
will not ever overwrite the existing configuration.

Dumps all or some of the data in Configure into a file or storage system
supported by a config engine. The serialization format is decided by the config
engine attached as $config. For example, if the ‘default’ engine is
a Cake\Core\Configure\Engine\PhpConfig, the generated file will be
a PHP configuration file loadable by the
Cake\Core\Configure\Engine\PhpConfig

Given that the ‘default’ engine is an instance of PhpConfig.
Save all data in Configure to the file my_config.php:

Configure::dump('my_config','default');

Save only the error handling configuration:

Configure::dump('error','default',['Error','Exception']);

Configure::dump() can be used to either modify or overwrite
configuration files that are readable with Configure::load()

You can also store runtime configuration values for use in a future request.
Since configure only remembers values for the current request, you will
need to store any modified configuration information if you want to
use it in subsequent requests:

// Store the current configuration in the 'user_1234' key in the 'default' cache.Configure::store('user_1234','default');

Stored configuration data is persisted in the named cache configuration. See the
Caching documentation for more information on caching.

When restoring configuration information it’s important to restore it with
the same key, and cache configuration as was used to store it. Restored
information is merged on top of the existing runtime configuration.

CakePHP provides the ability to load configuration files from a number of
different sources, and features a pluggable system for creating your own
configuration engines.
The built in configuration engines are:

If you have any additional configuration needs, you should add them to your
application’s config/bootstrap.php file. This file is included before each
request, and CLI command.

This file is ideal for a number of common bootstrapping tasks:

Defining convenience functions.

Declaring constants.

Defining cache configuration.

Defining logging configuration.

Loading custom inflections.

Loading configuration files.

It might be tempting to place formatting functions there in order to use them in
your controllers. As you’ll see in the Controllers and Views
sections there are better ways you add custom logic to your application.

In addition to the config/bootstrap.php file which should be used to
configure low-level concerns of your application, you can also use the
Application::bootstrap() hook method to load/initialize plugins, and attach
global event listeners:

// in src/Application.phpnamespaceApp;useCake\Core\Plugin;useCake\Http\BaseApplication;classApplicationextendsBaseApplication{publicfunctionbootstrap(){// Call the parent to `require_once` config/bootstrap.phpparent::bootstrap();Plugin::load('MyPlugin',['bootstrap'=>true,'routes'=>true]);}}

Loading plugins/events in Application::bootstrap() makes
Controller Integration Testing easier as events and routes will be re-processed on
each test method.

While utilizing generic table classes - also called auto-tables - when quickly
creating new applications and baking models is useful, generic table class can
make debugging more difficult in some scenarios.

You can check if any query was emitted from a generic table class via DebugKit
via the SQL panel in DebugKit. If you’re still having trouble diagnosing an
issue that could be caused by auto-tables, you can throw an exception when
CakePHP implicitly uses a generic Cake\ORM\Table instead of your concrete
class like so: