I looked into it more than twice in the last year coming up with almost nothing. After many hours of investigating I just postponed it again for times unknown.
It should be said that debugging the session/cookie based stuff – here Authentication – is quite a difficult past. Many things play into it making it hard to reproduce the issue.

The cake documentation also doesn’t tell us, that for php sessions to work this long it is also required to raise the internal max_lifetime. I stumpled across this by accident. Always thought this would be taken care of by cake itself.
But after switching to database as session container I didn’t notice any improvements either. So the server side garbage collector maybe wasn’t responsible after all. At least not all alone.

So, to sum it up:
- Setting up timeouts was a waste of time
- Security level, as well (I just left it at `low`)
- Moving from php/cake to database didn’t work either – although it provides little more control
- Raising the php.ini settings for gc_maxlifetime didn’t work too well, either

I still get logged out after totally different lengths. Sometimes minutes, sometimes a few hours. It never lasts much longer.
Not only a deadly problem for a social network running with Cake.

I tried multiple times to add an encrypted cookie as `RememberMe` functionally (to quicklogin such a logged out user again). But I failed – as I later found out due to a PHP bug with srand/mt_srand and suhosin (details).
Thanks to miles’ post regarding this bug I took a step forward and decided to take action (a lot of users have been complaining about unexplainable logouts the past months anyway).

AutoLogin? A way out?

I finally – after putting up with it for many years – adjusted Miles’ great spadework with his AutoLogin component to work with my apps.

Basically, this component saves the user data to a cookie on login. As soon as the session gets lost again (for whatever reason!?) the component re-logins the user. It happens silently without bothering the user.

The code can be found here: github.com/dereuromark/cake-auto_login

I actually merged it into my Tools plugin. But for the sake of simplicity I left the forked rep from Miles intact and up-to-data.

Usage and Features

After successfully running it in a few cake2.x apps, I want to share the basic HOWTO.
The only required thing to do is adding the component globally in AppController:

public $components = array('Session', 'RequestHandler', 'AutoLogin', 'Auth', ...);

It is important to include it before any AuthComponent to avoid getting any “not logged in” error messages triggered by it.

You can use /Config/configs.php (or any other Configure place) to define its settings:

$config['AutoLogin'] = array(
	'controller' => 'account',
	'username' => 'login',
	'requirePrompt' => false
	... //see the component for details on other options
);

Please use the last one with caution. If `requirePrompt` is disabled you use AutoLogin for ALL logins. This requires users to always log out correctly in public places (especially in internet cafes this can be quite dangerous as others opening the site could hijack this logged in user even after several days). So make sure you use is only for sites where all users are properly informed and educated on this.

So for the default case you will need to add a checkbox into your login form:

if (Configure::read('AutoLogin.active')) {
	echo $this->Form->input('auto_login', array('type'=>'checkbox', 'label'=>__('Remember on this computer')));
}

That’s it.
You can easily test it using database sessions and truncating the session table after login.
It should log the user right back in as well as creating the new session table row. If everything is working right, the user shouldn’t even notice that he wasn’t logged in for a split second.

The if statement is optional. I use it to dynamically enable/disable the component based on the environment.
But if you use it, make sure you defined `active` as `true` in Configure.

Getting rid of the suhosin bug
As explained by Miles in the above links, most linux apache environments come with the suhosin patch which messes up srand by default. My localhost WAMP doesn’t. So there it worked right away. But to get it to work on the linux environment, all there is to do is:
In your `/etc/php5/apache2/php.ini` add this line at the bottom:

suhosin.srand.ignore = Off

And don’t forget to restart apache or at least `/etc/init.d/apache2 force-reload`.

TIP: I added a test case for this bug (see test file in the rep). Run it on every environment if you are not sure whether it is affected or not.

More tips
If you want to disable AutoLogin for specific sites you can simply set `active` to `false` for this site in your configs or dynamically in the controllers’ constructor.
Remember: Since you need to include it before Auth etc you cannot dynamically add it to the list of components. But you can always disable the included component this way

The debug mode is on auto-detect by default. If you develop locally (debug > 0) you have it enabled right away. But, of course, you can overwrite this value in your configs.

Another important setting is `expires` – it defaults to `2 weeks` but can also easily be adjusted.

The migration guide from 2.0 to 2.1 can be found at
book.cakephp.org/2.0/en/appendices/2-1-migration-guide.html

