I just found the official Kohana documentation for upgrading your Kohana applications to the latest version. In fact, these instructions also work for upgrading Kohana v2.3.4 to v2.4 and Kohana v2.x to v3.x.
Upgrading your Kohana Application
Read the source code, note differences in the available methods and properties. For more detailed information, please refer to the change log.
The official Kohana change log may be obtained by using diff, or the Windows equivalent, against the old and new versions. Please enjoy using Kohana!
As one of the lead developers proudly proclaims – “We try to be an advanced framework for developers who know what they are doing when it comes to programming. The framework should not hold the developer’s hand.” He also thinks people complain when new versions are released and says it’s because “they’re stuck in the past” even though he was recently threatening to fork the project because his v2.x branch was in danger of not seeing the light of day due to the new v3.x branch.
My recommendation is that you should just use a single version of Kohana for your application and not worry about the future as it’s uncertain and likely to be a complete waste of effort upgrading.
When I started messing around with Kohana, I was impressed. It met my needs, fitted in with my level of programming knowledge and saved me a lot of time writing my own library of code, or my own framework. However, I think I misunderstood the objectives of the development team.
They seem to want to promote Kohana as a better version of CodeIgniter with loftier goals, mainly that it’s based on PHP v5 and that it’s not guided by an evil corporation. However, mainstream products come with a price tag, you need to sell it. For any code library, that means a slick site, easy to access API and high-quality documentation. CodeIgniter has this, so does CakePHP, Symfony, Zend Framework and other high profile open source libraries such as jQuery and Prototype. If Microsoft has taught programmers anything, it should be that marketing wins, not the quality of code. Most of Microsoft’s software is so-so but the interface is usually very well engineered and the marketing machinery is superb. Together they’ve managed to eliminate many pieces of better software.
Kohana seems to be at a crossroads today. Do they pursue the mainstream; gain wider adoption, more users, more money and become more competitive OR do they stick with their niche product and keep telling people to read the source code? Either way is good for me, I’m sure I’ll stick with the product until it dies, gets forked and renamed. I’ll just stop saying nice things about it and stop doing my bit to try and help out, ease the woes of newbies and tell them to go somewhere else.
I just wish the project had better management at the top and knew where it was going, rather than just ambling along at the will of the lead developers. It almost seems that Kohana is what it is and if it works for you, good. If it doesn’t, there are plenty of other frameworks out there.
A popular question asked all over the internet is – “Which PHP framework should I choose?”. The likely candidates are Kohana, Cake, Zend, CodeIgniter and Symfony. There’s a very simple answer.
It never ceases to amaze me how I can destroy my working setup in a matter of seconds that takes hours to recover from. Take todays example…
I posted a message on the Kohana forums to find out what the Kohana Ninjas use for developing their applications. As I’d been having problems with the ORM objects and my incorrect pluralization when I setup the relationships I wanted to step-through the Kohana internals and discover where I was going wrong.
So after downloading all of the leading PHP IDEs, installing them and failing miserably to get them working with my Kohana application, I turned to the forums. So far I’ve had some great replies and will be working my way through them over the coming weeks. One particular comment struck a chord though, I should be using Subversion.
I agree and I’d been trying to get it going on and off for a while and then I recalled that Dreamweaver CS4 had source control built-in so I used a handy guide to setup Subversion 1.6.3 on my PC. As Jeff’s post said, it took less than 30 minutes to get it going and I even added the repository into my Mozy backup just to make double sure. All worked fine until I shutdown my PC and tried to start CS4 up again, it refused – BANG!!!
CS4 started up and then failed while ‘Initializing Files’. I tried a whole multitude of fixes, including the deletion of files, registry keys. I even downloaded the Microsoft Debugging Tools, used the File Monitoring application from SysInternals and Google’d every step of the way.
In the end I found the clue online – it was Subversion. As this had been my last change I’d suspected this was the culprit, I’d even removed the web site I was working on, as well as stopping the service but to no avail.
Dreamweaver CS4 is only compatible with Subversion 1.4.5 so I had to downgrade my Subversion. I found a copy of the 1.4.5 Windows binary online and installed it. DON’T DO THIS!!!
I ended up over-writing my copy of Subversion and then going through some hoops to dump the repository with the 1.6.3 copy and reload it with the newly installed 1.4.5 copy.
WITH HINDSIGHT – Dump the repository with the 1.6.3 copy you have installed, THEN downgrade it, recreate the repository, setup the users and permissions again and then reload the repository from the dumped files.
And now it all works again – phew! Just another 8 hours wasted of my life.
UPDATE: It seems the problem may be caused by TortoiseSVN and Dreamweaver CS4 as it seems DW will work with a later version of Subversion but only if no other client interacts with the repository … ever. See this Adobe forum posting for more information. To me, it seems highly unstable though and would still recommend downgrading to 1.4.5 until Adobe fix the ‘real’ problem.
My name is Pablo and I’m a Dreamweaver addict.
I’ve worked with Dreamweaver for many years and always developed my PHP applications in it. I find it a nice environment where I can modify my HTML, CSS and write my PHP. I’m used to it and it works for me … mostly.
And then there’s that odd occasion where the PHP code is too complex and peppering the code with var_dumps and echos is too time-consuming to track down some bugs. I then have to shift to an IDE where I can step through the code, adding some watches and breakpoints and really get to the root of my problem.
I’ve reached the same point with my Kohana application. I just can’t understand why one of my related models isn’t accessible. The problem seems to come and go so I must have something wrong somewhere but I want to track it through the internals of Kohana to see where my problem is. And for that I guess I need to step into the ORM::__get method and see why it’s not picking up the related model.
So I posted a message in the forums to find the perfect environment but no replies as yet. I read all the other posts on similar topics but they all talk about editing PHP files, I don’t want a text editor, I want an IDE with debug hooks.
I’ve played with phpDesigner, phpED and Zend Studio already. The first two have no way of understand how to get from a controller to a URL, I just can’t map it, i.e. this file refers to this URL. I also don’t see any method of starting a debugging session by simply entering a URL.
So I figure if I’m going to use an IDE I should also integrate source code management into it so I can track all of my changes. I use XAMPP on Windows as my DEV environment and keep my code in C:\Data\Sites\Project and then upload the final code to the remote PROD server when it’s all done. I’m sure I can improve my environment though and will report back on what I ended up with.
It’s no secret that I’ve been struggling with Kohana over the past few weeks as I’ve been building a new site for a non-profit in Vancouver, BC.
You may want to read my web development background for more information about my development path and how I got to this current project.
Although I’ve been programming in PHP for a decade or so I’ve learned the limitations of the language and started building up a reportoire of code modules and drop-in classes. The first one I wrote was an error handler as v4 was hopeless. My class would intercept the errors, log them, show them in development but not production, and would even dump the source around the problematic line.