As you probably have heard, RC3 of CakePHP 1.2 has been released today (together with a bug fix release of CakePHP 1.1), see also the official announcement.
Upgrading NoseRub, which has to act as my guinea pig in such cases, from RC2 to RC3 was a piece of cake. In the “app” folder I had to update the following files as there were some minor changes in them:
- app/webroot/js/vendors.php
app/webroot/css.php(my mistake, this file wasn’t changed)app/webroot/index.php(my mistake, this file wasn’t changed)
And then I had to replace the “cake” folder, of course.
Up to now I encountered only two small “issues” which were easy to fix.
The first “issue” just broke some tests: the order of the attributes “value” and “id” of the hidden field created when using FormHelper::checkbox() changed from:
<input type="hidden" name="data[OpenidSite][email]" value="0" id="OpenidSiteEmail_" />
to
<input type="hidden" name="data[OpenidSite][email]" id="OpenidSiteEmail_" value="0" />
The second “issue” caused the following warning:
array_merge() [function.array-merge]: Argument #1 is not an array [CORE/cake/libs/view/helpers/form.php, line 1141]
The reason for this warning is that we used FormHelper::select() “wrong”:
echo $form->select('Account.service_id', $services, null, null, false);
The problem is that the default value for the fourth parameter has to be an empty array and not “null” and so I had to fix the statement from above in the following way:
echo $form->select('Account.service_id', $services, null, array(), false);
As you can see, the upgrade was very smooth here. Thanks to everyone involved with this release!
Now I’m looking forward to the final version of CakePHP 1.2 :)
Update (2008-10-02): Another “issue” I just noticed is that the “old” Model/field syntax no longer works correctly. For example:
echo $form->textarea('Micropublish/value');
generates the following HTML code:
<textarea name="data[Micropublish/value]" id="Micropublish/value" ></textarea>
The fix is simple:
echo $form->textarea('Micropublish.value');
This will create the correct code:
<textarea name="data[Micropublish][value]" id="MicropublishValue" ></textarea>
Heh, I knew you’ll be the first to publish the migration steps, you sure are reliable :-)
Well covered Daniel, thanks!
[...] Migration from CakePHP 1.2 RC2 to RC3 – cakebaker [...]
For testing HTML, I recommend the assertTags function in the CakePHP test suite. It can check the structure of any snippet of HTML or XML without worrying about things like whitespace or attribute order.
As far as the FormHelper::select() issue, I can add a typecast so that nulls are allowed.
Thanks for the comprehensive article.
Thanks about the $form->select .. was banging my head with that one myself.
@all: Thanks for your comments!
@nate: Thanks for the tip with assertTags!
I think it is not necessary to allow null, as it is quite obvious from the method signature that the default value is an empty array.
App::Import seems to have changed. Before we could call
from within a plugin and it import the model from the main /models/ folder. Now it gives: Fatal error: Class ‘Depot’ not found in ….
Not sure how to fix it yet.
@cakebaker: True about the default value, but it’s a simple change, and it doesn’t require people to remember that the type of empty value *must* be an array. And if it eases migration pain, I’m happy to do it.
Unfortunately it looks to me like the earlier versions are not tagged in the CakePHP repository so, if you’re using svn:externals to include CakePHP and the latest version breaks everything (nearly all our unit tests are utterly foo bar with this latest update) you can’t roll back to the previous version. Hmm…
Whoops. Never mind. Ignore the above comment about App::Import :o
I can’t see any relevant changes in:
* app/webroot/js/vendors.php
* app/webroot/css.php
* app/webroot/index.php
only SVN propeties are changed ?!
Thanks :)
Thanks for the article, got to update now! With timezones I’m only just starting the day……looking forward to the 1.2 release.
Hey, your a life saver! I was about to create a new project and drag in all my files!! How did you know what files had been editted? Outside of the cake directory?
[...] Migration from CakePHP 1.2 RC2 to RC3 – cakebaker [...]
As majna said, i can’t see major changes in app/webroot/css.php neither in app/webroot/index.php.
In app/webroot/js/vendors.php i saw a change. In the other ones, just the @lastmodified comment.
@all: Thanks for your comments!
@Alex: Yes, the earlier versions are not tagged in the repository. I have no experience with svn:externals, but isn’t it possible to specify the revision you want to use? Which in the case of RC2 is 7296.
Regarding your tests I hope it is not that bad as it sounds ;-)
@majna, Vinicius: Yes, you are right, index.php and css.php were not changed in RC3. Obviously I didn’t update those files to RC2 at that time… I’m sorry for the misinformation, and thanks for pointing out this mistake. It’s now fixed in the article.
@Josh: I just go through the files and compare them manually with the files of the application.
Just to update that nate has added support to null on fourth param of FormHelper::select() on [7697] – https://trac.cakephp.org/changeset/7697.
The only ‘issue’ I encountered was findNeighbours() not working properly anymore. It has been replaced by find(‘neighbors’). You can find a piece of example code in the cookbook.
Other than that, they really delivered on the speed increase in the bootstrap. On a App::import heavy project of mine I did get a ten-fold speed increase. With ‘normal usage’ it stayed the same, but 6ms (without op-code cache) wasn’t too slow to begin with.
@Rafael: Thanks for the hint!
@Terr: Hm, at least theoretically findNeighbours() should still work ;-) On the other hand the method has been deprecated a while ago, so it is a good idea to switch to find(‘neighbors’).
Haven’t worked it out just yet….. however a non-core function commonly in use “unbindAll” appears to be broken by RC3.
-Ben
Nope all cool, was a patch I’ve made to the core to get multiple groups in ACL working.
For me, the
$html->linkis broken when using multibyte characters, in my case Japanese. I couldn’t find documentation for RC3 yet on the api.cakephp.org site either.Sorry to post twice, but it was an error with the App.encoding. Mine was set to UTF8 but in a few pages I am using another encoding on the view. I fixed it by using this code in the view.
Configure::write('App.encoding', 'SJIS');@Mr-Yellow, Jason: I’m glad you could solve those issues :)
Hello, thanks for this post. It was very helpful especially for “second issue” in forms.
I have a question about bake script. Did they changed it in a way that all first letters of baked variabls are Uppercased?
@Luka: About which variables are you talking? I just baked controller, model, and views (using rev. 7908), and all generated variables seem to start with a lowercase character.
Sorry, maybe I was wrong with lowercase and uppercase but I think I had to change variable names in my views because controller was baked with rc2 and views were baked with rc 3.
I don’t remember in details what I had to change but I think it was:
$this->set(Products,xxx) to $this->set(products,xxx) or vice versa…
Please don’t laugh but I don’t recall in details what I had to change to make my app work :)
@Luka: It’s possible this has been changed. I don’t know, I don’t use bake that often I would notice such a change…
Why should I laugh about you, I forget such details myself ;-)
Btw: Nice graphics on your website!
@cakebaker “Nice graphics on your website!”
thanks :)
Here’s a change I had to make. I was using NeatString::randomPassword(), but the NeatString and NeatArray classes were removed. It’s time to write my own function. :)
@Joel: Yes, those classes have been removed a while ago. However, those classes are still available in the repository. I don’t know if they still work, but at least you could use them as inspiration for your functionality.