New stuff for the upgrade shell

I used this chance to enhance my version of the upgrade shell and added – besides some minor fixes – a command `cake21`. It should take care of all api standard updates for 2.1: git commit1 and 2
The Upgrade Plugin can be found here.

It currently updates Auth::allow() and layout stuff ($content_for_layout, $scripts_for_layout etc).

Feel free to add missing replacements.

Traits

With PHP5.4 approaching fast, it will probably be the standard sometime in 2012.
It will have one major feature that we will all going to love: oop5.traits.

What are they?
The above link describes it pretty good. They are some kind of behavior – like the one we attach to models right now. Only way more flexible and powerful.
Every class can then use those `behaviors`.

trait Hello {
    public function sayHello() {
        echo 'Hello ';
    }
}
 
trait World {
    public function sayWorld() {
        echo 'World!';
    }
}
 
trait HelloWorld {
    use Hello, World;
}
 
class MyHelloWorld {
    use HelloWorld;
}
 
$Foo = new MyHelloWorld();
$Foo->sayHello();
$Foo->sayWorld();

The result would be Hello World!

Imagine what would be possible with Controllers, Components, Shells, and other classes that can now not only extend parent classes but also use traits.

Cool things you can do with them

The above link contains a good set of examples.
I will outline the most interesting ones:

public function sayWhere() {
    echo __CLASS__; // same with __FILE__ etc
}

As of right now objects that are extended by some subclass would always return the wrong class, because inside a class those magic constants always relate to the current file (and therefore often the parent class defining it).
With traits the magic is endless – they will make it possible to inject functionality that overcomes that deficiency:

trait sayWhere {
    public function whereAmI() {
        echo __CLASS__;
    }
}
 
class Hello {
    use sayWHere;
}
 
class World {
    use sayWHere;
}
 
$One = new Hello;
$One->whereAmI(); //Hello
 
$Two = new World;
$Two->whereAmI(); //World

Another neat feature is, that we can override specific methods if needed – both ways:

class Base {
	use SayBye;
 
	// we want this method to be overridden by the trait to do some extra stuff with it
	// can only be done in the inheriting class, though
	public function sayHello() {
		echo 'Hello ';
	}
}
 
trait SayWorld {
	public function sayHello() {
		parent::sayHello();
		echo 'World!';
	}
}
 
trait SayBye {
	// this method will be be overridden by the class method to do some extra stuff with it
	// can only be done in the inheriting class, though
	public function sayBye() {
		echo 'Bye ';
	}
}
 
class MyHelloWorld extends Base {
	use SayWorld;
 
	public function sayBye() {
		echo parent::sayBye();
		echo 'World!';
	}
}
 
$Foo = new MyHelloWorld();
$Foo->sayHello(); //Hello World!
$Foo->sayBye(); //Bye World!

Preparations

I assume you already got the AuthComponent included in the $components array of your AppController.
You probably also excluded all public views with sth like

$this->Auth->allow('contact_form'); # in beforeFilter() of the specific controllers

This here (in the contact controller) makes Auth skip this action completely. The action will be accessable to everybody right away.

You probably got a Role model (User belongsTo Role / User hasAndBelongsToMany Role) attached to the User.
If you don’t want this, use Configure to store your keys like so:

$config['Role'] = array(
	'superadmin' => 1,
	'admin' => 2,
	'moderator' => 3,
	'helper' => 4,
	'user' => 5,
);

You should at least have the user and admin role for it to make sense.

You should also have some kind of Authentication in your AppController:

$this->Auth->authenticate = array('Form')); # uses username and password for login

So far so good. You can login/logout and once you are logged in browse all non-public pages.
Even admin pages, of course. Thats where the TinyAuth class comes in.

TinyAuth

The code can be found at github.

First of all include it in your beforeFilter() method of the AppController:

$this->Auth->authorize = array('Tools.Tiny');

If you don’t place this code into your “Tools” plugin, make sure to remove the Tools. prefix then.

Now create a file in /Config/ called acl.ini like so:

[Tools.Countries]
* = superadmin ; this is a comment
 
[Account]
edit,change_pw = *
 
[Activities]
admin_index,admin_edit,admin_add,admin_delete = admin,superadmin
index = *
 
[Users]
index,search = user
* = moderator,admin

