I have one old CodeIgniter 2 project.
How do I update/upgrade it to CodeIgniter version 4 without any code or function change?
Is it possible?
There is no point in upgrading from 2 to 3 since at the end of the day you won't be able to smoothly upgrade from 3 to 4.
It's a poor time and labour cost calculation advising you to go through two (2 -> 3 -> 4) framework versions if you can efficiently move straight/directly to the latest version. Upgrading a framework alone consumes time, labour and comes with its own set of bugs.
Just come to terms with your current situation that a complete project rewrite directly to CodeIgniter 4 may be necessary. Nonetheless, you may be able to save some parts of your old project.
Upgrading from 3.x to 4.x
CodeIgniter 4 is a rewrite of the framework and is not backwards
compatible. It is more appropriate to think of converting your app,
rather than upgrading it. Once you have done that, upgrading from one
version of CodeIgniter 4 to the next will be straightforward.
There is no 12-step checklist for upgrading. Instead, start with a
copy of CodeIgniter 4 in a new project folder, however you wish to
install and use
it,
and then convert and integrate your app components.
CodeIgniter 3 is in maintenance mode, receiving mostly just security updates.
There is no upgrade path to go from version 3 to 4, especially if you do not want to do any code or function changes, but I disagree that there is no point to upgrading to version 3. Actually, you will be unable to upgrade to even CI 3 without code or function changes. That ruled out, meaning you HAVE to change code or functions, the following might help.
Before you cut your losses and redevelop as suggested, using the below work from Kenji a shot might help. But to do so, you need to upgrade to CI 3 first. Kenji is a very accomplished CI developer with lots of contributions to the framework, including a PHP Unit wrapper for CI. You could follow the guides and upgrade to version 3, and then try to use this: https://github.com/kenjis/ci3-to-4-upgrade-helper/tree/1.x/src/CI3Compatible
The steps to upgrade from version 2 to version 3 may be a big job as well, the biggest one being the initial step - not saying it is going to be easy, but if you try this, and it is not working for you, redeveloping might be your last resort.
For completeness, CI 3.1.13 has been released, and CI is thus now PHP 8.1.3 compatible. The upgrade process from 3.1.11 that I had in my projects to 3.1.13 was literally as easy as 1-2-3.
Related
I am currently working on a code already made laravel 5.4 and I wonder if it is mandatory to update to the latest version and is it advisable to continue with this version(5.4) there. I really just need only basic stuff on laravel to do my project.
No, it is not required to upgrade the version but it is better if you can keep up, because each version might contain security patches alongside good features and improvements to the existing ones.
Laravel provides very simple upgrade guides that you can follow and if you upgrade them regularly there are almost zero breaking changes.
If you don't like doing it manually then there is a very good service called Laravel Shift which for a couple of bucks can help you with the upgrade.
As a developer I have to make a upfront commitment for 5 years support for a new Laravel project.
My question is - whether I should use Laravel's Long Term Support (LTS) version only?
What could be the potential pitfalls with regards to the support commitment if I use the latest Laravel 5.3 instead of the LTS version?
Any information regarding points to be considered like pros/cons with regards to the support commitment for 5 years when using the latest Laravel version versus using LTS version would help me make a correct decision.
To keep your application framework-agnostic, or to make it easier to swap out or not depend on the framework, the approach which worked the best for me was to isolate my business logic in separate libraries.
I handle those libraries using GITLab server, and I expose them to my composer via satis.
If you use Laravel's routing to map request to a controller, then you can use your library inside that controller and perform the rest of the work.
Constructing your app this way lets you:
isolate business logic
rely on framework to provide correct input since you can use middleware to filter out requests that don't fit.
have it easier when it comes to swapping the framework out
you're using composer, which lets you easily manage library and framework version(s)
This way, you can upgrade your app bit by bit as time goes by, you don't have to rely on having only one framework version forever, without being able to use newer releases.
Good luck with your project!
I made a website and I spend about 2 month on it, I made it by Laravel 4.2 and now I see the new version of Laravel released (Version 5).
My Questions:
Should I change and work with Laravel 5?
What happens if I don't change to Laravel 5? Does Laravel 4.2 Works or it has security issue?
Why does Taylor change the coding style of Laravel? (I know Laravel 4 had lot of diffrent with Laravel 3, And this is not good for Developers.)
Edit:
I learned Laravel in about 2 weeks, How much time do I need to learn or migrate to Laravel 5?
To answer question 2 - Laravel 4 will continue to work. Taylor provides back-ports for security issues - so it will continue to remain a viable framework.
In saying that - the upgrade guide from 4.2 to 5.0 shows you how to upgrade. Most websites can be upgraded in less than 4 hours (from reading various forum posts) - so you could just upgrade and take advantage of the many awesome new features.
Regarding your first and third question, you have to deside for yourself.
That being said, in order to make a fact-based judgement, I would advise you this:
Check out the free Laracasts serie introducing you to Laravel 5
Listen to the Laravel podcast episodes 18-21 where Taylor Explains new features and why he changes things like the file structure
Read the release notes (as The Shift Exchange noted) to find out new and useful functionality in Laravel 5
No need, the difference between Laravel 4 and 5 is mainly structurally, both depend on third party libraries via composer.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 7 years ago.
Improve this question
I'm just starting on a software as a service project using CakePHP. I can see that version 3 is still in beta and I can see this project taking 3-6 months.
My question is should I start with version 2 or version 3 beta with the latter probably reaching a stable release.
I don't want to learn version 2 and then version 3 has a fair few changes.
Update: Go for CakePHP 3.0 now if you start a new project. CakePHP 3 is no longer in RC or beta state so it can be used without any doubts now.
The question is likely to get closed because it is opinionated, I'm undecided to put up a close vote for that reason myself, however...
Cake3 is in fact OK to be used for a project that is going to take 3-6 month - that is my opinion. But you'll have to expect a few API changes until then. I would not sacrifice the more modern architecture of Cake3 and language features, mostly the namespaces and closures for using an old version that doesn't support them just because Cake3 has not yet reached 3.0 (without the RC).
I've started using Cake myself when 1.3 was in alpha and the transition from 1.2 to 1.3 was pretty smooth. I've had to adept to the API changes during the ongoing development of 1.3 but this was not a game breaker and I never had to spend much time for it.
Same story with Cake3. We are using 2.x and started a new project using Cake3 and don't have much trouble with it. So far it just works fine and the occasional adoptions to the API changes are no game breaker as it was before.
You can see that Cake3 is mostly feature complete by now.
https://github.com/cakephp/cakephp/wiki/3.0-Roadmap
If you go further you'll notice that 3.1 is going to raise the minimum php version to 5.5.
https://github.com/cakephp/cakephp/wiki/3.1-Roadmap
This is because 5.4 is going to reach it's end of support. So there is no reason to support it any more. Based on this you can make your guess when 3.0 will be released: Likely before 5.4 is officially deprecated.
The one and only disadvantage of Cake3 right now might be the availability of plugins. But there are already lots of plugins that are upgraded to 3.0 and even new plugins for 3.0.
Update:
Absolutely 100% go with CakePHP 3.x. There should no longer be any debate as Cake 3 is now up and running and no longer in beta or RC...etc.
Original Answer:
If you're starting now (Jan '15), I see no point in learning CakePHP 2.x. Why go through the trouble, when by the time your project is complete, you'll already have out-of-date code (I know "out-of-date" might be a bit extreme, but...).
Not only that, but CakePHP2 and CakePHP3 are worlds different with a fairly sizable learning curve. I cannot imagine, at this point learning one language only to have to re-learn the entire thing in less than a year.
IF CakePHP 3 RC wasn't a viable choice (ie projects crashed all the time, or had issues left and right), and you're on a deadline, then you'd have no choice anyway. But CakePHP 3 RC seems to be running fine and is already being used on live projects.
The no-brain answer IMO: Go with CakePHP 3. I certainly would if I were in your shoes.
At this point (19th Jan 2014) , it is safe to go with cakephp 2 . cakephp 3 is not a stable release and there is no clear schedule date for stable release yet. I dont think it will be a breeze to update it later to a stable version if you develop in its current version . You might end up changing lot of code.
Hi I am working with cakephp since 1 year and I found that you can use cakephp 2.x because it is stable version don't need to extra configuration but in cakphp 3 is unstable version you install the composer in cakephp 3 & the structure of cakephp 3 is totally different form cakephp2 such as cakephp2 root folder is APP but cakphp 3 there is no app folder its contains src, bin, vendor etc
I found too many problems width cakephp 3.1 :
In appController, the function beforeFilter() is not working well as it was in cakephp 2.x, when I tape return false It should return a blank page but now It returns everything like if this function beforeFilter() in the appController is not controling nothing.
In Model, the functions beforeFilter(), beforeSave() and beforeDelete() have been replaced with too many functions in cakephp 3.1 but in reality those functions are not realy usefull, for the simple reason these functions don't work as we expected them to work, there is no centralization of these functions, you can say those new functions are not working at all.
The system of prefix and how we can contrôl access to some users to access to Admin/ prefix for example only from the controller and all the liberty this great functions of cakephp 2.x can give us now all this is gone with cakephp 3.1 and there are some bad restrictions you should respect.
cakephp 3.1 error managing are not helping you at all to found the source of the problem, it's like you're working with no compiler you found the source of the problem yourself, an if it's an very big project I garenty for you that you can failed at 60%....
too many reasons push you to wait for an other stable version of cakephp 3.x to start using this technologie.
Joomla 1.5 will reach the end of its life in a short term and many site are being upgrade to a 1.7 or 2.5 version. We are trying to figure out how we can upgrade our sites. Unfortunately the developers of Joomla, who are doing a great job, haven't kept backwards compatibility high on their requirementslist.
We know there are many resources describing how to migrate a Joomla site to version X from version 1.5. But in our company we have about 120 Joomla sites. With all the migration steps that have to be done to the templates, custom written code and the third party modules we use this would be a hell of a job to migrate. So we are looking into methods and techniques that would make our (upgrade) job easier.
I can't imagine we are the only one with this problem so I am looking for more information on migrating these sites on a large scale. We can't be the only one who are struggling with this.
To give some detail, for upgrading of the minor versions we used the Vendor branches technique which worked awesome. In short, in our SVN repository we have a folder containing the current Joomla release. In the same repository we have a folder containing our own Joomla version with some custom code adjustments. Every project is based on that custom version. With the use of version branching we could easily update all our projects to the latest Joomla version.
For the major upgrade this technique won't be suitable. For instance we expect that some projects won't be upgraded to the new Joomla version for compability issues.
A way to solve this for the 2.5 branch could be to create two new folders with the 2.5 release of Joomla and our own customized 2.5 version. Each migrated project then would be branched of the 2.5 customized version. The migration process would be tedious and for sure be a manual drill.
We are afraid that we have to do this for every major release of Joomla so this won't be a real solution.
A solution we are thinking of is using phar and composer to create the project. If we succesfully can create a joomla phar as library and put custom development in an other phar, upgrading should be as simple as replacing the phar. Third party modules should be put into a phar archive also for easy updating. If modules don't support this, we are going to phar it ourself.
Of course we know that Joomla has a new, integrated update mechanism. We are looking into this mechanism but doubt we can use it since we have some custom patches to core code or module functionality.
To summarize this post, we have two challenges we'd love to get some feedback of.
How would you sggest upgrading 120+ sites to the latest release of Joomla
How do you manage Joomla updates if you have a large number of Joomla sites to maintain
The bad news is that there is no automated upgrade path from Joomla 1.5 to 2.5, as the changes are so drastic that they are almost like night and day. The template changes are such that you may have to rewrite them from scratch. Do not forget that 2.5 does a number of things differently too so you may also face a learning curve.
My suggestion would be to have a tiered migration plan and only migrate the sites that you need to or can justify the costs of the migration as the components, modules and plugins you use.
When doing so you need to watch the release schedule which provides a Long Term Release every 18 months each of which will most probably break backward compatibility from the previous versions, so you will end up with sites at 1.5, 2.5, 3.x etc
I believe that phar can be used in order to distribute a new upgraded version - but it will not help you in the upgrade process itself.
My (painful) experience with a migration from 1.5 to 1.7 taught me that not only the code changes were dramatic but also the DB changes (structure!), ACL implementation etc etc. The template will probably be the least of your problems.
My question back to you is, why do you want to upgrade ALL the websites ? if a specific website needs tools/plugins that are available only on higher versions of Joomla then I guess it's a good enough reason. But to upgrade all the websites will be, like you anticipate, a project from hell...