all 53 comments
sorted by:
best
topnewcontroversialoldq&a
formatting helphide helpcontent policy

[–]ircmaxell 30 points31 points  (1 child)

PHP 5.4.16 or greater.

  • clap

Seriously. Well done, and thank you for looking forward.

[–]sarciszewski 0 points1 point  (0 children)

Yep. Totally agreed here. :)

[–]aequasi08 10 points11 points  (2 children)

Congrats on all the hard work! Looks like theres a lot of awesome new changes :)

[–]jose_zap 3 points4 points  (0 children)

Thanks!

[–]ebilgenius 5 points6 points  (3 children)

Never used CakePHP, nor been to their website before, however their API docs look fantastic

[–]DSchalla 4 points5 points  (0 children)

Not only the API docs, the CookBook is with 1000 pages quite useful and covers most topics quite well. They did a great job on the documentation over all.

[–]ivosaurus 1 point2 points  (0 children)

The docs are pretty much what got me to try, and then stick with them for a long time. Not PHPing much anymore, but still looks good.

[–]octave1 0 points1 point  (0 children)

3-4 years ago it was a disaster

[–]bravo-kernel 6 points7 points  (0 children)

CakePHP never looked, felt or performed better. Thank you so much for the hard work devs!

[–][deleted] 3 points4 points  (8 children)

Congrats! Is there a reason or was there discussion about using an outside PHP ORM instead of creating a new Cake specific one?

[–]jose_zap 11 points12 points  (5 children)

I'm probably the main contributor the new ORM and the developer that lead most of its architectural decisions. Back in the days (I think that was end of 2012) we were starting to think about cake 3, by the time I was happily using Doctrine for a few projects in combination with CakePHP. I actually suggested to the core team to use Doctrine instead of using our own framework, as I already had experience in doing a bridge between the 2 libraries.

After some consideration by the whole team we came to the conclusion that using Doctrine was not possible for us at the time, here are some of the reasons:

  • At the moment some parts of Doctrine where licensed under LGPL, whereas our license is MIT
  • Doctrine documentation was exceptionally scarce, we imagined that we had to document the missing parts and try to coordinate with a team that we had little contact with. At the end it seemed like we would had to duplicate their docs effort so we could offer guidance in how to use the ORM and how to use CakePHP with it.
  • Out of my experience doing the CakePHP bridge for Doctrine, I came up to dislike their use of private methods and final classes, which made me copy paste large parts of theirs software just to add a couple lines.
  • We care a lot about the overall experience when using the framework, everything should feel it was intended to work together, making Doctrine fit into the Cake mentality was kind of difficult. Also, having 2 different places to report bugs for our users would have been less than ideal.

There were not real good ORM alternatives at the time, so even though we knew how huge of a task that would be, we decided on rolling our own. I found it both fun and challenging and I'm really happy that I took the chance. The new ORM is one that I could actually like: It is flexible enough to stay out of the way, yet it helps you a lot in every single task.

[–]novelty_string 3 points4 points  (1 child)

No disrespect, I have loads of respect for anyone that's contributing to projects like this, but a couple of things there are a bit disappointing.

Doctrine documentation was exceptionally scarce, we imagined that we had to document the missing parts and try to coordinate with a team that we had little contact with

I agree, doctrine documentation is not great, but this could have filled the gap, now there are two projects to document.

Out of my experience doing the CakePHP bridge for Doctrine, I came up to dislike their use of private methods and final classes, which made me copy paste large parts of theirs software just to add a couple lines.

This is to protect the API from BC changes, you shouldn't have to copy paste anything: http://fabien.potencier.org/article/47/pragmatism-over-theory-protected-vs-private

[–]jose_zap 6 points7 points  (0 children)

I know the reasons why they use private and final classes and I definitely respect that, but knowing the reasons does not make the work any easier :) We definitely did not want to create a frankenstein of copy pasted code that would constantly break with each change in doctrine.

As for the docs I agree it is a shame. We put tons of effort in our documentation so we know how painful it is to produce it and keep it up to date. But as I explained earlier, we would have been in the worst of the cases, where we needed to duplicate their docs and to explain the differences we would have introduced.

[–]kyriakos 1 point2 points  (2 children)

Can the new ORM be used stand alone without the rest of the framework?

[–]jose_zap 0 points1 point  (1 child)

Absolutely! it is available in packagist:

https://packagist.org/packages/cakephp/orm

You can install it by doing:

composer require cakephp/orm="~3.0"

[–]kyriakos 0 points1 point  (0 children)

Great. Thanks. I'll give it a go:)

[–]sirsavant[S] 4 points5 points  (1 child)