The format is normal PHP INI style. I already included all kind of examples. * is a placeholder for “any”.
The plugin prefix for controllers is not necessary as of now (maybe for Cake3 where the same controller name is allowed multiple times due to PHP5.3 namespaces).
Comments in ini files start with “;”.

Explanations:
- Superadmin can access all Countries actions
- Account actions are accessable by all roles (and therefore logged in users)
- Activities can be modified by all admins and listed by all everyone
- Users can search and list other others, but only moderators and admins have access to all other ations

That’s it. Really easy, isn’t it?

Some details

TinyAuth expects a Session Auth User like so:

Auth.User.id
Auth.User.role_id (belongsTo - role key directly in the users table)

or so:

Auth.User.id
Auth.User.Role (hasAndBelongsToMany - multi role array containing all role keys)

As you can see it can manage both single and multile role setup.
That’s sth the core one lacks, as well.

The current configuration is cached in the persistent folder by default. In development mode (debug > 0) it will be regenerated all the time, though. So remember that you have to manually clear your cache in productive mode for changes to take effect!

Quicktips

If you have a cleanly separated user/admin interface there is a way to allow all user actions to users right away;

$this->Auth->authorize = array('Tools.Tiny'=>array('allowUser'=>true));

Only for admin views the authorization is required then.

If you got a “superadmin” role and want it to access everything automatically, do this in the beforeFilter method of your AppController:

$userRoles = $this->Session->read('Auth.User.Role');
if ($userRoles && in_array(Configure::read('Role.superadmin'), $userRoles)) {
	# Skip auth for this user entirely
	$this->Auth->allow('*');
}

UPDATE 2012-01-10

The auth model can now be anything you like. It doesn’t have to be `Role` or `role_id`.
The new cake2.x uses “groups” per default.
You can easily adjust that now by passing `aclModel` => 'Group' or `aclKey` => 'group_id' to the Tiny class, for instance.

Model

The most important part first: We need a solid validation for the form. How many forms are out there that do not have any validation. The first thing I always do on about any public contact form: Hit the submit button and smile it if tells me that my empty form “has just been successfully sent”. We can do better than that

class ContactForm extends ToolsAppModel {
 
	protected $_schema = array(
		'name' => array('type' => 'string' , 'null' => false, 'default' => '', 'length' => '30'),
		'email' => array('type' => 'string' , 'null' => false, 'default' => '', 'length' => '60'),
		'subject' => array('type' => 'string' , 'null' => false, 'default' => '', 'length' => '60'),
		'message' => array('type' => 'text' , 'null' => false, 'default' => ''),
	);
 
	public $useTable = false;
 
	public $validate = array(
		'name' => array(
			'notEmpty' => array(
				'rule' => array('notEmpty'),
				'message' => 'valErrMandatoryField',
				'last' => true
			)
		),
		...
	);

The _schema var mocks a database table so that we don’t really need one. This helps the FormHelper to generate the inputs (maxlength, type, …).
The validation rules will make sure the email is valid and the user actually entered some text.

Controller

The logic cakes care of the validation on POST.
/Controller/ContactController.php

<?php
class ContactController extends AppController {
 
	public $uses = array('Tools.ContactForm');
 
	public function index() {
		if ($this->request->is('post') || $this->request->is('put')) {
			if (!$this->Session->check('Auth.User.id')) {
				$this->ContactForm->Behaviors->attach('Tools.Captcha');
			}
			$this->ContactForm->set($this->request->data);
			if ($this->ContactForm->validates()) {
				$name = $this->request->data['ContactForm']['name'];
				$email = $this->request->data['ContactForm']['email'];
				$message = $this->request->data['ContactForm']['message'];
 
				//send email with CakeEmail
			} else {
				$this->Common->flashMessage(__('formContainsErrors'), 'error');
			}
 
		}
		$this->helpers = array_merge($this->helpers, array('Tools.Captcha'));
	}
}

As you can see it only sends emails after successfully validating.
For public contact forms I usually like some easy captcha behavior attached so that spam doesnt reach me. You can omit that, of course.
Also note: you should use your own setFlash() method instead of mine!

Last but not least: View

/View/Contact/index.ctp

<?php echo $this->Form->create('ContactForm');?>
	<fieldset>
		<legend><?php echo __('contactLegend');?></legend>
	<?php
		echo $this->Form->input('name');
		echo $this->Form->input('email');
 
