You apparently did not read my last post at all. These are recommendations, and most developers do not pay attention to them anyway. Like I said in my analogy, if the traffic rules such as cars should stop behind the parking line at red light is not a requirement, but a recommendation, you should expect 100-1000x more traffic accidents. CI supporting PHP 5.2 is a huge drawback, very irresponsible and incompetent.
Also CodeIgniter supporting PHP 5.2 means that it is not utilizing some cutting edge new features such as namespace, late static binding, anonymous functions. Also it cannot use more secure version of functions/libraries that only exist in PHP 5.3+. This is bad from an educative point of view too, as developers using CodeIgniter will not be exposed to the best practices of PHP development. It may be easy and light-weight, but in the end you get incompetent programmers and applications.
Unless I’m missing something I see they have a composer file but CI isn’t using any /libs besides their own that are tightly coupled with the framework. Unlike a project such as Laravel that uses a wide array of external projects and doesn’t really attempt to reinvent the wheel or rely on old, antiquated namespaceless code.
CI is an all in one yes, and namespaces were as of 5.3 so they don’t use them, however, in CI3 settings you can point to the composer autoload. Also you can use the CI built in or load separate similar to Laravel. Using a framework does not necessarily bind you to using all of its parts. Laravel is separating part after part, and has now moved its HTML stuff to a separate group away from the core which is REST focused. So you can utilize those parts, but there are also issues with relying on numerous third-party stuff, that is to say that it “could” be an issue, should one of them make a drastic change which affects your code, or alternatively they could drop entire sections or stop supporting that component. Personally I use Laravel for new web applications, Symfony for long term support applications, and CodeIgniter for simple websites. Each framework has good and bad, and has best use cases.
Well, I’d hazard a guess that the CI developers had a different perspective to yours.
First, I suspect they didn’t need to use all those wizzy new (as yet unproven) features in more recent versions of PHP in order to make their code work. Some of us have been writing quite sophisticated systems for many years in older versions of PHP and while the new features are certainly nice, they haven’t really been holding the professionals back from doing excellent work.
Second, since some web hosts don’t support every version of PHP they probably made the same business decision that lots of other product suppliers have made (Wordpress comes to mind, and they’re rather large and popular as I recall) to allow their users time to catch up with the latest versions of PHP on their server. Motivated and educated developers will probably want to use the latest versions of PHP anyway. Cutting out those who are forced to stay with earlier versions of PHP because they have to wait for their IT departments or web hosts to upgrade their server packages is counter productive. Among other things it forces developers in that position to continue using the original version of CI for new projects when they’d prefer to move on to the more recent code base. And frankly, given the security upgrades and bug fixes added in CI 3, I think it’s more responsible to give the maximum number of developers access to the new, safer code base than to force them to use a code base that’s in need to improvement.
Plus it extends the time that the owners of CI need to support the old code base, which prevents them from applying resources to supporting and improving the new version, and that’s a critical business decision.
Every language has a range of programmers. Some are uneducated and/or stupid, and some are smart and professional. It’s not the job of a framework (or a language provider for that matter) to force programmers to write great code. Nor is it possible. Good programmers are good in almost any language, and bad programmers are bad in any language.
The CI developers are far from incompetent as anyone who’s used the framework knows. And as I’ve pointed out above, there are several ways of looking at the issue of being “responsible” in this kind of situation.
These are not ‘unproven new features’, their usefulness has been proven a long time ago. Symfony proves it, Zend 2 proves it, CakePHP proves it, many modern PHP framework prove it. If you understand why the well-respected long-term CI ex-developer Phil Sturgeon quit CI team, you will understand how CI sticking with PHP 5.2 is holding developers back. Whether or not some legacy coders like it, features such as namespace and late static binding have become the new standards for modern PHP application development. If they prefer writing legacy code, it’s another thing, but I am talking about modern application here.
Sure some webhosts do not provide every version of PHP, but as far as I know every popular webhost does make at least PHP 5.3 its default version. For legacy projects hosted on PHP 5.2 servers, they are probably using CI2 or even CI1 and will not be upgraded to using CI3 anyway. For new projects, they will not have to be stuck with PHP 5.2 servers since it’s no longer the default options for webhosts. It’s just in no way that PHP 5.2 support is necessary for a new major version of a framework released in 2015, whatever way you look at it.
Wrong again, framework may not have a direct responsibility of forcing programmers to write better code, but a good framework will always at least show how this can be done by using itself as examples. CI, on the other hand, is doing the opposite. By not utilizing the coding standards for PHP development, it’s essentially telling programmers that you are fine writing bad and obsolete code, and security is not important. This is beyond irresponsible and unreasonable. To think that CI claims that it ‘recommends’ PHP 5.4+, it sure does not show how and why it recommends this in action.
I agree that good programmers are good in almost any language, and bad programmers are bad in any language statement, but one quality for a good programmer is to pick the best tool for his job. Otherwise why dont we all program in Assembly Language? A good programmer should be good in writing assembly code as well, right? A good carpenter can drive in a nail with either a rock or a hammer, but how many carpenters do you see bashing stuff with rocks? Consequently, this is not an excuse for an incompetent framework/API, especially with so many better alternatives available.
Several people have posted this snippet from the CI Git repository regarding Server Requirements:
PHP version 5.4 or newer is recommended.
It should work on 5.2.4 as well, but we strongly advise you NOT to run such old versions of PHP, because of potential security and performance issues, as well as missing features.
To me that doesn’t say they are SUPPORTING 5.2, but rather that it “will probably work, but maybe not” so use of 5.4 is recommended.
Just looking for clarification. I for one am excited that CI has found a new home, and it seems like there is quite a bit more active development.
With all that said, my thoughts on this original topic are the only wrong framework, would be one that doesn’t do what you need it to. If you site has all the features you would like it to, then you must have used the right framework. When you can no longer do something (or find a glaring security issue) then you should reconsider your choice and possibly re-write (beside a re-write from time to time is usually a VERY good thing).
Namespaces were introduced in 5.3. Therefore, ci will not be using namespaces for its own dedicated code. Which is a mistake if your writing and/or revamping a framework in this day and age. It just screams laziness and unwillingness to progress which is not a framework I myself would get behind. If Drupal can do it so can ci and any project for that matter. Anything less is lack of leadership, knowledge, and/or passion to do things right. I have no respect for a developer who doesn’t recognize the importance of things such as namespaces in building what they refer to as a modern php framework. You may be able to sell that shit to some people but not me. I work on my fare share of older software and it’s fine not using newer things or spending a bunch of money to update something that works well enlighten but might not employ the latest and greatest tech but don’t call it modern, that’s it.
Wow, looks like this thread spurred a lot of discussion.
I suppose the best course of action would be to continue using CI, and re-write only if necessary (due to scaling or performance issues, etc). I suppose I’d need a lot of traffic to even reach that state first though. How difficult would it be to re-write a CI application in, say, Laravel or CakePHP or Symfony?
Rewriting to any other framework is in all probability a large feat. Learning Laravel is your best bet, since its an easier version of Symfony and Laravel 4 will look relatively familiar to CodeIgniter in some ways. Laravel 5 is a different folder structure so make sense of 4 then build in 5. At least thats my suggestion I’m sure there are many who will disagree.
Please note that CodeIgniter started way back in “February 28, 2006” and since then many large projects have adopted the framework.
CI is playing catch-up to the latest fads (i.e. Namespaces) but first and foremost respects their users and have not issued upgrades that will break existing systems. Their upgrades documentation is comprehensive:
I would like to know why you believe namespacing is a fad other than your coveted CodeIgnitor doesn't use it.
I’m equally interested in why a feature that has been available for 5 years is considered “latest”.
I have had further thoughts on using namespaces with the latest CodeIgniter RC3 and standby my previous thoughts:
CI is playing catch-up to the latest fads (i.e. Namespaces) but first and foremost they respect their users and have not issued upgrades that will break existing systems…**
Also and far more importantly if CodeIgniter uses a PHP version with namespaces then this feature can be incorporated into the the latest CodeIgniter RC3:
To test this assumption I have added the following function to the standard CI Welcome screen, called the function in the Welcome Class and displayed namespace->result(); in the Welcome.php view:
function nameTest()
{
$feline = new foo\Cat;
$feline = $feline::says();
$canine = new bar\Dog;
$canine = $canine::says();
$animate = new animate\Animal;
$animate = $animate::breathes();
$namespaces = highlight_file('namespaces.php', true);
$welcome = highlight_file('Welcome.php', true);
$result = <<< TMP
<div style="border: solid 1px #ccc; padding: 1em; background-color:#ddd;">
<h3>
<a href="http://php.net/manual/en/language.namespaces.php">
Nicked from - PHP Manual:
</a>
</h3>
<pre style="font-weight: 700;">
Be warned that it is not trivial to convert a project to use namespaces.
If you add the same namespace to the top of all your files, your application will break.
All objects in the global namespace, such as ArrayObject, must have a backslash (\) prepend to them.
If you use get_class() and instanceof, you will have to make adjustments here to.
If you have an autoloader, you will need to change its behavior.
It can be done, but subtle errors can creep in and are tedious to rectify.
</pre>
</div>
<dl style="background-color: #eee; color: #333; padding: 1em;">
<dt>Output from namespaces.php</dt>
<dd> $feline </dd>
<dd> $canine </dd>
<dd> $animate </dd>
</dl>
<h2> Source: namespaces.php </h3>
$namespaces
<h2> Source: Welcome.php </h3>
$welcome
TMP;
return $result;
}//
An online version can be found here: (no download, only a web-page
PHP 5.3 introduced namespace and I think that many programmers just had to use this latest fad. Fortunately namespace has now been tried, tested, proven, matured and has now become a trend,
Namespace makes Plug & Play libraries easier to update.
Please do not forget that all PHP versions are server side scripting languages - users submit a query, which is processed and a web-page script is rendered to a browser.
Ahh, here we are, doing it again. Talking about the old and always present issue of backwards compatibility with shared/ duplicated software, because that is what this discussion can be boiled down to.
IMHO, a framework is supposed to lead by example. It must do things “as right as possible”, because it forms the foundation for your “modern” application. Does anyone disagree with that?
If you do, then you must also agree, supporting code still built to work for an old PHP version, like PHP5.2, is not doing things “as right as possible” and it certainly isn’t leading by example. In my mind, it is supporting and demonstrating… laziness. The wrong kind of laziness. Laziness to refactor the code to meet modern coding standards. It is simply wrong and as such, this alone is a clear reason why you shouldn’t build your site on Codeigniter, if you want a modern up-to-date application built on it. They aren’t being leaders, like they should be.
Now that being said, if you have no intention of also sharing your work (paid or free, a “one-off code base” as Anthony Ferrara called it), or you know it is simply a better fit to your or your team’s programming style, then it could be a great tool for you. You have to decide that. As others have pointed out, CI has been around for a while and is tried and tested, which means you can count on it. All that can also weigh in on a decision to use it and it would be perfectly fine to make the decision to use CI on that basis too.
Still, because they aren’t being the leaders they should be, IMHO, I’d still be wary of the decision to use it, because, one day they might just change things to finally break BC (when it is too late) and you’ll end up doing a lot of work, which you could have done up front, with possibly a little more effort and with a framework that is being a proper leader now.
