TIP: Use Markdown or, <pre> for multi line code blocks / <code> for inline code.
These forums are read-only and for archival purposes only!
Please join our new forums at discourse.kohanaframework.org
Kohana 3.3.0-RC1 Released
  • After a (too) long delay, we are releasing the first release candidate for Kohana v3.3.0. Please clone it and play around with it and report any major show stopping bugs.

    https://github.com/kohana/kohana/tree/v3.3.0-RC1

    It's only available via git right now.

  • Dont forget to change Kohana::VERSION and Kohana::CODENAME constants ;)

  • Yep, we do that in the release branch before final release. Things that aren't in master don't have real versions yet.

  • There's a changelog somewhere?

    Thanks

  • There's a migration guide in the documentation, and the full changelog is located in redmine

  • Yay! Really pleased to see this - thanks to the core team for all the work that has gone into this. Will try to have a play ASAP.

  • ORM in RC1 is broken guys, don't panic :) Also, my JSend module is for 3.3 - you might like it.

    https://github.com/kemo/kohana-jsend

  • Happy to here new release. Thanks. I retweeted announcement.

  • Here you have added a $allow_external param for Request::factory() and Request::__construct(). But why it was marked as "deprecated in 3.3"?

  • Because it will be removed in 3.4 :)

  • thanks for the work i like kohana :-)

  • Noob git question... I made a zipball from 3.3.0-RC1 but there's no module code. Are we just looking to test the core? Or did I do something wrong?

  • Nice. Gona upgrade my project tommorow!

    @phpguru Probably because those are submodules (subprojects) within git. You can clone with git and fetch them with

      git submodule init
      git submodule update
    

    If you really depend on the zipball. I do not know how to download including submodules nor if github supports this. You can download the zipballs of submodules manually by following the directories on github.

  • Github doesn't support that. Just use git and get out of the stone age :)

  • lol I got out of the stone age 2 days ago :D progit ftw :)

  • Big ups to the core devs and everyone else who has helped out on the project!

    I'll give it a go with one of my larger projects on 3.2

  • What happend to HTTP_Cache? I was looking for the replacement or other way to handle it but It's still in some code though:

    Client.php:

      public function cache(HTTP_Cache $cache = NULL)
    

    Client.php -> execute()

      if (($cache = $this->cache()) instanceof HTTP_Cache)
    
  • You may ignore my post above. I forgot to update my submodules......

  • Here's some (simple) installation instructions

    cd path/to/www
    git clone https://github.com/kohana/kohana.git kohana3
    cd kohana3/
    git checkout v3.3.0-RC1
    git submodule update --init --recursive
    

    On windows use the git bash console.

  • @mauserrifle The HTTP_Cache class was moved to the Cache module, I don't think anything else about it has changed..

  • Also, We've had a decent number of bug reports and fixes already.. Keep them coming - especially the ones with fixes ready to go ;)

  • So far no bugs for me. I'm really happy with the release, especially the psr-0 support. Makes integrating stuff like Doctrine2 much more natural. Big thanks to all the devs involved!

  • File uploads still use the POST method. Kohana v3.3 will have a Request::files() method, but it only be used for sending files over an external request, not for accessing $_FILES

    Was this not included?

  • @MasterGberry The Request::files() support was not merged in the end.

    Personally, I wasn't happy with the implementation due to the differences between initial request vs sub request's. Myself and Sam would like to continue the Request/Response cleanup that's been going on for the last few versions in 3.4, Hopefully we can get it to a better place for that :)

  • Ok. I have a different question :P I don't think Request::files() was meant to do this anyways, but i'd like to see if there is a way to do it. I have one controller for uploading files to the server. I have another controller that is meant to be an API controller. Is it possible to call a sub-request to the uploading controller and pass the $_FILES to it? I know you can transfer the $_POST to it using the method() and post() methods.

  • That's part of the purpose of Request::files() alright, the part that was inconsistent ;)

  • Darn :p Is it possible to be linked to where the changes were created? Would like to see what they were doing. I will probably just wait till 3.4 and maintain 2 copies of the code for now, but wanted to see what it was you were doing and what was inconsistent about it.

  • Can't wait to try 3.3 :) Thank you all.

  • Got a small git question:

    I've set up my project to grab kohana's core and modules as submodule, like explained in the docs.

    Is there an easy way to upgrade all modules to 3.3RC1? Or do I have to check each module which commit has been set for the RC and update each submodule by hand?

  • You have to go in each submodule and pull in the tag.

  • The git submodule foreach <command> command will help you with that :)

  • I grabbed 3.3 from github and when I uploaded it to my remote test server I got the following error. "A valid cookie salt is required. Please set Cookie::$salt." traced from Cookie.php to Request.php to Index.php's Request::factory call (line 155).

    Clearing my browser cookies fixed the problem.

    I did not write any code, it was just the bare bones "hello, world!" that I was testing. It worked fine locally. Could this just have been some freak issue with my browser (chrome on mac)?

  • Did you actually set Cookie::$salt after installing?

  • Nope. At this point I didn't think it mattered considering I'm not using cookies for anything.

  • It's possible kohana does, somewhere; or some module you use.

  • It has something to do with this 'if statement' from Request::factory , on the remote server it was obviously checking as TRUE. I have no idea why it was even looking for a cookie.

    if (($cookie_keys = array_keys($_COOKIE)))
    {
        foreach ($cookie_keys as $key)
        {
            $cookies[$key] = Cookie::get($key);
        }
    }
    

    I'm leaving it alone, since there's no way for me to reproduce the issue.

  • If for some reason a (cookie) session, Kohana or otherwise, has already started, and the salt it not set, you get that error.

    This can happen at the install.php stage too - not too friendly...

  • 3.3 requires PHP 5.3.3 (as defined in the installer). But I get an error using it with PHP 5.3.3-7+squeeze8 on debian.

    ErrorException [ Notice ]: Use of undefined constant DEBUG_BACKTRACE_IGNORE_ARGS - assumed 'DEBUG_BACKTRACE_IGNORE_ARGS'
    

    As far I googled I see DEBUG_BACKTRACE_IGNORE_ARGS was added in 5.3.6.

Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!

In this Discussion