		echo $this->Form->input('subject');
		echo $this->Form->input('message', array('rows'=>15));
 
		if (!$this->Session->read('Auth.User.id')) {
			echo $this->Captcha->input('ContactForm');
		}
	?>
	</fieldset>
<?php echo $this->Form->submit(__('Submit')); ?>
<?php echo $this->Form->end();?>

Result

Browse to /contact/
That should display the form right away.
After the successful POST you should redirect back to the contact form (emptied then) or to another custom page.

Final notes

Currently, the Model is in the Tools.Plugin. You could put it into your normal app model folder, as well.
But I use it in many projects and therefore I want to keep it dry. Feel free to adjust any of the code to your own needs. Same goes for my own custom methods like $this->Common->flashMessage() etc.

Execution Order

The documentation wasn’t all that clear about it. So I tried it with the following test file:

App::uses('MyCakeTestCase', 'Tools.Lib');
 
class TestCaseExecutionOrderTest extends MyCakeTestCase {
 
	public function setUp() {
		parent::setUp();
 
		$this->out('setUp');
	}
 
	public function tearDown() {
		$this->out('tearDown');
 
		parent::tearDown();
	}
 
	public function startTest() {
		$this->out('startTest');
	}
 
	public function endTest() {
		$this->out('endTest');
	}
 
 
	public function testFoo() {
		$this->out('* foo *');
	}
 
	public function testBar() {
		$this->out('* bar *');
	}
 
}

Note the parent calls for setUp and tearDown. Those need to be set. The other 2 methods don’t require this.

The result was pretty obvious:

setUp
startTest
* foo *
endTest
tearDown
 
setUp
startTest
* bar *
endTest
tearDown

Debug Output with PHPUnit >= 3.6

On the release notes of CakePHP2.0.3 you could find the note

A big difference people will notice when writing unit tests is that all output is swallowed by PHPUnit and not presented in either the web tester page nor in the CLI tester. To overcome this annoyance use the--debug modifier if you are using the CLI interface

Well, that broke a lot of existing debug code, of course.
So I tried to come up with a solution. The Shell uses a specific output(). Why not use sth like that in test cases, too?

/**
 * outputs debug information during a web tester (browser) test case
 * since PHPUnit>=3.6 swallowes all output by default
 * this is a convenience output handler since debug() or pr() have no effect
 * @param mixed $data
 * @param bool $pre should a pre tag be enclosed around the output
 * @return void
 * 2011-12-04 ms
 */
public function out($data, $pre = true) {
	if ($pre) {
		$data = pre($data);
	}
	echo $data;
	if (empty($_SERVER['HTTP_HOST'])) {
		# cli mode / shell access: use the --debug modifier if you are using the CLI interface
		return;
	}
	ob_flush();
}

As you probably noticed, I use it in the above “execution tryout”.
You can make yourself a custom “MyCakeTestCase” class with then extends the core test case class and put it in there.

UPDATE January 2012

The core (>=2.0) now contains a native way to enable debugging output for your tests.
You need to append &debug=1 to the url. Not ideal, but it works.

How to start

Skip this, if you want to cut to the chase.

In your routes.php you need to add Router::parseExtensions(); (or only specific ones).
That tells cake that urls ending with “.xyz” will be served as files (either inline or as download attachment).

Setup

Let’s say you want to display an invoice as pdf. The normal url is /invoices/view/1.
Now, we set a link in the view to the file like so:

$this->Html->link('View as PDF', array('action'=>'view', 'ext'=>'pdf', 1));

Since cake automatically detects that this will be a pdf file, it will
a) set the correct header (application/pdf)
b) will try to find the specific pdf view in /View/Invoices/pdf/index.ctp and the pdf layout in /View/Layouts/pdf/default.ctp

That’ all

Download it right away

Files like pdf can be displayed inline. So the browser will usually not force you to download it.
If you want this, though, you need to call $this->request->download($filename); in your controller action or in your layout.

Note: If your browser does not understand the file format (in this case pdf) it will probably trigger the download right away.

Browser bugs and easter eggs

Well, you could also call it a bug. But during my tryouts I found out that files served inline (Content-Disposition: inline; filename=”…”) will not use the given filename on save. They will be saved with the name in the url instead. In the above example it would be “1.pdf”. I did some research: Thats a well known browser deficiency that nobody yet fixed. Or so it seems.
Ok, but nobody wants his invoice to be “1.pdf”. So what can we do about it?

