[split] Composer?

I think the core should be 100% included (which BTW I currently download via composer). As for some of the other Libraries and Helpers. I think the team should deprecate the ones that just add "busy work" to the project and the team (calendar, cart, ftp, javascript, etc...). Anyone that needs them can download a zip file with the "last supported versions" and drop them in as needed. Having the team continue to support a FTP or calendar library seems like wasted of their limited time.

I agree with this libraries, but I don't think we should erase most libraries. I think we should not transform CodeIgniter into Laravel, nor in a microframework, CodeIgniter should be between this extreme.
You and all the people that think only the core matter should go with a microframework. Why you don't use Slim framework(it has composer as you like, and doesn't have many libraries) or other microframework?

GeorgeD, I think it becomes a balance of what to support as a team moving forward.


A lot of the libraries and helpers where added by Ellis Labs because they built it for a specific need in there paid product Expression Engine. Therefore they continued to update it as THEY needed (which had it's draw backs but no need to open old wounds)

Moving forward does the current team have the resources (all volunteer) to support the  decisions/code made by the previous owner?

I'll pick on Calendars in this example but you could replace that with any PHP file I have listed below.

There are many other PHP libraries out there which do calendars a lot better than CodeIgniter. Back when Ellis Labs sold CodeIgniter as part of Expression Engine they couldn't use a number of these "better" calendar libraries for various reasons (license, ethics, etc...).

As the current CI team migrates the code base forward they need to spend countless hours updating the Calendar code and documentation. This will also slow release time!

Being this is now a completely volunteer effort, resources are limited. I'm not saying drop everything just the code that only a small percent of people actually use or 9 out of 10 times they just download another library for anyway.

Most of these where Expression Engine Specific.
smiley_helper, xml_helper, Ftp (Don't promote this insecure protocol), Javascript (to specific to EE), Trackback, Xmlrpc, Xmlrpcs, Pagination (to specific better libraries), Calendar (to specific better libraries), Cart.php (better libraries), Table.php (to EE specific).

I am sure a few other "fit the bill" but you get the point.

If it's part of the included code the CI team will need to "support it" If the team isn't going to continue to add new features or improve it then they can deprecated it and eventual move it to a external download as "unmanaged code". When we switch to version 4 I think that would be the best time to remove EE specific/legacy code.

Another good example is Email (I'm NOT saying to remove it) This is a ever changing library as security requirements change. 1/2 of the time CI's doesn't work with my clients email system for various reasons. I don't expect the CI team to support every system I need to deal with. I think a better use of there time would be to make it more like a driver. Include the library they have now as a driver option and allow others to "drop-in" a new driver as needed (like GMail which seems to change weekly!!).

For example I downloaded a CodeIgniter wrapper for phpmailer (which seems to work 90% of the time) big thanks to Ivan Tcholakov on that one! but, I made it composer compatible.

I spoke about Monolog in another thread because a lot of people felt CodeIgniter should do this and that with logging. Well's it's source is 242k and around 80+ files. I sure hope it can do all that (some of the handlers need even more files installed to function IIRC). I don't want to see CodeIgniter turn into something like that "Just to Support more feature in logging". I'll be downloading 32mb zipped and 8000 files soon.

Let's remove some EE specific/legacy code and make what we have even better!

Bring back "sparks" then we can plugin CodeIgniter specific code for what we don't have.

Trust me I've had some rough time with CodeIgniter over the years but, when it's all said and done as a whole it's still a great product.
I only want the best for it.

DMyers

https://github.com/ProjectOrangeBox / https://github.com/dmyers2004