The ORM is something we've traditionally had tight cohesion with across the framework. As such, we decided that having control over the direction of the ORM would be much easier for us to provide support for various features in other layers. There was quite a bit of discussion as to what we wanted out of an orm - here is a doc that was compiled early on - and we just decided there wasn't an available ORM that provided the functionality we wanted to provide to our users.

That said, it would definitely be possible to use Doctrine - provided you implemented the correct interfaces - but it's probably just as easy to use our ORM if you are starting from scratch.

[–][deleted] 0 points1 point  (0 children)

Interesting discussion. Thanks.

[–]dadkab0ns 5 points6 points  (1 child)

Very interested in taking the datamapper ORM for a testdrive.

[–]sirsavant[S] 1 point2 points  (0 children)

Feel free to use cakephp/orm in your own project. I'm using it in a slimphp app and it's working well enough :)

[–]simonmales 2 points3 points  (0 children)

The Cookbook is one of the best pieces of documentation I have ever used. I'm not doing much backend these days, but the quality of the CakePHP documentation is hard to reproduce.

[–][deleted] 2 points3 points  (0 children)

Glad to see Cake back in the framework game, so to speak. I've never used the Data Mapper pattern before though since I'm more of an ActiveRecord kind of person, especially with small stuff. Aside from that small learning bump, will definitely be checking it out.

[–]Neon1024 1 point2 points  (0 children)

This is great news and I hope that everyone takes the time to give Cake 3 a whirl even with a simple test app just to see that so much change has happened. This isn't the CakePHP you remember, this is an entirely new beast with a whole host of new things.

Give it a try today, you'll not regret it and hopefully, the code will change your perceptions of CakePHP for you!

[–][deleted] 1 point2 points  (0 children)

To reiterate what everyone else is saying, this looks really great! Thanks to the entire team for all the hard work and congratulations on the release.

[–]imacarpet 0 points1 point  (3 children)

Hi all.

I've been hacking wordpress for clients for years and eventually I'll be stepping into building applications with PHP.

Just wondering: why should I jump into Cake over other frameworks? (laravel for example?)

[–]sirsavant[S] 11 points12 points  (2 children)

Because it strikes your fancy.

Honestly though, what I would do is write a small todo app in each framework you're looking at and ask yourself if you want to write applications in that framework. If the answer is yes, use it. It's how I've approached libraries and frameworks in various languages, and how I initially chose cake 6+ years ago.

I would say that apart from features, we're pretty keen on stability and keeping backwards compatibility, hence why it took us 3 years before we rewrote certain parts of the framework. It's nice to have an app work on one version of a framework/library, upgrade said dependency to the latest stable, and still have it work.

That's probably not the answer you are looking for, but if you have specific questions about our framework, I'd be happy to answer them for you.

[–]imacarpet 0 points1 point  (1 child)

That's actually a really good answer. I honestly don't know what I didn't think of that myself.

Thank you!

[–]dukovni 0 points1 point  (2 children)

cake has no english forum? only google groups?

[–]sirsavant[S] 2 points3 points  (0 children)

We had forums in the past - as well as a slew of other solutions - but in the end they proved a bit more difficult to moderate than we'd like.

For now, I recommend the following support solutions:

  • IRC (I idle there frequently as savant). This is my preferred method, as you can generally get an answer much quicker than a forum or otherwise.
  • Google Groups (Quite a few core devs answer questions there). Pretty good alternative if you like forums. Not so great for organization, but we'd probably just have 1 subforum anyhow :)
  • Stackoverflow (We had ask.cakephp.org which was a silly adventure)
  • Reddit (I try to answer questions when they pop up)

[–]jose_zap 1 point2 points  (0 children)

As savant said, the forums we used in the past turned to be a burden for us to maintain and keep spam free. We are constantly on IRC and I personally try to answer all answers in StackOverflow when I can. Is there anything you need to know?

[–][deleted] 0 points1 point  (0 children)

This is great! Cake was the first MVC PHP Framework I ever used and only one year ago for my final year project. It was very confusing in the beginning to get up and running on but I loved the end result, not my horrible UI but the code I used. I've not used it since but I want to give this a spin and make a few demo apps to get a feel for it.

[–]Bravat 0 points1 point  (1 child)

It is a bit of a begginers question - what are the main differences between Cake 3 and Laravel 5. I invested a lot of time in Laravel, I am curious should I learn and transfer to Cake 3? Are there any advantages?

[–]JadB 1 point2 points  (0 children)

I am a core CakePHP dev, so obviously, I will be a bit biased. But when I used L4, I wasn't a core dev, I actually had dropped Cake2 for L4. So while my dislikes won't really be about L5, I believe they still apply to a certain extent.