I found a pretty well working workaround:

$this->Html->link('View as PDF', array('action'=>'view', 'ext'=>'pdf', 1, 'invoice-2011-11-01_some_customer_tag'));

As you can see we simply add our filename to the url – after the id (!).

Since it is only “filename cosmetics” we dont need to add this second passed param to our method:

public function view($id = null) {}

It will be ignored in the action itself.

So the generated url is /invoices/view/1/invoice-2011-11-01_some_customer_tag.pdf and will result in a file saved as “invoice-2011-11-01_some_customer_tag.pdf”.
Job done.

Let me know what you think.

Example for PDFs

A pretty quick example how to output your content as pdf using DOMPDF.

In your layout (default.ctp in /pdf/):

App::import('Vendor', 'dompdf/dompdf.php');
$dompdf = new DOMPDF();
$dompdf->load_html(utf8_decode($content_for_layout), Configure::read('App.encoding'));
$dompdf->render();
echo $dompdf->output();

For me it seemed that without utf8_decode the DOMPDF lib seems to be buggy – although it claims to support utf8.

Using the console for 2.0

I once wrote about how to use the Cake1.3 console.
The 2.0 shell is not so much different. The Console folder was only moved to /lib/Cake/Command/.
Make sure you use this new path. Also note, that it now seems to be important to have a “base app”.
You can’t just use the console anymore anywhere you like. It needs to have an app to get configuration and additional information on.
It also might be important which direction you are using the console – at least in 2.0 now. Being in the Command path with -app param might result in sth different than using the default way of using the console from within your current app directory.
So you should always go with the latter:

E:\...\trunk\app\>..\lib\Cake\Console\cake [command]

And if you put your “…/Console” path in your System Environment path (see the other article for details), you can use “cake” as standalone again:

E:\...\trunk\app\>cake [command]

Cronjobs now work this way (using crontab):

*/30 * * * * /srv/www/.../trunk/vendors/cakeshell app -cli /usr/bin -console /srv/www/.../trunk/lib/Cake/Console -app /srv/www/.../trunk/site >> /tmp/log.log

This runs a the AppShell (defined in your /App/Console/Command/ folder) every 30 minutes and logs errors/results to the given log file.

Note: cakeshell is a file containing the script from the cookbook.
Also note: If you use windows you might need to run “dos2unix /…/Cake/Console/cake” in order to make the cake console working.

Upgrade using the upgrade shell

cake upgrade all -params

I use an enhanced shell which provides more functionality.
For params I use –svn. It cakes care of the moving process if you use subversion. git is also supported.
Even if you already upgraded you should run it. Just in case you missed anything. The shell also auto-corrects some styling errors or deprecated syntax.

Rendering elements from helpers

This is now possible because the View is available in the helpers now.
So inside a helper method just do:

$elementContent = $this->_View->element('...');

Note: element() now has three params. The second still is the one where you can pass variables to the element scope. But the third param is now the options param (cache, plugin, callbacks, …).

It is even possible to alter the output from a helper directly:

$output = $this->_View->output; // contains the current rendered output

If you need any information on the current url or params:

$this->_View->request // contains all information about the current request

Overriding plugin views in the app

Another feature that finally arrived. Now plugins don’t have to cover all possible cases.
For specific apps you can override the plugin view locally.
Place the view in /app/View/Plugin/PluginName/Controller/action.ctp. The same goes for layouts, of course.

Enhancing objects and aliasing

public $helpers = array(
    'Html' => array(
        'className' => 'Tools.HtmlExt' // Tools Plugin - HtmlExtHelper
    )
);

Declared anywhere in the code the HtmlExt helper will then be used instead of the core Html helper.
The important change is, that it will use the old namespace, though. $this->Html is still the right way to use it. So you can enhance every helper, component, … to suite your needs without having to change the existing code itself.

This opens whole new possibilities. Until now you would have used a FormExt helper and manually called it with $this->FormExt->foo().
For 2.0 I use and recommend the following structure:
Add Ext to helpers/components etc from the core you want to Extend:
- FormExt(Helper)
- RequestHandlerExt(Component)
alias them as above to the original one.
Best to place them in a plugin all your apps have in common (Tools in my case).
Now if you want to go even further, you can override that one again specifically for this app by prefixing it with My:
- MyForm
- MyFormExt
…
All app specific helpers are not in a plugin but the app dir structure and start with My.
And using aliasing you can still call the helper with $this->Form->foo().
Same goes for components, behaviors, …

