debuggable

Hi guys,

here are five quick CakePHP tips you should consider when you want to make your life easier. Isn't clean code all we want?

1. The prd() convenience function

Do you often find yourself doing the following in your controller, models and views?

Why not wrap it up into a nice function that you can call just like pr() ?

Simple, yet effective! You can just drop that into your bootstrap.php and do this from now on:

One line less to type! I hear many people argueing that you should use debug(). Good call, but it does not provide a parameter that let's you exit out, so you would end up doing something similar anyway. If someone uses anything else, be sure to throw it into the discussion.

2. How to debug your CakePHP emails?

Yeah so you set up a local mailserver in order to test your emails' output? Then had to wait between one and twenty minutes for the email to arrive? That is not KISS is it?

Cake's Email Component has a nice debug mode which you can use. Just set the following in your controller:

The Component stores its debug output as a Session flash Message, however. In order to access the debug information, you would do this:

The dump includes all headers, subject and message. The debug output is internally wrapped into a <pre> tag and therefore you have to keep in mind that non-explicit newlines will be shown as such in the debug output. However, they will not be in the email text. Be sure to explicitely insert newlines in the email via

for example.

You could also create a debugEmail() method in the app controller to wrap this Session read call to not always have to remember it.

3. Use elements where possible and make them belong to the controller

In a web application you will find yourself dealing with the same "site elements" time and again. Cake's elements are very handy for that. So why not use the views of a specific model as an element, too, to save code lines? Have a look at this in a fictive /views/posts/index.ctp

This looks much better:

You can use that as an element now in the index.ctp view as we did or as a different page. Only controller-independent elements should go into /views/elements. Everything else should stay in the controller-specific folder as view files. Disagree? Share your view!

4. Combine your h1 titles with Cake's page title

Very often people set the page title within their controller, which is bad. The page title is view logic so it should go into the view. For everybody not knowing about this yet, you can do the following in any view file as well:

So let's go a step further and output the page title as the h1 headline for your page in a very semantic line to kill two birds with one stone:

5. Avoid long parameter lists

A method with long parameter lists is always not a nice thing. It takes up space and will most likely need to be wrapped over two lines. How ugly!

Consider this:

instead of a function with a long parameter list.

Happy baking!

-- Tim Koschuetzki aka DarkAngelBGE

Hey folks,

so as you can see we made some minor design changes. ; ] In fact we wanted to show the design to a few people before we push it live, but since we are pro-active folks we just played a game of rock-paper-scissors and I won. So we just pushed the changes live and hope for the best, including your feedback. :]

So we think the header and footer are a little heavy now, a little too dark and the borders seem a little too thick. Please throw in your two bits.

Thanks a lot!

Solving a known problem is great. Solving a problem nobody even knew they had until they see your solution is ingenious.

I'm playing around with git right now (while I really should be working on this). Besides doing a ton of cool stuff, it helps me with something I never even realized was a major PITA: The lack of cheap branches in svn.

A lot of times I'm working on a new feature for an application (and have a therefore unstable working copy) and suddenly a client / other developer wants me to fix some bug or look into an issue he has. Well normally I've done things as ridiculous as copy & pasting the contents of the files I modified in temporary files, reverted the changes and then checked out the problem only to quickly undo my revert minutes later.

With git this is what I do:

$ git commit -m "Interruptions suck less with git"
$ git checkout master
Switched to branch "master"
$ git checkout -b john.bug
Switched to a new branch "john.bug"
...
$ git checkout newfeature
Switched to branch "newfeature"

And voila I created a completely isolated branch called 'john.bug' based on the current repository master (trunk) branch without having to sacrifice my work in the 'newfeature' branch. Oh and the fact that I can do a million commits in any branch without them ever showing up in the master branch after merging with 'git merge --squash newfeature' is just amazing.

The best way to get started with git is to use it with your current subversion repository. I currently do all my work on the cakephp core using git, allowing me to do big refactorings in several (local) commits without anybody ever seeing them.

If you are new to a programming language, forget about the KISS principle. Experiment with crazy & complex code.

This might not be obvious but a conversation with somebody on #jquery today made this very clear to me. Trying to apply KISS when getting into a new technology is STUPID. Writing the most succinct and simple code is only possible if you know all nuances of what you are working with. Otherwise your simplicity will be based on wrong assumptions and lead to buggy code.

A prime example for PHP developers learning JavaScript:

(JavaScript type juggles empty objects / arrays to true in a boolean context)

Update: If you are wondering how to provide a patch, please follow this guide.

Hey folks,

the CakePHP team is gearing up to finally push out a stable 1.2 release! If you are following the trac timeline you can see that everybody is putting in huge amounts of work to fix bugs and get everything stable.

But in order for this to happen we need your help! Here are a couple things you can help with:

• Submit patches and test cases: If you know how to write test cases, please try to provide test cases and patches for opened bugs that currently have none.
• Provide information on how to replicate bugs: We spend lots of time trying to replicate bugs with little information provided. If you experience any of the listed bugs and are able to replicate them, let us know how!
• Report new bugs: If you know of any bugs currently not listed in trac, please open a new ticket with as much information as possible.
• Help the docs team: The better the docs, the better the framework. Help by submitting content to the CakePHP Book.

This is a great opportunity for everybody out there to get actively involved in open source development and steady contributors will be considered for the core team.

Join us in #cakephp-dv on freenode.net

We just opened a temporary channel called #cakephp-dv on irc.freenode.net for pushing out the 1.2 release (code name "DV"). Everybody willing to help is welcome to join us there, we have plenty of stuff for you to work on!

So lets bake folks!
-- Felix Geisendörfer aka the_undefined