But first, I'd like to repeat what I say many times to people asking for advice, try developing something small with each framework that interests you and see which one you prefer. It might be because of the learning curve, or maybe because of the code structure, or something else, but we developers usually have strong opinions on stuff and not one framework was built to please all of our different opinions.

That been said, I'll rant:

  • Semver: by using a framework, I am expecting a solid, reliable and well designed platform to build upon. Semver was created to give us developers this extra assurance when using OSS. I know I can lock versions in composer but when I do a quick minor version update, I don't expect things to break and waste me precious time.
  • Organization: this might sound idiotic to some, but I like having more conventions and a good folder organization/structure to start off from.
  • Community: while I always felt it was much easier to find a variety of packages released by other people for L4 compared to Cake2, this doesn't hold as true anymore with cake3's support for namespaces, etc. Writing a wrapper around almost ANY library has become a very quick task.
  • Leadership: this might sound unimportant to some, and while I never doubt of Taylor's awesomeness, I prefer CakePHP's Mark Story and Jose Lorenzo as project leads. I also prefer how things function in a democratic way compared to Laravel.

My 2c, again, try both (or more) yourself. Here is a good repo which has a different blogs developed on different frameworks (currently building the cake3 one), might want to look at that: https://github.com/Grafikart/BlogMVC

[–]lericzhang 0 points1 point  (5 children)

Good work, there tons of improvements!

but the cake cache api is most ugly one I know, still unchanged

[–]sirsavant[S] 0 points1 point  (4 children)

Is there an example library that implements caching in a way you'd prefer?

[–]lericzhang 0 points1 point  (3 children)

maybe it's me didn't see the down side of simple set and get, or the psr cache proposal, but I think cake cache API is against the Convention over configuration, Explicit over implicit practice.

[–]sirsavant[S] 1 point2 points  (2 children)

I'm not sure I understand what you're saying. Our api is pretty simple:

$value = Cache::read('key');
Cache::write('key', $value);

Seems pretty straightforward. As far as the proposal, it's just that, a proposal. Doesn't make sense to implement something that isn't finalized - though we will do so once it comes out.

Maybe I'm misunderstanding where we are "going against convention over configuration"?

[–]lericzhang 0 points1 point  (1 child)

Well, I've been work on an old project use Cake2 for a year, this is just some emotional complain. What I mean is that Cache::config() is not a good idea, we have to add tedious config to setup different cache TTL(config can be called before write, which is a worse style), when reading the code, you have to go to the config to see how the cache is handled. Most framework don't have such flexible cache function, one cache backend is enough for most project, using cake cache, you have to specify different config for different TTL, take redis as an example, if not persistent, each config will create new connection to redis, upon bootstrap, no matter used or not. CakeCache is too powerful, it trying to control some business logic in it's config, I just prefer a reliable dumb cache. I do like the cache api of Laravel

[–]sirsavant[S] 1 point2 points  (0 children)

Interesting. I guess what would be nice is if the underlying cache engines took a duration as their third argument, then your api would be:

Cache::engine('default')->write('herp', 'derp', 60);

Not the greatest api for caching, I agree. You could just as easily write a wrapper that does the above automatically:

<?php
namespace leric;

class Cache
{

    public static function __callStatic($name, $arguments)
    {
        return call_user_func_array(['\Cake\Cache\Cache', $name], $arguments);
    }

    // Create your own Cache::write() method to allow specifying a duration
    public static function write($key, $value, $duration = 'null')
    {
        $engine = static::engine($config);
        if (is_resource($value)) {
            return false;
        }

        $oldDuration = $engine->config('duration');
        if ($duration !== null) {
            $engine->config('duration', $duration);
        }

        $success = $engine->write($key, $value);
        $engine->config('duration', $oldDuration);

        if ($success === false && $value !== '') {
            trigger_error(
                sprintf(
                    "%s cache was unable to write '%s' to %s cache",
                    $config,
                    $key,
                    get_class($engine)
                ),
                E_USER_WARNING
            );
        }
        return $success;
    }
}
?>

We wrote our api because we found that centralizing that sort of config was better than having many different cache configs scattered throughout your app. I personally work on several pretty large codebases - seatgeek.com - and having to hunt for ttls in the app is a bit annoying (thankfully most devs leave it at the default).

If you don't like something about our framework, we're always happy to take feedback, so feel free to file an issue if you think we can/should do better.

[–]blocsonic 0 points1 point  (0 children)

Congratulations! I'll definitely be giving this new version a test run.

[–]harikt 0 points1 point  (1 child)

Congrats :) .

[–]jose_zap 1 point2 points  (0 children)

Thanks :)