Working with exceptions

$post = $this->Post->read(null, $id);
if (!$post) {
	throw new NotFoundException();
}

The exception should then display a 404 error page.

Including scripts

Before 2.0 you always used App::import();
But with the switch to App::uses() the files do not get included anymore at startup due to the Super-lazy-loading. This should only be used for real classes. Also start to group by PackageName:

App::uses('GeolocationLib', 'Tools.Geo');  # in /Plugin/Tools/Geo

It will only be included by Cake if actually needed. One reason why Cake2 is so much faster.

If you have a file without a class (containing functions or constants or whatever) you still need to use the old method:

App::import('Lib', 'Tools.Bootstrap/MyBootstrap'); # in package "Bootstrap"

Using own classes instead of core ones

Let’s say, you want to apply a fix to a core file without overriding the core folder. Or you want to replace a file altogether. Simply use the same folder structure inside the /Lib folder.
For your own “FormAuthenticate”
/app/Lib/Controller/Component/Auth/FormAuthenticate.php

Cleanup!

If you are upgrading to 2.0 – or already have – you should get rid of old PHP4 chunk.
For starters, the &+object needs to get eradicated once and for all.

Old style:

public function setup(&$Model, $config = array()) {}

A correct piece of a behavior now looks like:

public function setup(Model $Model, $config = array()) {} # type Model and no &

Same goes for components, controllers, helpers, …
Note: You can do this for 1.3 already, as well. At least if you are using PHP5 (and you probably are).

You should also change all “var $x” to “public $x” and add “public” to all methods in classes which don’t have a visibility attribute yet.

I wrote a “CorrectShell” which extends the UpgradeShell. It does take care of almost all changes. I will publish it soon.

Things I did find out the hard way

Most of my libs and helpers which use the Xml class had to be modified quite a bit.
The class itself is not accessed statically, and more important does return only lowercase keys.
This was some piece of work to find and correct all those necessary changes.

If you make use of the internal HttpSocket class you might want to be interested in the fact, that it now returns an object as response. So you need to use $response->body to access the result content.

You cannot really set the headers and content type in your layouts anymore manually using “header()”. You need to do this using the response object:

$this->response->type('pdf'); //or as mimetype:
$this->response->type('application/pdf');

Either from the controller or the view/layout/helper.

The core.php, routes.php and bootstrap.php need new settings in order for your app to fully function under 2.0. Tip: Look at the original 2.0 app files and compare them to your upgraded files.
Add anything that is missing.

There seem to be dependency problems now with components and helpers. So the order in which you add them in your controller is now important (wasn’t in 1.3). If they depend on a class you should add them after that one to prevent the collection to fatal error. (UPDATE: Some if it seems to be fixed now).

Shell tips not mentioned in any upgrade guide

Shells are one of the most useful tools out there. I have dozens of them and those were the first classes I ported to 2.0. Therefore I ran into problems with those, first. So in case, you write your own ones, too:

The usage of shells has changed quite a lot. You don’t need a help method anymore. The consoleOptionParser object will take care of that using “-h”.
For using params/args you will now need to set up a “getOptionParser” method (see the core shells for examples).
For string options you should set an empty default value: 'default' => '' (prevents you from warnings). For boolean values set 'boolean' => true.

A main() command should always be called explicitly (“cake Shell main -f” instead of “cake Shell -f”) if you want to pass params or args. Otherwise it won’t run.

And there is more

Make sure you check all your forms. Especially the ones where you customized. Since 2.0 now adds HTML5 types automatically, it can get unwanted results when you use names for fields that are already matched in the schema. In my case many normal “text” fields suddenly ended up being “type”=>”number”. Which screwed up the whole form (could not validate anymore).
Some normal selects (for search etc) suddenly ended up being “multiple”=>”multiple”. Why? I am not yet sure

The FormHelper does not support some field type aliases anymore. So for textareas you have to use 'type'=>'textarea'. “textfield” doesn’t work anymore – if you have that still somewhere in your forms.

Custom Joins do not need the prefix anymore. In 1.3 you had to do:

