Thread

Why I use Codeigniter:
Because it has small footprint, Good on shared hosting, It is not bloated like others.

1) Love the fact it is basic/small to get us started.. (Sometime we may need extra - Remember not always {in that case we will work around to get the addon} - its gives me goodnight sleep knowing, I do not have what I do not need)

2) Features: I understand i will get alot comments on this:
Why do i need latest features - while i have a working framework/site (I am happy as long as its keep working)
We need to understand: latest features and bleeding edges are not always great (old is Gold)

Finally, What i wish EllisLab need/could do for us:
1) keep CI as is(small, lightweight) But keep a constant update/fix

2) No need for updating php version (5.2 default), But make-sure its keep on working on future php updates (shared hosting updates their php versions - makesure Ci keeps on working)

3) Give us an release date for CI 3.0 (and release it asap - keep rolling updates)

Above all - Keep CI alive….  Thank you Nerf for your hard work!

            ———EllisLab <—- thank you for not showing you care about people who love this
—————Those who are developer/self looking for bleeding edges or latest php version.. move on to other or roll your own (dont make/post comments - Respect other who trying to keep this going (why don’t you help CI to move further… help develop?)  WordPress still uses php 5.2.

———————-Sorry, if i pushed anyone button——————-

Keeping things the same isn’t going to change the PHP community’s perception, which is that CI is dead.

Keeping things the same isn’t going to change the PHP community’s perception, which is that CI is dead.

By the same token you could argue PHP is dead, all the bleeding edge frameworks aren’t based on it.

I think the best outcome would be for a few CI dev’s to fork or continue development of the dev branch. The only annoyance I have with CI could be seen as a benefit to some; the lack of a proper (imo) default projects structure. If HMVC was baked into the core a lot of possibilities would open up that I’d be willing to contribute to.

Keeping things the same isn’t going to change the PHP community’s perception, which is that CI is dead.

By the same token you could argue PHP is dead, all the bleeding edge frameworks aren’t based on it.

I think the best outcome would be for a few CI dev’s to fork or continue development of the dev branch. The only annoyance I have with CI could be seen as a benefit to some; the lack of a proper (imo) default projects structure. If HMVC was baked into the core a lot of possibilities would open up that I’d be willing to contribute to.

I was talking about the PHP community, and your suggestion is to more or less keep things the same. So again, how is that going to change the attitude of the PHP community? Take a look at the popular PHP frameworks, and you’ll see similarities, but CI is the oddball. It’s the black sheep. It’s the one nobody likes because it’s not cool to like CI anymore. Just mention CI in a forum and you’ll get lots of feedback on how CI is your grandma’s framework. It sucks. It’s outdated. It’s from 10 years ago. You’re not going to change perception by making minor changes. One of my biggest complaints is the license, but if you really want to know what people think about CI, just ask them in another forum. You’ll get plenty of feedback.

Who really cares what the PHP community thinks? I don’t base my solution on what’s popular at the time.

We don’t need another Larvel, Phalcon, Symphony, we already have those. Why make CI something it’s not? CI has strengths that can be built upon. The reality is no framework lasts forever and it’s a waste of time to try to make one framework the be-all-end-all of development. Tailored solutions are always better, while it’s useful keep it going, when it’s not retire it. I don’t think we’ve seen CI’s EOL yet.

Who really cares what the PHP community thinks? I don’t base my solution on what’s popular at the time.

We don’t need another Larvel, Phalcon, Symphony, we already have those. Why make CI something it’s not? CI has strengths that can be built upon. The reality is no framework lasts forever and it’s a waste of time to try to make one framework the be-all-end-all of development. Tailored solutions are always better, while it’s useful keep it going, when it’s not retire it. I don’t think we’ve seen CI’s EOL yet.

The name of this thread is “How do we get CodeIgniter back to the PHP framework of choice?”. The name of this thread is not “Why should we care about what other people think of CI?”.

I addressed that in my first post in this thread. I don’t know why this topic needs to be rehashed on the forums over and over again. If CI doesn’t meet your needs use another framework. I’m willing to donate time/code as long as we can all agree on a direction to take the framework. A rewrite is pointless and will alienate what users we do have left.

If the issue is missing features, let’s add them. All I ever hear is “PHP 5.6 BLARTY BLAR BLAR” which is not constructive in the slightest. Perhaps a better post would be a poll on where you’d like to see CI go moving forward. Take the best ideas and have community members send PR’s.

@jonez

Let us put time factor in our considerations. I hope, CodeIgniter 3 would be released this year, and this release is not something radical. Of course it will be supported for some time. This means that those who like CI as it is would be happy for about 5 years. You are in a safe place, don’t worry.

What beyond that?

The question “How do we get CodeIgniter back to the PHP framework of choice?” is interesting for me, mainly because that this framework reached very narrow consensus what to provide and what is the right way. The framework is not just code, it is practice too, it unifies practices to make them efficient. I tried hard to like other frameworks, but without success.

I am absolutely sure, that a potential future owner asks himself/herself this question. There is a real interest on this, because money is to be invested. Without defining an idea for competition and following it in a long term what is the sense of owner change? - None.

There is a pure social issue too. How valuable is CodeIgniter to your CV now? Not very much. People with talent and capabilities are not interested.

If CodeIgniter wants to be the best (IMO there still are chances, window of opportunity is closing however) it needs a complete rewrite, carefully, with balancing of interests, and learning from the mistakes of others. This is a middle-term effort, about 2-3 years, the end-user will adapt for about two more years. I agree with skunkbad, that starting a complete rewrite is not that scary. The consensus about the features and practices is the difficult thing.

How many Hours.. do you guys think it will take to Re-Write CI to set PHP 5.5 as default
Keeping in mind: no additional feature needed
                    and get rid of backward…compatibility

Let me see if i can pay some one to do that for you all…...  S***w ELLISLAB you S**K!

One thing you are all forgetting is that CI is the backbone of Expression Engine so no way will they break backwards compatibility.

I’m fairly sure they use their own internally maintained version of CI for EE and not what’s in their public github repo. I remember reading something about that years ago when Ellislabs stopped development of CI and turned it over to “the community” or “community reactor” team to work on it.

Ok, kool I was un-aware of that.

@ivantcholakov

It’s not that I’m against a rewrite, I just don’t see the point in calling it Code Igniter if it went that direction. It’s an interesting subject. If you could build your dream framework, what features would it have and why? Here’s a list off the top of my head;

1) Fast, minimalistic design. All core functionality easily extendable.

