Migrating from CakePHP 1.2beta to RC1

Published on and tagged with cakephp  release  update

You probably know it already: the first release candidate (RC1) of CakePHP 1.2 has been released today (see the announcement).

Here some things I noticed/encountered while migrating from the beta version to RC1.

In app/config/core.php the class name for ACL has changed. Instead of

Configure::write('Acl.classname', 'DB_ACL');

it is now

Configure::write('Acl.classname', 'DbAcl');

The model-based storage engine for the cache (cake/libs/cache/model.php) has been removed.

Probably the first thing you notice when you migrate to the new version are the warnings caused by the deprecated “vendor” function. This function has been replaced by App::import(). Unfortunately, you can’t perform a simple search/replace operation as files/directories which don’t follow the cake conventions have to be treated differently (see also Loading vendor files). Examples:

App::import('Vendor', 'follows/cake/conventions'); // .php is automatically appended
App::import('Vendor', 'unconventional', array('file' => 'doesnt/follow/Cake/Conventions.php');

Another newly deprecated method you might use is Model::execute(). It has been replaced by Model::query(). This time you can use search/replace.

With Model::find() I encountered a situation, where the method didn’t return any data. I don’t know whether it is a bug or simply no longer supported. Here the code I used (simplified):

$this->Location->find('list', array('fields' => 'id, name'));

It performs the correct SQL statement, but somehow the preparation of the result doesn’t work. A simple workaround is to use the model alias for the field names:

$this->Location->find('list', array('fields' => 'Location.id, Location.name'));

Or as mentioned by Xr in a comment:


A new feature of the FormHelper caused a visual problem in my application: it adds a class with the name of the input type to the respective input field (e.g. “text” to a text field, “password” to a password field, etc.). As I already used a CSS class with the name “text”, my forms looked a bit ugly after the update ;-)

The latest issue I encountered was a blank page (only the performed SQL statements were shown). It was caused by the following snippet which worked with the beta version (don’t ask me why there was an exit at the end of the method *g*):

public function xy() {

After removing the exit, the view was rendered as expected, obviously something changed internally.

All in all, the migration was quite smooth. Thanks to the cake team for this piece of cake :)

