— CakePHP (@cakephp) May 20, 2015
CandyCane – Redmine ticketing system port to CakePHP
Disclaimer: I’ve written this post a few days after I came back from CakeFest 2014. Unfortunately, it is unfinished, and by now I have completely lost hope of ever finishing it. My main excuse is that the first day after CakeFest was my first working day at my new job, which completely and totally consumed me for a few months. And now, it seems like CakeFest 2014 was a few decades ago. Mostly I wanted to do two things here: list all the talks with videos and slides, which has probably been done by other people by now, and tell everyone that this was one of the best events I’ve ever attended. For those who haven’t been to one, I strongly recommend getting a ticket to CakeFest 2015, which will take place end of May in New York, USA. End of Disclaimer.
It’s been a week since I came from Madrid, where I’ve attended CakeFest 2014, a conference dedicated to CakePHP framework. Now that I’ve caught up on sleep, calmed down, and cleared out my mailbox, I have a few minutes to look back at the event and share my thoughts and impressions.
For those of you who are too busy to read the whole thing, here’s the executive summary. I had very high expectations of the conference way before I went. I knew there will be one or two core developers. I knew that there were previous events before. And I do usually expect high quality stuff from the CakePHP community. But as I high as my expectations were, the event went through the roof! It was an absolutely amazing couple of days, where I met a lot of cool people, learned a lot, and had plenty of fun! If you missed this year’s conference and you are involved in any shape or form with CakePHP, make sure you attend the next year one. Start making your arrangements now. You can thank me later.
Now for the long story…
For those of us who have been using PHP since the early version 3 days and such, here is a modern day refresher for PHP tags:
If a file is pure PHP code, it is preferable to omit the PHP closing tag at the end of the file. This prevents accidental whitespace or new lines being added after the PHP closing tag, which may cause unwanted effects because PHP will start output buffering when there is no intention from the programmer to send any output at that point in the script.
And from the comment on the same page:
Since PHP 5.4 the inline echo <?= ?> short tags are always enabled regardless of the short_open_tag (php.ini) setting.
For me personally, closing PHP tags are a part of muscle memory. I’ll have to unlearn that, I guess. And in regards to the inline echo tags, I was under the impression that they are being phased out together with the other short tags (<? … ?>). Apparently, I was wrong. They are here to stay. Which explains why there are in PSR-1, PSR-2, and in CakePHP 3 (which requires PHP 5.4.16 and fully adopts PSR-2) in particular.
Mark Story goes over a few reasons of why CakePHP 3.0 breaks compatibility in this blog post. If you are working with CakePHP or involved in any large system that lives forever, you should read those in detail. Otherwise, here is an overview:
- PHP has changed
- Ideas that didn’t work out so well
- Outdated implementations
- Improve consistency
Also, if you are working with CakePHP, you should attend the CakeFest 2014 event next week in Madrid, Spain.
I am seriously considering going to CakeFest this year. Madrid is not too far away to fly to. The event takes place over the weekend, so work stuff can be easily arranged. And it doesn’t cost too much – a 2-day conference with the 4-star hotel is only $480 USD (early bird prices until July 15th). That alone is a good deal.
But looking at the schedule, it’s even more tempting. The upcoming CakePHP v3 coverage, advances queries, testing, debugging, profiling and optimization, using CakePHP with Composer, Twitter Bootstrap, Travis CI, Selenium, AngularJS and more – these are just some of the subjects that will be covered. And the speakers are on par including core developers, community leaders, and otherwise interesting people.
As some of you might know, I’m a big fan of CakePHP framework. I’ve used it on numerous projects since the beginning of times. I’ve built projects small and large, migrated existing native PHP codebases to CakePHP and even survived a few major CakePHP upgrades – 1.2 to 2.0 comes to mind.
Currently, I am at the start of a couple of projects, which require a bit of the future support. CakePHP 2.x can handle the job now, but I’m looking more into the next 3-5 years. And that’s why I’m looking at CakePHP 3, which is still in the early development stage, with an alpha release coming not too long from now (have a look at the CakePHP 3 roadmap document). Let’s have a look at the high level goals for CakePHP 3:
CakePHP 3.0 represents a significant break in backwards compatibility. One of the largest the project has ever had. We are trying to modify existing methods and classes only where it is required. However, modernizing the ORM has caused a significant ripple effect in other parts of the framework. When making changes we are working towards a few goals:
- Adopt broader PHP community standards. Tools like composer, and PSR-0, PSR-1 have proven to be useful tools for improving interoperability. CakePHP should embrace these community standards where possible.
- Increase modularity. CakePHP has had history of being tightly coupled. We’re trying to reduce coupling and make more standalone libraries. For example the new Collections library, and Events system have no dependencies on the rest of the framework.
- Use PHP 5.4. When we started on CakePHP 3.0, this seemed ambitious. However, with the release of PHP 5.5, and impending release of PHP 5.6, it feels right on target now.
- Modernize and simplify the framework. CakePHP has accumulated numerous features over the years. By removing some features that are better implemented as plugins we make CakePHP simpler and smaller for everyone. Separating features into plugins allows greater community involvement and more rapid iteration on features.
That sounds like a lot. In times like these, migration guides are useful. With no code to migrate, such documents help migrate the knowledge. They usually answer the questions of what changed, what new stuff was added, what was removed, and where, in general, this whole thing is heading. Reading through the migration guide, here’s what I picked up for myself:
- CakePHP 3 supports Composer. This is a very welcome change!
- All of the source code has been reorganized to support PSR-4 autoloading specification. Yes, that means changes namespaces, lots and lots of backslashes, and moving files around.
- ORM has been completely rewritten. I didn’t have much trouble with the old ORM, but I guess there are better ways of doing things. Now, the Model is gone and it has been replaced with Table objects and Entities. These are somewhat logical. Table objects provide access to collections of records, while Entities provide access to individual records. More or less. It’s more flexible than that.
- Immutable configurations for logs and caching. Again, logical. Instead of changing things on the fly, unload one configuration and load another one.
- Named parameters in routing are gone now. Apparently, it was a very complicated piece of code which caused a lot of headaches. I somewhat enjoyed them in a few projects though, but can live without. Not a biggy. Furthermore, all of the routing has been reworked and will be much faster, using scoped routes, which I need to learn more about myself.
- Asset.filter is gone now. This should be handled via a plugin. Have a look at Mark Story’s Asset Compress, for example.
- Scaffolding is removed also.
That’s a pity, actually, as I used it for quick prototyping a lot. There is a possibility of a standalone plugin to provide this functionality.There will be a much more powerful Crud plugin instead.
- A few changes around encryption things. It looks like anyone brave enough to migrate an application from CakePHP 2 to CakePHP 3 will also have to decrypt/encrypt some data as well. Gladly, this is not my case currently.
- FormHelper and HtmlHelper are now much flexible with the HTML that they produce. These are great news indeed, as I’ve been a few times through pulling a CSS framework (like Twitter Bootstrap) over the CakePHP, and while it’s very possible, I had no fun at all.
- I18n is possibly being pushed more towards better support of PHP’s intl extension. (It’s still a maybe, particularly due to intl extension not being installed universally.)
- Tests are pushed more towards PHPUnit compliance.
Overall, that’s a monster of a change and it will take some reading and playing around to get used to the new ways. The earlier, the better, I guess.
Either I missed it entirely, or knew about it and completely forgot, but … CakePHP has an event handling system, complete with events, listeners, priorities and event data support. Awesomeness!
I joined Easy Forex back in 2012 to work on a rather complex project – migrate main website of the company from a really outdated version of DotNetNuke to WordPress. WordPress, even though it is an absolutely amazing platform, turned out not to be the right tool for the job. But we’ve managed to deliver anyway. One of the annoying practices that we had to employ though was a semaphore flag for the database changes – only a single developer could work on the database at any given time. (Again, this wasn’t a WordPress limitation, but rather specifics of our environment at the time). That was the time when we introduced the Semaphore Bull to our development process.
It worked out quite well. But being a soft toy, it got abused a lot along the way. It lost a leg, which was screwed in for a while. Then it nearly lost the whole butt. Then the head. Beaten, barely alive, it still stood its ground and did the job! At some point it got so bad, that we’ve had to place it into the plastic container, where it survived for a few more month.
Today we’ve finalized our migration of the main website from WordPress to CakePHP. The system is so simple now that we don’t even need a database anymore. And with that, the job of the Semaphore Bull ends. Gone, but not forgotten though!
Because of its huge contribution to our work, because it saved us from countless painful hours of resolving SQL conflicts, we’ve decided to create a memorial. Ironically, the memorial to Semaphore Bull is built out Semaphore Bull itself, and the container it lived in. For the future generations to remember the deed, we’ve printed out the snippet of the developer’s manual and embedded it into the memorial together with the dates. Here’s how it looks altogether now.
Thank you, Semaphore Bull. You’ve done us a great service. Rest in peace.
CakePHP framework comes with the default PagesController which is an awesome out of the box way to build a website of mostly static pages. There is one rather annoying limitation though – no search option. If you need a website of mostly static pages with search functionality, you are out of luck. I spent a good chunk of time Googling (searching, eh?) for a solution and even talking to people in #cakephp IRC channel. The best alternatives, it turned out are listed in this StackOverflow answer:
There is no built in way to search static pages as they are just files on disk.
You have three options
- Build a model to hold the data somewhat like a CMS so you can use mysql search.
- google search for sites
- the more hacky approach of reading the contents of all the pages and using preg_match() or similar on the contents to find matches.
The first option is probably the best depending on your use case. The second option is the easiest if its public facing content. The third option is a horrible idea
Since I need the solution for a public facing website, it looks like I’m gonna go with Google Custom Search Engine option.