I would like to know about the compatibility between upcoming versions of KO3. I have heard that once 3.1 comes in, it won't be easy to simply upgrade to it from kohana 3.0 (Wordpress upgrade is pretty swift from 2 to version 3)
If I create my project in KO3 (currently using 3.0.6.2), what are the chances that my project will be easily upgradable to 3.1 or above versions without breaking anything ?
Please answer if you are a real pro on KO3 or part of the development team.. This is important.
Major versions (eg: 3.0 to 3.1) may change the API. Currently, the biggest API change will be splitting the Request class into Request and Response, as well as changes to Request that allow external routing. This also implies that the Remote class will be significantly modified to removed completely in favor of external requests and responses.
You can keep track of the changes scheduled for 3.1 by following the 3.1 roadmap.
I'd just like to point out that wordpress is an entirely different system, it's basically an application written on their own framework whereas kohana is just the framework and you supply the application.
If the wordpress core framework changes then they also change their application to account for those modifications. Sometimes plugins aren't compatible across upgrades so the plugin author has to release an update which makes it compatible. All of this is hidden from the front end users, they don't need to be aware of how it works in order to use it.
Kohana on the other hand has no gui or front end, you're getting nitty gritty with the code. If an interface changes then you'll have to adapt your implementation to suit, there's no way around that.
And as antpaw said, unit tests are always useful for making sure things work as expected! For more info see the unittest repo
it highly depends on the features your have used. give it a try and watch your logs or even better: you run unittests. http://github.com/kohana/core/compare/3.1...master if i picked the right repository. this will help you to see the difference betwenn ko3.1 and ko3.0.7
Related
I've been using Wordpress for the past 4 years for developing small and medium websites. Now I have an enterprise project and I'm considering using Phalcon PHP framework.
My enterprise project will be handling a large amount of users and will be publishing articles with images. This is why I still want to use some sort of CMS.
I think framework like Phalcon is great for service and business layers, but it lacks the GUI / services found in various CMS's like Wordpress. I know Phalcon Eye is in development, but it's in very early development stage (I think).
Can Phalcon MVC be used alongside any CMS? If yes, wouldn't the speed of Phalcon bee compromised by much slower CMS? (And what CMS is recommended?)
Update
The first version of my enterprise project is currently using WP for handling user registration, page / template handling, articles etc. But that's just a small part of the solution. All other code is custom and I've realized that should use a solid framework like Phalcon, Laravel, Sympfony etc.
Update 2
What if I use a framework like Phalcon for my custom code, present data and form handling. Then I build a Wordpress service that will retrieve articles from WP DB's. That way I would not need to use wordpress for presentation, but I can use WP for handling articles, images and maybe even users. Bad idea?
You can use Yona CMS (built with Phalcon), whose code is hosted on GitHub, with modular structure and great speed of Phalcon Framework.
There are few large projects working on this CMS.
Using an existing CMS for the admin and writing a phalcon frontend for it is a very intriguing idea I have pondered on and off over the years. (I haven't done it yet because I have a custom CMS to maintain, which I am not sure how to replace with WP or joomla etc)
I think it would be possible to have a site that is much faster than a WP site by using phalcon, but I think the tradeoff is no WP plugins will work, and the more PHP you use to make them work, the more you erode the benefit of phalcon and you might have well just used WordPress.
I have never used Phalcon 2.0 with Zephir, so can't comment on that.
----- extra comment stuff----
I see a comment about updating phalcon, which I thought I would address you can update phalcon with 3 or 4 commands (or a single shell script), and it only takes affect when you restart your webserver. Apache can do a graceful restart which shouldn't affect any of your users.
Whether phalcon is harder to update than a framework written in PHP file comes down to your update method. Updating phalcon with git is far quicker, easier and safer than FTPing individual files for example. Naturally using git for both I don't see much of a difference, just as long as the webserver is clever enough to not open the php file just as you are copying it of course...
re: speed - phalcon is very fast (upto 10x faster than zend framework v1 IMO, YMMV), it might not be as fast as node depending on what you are doing, but if your PHP is far better than your JS and your Server Admin has never used node - like me then the difference in speed it didn't look like it was worth the extra effort.
I think as per your requirement you should go for a CMS, Phalcon does not provide you the functionalists of a CMS, it has it's own advantages. If you are using wordpress and not satisfied with its performance then there are many other popular CMS solutions available in PHP like Joomla or Drupal, you can look into that also, and choose the best that fits in your requirements.
Only a CMS based on phalcon, like phalconeye, may get the benefits of phalcon's speed.
If you want speed, avoid Drupal, that not where it is the better.
I am in the process of planning a custom web application which will be sold (not SaaS) and so will be required to be installed on different servers. Do you think it would be a bad/good idea to go with Symfony2 or Zend Framework.
I have to choose 1 and can't go with any other framework as I only have extensive knowledge with both of these. Despite my experience with Symfony2, I would still appreciate another opinion.
My main concerns are ease of install on servers and source code protection. Sadly, it would seem ZF already has this going for it in that you don't need 5.3 like Symfony2, and we have Zend Guard.
Any advice is welcome! I am looking to nurture and grow this app and I really want to be sure the first step is the right one.
The Symfony2 download page still says:
Be warned that Symfony 2.0 is not
stable yet; use it with caution
(current version is Beta 1).
So I would wait just a but for Symfony2.
I'm not sure what you mean by source code protection but there is no point in encoding any part of any of the two frameworks since they are both open source (and you should see if their licenses actually do permit that!).
Zend Framework 2 is still in the oven and for the looks of it, Symfony2 will be out of beta way before ZF2. If you can't wait, then use the one that you are most comfortable with. Otherwise, wait for Symfony2 to come out of beta and then wait a little bit more until they iron out it's bugs.
Now, about bundling the framework in your application, you are probably going to need to write an installer of sorts. You could first look at the "sandbox" version of Symfony to see how they did that. It's basically an unzip-it-and-it-works kind of install. No need to set anything up. That could give you some pointers.
Whatever you do, you'll need to write a minimum specs script that users can download and run to check whether their system has everything ready to run your app (check configs, php modules, etc, etc). See SlideShowPro Director for an example of such scripts.
Subjective answer: I'd go with ZF because that's what I know better, but having said that, performance wise I've had better results with Symfony. Apparently ZF2 will have see huge speed improvements.
I'm looking for inputs into how I can manage the upgrade process itself of a homegrown php/mysql application. Meaning, if we have a 'stable' version of our php/mysql application working on our production server, and we now want to upgrade it to the next version that we've worked on - how do we go about doing that elegantly? What practices should I be implementing?
What I was planning to do was just to
Ask the developers to stop
checking in code after all stability
/ functionality tests are done
Take the application offline*** (Q: how should I prevent ppl for logging in / accessing public pages? Best practices for that?) but allow access to developers through a secret login page / url
Log onto the production server and check out the latest version
locally***
Have the developers/testers test their code through the secret access page / url***
After that is done, we restore access to all by removing this secret access page / url, removing the site-under-maintenance page and restoring access to all.
***NOTE: A simple way of doing this would be to rename /myapp/ to /myapp.old/ and put the new application version into /myapp.new/ Developers would access /myapp.new/, test to their satisfaction and then after we're done, we would rename this back to /myapp/ (this is just the basic idea)
This is a huge question, and in many ways it will depend on your specific project. But here are some practices to think about:
Put lots of comments in your code. Things that seem perfectly logical now will be confusing when you go back to make changes in a year or two.
Maintain a development version of the site with its own database. You can test changes to the site before publishing to your production site.
Use a PHP framework (such as CakePHP, CodeIgniter, etc). If you are far along on your project, this may be difficult to do. But it will help you write code in a way that is easy to update, and will include a lot of stable, mature functions that you won't have to write from scratch. Using one of these frameworks (and following its best practices) is probably the best way for a beginner to learn to think about writing modular code that's easy to update. This will also encourage you to develop your database in a way that is consistent with the structure of your site.
Write tests (the framework should help you with this) to programatically check your code for errors.
Use a version control system such as Subversion or Git. This allows you to track changes to the site, and easily roll back changes if/when you realize they are buggy.
Comprehensive unit test coverage would be very helpful, as would small, highly cohesive, low-coupled classes. In addition to the unit tests, good coverage from an integration level would be valuable.
How long do you normally test an update for Zend Framework before pushing it out into a productions project. We can break this question up into minor updates 1.6.0 -> 1.6.1 or maybe a major update 1.6.2 -> 1.7.0. Obviously you don't release it if it add bugs to your code.
Also, as with most other server software updates normally people have a window of time they like to wait and watch the community before even attempting an update on a development environment. How long do you even wait to start the process?
It seems like the best method would be to have a comprehensive set of tests that exercised all the functionality in your application. With a good method for testing it seems like you could push it into production pretty quickly.
Another simple thing you can do to help you make your decision would be to simply do a diff against the repository to see what changes where applied to any modules that you use. If there where no changes, then upgrading shouldn't make any difference. If something underwent a major re-write, you would probably want to investigate a lot deeper.
I'll often jump through update releases (1.7.1 -> 1.7.2) without much hesitation. When the minors roll in, it's another bag of tricks though. For example, there were a lot of changes with Zend's file upload elements, and Zend form in between 1.5, 1.6 and 1.7.
Whether or not I even move on a new release depends on what's been done. Checking the update lists provided is pretty important for deciding on whether or not to go.
As for timing, it varies. There's no set in stone process.
Finding "what breaks" is quickly accomplished with the unit tests. But, who really has a full set of unit tests for their application, right? ;)
Using unit testing will help catch some of the deltas. Zend Framework now comes with Zend_Test to make testing applications a bit easier. I updgrade between projects (so new projects that are coming up will get the latest version).
I am deciding on a framework to try out for PHP. I have narrowed it down to CakePHP and CodeIgniter. I have a couple of questions for any of you who have used or are familiar with both:
I like the fact that CakePHP keeps most of the code outside of the webroot by default. Especially since I may end up using a single framework install for multiple apps. I see CodeIgniter will do that too, but you have to configure it and move some stuff around. Is that workaround secure and reliable, or is it an afterthought hack?
Which (if not both) is easier to upgrade, and maintain over the long term? As new versions of the framework (and PHP itself) come out. I don't want to find my stuff either breaking, or becoming outdated.
Edit:
This is a very old post, but I thought I would update it with what I finally ended up doing, which was to use Kohana.
You should try both frameworks for a week or so, building something trivial (like a blog or wiki) in both, and see which you prefer using. Whatever makes the most sense to you will probably sustain you the longest through upgrades an deprecations.
CakePHP is in a bit of a volatile state right now, still unearthing bugs while pushing to release version 1.2 (which is not backward compatible). I wouldn't suggest building a critical application with it if you need something rock solid right now. If you can wait a month or two for things to settle, then it's probably a moot point.
To address your concerns:
1) Cake and CI do it the same way (iirc). They are equally secure, reliable, and hackish on this front.
2) Everything changes. If you need concrete, perpetual assurance of stability and backward compatibility, roll your own framework. There's not that much to it, and you're guaranteed that nothing changes unless you want it to.
I have deployed multiple applications on CakePHP and it's been a very, very, nice experience. You can't go wrong either way, as both are solid.
is a non-issue.
CodeIgniter has a sponsor behind it, so it's definately the one to choose for the long term. Also, it's faster.
This is a non issue. The app has a couple of lines which says where the core and your application code lies. You just need to change those lines.
You can never anticipate this one.
The state of PHP is a wildcard here. One app (CI) is built to be compatible with PHP4 the other requires PHP5. If you need to deal with the possibilty of a web host only supporting older versions of PHP then you need to go with CO.
Another issue is unit testing. If you require your framework to ship with tests, then CI is not the way to go.
Personally, I feel comfortable with CI because of the corporate backing. The company behind CI is making real profit from their efforts. Though CI is free, their paid product (ExpressionEngine) will eventually live on CI. The same could be said of the Zend Framework and even the birth of Rails (originally built for Basecamp.)
A minor correction to an above comment: both are compatible with PHP4, not just CI. Also, I don't think that having a sponsor makes CI and more or less upgradable or maintainable. Money doesn't solve those problems in the least.
I use CakePHP for a variety of applications and I've been happy with it thus far. 1.2 is a huge improvement over 1.1, and while the library source may change from RC3 to Final, I don't think any code you write will become obsolete. My only niggle is that the Manual isn't as comprehensive as it should be (in my opinion), and I end up in the API quite a bit. The trade-off there is that I now understand the code behind the scenes very well. In any case, I highly recommend it.
On the other hand, I've never played around with CI, so I can't recommend CakePHP over CI. I would take each for a spin and see which one grabs you. Whichever one you choose, study the hell out of its conventions and capabilities. When I started with Cake, I unwittingly wrote a bunch of code to do something Cake did "automagically" by having me set one variable in the controller.
CodeIgniter is very flexible as you would see once you try it. So how your application would be maintainable would fall you your hands.
I have also deployed multiple applications using the same installation. I usually create 2 applications for CMS projects (one for admin, one for the front-end).
To address both of your questions from a CodeIgniter perspective (I don't use Cake):
1) CodeIgniter doesn't keep itself outside the webroot by default, but it can do so with some very simple changes. The first part of my CI tutorial series explains how to do so, along with a walk through of the setup of a new CI instance. Once finished the only part of CI that needs to be in the webroot is a small index.php bootstrap file.
2) I've got an application which I originally developed in CI 1.4.x and I've sucessfully migrated to 1.5.x then 1.6.x. With each new release the CI dev's make available detailed upgrade instructions laying out what needs to be replaced so upgrades are fairly easy.
Jim.