Migrating from CodeIgniter

[eluser]WanWizard[/eluser]
Very good remark.

Unfortunately it is the experience in our company that CodeIgniter is "framework B", our productivity when up 40% after switching to a more modern and flexible framework.

[eluser]pettersolberg[/eluser]
So, WanWizard, please spread the word - which framework has your company switched to?

[eluser]jonez[/eluser]

Personally if I want to do/learn something new, I will focus on framework based on node.js(now it is to young maybe in 1-2 years), and not on another framework that do the same thing.

My sentiments exactly. Node.js is stable, check out Express.js for a great MVC framework. The only real annoying part of Node atm is API integrations. Most are still in classic languages so you have to run a second site to handle them. As more and more companies provide JS integrations (Square has a great one) development will shift from the server to the client.

Only JS can provide offline access, with Couch or Hoodie you can replicate an offline client state to the server when connectivity becomes available. You simply can't do things like that with PHP.

Google just announced offline editing for Docs. It begins!

[quote author="WanWizard" date="1386920196"]Very good remark.

Unfortunately it is the experience in our company that CodeIgniter is "framework B", our productivity when up 40% after switching to a more modern and flexible framework.[/quote]
Unless you were one of the few who were working around namespaces I can't imagine a task that would be almost twice as fast in any other framework. What exactly do you find time consuming in CI?

[eluser]Alucemet[/eluser]
Jonez, for me it's all about the productivity, available "plugin type" libraries (from people who don't suck), sophisticated autoloading, built in authentication (which CI has never got around to adding), and in general a more flexible framework. What I like about CI is the routing, and DB usage, and the way MVC is implemented. What I don't like is the license, the way classes are loaded and accessed, the lack of an authentication library, and lack of real support for SSL. It's also impossible to re-route a request after the initial routing, which means unnecessary redirects every once in a while. This is why I made my own framework. I think anybody that uses open source frameworks long enough will at some point decide they can make it better, and personalize it for their own development tastes. This is what I recommend unless creating a framework is beyond a dev's ability, and then I still say they should give it a shot. There is so much to learn when doing this.

I used a lot of CI code when making my framework, but because I could make it my way, and dump a lot of the stuff I considered garbage, my code is way leaner, and I get benchmarks that are slightly faster. Most importantly, I get what I want, and I get it done the way I want it done.

If you've read some of my recent posts, you know that I very much would like Ellislab to change the license and truly give the framework away. In my case I've borrowed code that would require me to comply with the OSL license, and it makes distribution impossible. If Ellislab would change the CI license to MIT or BSD, you may one day see my framework available for distribution. I think you'd see a lot of new frameworks popping up. There would be great benefit to the PHP community by a simple license change.

[eluser]jonez[/eluser]
@Alucemet
Don't get me wrong, it probably sounds like I'm advocating "CI or bust!" but that's not the case. There are plenty of reasons to chose another framework over CI, my main frustration is a certain community member has hoodwinked what seems like a large percentage of the community into believing their code is worthless now. Every project has it's own unique requirements, if CI fits the bill dev's shouldn't avoid CI because of what one person says. His requirements are not theirs.

It's funny you say that, when I found CI I was glad it didn't include an auth library. Authentication is too specific for a general implementation to work. Usually you'll either offer local sign in or 3rd party (Facebook, Google+) so unless your library offers both in one project you'll use it and in another you'll have to work around it. For that reason I prefer nothing by default so I can chose only what I need (similar to your frameworks goal). I wrote a login system/pw reset for CI in a few hours so I never saw it as a big deal.

I'm not sure what you mean about SSL, as long as you form your links like '//www.domain.com/path/to/something' your browser will auto detect http/https. You can link to local or external assets that way and it will include them under whatever protocol you are currently using.

I know most dev's will disagree with me but I've never thought auto-loading was good practice. Giving up performance for being lazy is not my idea of worthwhile tradeoff. For the same reason I don't use ORM's, unless you are writing financial software with abstract user permissions I can't see the performance loss being worth the time savings. I know several dev's who've had to replace ORM's late in a project because of performance. I'm sure it was quick to develop but the queries it spit out for nested relationships were awful. I'm sure they will get better as time goes on, but they will never match the performance of a finely tuned hand written query- something I think every PHP dev should be able to do.