2) HMVC by default. This is the only opinionated design choice I’d enforce.

3) Better client side asset management. This follows up #2, with a standard site layout you can make some interesting optimizations and improvements. Automatic client side includes, merging, minification, caching, etc. This can be extended further to support responsive CSS by using a file naming convention. Ex: ‘style.css’ for 600px+, ‘style-small.css’ for <600px, ‘style-large.css’ for 1600px+. Server generates includes and stacks them for you based off type/name. Design mobile first then use subsequent styles to translate mobile to desktop.

4) Better config system. I like how CI defines configs but I don’t like how you access them. I wish we could access them by group/setting using dot notation, ex: ‘system.session.driver’ => ‘native’.

5) Composer support to replace the 3rd party folder. If we support package management the core should only contain what’s necessary to boot an example page and nothing more. The ‘less is more’ approach is one of my favourite design choices of CI and Node frameworks.

6) Better routing for SEO. I’m a huge fan of class definitions building routes, I do not want to define every single route like you do in some other frameworks. One suggestion is to use camel case for method names and convert those to dash separated paths for routes. Ex: ‘myController->myMethod’ mounts to ‘/my-controller/my-method/’.

7) DB support through a common API using parametrized queries. No ORM or active record. Active record is a great concept for basic queries but falls apart quickly with more advanced logic. For that reason I wouldn’t bother with it. Most developers I know either want to write their own statements or use an ORM (which should be available as a separate package).

8) View system improvements, use Mustache or ideally support multiple parsers via packages.

9) Better client side tools. The web today is all about perceived performance and most frameworks lack any direction on how to minimize waiting by fully utilizing the client. They either provide nothing out of the box or you have Ember/Angular that do everything for you. This subject can be quite opinionated on best practices and needs vary wildly from project to project. At minimum a base set of tools should be provided to reduce the boiler plate code most sites/apps need. My suggestion would be RequireJS modules with system/module inheritance and support for client side templating.

In addition to this I like what you’ve done with your project. Koa does this with Koala, provide two installers one for just the framework and another with common packages built in. This satisfies both groups needs and keeps the core lean.

@jonez

If you could build your dream framework, what features would it have and why?

This is a very hard question to be answered in details. I’ll try to answer not quite soon.

I think this is a great discussion thread and hope that someone is listening….

I have spent more that 15 years developing in Visual Basic, Delphi, Java, C++, PHP…and have developed in Spring Framework for Java, CakePHP, and CI.  Just want to set the stage.

I think we should tweak the question and state it more like “How do we get codeigniter back the the best php framework?”.  I don’t want the most popular, like Laravel, I want a better CI.  To start my rant on this issue I do have to say that lack of movement is the direct opposite of it.  I think the #1 thing that is killing CI is no activity.  Who wants to be involved in something that Ellislabs is barely keeping up and is actively looking for a new maintainer.  Lets get this moving, nobody wants to sit on a bus that isn’t moving…it could be the best bus in the world but if it can’t get you anywhere, well, got to get off the bus and onto another one.

1. Keep updating CI.
2. Evolve with the times and embrace the new features that are needed. (Seems like 3.0 is a good start if it can get out of the terminal)
3. Continue to be a framework that is true to it’s form a small, quick, framework.  The great thing about this I believe is that you can build in the complexity on top of CI that people might be looking for.  You want ORM add a module, you want other more complicated stuff add a module.
4. Keep CI a framework and embrace other extensions like Symfony has to offer.  Similar to Laravel, but better, it is CI. 

I know there are a lot of technical items on the list that everyone is posting.  And I agree with them.  But most of all you have to have the living, breathing, CI back before any of that matters.  Until that happens this project will continue to be viewed like it is snuffed out….

Thanks and I hope all this results some life giving Oxygen to CI…

@jonez

https://github.com/ziadoz/awesome-php

See “Dependency Injection” section.

There are several implementations and the last one, Acclimate, tries to abstract them. Wow. Carefully.

I realized that your minimalistic vision is more adequate. Even it would require a lot of work for CodeIgniter team.

Feature-greedy people like me should create/search generic projects.

The question “How do we get CodeIgniter back to the PHP framework of choice?” is premature. Let us see how CodeIgniter 3 would change the landscape, what other people will do. This takes a year, I think.