array(
	'table'=>$this->Conversation->tablePrefix.'conversation_messages',
	'alias'=>'ConversationMessage',
	'type'=>'inner',
	'conditions'=>array('Conversation.last_message_id = ConversationMessage.id'),
), ...

In 2.0 it’s just:

'table'=>'conversation_messages'

Otherwise it will prepend the prefix twice which, of course, breaks the query!

The Routing has changed quite a bit. Some to the better – some to the worse (or I coudn’t figure out yet how it is done in 2.0):
In 1.3 this was working to connect an url and all its prefixes:

Router::connect('/shortcut', array('controller' => 'overview', 'action'=>'some_action'));

But this will not in 2.0 anymore. Here all prefixes get treated as normal named params.
A quick fix (which does not enable the prefixed urls, though!) would be:

Router::connect('/shortcut', array('admin'=>false, 'controller' => 'overview', 'action'=>'some_action'));

At least the normal user url is working, again.
Although this doesn’t seem to work flawlessy, either…

Custom joins don’t need a model prefix anymore:

'joins'=>array(
	array(
		'table'=>$this->tablePrefix . 'conversation_users',
		'alias'=>'ConversationUser',
		'type'=>'inner',
		'conditions'=>array('Conversation.id = ConversationUser.conversation_id')
	),
)

becomes

'joins'=>array(
	array(
		'table'=>'conversation_users',
		'alias'=>'ConversationUser',
		'type'=>'inner',
		'conditions'=>array('Conversation.id = ConversationUser.conversation_id')
	),
)

Cake is now capable of prefixing the table names automatically.

Some of the important aspects of 2.0

• Faster (20-40% depending on the application)
• Modern (>=PHP5.2 and state of the art functionality)
• More Flexible and extensible (almost every class can be switched out with own ones)
• Exceptions as error handling
• PHPUnit as test suite
• Hundreds of fixes which had to stay in 1.3 due to compatibility issues
• Lots of enhancements and new functionality like “aliasing” – details

If you start a new project dive right into 2.0. That’s the future

For all those who like to assimilate the changes as online video:
tv.cakephp.org/video/CakeFoundation/2011/10/06/ch-ch-anges_cakephp_2_0_-_by_mark_story

Tips for upgrading

The migration guide will help to upgrade existing applications to the new version.
This will be quite a bit of work, though. Almost all classes are renamed, many methods and object variables have been dropped.

Your biggest help will be the cake shell script “ugrade” which is available in 2.0 now. It helps you to automatically upgrade some of the code. You can either select all or single tasks like renaming components etc.
Simply type “cake upgrade” in the console to list all available methods.
It really is a huge time safer. You should backup or commit everything before you attempt to run this script, though.

UPDATE:
I tried to upgrade a medium sized 1.3 app to 2.0. After finding several problems I opened a ticket.
Hopefully the upgrade process will be made smoother the next couple of weeks

Last Words

I am a little bit proud to see many of my tickets and proposed changes/fixes being now part of the framework.
Contributing to such a popular and large framework is sometimes easier than one might think. Sometimes it needed only hours to approve one of my tickets. OK, sometimes it needs months.
Providing a good reason and attaching proposed changes as diff or patch can really speed up things and should encourage you to involve yourself in cake core development, as well.

SVN becomes more GITish

With the release of all new 1.7 the thousands of .svn folders are finally history!
Only a single .svn file in the root folder remains. Yes, most of you will immediately think of GIT
Well, now SVN uses a sqllite DB to work the same way.
The speed increased, as well.

All you need to do on windows:
- Update TortoiseSVN
- Rightclick on the root folder of your svn folder and select “SVN update working copy”

Details:
tortoisesvn.net/tsvn_1.7_releasenotes.html

Numbers wanted?

To demonstrate how huge this step in the right direction is:
“cake2.0rc3″ – the current 2.0 head – consists of 1518 files.

Before the upgrade to tortoisesvn1.7 the complete folder consisted of 4100 files in 5100 folders. So almost twice as much svn crap – overall 38 MB in size.
After the upgrade the folder counts 2826 files in 848 folders (wow!). File size is now down to 32 MB.

I really like it. Copying/Moving is now so much easier. I had just recently written a script which could delete all tmp folders (.svn) from a directory recursively to be able to merge it into other folders.
This is now history. Merging finally works as easy as in GIT.
Backuping and remote copying is now so much faster due to less structural overhead.