What I've always loved most about CI was just how easy it is to overload. Core extensions are a breeze, it was very easy to mold CI into what I want. It covers the basics and let's me decide how to fill in the rest. It's a shame you can't release your update I'd love to see it. Someday I'd love to strip down CI even further and use it as a bridge for Node apps.

Just like you I have my own "hack pack" of core extensions for CI. I'm hoping to release it over the holidays on GitHub. It's based off CI3 and has a few useful features that almost any app could use. In CI3 it was easy to swap suffixes so I chose to suffix controllers as "Name_controller.php" which prevents namespace issues for models/library's. It also has methods for page templating, database logging of PHP errors, auto minify/combine/caching of system wide and controller level assets, extra validation options, and a bunch of extra helpers (array/file/string utility methods).

In v3 they went out of their way to rework the routing class to make it easier to swap suffixes by splitting up the default logic into more overloadable methods. Most frameworks follow their own path and try to pigeon hole you into it. CI is actively working to make it easier for you to change the default behavior if you want to!

I hear a lot of dev's mention flexibility as a reason they left CI. I've always wondered exactly what they meant? I've always thought of a framework as scaffolding. I want it to hold me (gently) while I paint the house. If I have to work around it it's not doing it's job. The less I see it the better! Other than the "$this->model" pattern CI imposes I don't notice it's there most of the time.

[eluser]ivantcholakov[/eluser]
@jonez

Just like you I have my own “hack pack” of core extensions for CI. I’m hoping to release it over the holidays on GitHub.

Can you give a link to your GitHub account? I would like to have a look at your work when you publish it.

[eluser]Alucemet[/eluser]
Jonez, I just want to comment:

I still maintain and actively develop CI applications. It's not so bad, but without all of my "hacks" (which would take countless hours to code from scratch), CI is a little weak. Maybe the same could be said for any framework.

Maybe you're right about the Auth. I really don't like some of the popular CI auth libraries, and if one of them were the official auth of CI, I may have chosen another framework. I do like my own auth library, so maybe it's just my desire for that to be built in to the framework, or something else that is usable, that makes me consider it a requirement. I can't remember the last project I did that didn't have some sort of need for Auth. Yes, the auth requirements change from project to project, but there ought to be at least some driver based auth solution. CI would be better if it had "standard auth", "facebook auth", "etc", "etc" auth drivers. This is a huge thing. Maybe me and you are smart enough to pull off a good auth library, but the majority of devs simply have no idea where to get started with this. They find 10+ auth solutions as they search the internet for one, and then they choose the wrong one because of X, Y, or Z.

The SSL issue is primarily a need for the URL helper and FTP library to do some of the following things:

1) Create secure links even when the current page is not secure.
2) Create standard links when the current page is secure.
3) Create links that are secure if the server has SSL enabled, but not secure if it doesn't.
4) All of the above applies to anchors too, and site links.
5) FTP library currently offers no secure connection, and there are no other options. I end up using phpseclib.

Autoloading; I just want to type as little as possible. For the fraction of a fraction of a second that autoloading might cost me, I willing to make that sacrifice so that my fingers still work in 10 years. Also, being able to use the PSR-0 or PSR-4 autoloading is pretty cool. No more $this->load->library('X'); This doesn't seem like a big deal, but as applications reach the point of being considered huge, it's easy to forget about loading. I want to forget about loading!

Yes, overloading in CI is very simple, unless you want to make a change to the DB classes, then you're kinda screwed. I've done it, and done it the right way, but man what a waste of time.

Flexibility... I mentioned it because in my own framework I've managed to use dependency injection for everything, yet at the same time can access everything using static classes. It's like 2 for the price of one, and everything is autoloaded. I don't know what other people are talking about when they mention flexibility, but that's my flexibility. I've also set up my config class to use "dot" style syntax like Laravel. This is really nice compared to CI's flat config array. Yes, you can nest arrays, but retrieving is more complex. I don't know if there is anything big in the way of flexibility, but all the little things add up.