29 comments baked

  • nate

    Configure::write(‘Acl.classname’, ‘DB_ACL’);

    This setting should actually be backwards-compatible. I added an inflection when the setting is being read. Thanks for pointing it out though.

  • Abhimanyu Grover

    Nice info, man..

  • Andrew

    Great post!

    Suggestion for a future blog post: What about migrating from a Cake 1.1 installation to Cake 1.2? I have quite a few projects still running 1.1, and it’d be great to see some sort of upgrade-guide to 1.2. (If one already exists, my apologies for my ignorance.)

  • francky06l

    I noticed the render “issue” a while ago in the SVN branch. Be sure not to “exit” or “die” after render, make a “return”.
    Another point, as mentionned in the annoucement, are the conditions in queries. I did transform such array(“field” => “>= value”) into array(“field >=” => “value”). Pay also attention on condition having “-!” kind of keyword. Conditions as array(“field >= ‘{$value}'”) are ok.
    The renderElement is deprecated, use element() instead .. a story of few seconds with a good editor.
    @Andrew: depends the size of your application, major work is on view, validations, queries .. Now if you want to take advantages of the functionalities of 1.2, you might think more of a re-factoring than porting.

  • teknoid

    thanks for the post!

    one thing I’ve noticed with the new containable and RC1 is that when you pass ‘fields’ as a string i.e. ‘fields’=>’id’

    There is an error… Fatal error: [] operator not supported for strings… in containable.

    changing to ‘fields’=>array(‘id’) fixes the problem

  • Andrew

    @francky06l – Ya I hear ya… I guess I was thinking more along the lines of… “Okay, if I upgrade Cake 1.1 to Cake 1.2, what exactly will break, and what do I need to change to make it work?” I’m not exactly inquiring just for myself, but I think that kind of guide could be helpful for the community. Hell, maybe I’ll take up the project myself.

  • Manny

    You the MAN ;)

    I’ll be coming back often because I’m assuming there’s probably more stuff that has been deprecated or changed that no one has come across :(

  • Jonathan Snook

    Andrew: there’s a rough 1.1 to 1.2 migration guide in the Book:


    As to the extra class names in forms, you have me to thank for that. :)

  • Tarique Sani

    A helpful post for everyone who waited for RC1 :)

  • CakePHP ออก 1.2 RC1 แล้ว « वीर

    […] CakePHP ออก 1.2 RC1 แล้ว Filed under: Uncategorized — वीर @ 5:19 am Tags: 1.2, 1.2.x, beta, cakephp, migrate, mvc, php, programming, rc1, release, web, web framework CakePHP ออก 1.2 RC1 แล้ว หลังจากเป็น Beta อยู่นานเหมือนกัน. และตามมาด้วยต้องออกแรงกันนิดหน่อยเพื่อที่จะ migrate จาก beta ไป rc1 ดูได้ที่ http://cakebaker.42dh.com/2008/06/05/migrating-from-cakephp-12beta-to-rc1/ […]

  • Xr

    $this->Location->find(‘list’, array(‘fields’ => ‘id, name’));

    I don’t get it. Why don’t you just find(‘list’) ? The id is automatically fetched, and if your ‘name’ field is not named ‘name’, you can set Model::displayField to whatever it is.

    Transition was pretty straightforward here : I don’t need ACL’s (so even if loading with DB_ACL failed, Cake still worked) and only had to change my vendor clauses.

  • CakePHP & DIEVOLUTION Blog » Blog Archiv » CakePHP 1.2 RC1 gebacken

    […] eurer aktuellen Cake1.2 Beta Programmen rumschlagen müsst, hat der cakebaker einen Artikel veröffentlicht, der euch das Upgrade auf den ersten RC so einfach wie möglich machen […]

  • FL1

    Another thing that cropped up for me in the changing of html element naming, and in turn the changing of how data is passed through a form, from $form->datePicker() (I imagine that it carries through to $form->input() with a ‘datePicker’ type). Instead of $data[‘Model’][‘field_unitOfTime’] they’re now sent as $data[‘Model’][‘field’][‘unitOfTime’].

  • Watts

    Migrating from CakePHP 1.1 to 1.2 has so far been a remarkable pain in the butt that the migration guide doesn’t even begin to hint at. :) Off the top of my head –

    – The new Forms helper is great, but the equivalent functions in HTML helper aren’t there and deprecated, they’re just gone. On both my development machine and my production machine (two different OSes), the old form helpers would mysteriously fail until you turned on debug… at which point Apache would consistently segfault.

    – The ACL system between 1.1 and 1.2 is not backwards-compatible and there is no documentation on the difference. (The new ACO and ARO tables have ‘Model’ and ‘foreign_key’ fields.)

    – Actually, finding documentation on the new ACL system at all is difficult. Currently the Cake 1.2 manual in fact just repeats all the stuff from 1.1, which is completely inapplicable and thus slightly worse than useless. A few articles on http://lemoncake.wordpress.com/ have been the only things that have helped me here so far.

    – The way beforeFilter and afterFilter callbacks are implemented is different now (Cake actually calls functions with those names, i.e., beforeFilter(), rather than having a “var $beforeFilter = array(‘foo’, ‘bar’)” listing functions to call).

    – I’m told that “$uses” is deprecated and has been replaced by “App::import” but hell if I know what the implications are yet!

    The difference between 1.1 and 1.2 is really more the difference between a 1.1 and 2.0 release, because the changes are sweeping and the choice to break so much backward compatibility is honestly frustrating. I can understanding doing deprecation warnings, but a lot of stuff is just *gone.* To people who’ve been using 1.2 alpha releases for the past two years this may not be an issue, but to people who started on 1.1 because 1.2 didn’t get tagged as even beta quality until the start of this year, it sucks teabags.

  • Jonathan Snook

    Watts: as far as I know, var $uses hasn’t been deprecated but rather the function uses() has (in favour of App::import).

    As to your other concerns, if you could add your experience to the migration guide in the Manual, that’d be awesome.

  • Amr Tami

    after i turned to RC1 from 1.2 BETA,
    I faced some problem, but the all has a solution.
    but there is something, that when i run the console, the console doesn’t show me all the table in the my database “in RC1”.
    but if i run 1.2 beta ‘s console, it shows me all tables !
    What’s the problem ?

  • cakebaker

    @all: Thanks for your comments!

    @nate: Thanks for the hint that the old value should still work, I wasn’t aware of that.

    @Andrew: I agree with you that a migration guide would be quite useful, and as Jonathan already mentioned, there is a chapter about it in the manual. At the moment I think I can’t write such a post as I no longer have any cake 1.1.x.x applications to go through the migration process ;-)

    @francky06l: Thanks for mentioning renderElement. Even though it is mentioned in the announcement I forgot to change them ;-)

    @teknoid: Hm, strange, according to the tests that should work. They use the following statement in the tests:

    $r = $this->Article->find('all', array('contain' => array('Comment' => array('fields' => 'comment'))));

    @Manny: Most deprecated methods show a warning when they are used.

    @Jonathan: I think it is a good idea to have the extra class names in forms.

    @Xr: Yes, you are right, find(‘list’) is enough. I added it to the article.

    @FL1: Thanks for the hint, I wasn’t aware that this behavior was changed.

    @Watts: I can understand your frustrations. It would have been better to label it as 2.0 resp. to release 1.2 at a time as the differences between 1.1 and 1.2 weren’t that huge. I really hope the cake team learns from this “debacle” and will make it better in the future.

    @Jonathan: As far as I know uses() is not (yet) deprecated, there is no deprecation hint in basics.php. But it is probably a candidate to get deprecated, as App::import() provides the same functionality.

    @Amr: Hm, do you get any errors/warnings?

  • Bernie

    First up – Fantastic blog, have been a reader for quite a while now.

    Just to add another interesting complication that I just came across whilst upgrading to RC2.

    My problem was that certain pages started endlessly looping after the upgrade. For example, a simple $this->redirect(‘/’) from within my logout action would just die looping.

    After a few hours of debugging outputs throughout the core, it seems some of the redirect() code, along with the dependent Component::beforeRedirect() changed.

    The problem came down to a few custom components which extended ‘Component’ rather than ‘Object’, and somehow interfered with beforeRedirect() stuff linked to the redirect() function. This resulted in my simple $this->redirect(‘/’) to actually redirect somewhere completely different (in this case back to my logout action), as it happens the same action as it was being called from. Odd.

    Glad I actually referred to the Cookbook just to double check the proper structure for components – otherwise this might’ve consumed a lot more time :) Who would’ve known! Hope it’s helpful to someone.

  • Chris Walker

    I experienced the same issue with Controller::render(); and it seemed to me that the function no longer outputs the html directly, so “exit”-ing directly afterwards give you a blank page.

    The reason is that apparently “render” is designed to allow the code to continue executing, as opposed to “redirect” which should stop it (redirect now exits by default).

    However I used “render” to render views that I might not have done otherwise, AND I don’t want to redirect. The fix I came up with was to add an echo:

    echo $this->render(‘someview’);

    Of course if you DON’T want to stop processing you can just remove the “exit()”.

  • cakebaker

    @Bernie, Chris: Thanks for your comments!

    @Bernie: Yes, the Component class is not the base class for components as you might guess. The Component class is used by the controller to manage the component callbacks.

    @Chris: Yes, the functionality to output the rendered view has been moved. Now, the render method simply sets a variable with the view content (and also returns its value), the output happens later (resp. doesn’t happen if there is an exit).

    PS: Is there no RSS feed for your blog?

  • Chris Walker

    [quote]PS: Is there no RSS feed for your blog?[/quote]

    There wasn’t, I had been meaning to make one. Your comment spurred me on. http://thechriswalker.net/post/rss

    … I guess I’d better build that comment system now… ;)

  • cakebaker

    @Chris: Cool :)

    And regarding the comment system, you could have a look at the comment system of snogs (http://cakeforge.org/projects/snogs/), maybe it saves you some time.

  • Amr

    thx you ..
    mmmm, i think no errors i had !

  • cakebaker

    @Amr: So, that means there is no longer a problem?

  • Stripthis

    I got a problem when switching to RC1, with custom component initalisation that doesn’t seem to be perform in debug mode when errors pages such as missing controller/action are rendered.

    It seem to me that controller components are not startuped anymore in such context, since it use to works perfectly well and works well with RC1 if I run the startup manually in AppController::beforefilter on the incriminated custom components.

    While it’s no big deal, I felt like telling it, as it might save some time to people here ;)

  • cakebaker

    @Stripthis: Thanks for this information!

  • CakePHP 1.2 RC1 « Linerox

    […] los actuales usuarios de la anterior versión Beta de CakePHP 1.2, esta guía explica cómo realizar una migración exitosa al […]

  • Andreas Hofmann

    I have the same problem like Amr, that the Components are not started automatically.
    If I do App::import(‘component’, ‘Auth’) cake says:
    “Undefined property: GameController::$Auth”

    I’m using RC2

    I’ve posted a message to the google group… let’s see what happens.

  • cakebaker

    @Andreas: Well, using App::import() to load the component doesn’t make it a property of the respective controller.

    There are two ways to fix the problem: add the component to the $components array of your controller, or if you want to use App::import() then you have to instantiate the component manually.

    Hope that helps!

© daniel hofstetter. Licensed under a Creative Commons License