So, in conclusion, I think I'd rather not use anybody else's framework again. Having my own and being able to do whatever I want with it is priceless. I still use CI daily, but my "employer" has already said that we are never upgrading to 3.0 because of the license. To me the license is a bigger issue than anything else, and it's one of the things that makes 3.0 useless to me. I can never count on benefiting from CI 3.X+, unless I want to break the rules of the license. I feel ripped off. I spent years getting into CI, making it work for me, and then hit in the face with a license that sucks. Now they just want to give it away? Heck, if they'd just change the license to MIT or BSD, then they'd really be giving it away. I could only expect that greed has some bearing on their decision not to do so. Do they just want to have their name attached to CI and all derivative works for eternity?

[eluser]jonez[/eluser]
[quote author="Alucemet" date="1387059194"]To me the license is a bigger issue than anything else, and it's one of the things that makes 3.0 useless to me. I can never count on benefiting from CI 3.X+, unless I want to break the rules of the license. I feel ripped off. I spent years getting into CI, making it work for me, and then hit in the face with a license that sucks. Now they just want to give it away? Heck, if they'd just change the license to MIT or BSD, then they'd really be giving it away. I could only expect that greed has some bearing on their decision not to do so. Do they just want to have their name attached to CI and all derivative works for eternity?[/quote]
As far as I understand OSL only applies to the "system" folder and the "application" folder is under AFL. Doesn't that mean that as long as you don't distribute edited core files (core extensions should be fine) you're in the clear?

[eluser]Alucemet[/eluser]
[quote author="jonez" date="1387060085"]
As far as I understand OSL only applies to the "system" folder and the "application" folder is under AFL. Doesn't that mean that as long as you don't distribute edited core files (core extensions should be fine) you're in the clear?[/quote]

No. You'd have to go back and read some very long forum threads regarding the subject. Basically, the worst part of it is that simple deployment to your hosting environment constitutes distribution, which means that you have to make the system dir source code available to site visitors. For as long as I've been a dev it has been standard practice to hide as much as possible about the application and server details, simply because revealing these things can lead to easier hacking of the site or server. By making the source code available, there's no way to hide these things. Anyone that knows you are using CI can also know you are running the app on PHP. So, with my main job, the boss took a look at the license and said no effing way. We have been using CI for his rather large website for 3 years. We've got nearly a gig of source code, so switching frameworks isn't even an option. If he didn't care about staying legal we would just not tell anyone, but this is a guy who has like a half dozen attorneys look at everything he does. So yes, this is a big deal, and it sucks. I'm just glad that I'm not the one that suggested CI to him. He actually made that decision. But, if you are a freelancer, how do you suggest CI to a client knowing about the security issues involved with revealing source code and server details. The simple answer is that you can't, we'll at least not without having them sign a waiver, and even then they could sue you if you had not completely disclosed the issue. To me the CI 3.x branch is only suitable for personal websites, and even then it's still pretty bogus to make the source code available. This is liken to a "powered by full retard" link at the bottom of each page.

[eluser]jonez[/eluser]
If you aren't directly editing core files the system source is the same as what's publicly available anyway? According to the license page providing the source only applies to derivatives of the original work. If you modify core files you have to open source your core modifications (only), which makes sense if you think about it. You never have to give out the source to your application. I made a mistake earlier the app folder is not under AFL the config folder is.

http://rosenlaw.com/OSL3.0-explained.htm

Only the Source Code of the Original Work or the Source Code of a modified (altered, etc.) Derivative Work must be disclosed.

I don't see a problem with a notice that a site is powered by CI, you don't have to list the version. The only hack I've seen was an SQL injection on a old classic ASP site that was inherited. All they did was add links to every page to mess with Google. If you use a payment gateway and prevent SQL injections you aren't a priority. If bot's can't inject link spam into your pages and human's can't steal financial info there's better targets out there. Even CSRF is highly unlikely.